Hamiltonian path as protection against DOS.
Anne & Lynn Wheeler
lynn at garlic.com
Thu Aug 17 18:28:33 EDT 2006
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.
http://www.garlic.com/~lynn/aadsm25.htm#17 Hamiltonian path as
protection against DOS
so much of postings at
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)
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
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
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
More information about the cryptography