Hamiltonian path as protection against DOS.

[Anne & Lynn Wheeler]

James A. Donald wrote:
> This is obviously the right way to do it - the current
> system has security and checking boundaries in the wrong
> place, as well as being unnecessarily verbose.
> 
> Yet the plan never went anywhere.  What happened?
> 
> There is a gap between communications that are highly
> efficient with TCP, and communications that are highly
> efficient with UDP.  Brief transactions (which must be
> reliable and two way, but are brief, are not efficient
> with either one.
> 
> Indeed, ideally we would have one protocol that rapidly
> starts to approximate TCP behavior with communications
> that for which TCP is good (transferring large files)
> and that approximates UDP with communications for which
> UDP is good.

ref:
http://www.garlic.com/~lynn/aadsm25.htm#17 Hamiltonian path as 
protection against DOS

so much of postings at
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

talks about attempting to standardize xtp as HSP (high-speed protocol) 
in ansi x3s3.3 (and iso chartered organization) ... which was under 
mandate that no standardization work could be done on networking 
protocol that was in violation of the OSI model. turns out xtp/hsp 
violated OSI model in at least three different ways.

xtp implementation was an adjunct to the tcp/ip (typically kernel) 
protocol stack.

I've often commented that both SSL and VPN were successful because they 
added security layer w/o requiring changes to the (kernel) tcp/ip 
protocol stack.

A person that we had worked with quite a bit introduced something (that 
since become to be called VPN) in gateway working group at the '94 san 
jose IETF meeting. my view was that it caused quite a bit of 
consternation in the ipsec crowd ... which were working on 
implementation that had hits to the underlying tcp/ip stack. VPN got a 
lot a lot of immediate uptake because it added security w/o requiring 
hits to the protocol stack in the end-nodes. The ipsec crowd somewhat 
reconciled VPN by starting to call it lightweight ipsec ... and some 
number of others then started called (regular) ipsec, heavyweight ipsec.

original (lightweight ipsec) vpn resulted in some peculiarities .... 
being a countermeasure to internet anarchy by being a boundary router 
between corporate intranets tunneled thru the internet ... w/o requiring 
changes to the end-points. part of the issue was that some of the router 
vendors had sufficient extra processing capacity to do the necessary vpn 
crypto and some didn't. so two months after the san jose ietf meeting 
... you saw some router vendors announcing VPN "products" that were 
actually just add-on of traditional hardware link encryptor boxes.

so i've frequently claimed that ssl got market traction in much the same 
way that vpn got market traction ... by providing a solution that 
avoided hits to the (kernel) tcp/ip protocol stacks (modulo some really 
emergency server fixes at some high-end websites to handle the finwait 
list handling problem).

requiring coordinated (most frequently kernel) tcp/ip protocol stack 
upgrades for all (or majority of the) machines in the world, is a uptake 
inhibitor. ssl wasn't necessarily the optimal networking solution ... 
but it did have the minimum impact on existing deployed infrastructure.

in any case, some of the xtp features are starting to appear in some of 
the real-time streaming extensions ... like one of my favorites ... 
rate-based pacing (which i was forced to implement in high-speed 
backbones in the mid-80s)

many of the online xtp resources have since gone 404 ... however there 
still are a few around
http://usuario.cicese.mx/~aarmenta/frames/redes/xtp/biblio.html
http://www.pcmag.com/encyclopedia_term/0,2542,t=XTP&i=55105,00.asp
http://www.ccii.co.za/products/xtp.html

HTTP1.1 attempted to amortize multiple HTTP interactions across a single 
tcp session (attempting to mitigate the overhead of reliable session 
protocol for something that was frequently very transaction oriented). 
again w/o requiring hits to the underlying protocol stack.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com