Paul Hoffman wrote: > > At 1:07 PM -0800 3/11/09, Vijay Devarapalli wrote: > >There are environments where the client (e.g, Mobile IPv6 > MN, 3GPP I-WLAN client) always discovers the gateways they > need to attach to. They might get assigned different gateways > based on what service they want to access, what their > subscription profile is, etc.. In such environments, the PAD > entries are created dynamically, but of course bound by the > configuration on the mobile node. > > Of course. I was proposing that we do not add this mechanism > to the list, but instead have it reflect the settings that > were made by the other mechanisms. > > >I think the REDIRECT mechanism is of limited use if you can > only redirect to another gateway for which the mobile node > already has a PAD entry. > > Hmm. That was not clear to me from the document, but I could > have missed it. What do others think about this statement?
Strongly disagree. The REDIRECT in the Initial exchange is unauthenticated. The mobile node has not idea where this message has come from. I don't think it makes any sense to alter the PAD based on an unauthenticated notification. If we allow this, then REDIRECT says "go to this address on the Internet, and give them your user name and password". A fake REDIRECT could lead you to the attacker's gateway. You will accept any IDr it presents (because you don't have a PAD entry to authenticate that gateway). That gateway can then mount a MitM attack with the real gateway. No. I would hesitate to change the PAD based on an authenticated message from a trusted peer. I would never alter the PAD based on an unauthenticated message. gw2 MUST be in the PAD (either the same entry or a different one) Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
