[e2e] Can we revive T/TCP ?

[David Andersen]

On Dec 26, 2005, at 1:31 PM, 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.
>
> So - is that all? If so, I'm wondering what kind of security concerns
> there could be. I can imagine more danger from DDoS floods (the
> first packet already causes the web site request to be processed!),

The packet can be much more easily spoofed.  The TCP three-way  
handshake does a fairly okay job of verifying that the person you're  
talking to is actually in control of the IP address their packets are  
coming from.  (not to be confused with verifying that the person or  
computer at that IP address is the one you think it is).  With T/TCP,  
the world is my DDoS reflector:  An attacker can send a single ~100  
byte packet that requests a ~1500 byte web page, spoofed to come from  
a victim.  The web server will then send 15x more traffic back to the  
victim.  The other DDoS possibilities that you mentioned are also  
very possible.

> and I can imagine that some other concerns would relate to
> authentication - but what about IPSec, then?

Sure, iff you have a key already set up with the person you're  
talking with.

>
> I don't understand why a web browser of someone doing telebanking
> with IPSec (not in tunnel mode) needs to set up a new connection
> whenever a link is clicked. There is a similar problem in the Grid,

It doesn't.  Most links are clicked within the same site, and most  
servers and browsers support persistent connections.  The connection  
is only torn down after an idle period or some maximum number of  
requests.

The case that this doesn't handle is the "I want to send a single  
packet to N different people (N is large) and not have to worry about  
connection setup" - if that's the case, and it really is a single  
packet, then just send it in UDP.  If it really is a reliable,  
congestion-controlled, in-order stream of data, use TCP, and in many  
cases, the connection setup RTT isn't going to completely kill you.

(I'm sure there are scenarios where it will, of course.)  In the Grid  
context, if you're talking about a not-huge set of trusted nodes,  
they can cache those TCP connections for quite a long time.

An interesting example of this is the 'rex' system by Kaminsky and  
Mazieres.  It's a remote execution tool much like ssh, but more  
flexible.  It supports connection caching under the hood, so you  
don't have to pay the setup time if you're using remote command  
execution.  It's worth noting that the major delay they're avoiding  
in the local area is the public key crypto processing time, but in  
the wide-area, both can add significantly to the total delay.

   -Dave