Date: Thu, 14 Feb 2002 22:25:23 -0500 (EST)
From: jamal <hadi@cyberus.ca>
To: Laurence <laudney@21cn.com>
cc: Netdev <netdev@oss.sgi.com>
Subject: Re: T/TCP Problems can be solved.
In-Reply-To: <200202140407.g1E47f915138@oss.sgi.com>
Message-ID: <Pine.GSO.4.30.0202142212010.13337-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Content-Length: 2412
Lines: 66


Your subject sounds exciting; i almost thought you invented
something new; I read it and was disapointed to find you are just
sounding like a salivating marketeer.
BTW, fix you eol

On Thu, 14 Feb 2002, Laurence wrote:

> 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.
>

Less data to chew on ;->

> 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.
>

How can a packet that carries data have the same effect in terms
of compute power and mem abuse as one that doesnt?

> 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

So lets kill those applications so that T/TCP can live

>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.

bullshit.

> 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.

So far any of your arguements above dont prove a thing.

> 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.
>

Look, nobody is going to stop you from implementing things; have fun
while doing it. Trying to sell used cars wont help you very much.

cheers,
jamal