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 [EMAIL PROTECTED]
