Thanks Tero. Can i know why is the DHCP allocated IP scenario not considered in IKEv2 RFC or any separate RFC(like RFC3456 for IKEv1)? Is it only because of CONFIG_PAYLOAD is capable of providing IP to IRAC during IKEv2 negotiation itself.
What happens when some corporate network providing vpn service to its employees want to allocate IP to their IRAC ipsec clients through their DHCP server rather than through IKEv2 configuration payload. Is it not a use-case or is this scenario is not expected or was there any draft version also addressing this scenario for ikev2? Regards, ...Balaji.J On Wed, Apr 6, 2011 at 5:33 PM, Tero Kivinen <kivi...@iki.fi> wrote: > 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
