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

[[e-mail]]

Mitesh-

> -----Original Message-----
> From: ext Mitesh Dalal [mailto:[e-mail]]
> Sent: Wednesday, April 21, 2004 4:22 PM
> To: [e-mail]; Swami Yogesh (Nokia-NRC/Dallas)
> Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt 
> 
> 
> 
> >>  -----Original Message-----
> >> From: 	Swami Yogesh (Nokia-NRC/Dallas)  
> >> Sent:	Wednesday, April 21, 2004 10:59 AM
> >> To:	[e-mail]
> >> 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. 
> 

I don't know if the problem is critical or not and I wasn't questing that. Sending 65,535 RST messages might be a problem for BGP, but in the broader context of TCP it might not be. A very simple intrusion detection system can (and already do) detect and drop such bursts of packets, especially when each packet has the same socket attribute.


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

No, by lots of vulnerabilities, I don't mean brute force attacks. Resetting a TCP connection might be a problem for BGP but might not the best MO for other kinds of blind attacks. For example, an attacker who wants to do blind DDoS attacks, might want to use exploit other TCP vulnerabilities (e.g., use ECN to reduce data rate) to reduce the connection handling capacity of the server than resetting the connections altogether. 

If the draft tries to make TCP more secure, as the title suggests, it needs to take a broader look than just BGP. Or it should explicitly say: "we are not looking at ..." (which is also perfectly alright with me). That's why I said it's better to define the scope of the problem.

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

Although I have not come across these problems myself, conventional wisdom says that if there is a security vulnerability in a protocol, it will be exploited sooner or later. The fact that this draft exists today and did not exist 10 years back, is a good evidence.


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

Not necessarily. You need setup/key-exchange only if both ends need to perform cryptographic operations on the same data fields. For TCP we might not need that. Or we might, depending upon what the working group considers as a secure solution. And, that exactly what my point was in the last e-mail. 

BTW, I doubt you will get easy consensus on the solutions without precisely defining what "secure TCP" means. Security means different things to different people at different times of the day.

--Yogesh

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