[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IPsec] clarification needed in address assignment using IKEv2 Configuration Payload
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. -- kivinen at iki.fi
Understanding Local Authentication and Address Assignment
This feature is supported on SRX300, SRX320, SRX340, SRX345, and SRX550HM devices. A client application can request an IP address on behalf of a client. This request is made at the same time as the client authentication request. Upon successful authentication of the client, an IP address can be assigned to the client from a predefined address pool or a specific IP address can be assigned. Other attributes, such as WINS or DNS server IP addresses, can also be provided to the client.
Address pools are defined with the poolconfiguration statement at the [edit access address-assignment] hierarchy level. An address pool definition contains network information (IP address with optional netmask), optional range definitions, and DHCP or XAuth attributes that can be returned to the client. If all addresses in a pool are assigned, a new request for a client address will fail even if the client is successfully authenticated.
Access profiles are defined with the profile configuration statement at the [edit access] hierarchy. A defined address pool can be referenced in an access profile configuration.
You can also bind a specific IP address to a client in an access profile with the xauth ip-address address option. The IP address must be in the range of addresses specified in the address pool. It must also be different from the IP address specified with the host configuration statement at the [edit access profile address-assignment pool pool-name family inet] hierarchy level. For any application, if one IP address has been assigned, it will not be reassigned again until it is released.