Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt

From: Mitesh Dalal <[email-masked]>
Date: Wed, 21 Apr 2004 14:22:28 -0700 (PDT)

>>  -----Original Message-----
>> From: 	Swami Yogesh (Nokia-NRC/Dallas)  
>> Sent:	Wednesday, April 21, 2004 10:59 AM
>> To:	[email-masked]
>> Subject:	
>> 
>> [Few late comments]
>> 
>> Although I have not read the draft thoroughly, I believe it's probably a good 
idea to fist define the scope of the problem that this working group should try 
to solve. TCP has a lot of vulnerabilities -- lot more than what this draft 
identifies -- and it's better to first define which problems should be solved 
and which one should not be. (Also, if the problem exists only because of BGP, 
which I don't think is the case, then maybe routers can use IPSec with a well 
known permanent shared key with different session keys. This will be more 
secure, compared to this draft, and faster to deploy.)

Yogesh,
the idea is to address blind attack from an attacker sitting outside your
path to the peer. The current problem is critical because it takes fewer
packets than originally believed. 

By lots of vulnerabilities I assume you mean brute force attacks such 
as SYN attack, reflection attacks and man in the middle kind of attack. 
We are clearly not addressing these. I would be glad to hear if you have
come across similar vulnerabilities as the current draft tries to address.

>> Moreover, it will also be useful to specify if the proposed solutions can use 
cryptography or not. Many people are not comfortable with cryptographic 
techniques partly because of throughput reasons. But in many cases it might be 
useful to have a low computation cryptographic methods to solve the problems 
without hurting the throughput. For example, a TCP sender with Time Stamp option 
could just encrypt the 32 bit timestamp using AES, and practically solve all the 
problems in this draft. (I am not saying we should do this). Encrypting a 32 bit 
number doesn't take a lot of time/computation and the receiver doesn't need to 
keep states to make this work. And, in principle it's not different from having 
a challenge response cookie.)

Cryptographic solutions have their own limitations. They have to be setup
at both ends and have to be agreed upon. In the current solution you only
need to worry about your side (fix is backward compatible), even if the 
other side is not up-to-date with patches, the fix will still work.

thx
Mitesh

>> 
>> --yogesh
>> 
>> ext Mark Allman wrote:
>> 	I support this being a working group document.  However, rather than
>> 	worrying about the name of the draft, I would imagine that getting
>> 	comments / feedback on the draft is the more important part.  Do the
>> 	chairs plan to try to get feedback on the draft and progress the draft
>> 	rather quickly?
>> 	    
>> 
>> We welcome technical comments.  We are always interested in timely
>> comments.  But, we do not have an apriori timeline that we have not
>> revealed.  As sketched in my first note today we are not pre-supposing
>> that the ideas in the draft are even the best fixes.  If everyone could
>> read the drafts and send their comments to the list, that'd be great!
>> 
>> allman
>> 
>> 
>> --
>> Mark Allman -- ICIR -- <http://www.icir.org/mallman/>
>> 
>>   
>> 
>
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm