[e2e] Can we revive T/TCP ?
Armando L. Caro, Jr.
acaro at bbn.com
Fri Mar 24 13:44:25 PST 2006
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
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
>> 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
More information about the end2end-interest