netdev
[Top] [All Lists]

T/TCP Problems can be solved.

To: Netdev <netdev@xxxxxxxxxxx>
Subject: T/TCP Problems can be solved.
From: Laurence <laudney@xxxxxxxx>
Date: Thu, 14 Feb 2002 11:10:0 +0800
Organization: SJTU
Reply-to: laudney@xxxxxxxx
Sender: owner-netdev@xxxxxxxxxxx
On mlists.linux.kernel, on comp.os.linux.development.sys, I keep hearing from 
people who say T/TCP is fundamentally broken because it has various serious 
flaws:
1. T/TCP guesses an unreasonable window size (4k) for its peer and sends SYN 
with data accordingly.

It can be easily changed into 2*MSS, which is used in standard TCP 
implementations.

2. T/TCP has great potential for DoS attacks.

Because T/TCP sends data along with first SYN, ttcp is more vulnerable to DoS 
attacks. But, if ttcp queues the data only TAO succeeds and discards it if TAO 
fails, this problem can be greatly lessened. Adding some host validation 
methods may fully solve this problem.

3. T/TCP has great potential for r-* services attacks.

TCP also has it! It's always recommended that r-* be turned off. And r-* is 
being replaced by SSH etc. Besides, ttcp sends packets with PUSH flag. r-* 
refuses any packet with PUSH flag. So, there should be no problem.



FreeBSD integrates ttcp in its kernel. This can be a strong evidence about 
ttcp's applicability.

T/TCP is considered flawed mainly because RFC 1644 doesn't consider security  
problems. It definitely needs improvements. A new RFC is necessary at the end.

What I'm going to do is to implement a "basic" ttcp patch based on RFC 1644. 
Then, when people download the patch and test it, I'll collect every posted 
problems along with it and modify the patch accordingly. During the same 
process, I'll find out what improvements are needed for RFC 1644 and draft a 
new one.

So, I hope people don't simply discard TTCP. Anyway, there will be more 
benefits for all of us if TTCP is fixed instead of being thrown away. I can't 
do that alone without your support and help.
Thanks.


------- Laudney



<Prev in Thread] Current Thread [Next in Thread>