>> 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?
Well, you are right at this point. A packet with data will never be
the same as those without data. But, just think about the benefits
of doing so (reducing total time by one RTT). It's simply a tradeoff.
>> 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
In my implementation, every socket (or connection) has its own right to
decide whether to turn T/TCP off. So, simply disable ttcp on listen
sockets of those services.
>> FreeBSD integrates ttcp in its kernel. This can be a strong evidence
>> about ttcp's applicability.
Not a good response for FreeBSD community.
>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.
Look, I'm really having fun while doing it. But let me clarify, I'm
not selling used cars. We're trying to find out proper fixes to Benz
400 and produce Benz 600.
Thanks for all your comments, which make me see more clearly the
other side of the coin.