Balaji J writes: > Recently i have started reading the IKEv2 RFC(5996). > I need a clarification on assigning the ip address using ikev2 protocol as > below which i couldn't find in the RFC4718:
Note that RFC5996 is more resent than RFC4718 and RFC5996 obsoletes both RFC4306 and RFC4718, so not all RFC4718 text is correct anymore. We did include most of the things from the RFC4718 to the RFC5996. > Is it valid to assign 0.0.0.0 IP address in the CFG_REPLY paylaod in > IKE_AUTH message to the initiator? I do not think there is anything that would explictly prohibit it, but I would expect most implementations would then try to configure that ip-address to be used, and that will cause problems. It would be better not to do that if you want interoperate with other implementations. > I need this information for the scenario where the initiator can obtain the > IP address by some other means(say DHCP). > But still if the initiator needs a secure channel to communicate with the > gateway first, before sending the DHCP request for obtaining IP address. I would say then it would be better to not to return any IP-address to the client. See section 3.15.4 of RFC5996 for more information. One of the ways to fail address assignment failures is to return with CFG_REPLY but without INTERNAL_IP*_ADDRESS. > Now when the DHCP server provides the IP-address to the initiator, > can the SPD be updated updated at that time(by extracting the ip assigned to > the initator from the DHCP message) rather than > doing the same during the IKE_AUTH response?(as i am thinking of assigning > 0.0.0.0 ip during initial IKE_AUTH response in CFG payload) That is local implementation matter. If you are assuming IP-address allocation is done in the DHCP over the IPsec tunnel, and your gateway does DHCP-packet snoopping on the link, it can modify the SPD based on that snooping. What you are doing sounds a bit like what RFC3456 did for IKEv1. > Because when i looked in to RFC4306 under section 2.19(Requesting an > Internal Address on a Remote Network) , it says, > "Message from responder to initiator: > CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) > > INTERNAL_NETMASK(255.255.255.0) > INTERNAL_SUBNET( > 192.0.2.0/255.255.255.0) > TSi = (0, > 0-65535,192.0.2.202-192.0.2.202) > TSr = (0, > 0-65535,192.0.2.0-192.0.2.255) > * All returned values will be implementation dependent." > > There is no mention in RFC something like "assigning 0.0.0.0 should be > handled as ERROR". > So can i safely say assigning 0.0.0.0 ip address is compliant with RFC? I would say yes, but do not expect it to work on generic implementations... > Also section 3.15.4. (Address Assignment Failures) says, > "If the initiator does not receive the IP address(es) required by its > policy, it MAY keep the IKE SA up and retry the Configuration payload > as separate INFORMATIONAL exchange after suitable timeout" > > Does it mean that the IPSEC-SA cannot be created unless a valid ip is > assigned? It depends. To send some packets over IPsec you need valid IP address. It is possible that some implementations will happily configure 0.0.0.0 as their IP-address and use that. On the other hand some implementations might simply do something different. > It is possible to create IPSEC-SA with the traffic-selector alone, rite? why > do we need to bother about IP allocation? Yes. That is possible. You do not need to allocate IP-addresses using configuration mode at all during the IKE_AUTH. That is optional feature of the IKEv2. > Assume that there is policy in initiator which says "0.0.0.0 MUST be > the ip-address allocated by NAS", then is it valid to send the same > in CFG_REPLY payload? If the initiator assumes that kind of setup, it is easier simply just skip Configuration payloads completely, and just create wildcard IPsec SA and use that for doing the DHCP. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
