Date: Fri, 4 Oct 2002 14:09:28 -0400 (EDT) From: Garrett Wollman <wollman@lcs.mit.edu> To: John Polstra <jdp@polstra.com> Cc: net@FreeBSD.ORG Subject: Re: Anyone T/TCP? Message-ID: <200210041809.g94I9Sbm015075@khavrinen.lcs.mit.edu> In-Reply-To: <200210041722.g94HMrbG002976@vashon.polstra.com> References: <Pine.BSF.4.21.0210040804420.13322-100000@InterJet.elischer.org> <200210041722.g94HMrbG002976@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 4 Oct 2002 10:22:53 -0700 (PDT), John Polstra <jdp@polstra.com> said: > Accepting incoming T/TCP creates a pretty serious DoS vulnerability, > doesn't it? The very first packet contains the request, which the > server must act upon and reply to without further delay. There is no > 3-way handshake, so a simple attack using spoofed source addresses can > impose a huge load on the victim. None of these assertions are correct. There is a serious vulnerability in T/TCP, but it has to do with how the connection counts are chosen and validated. The initial connection between two hosts always falls back to the three-way handshake; the second and later connections use the accelerated-open feature. However, the connection count used to implement accelerated open can be spoofed with a probability of 0.5 per attempt (or even more easily if the attacker can open a connection to the target beforehand). As a result, T/TCP can only be enabled safely if all the connections to a machine can be authenticated (either embedded in the request or below the transport layer). T/TCP is classified as an Experimental protocol. This means that it is not considered adequate for widespread deployment in the Internet, and implementations are not supposed to enable it without explicit configuration. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210041809.g94I9Sbm015075>