Subject: RE: middleboxes and Re: [tcpm] TCPx2

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 11 May 2006 10:27:43 -0700

Ethan Blanton wrote:
> Caitlin Bestler spake unto us the following wisdom:
> [snip...]
>> For example, this new option could say something as simple as "if we
>> both agree to use the 'extended connection' feature then the first
>> TCP segment we each send will be a special TCP segment that does not
>> contain ULP payload but rather special option negotiations. (That's
>> first TCP segment as sent, obviously the message should document its
>> length in the first two bytes and the receiver should rely upon that
>> length rather than on the actual segmentation).
>> 
>> If both sides do not speak the enhanced version then they simply go
>> straight to the ULP payloads without enhancements.
>> As far as any existing network element is concerned everything looks
>> like a standard TCP connection, albeit one with some new-fangled
>> option that is irrelevant to the network element.
> 
> As long as we're on the "but NATs really do suck!" bandwagon
> ... this isn't really true.  Try inserting some random goop
> between byte 0 and the first data of an HTTP exchange, and
> see how many middle boxes you break -- I bet it will be a nontrivial
> number. 
> 
> Ethan

Good point. The solution I suggested will deal with middleboxes that
snoop up to L4 while pretending to provide an L3 service. But those
that snoop all the way up to L7 are probably hopeless. Fortunately
those tend to be deployed at the server end and are more frequently
updated. The vast hordes of D-Link and Linksys wireless routers found
in millions of homes only cheat up to L4.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm