Vijay Devarapalli wrote: > > Right... but if the client does not have a PAD entry for gw2's IDr, > > then the IKE negotiation will fail. (I guess we're not considering > > updating the PAD based on REDIRECTs.) > > Thats exactly what I am suggesting. :) > > This would be similar to a Mobile IPv6 mobile node creating a PAD > entry for the home agent that it discovers using IETF-standardized > mechanisms. I don't think we should require a Mobile IPv6 mobile > node or a VPN client or a 3GPP client that uses I-WLAN and discovers > a PDG [*] to have PAD entries configured for all the home > agents/gateways/PDGs that it might attach to before hand.
Why not? As Tero already commented, this specification could simply assume that if the discovery mechanism creates a PAD entry, it can also create a wildcard PAD entry (that matches e.g. all gateways that have certificate issued by CA X). > (* Apologies for using 3GPP terminology in the above. Pasi knows > what I am talking about. If anyone wants to know more about this, > please let me know. You might regret it later though. :) > > > (BTW, note that "having same IDr" is not exactly the same thing as > > "having same FQDN" -- gw1.example.com and gw2.foobar.example are > > clearly distinct FQDNs from DNS-point-of-view, but they might or > > might not be distinct "principals" from IPsec PAD point of view.) > > If you put the FQDN in the PAD entry, you do have an issue, right? Well... the FQDN in the PAD entry can be a wildcard (but the FQDN sent in DNS query obvious can't). Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
