[e2e] Can we revive T/TCP ?

[Armando L. Caro, Jr.]

There is a fourth reason, and I believe it's the main reason T/TCP
support was removed from OSes in the late 90s / early 2000s.

     "An accelerated open is initiated by a client by sending a new
     TCP option, called CC, to the server.  The kernel keeps a
     special cache for each host it communicated with, among others
     containing the value of the last CC option used by the client.
     A new accelerated open is allowed when the CC sent is larger
     than the one in the per-host cache. Thus one can spoof complete
     connections." http://www.ciac.org/ciac/bulletins/i-051.shtml

Armando

Bob Braden wrote:
> At 07:31 PM 12/26/2005 +0100, Michael Welzl wrote:
>> Hi everybody,
>>
>> Here's something that I've had on my mind for quite a while now:
>> I'm wondering why T/TCP ( RFC 1644 ) failed. I mean, nobody seems
>> to use it. I believe someone explained this to me once (perhaps even
>> on this list? but I couldn't find this in the archives...), saying that
>> there
>> were security concerns with it, but I don't remember any other details.
> 
> 
> As the designer of T/TCP, I think I can answer this.  There are three
> reasons, I believe.
> 
> (1) There are very few situations in which single-packet exchanges
>     are possible, so T/TCP is very seldom a significant performance
>     improvement.  But it does have significant complexity.
> 
> (2) Since the server is asked to do a perhaps signficant computation
>     before the 3WHS has completed, it is an open invitation to
>     DoS attacks.  (This would be OK if you could assume that all
>    T/TCP clients were authenticated using IPsec,)
> 
> (3) I have heard rumors that someone has found an error in the
>    specific state transitions, of T/TCP although I have never seen
>    the details.
> 
> Bob Braden