Hi Yaron, > -----Original Message----- > From: Yaron Sheffer [mailto:[email protected]] > Sent: Saturday, May 16, 2009 2:37 PM > To: Vijay Devarapalli; [email protected] > Subject: RE: [IPsec] Redirect -09 comments > > Hi Vijay, > > Regarding loop avoidance, please use RFC 2119, capitalized should's.
Conversational English is ok sometimes. We don't always have to use SHOULDs and MUSTs. Using RFC 2119 terminology becomes important only if it affects interoperability between two nodes. In this particular case, we are talking about configuration on the client not to accept too many redirects within a short period of time. It should throw an exception which might require manual intervention. There is no need to use "SHOULD" or "MUST" here. FWIW, RFC 2460 (the main IPv6 specification) does not use "SHOULD" or "MUST" anywhere in the entire document. > Regarding identity protection, I now realize I don't > understand the relevant > paragraph. The text is: > > Redirecting based on the unauthenticated identities might leak out > information about the user when active attacker can get information > to which gateway user was redirected to. If redirection > is based on > some internal information of the user, it might leak information to > attacker about the user which might not available otherwise. To > protect against this kind of attack the redirection based on the ID > should happen only after client has also authenticated himself. > > If the information leak you are worried about is simply the > name/address of > the redirected-to gateway, then this is available to a > passive attacker as > well, by simply observing the client's next message. Or were > you thinking > specifically of an attacker sitting next to the gateway? I will let Tero respond to this. He had proposed this paragraph. I didn't see any harm in including text about this attack. Vijay > > Also note that the last sentence contradicts our choice to > allow redirects > at the first IKE_AUTH response (for EAP). > > Thanks, > Yaron > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:[email protected]] > > Sent: Saturday, May 16, 2009 0:31 > > To: Yaron Sheffer; [email protected] > > Subject: Re: [IPsec] Redirect -09 comments > > > > Hi Yaron, > > > > On 5/13/09 10:01 PM, "Yaron Sheffer" wrote: > > > > > Hi, > > > > > > While preparing to progress the draft to AD review, I > reread it once > > again. > > > Here are a few comments. Although not all are nits, none > of them should > > block > > > the document now. > > > > > > Thanks, > > > Yaron > > > > > > Not-quite-nits: > > > > > > General: a long way back we discussed loop avoidance, but > this never > > made its > > > way into the draft. The document implicitly allows > multiple redirections > > in > > > sequence. We should specify somewhere that the client MUST have a > > threshold > > > value X (possibly 1), where it is willing to redirect at > most X times in > > > sequence. This is meant to deal with faulty > configuration, not with > > active > > > attacks. > > > > I added the following text to the Security Considerations section. > > > > The client could end up getting redirected multiple times in a > > sequence, either because of wrong configuration or a DoS > attack. The > > client could even end up in a loop with two or more gateways > > redirecting the client to each other. This could deny > service to the > > client. To prevent this, the client should be configured not to > > accept more a certain number of redirects within a short time > > period. This should be configurable on the client. > > > > Freel free to modify the text. > > > > > 9. I believe the last sentence "To protect against this > kind of attack > > the > > > redirection based on the ID should happen only after > client has also > > > authenticated himself." should read "after the *gateway* has also > > > authenticated itself". > > > > Hmm.. This is about revealing information about the user. > So I don't see > > how > > this can be avoided if the gateway is authenticating itself. > > > > > 10. Please add at the end of the section: A specification > that extends > > this > > > registry MUST also define in which notification(s) the > new values are > > allowed. > > > > > > Nits: > > > > > > 1. "connect to the IP address of the VPN gateways", > change "gateways" to > > > "gateway". > > > > > > 3. "In practice, this means the new gateway either", remove one > > "either". > > > > > > 6. mesage -> message > > > > > > 6. "presented by the client in the first IKE_AUTH > exchange itself." - > > this > > > text is duplicated. > > > > Fixed all of the above. Thanks. > > > > Vijay > > > > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
