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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
