[braden@ISI.EDU: Re: [e2e] Can we revive T/TCP ?]

[Barney Wolff]

Perhaps of some relevance ...
At least two of the negatives apply to any conceivable t/tcp replacement.

----- Forwarded message from Bob Braden <braden at ISI.EDU> -----

X-Sender: braden at boreas.isi.edu (Unverified)
Date: Fri, 24 Mar 2006 11:11:15 -0800
To: Michael Welzl <michael.welzl at uibk.ac.at>
From: Bob Braden <braden at ISI.EDU>
In-Reply-To: <001301c60a4a$9831dc60$0200a8c0 at fun>
Cc: end2end-interest at postel.org
Subject: Re: [e2e] Can we revive T/TCP ?

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
----- End forwarded message -----

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I never met a computer I didn't like.