Subject: [IPsec] clarification needed in address assignment using IKEv2 Configuration Payload

From: Balaji J <[email-masked]>
Date: Wed, 6 Apr 2011 12:52:39 +0530

Hi ppl,

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:

Is it valid to assign 0.0.0.0 IP address in the CFG_REPLY paylaod in
IKE_AUTH message to the initiator?
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.
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)

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?

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 is possible to create IPSEC-SA with the traffic-selector alone, rite? why
do we need to bother about IP allocation?
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?

Any help is highly appreciated.

Thanks,
...Balaji.J

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Apr 2011 15:03:51 +0300

> 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. 

> 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. 

> 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. 

> 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. 

> INTERNAL_NETMASK(255.255.255.0)

I would say yes, but do not expect it to work on generic
implementations... 

> Does it mean that the IPSEC-SA cannot be created unless a valid ip is

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. 

> 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. 
-- 
[email-masked]

---

From: Balaji J <[email-masked]>
Date: Tue, 12 Apr 2011 12:35:56 +0530

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Apr 2011 14:54:11 +0300

Balaji J writes:
> Can i know why is the DHCP allocated IP scenario not considered in
> IKEv2 RFC or any separate RFC(like RFC3456 for IKEv1)?

It was considered, but working group decided that it is too
complicated and decided to include built in support for address
allocation using configuration payloads.

During the discussion in 2003 we had 2 major proposals, either using
DHCP over IKE or using configuration payloads. The DHCP inside the
IPsec tunnel was already mostly ruled out as it was only done in first
place because ipsec working group was forbidden to modify ike, so
that was only option.

If you are interested in the history and reasons why we did select
configuration payload you can see the discussion in the ipsec list
around year 2003. This thread seems to be the deciding one:

http://www.vpnc.org/ietf-ipsec/03.ipsec/msg00954.html

> during IKEv2 negotiation itself.

Yes. None of the implementors really liked the way to use dhcp over
IPsec tunnel to get configuration. That was only made because we could
not change IKE. There are very few implementions who ever supported
that RFC3456.

> 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.

They will either implement some kind of dhcp proxy system where the
VPN gateway will act as dhcp client and get addresses from the dhcp
server and then give them out in the configuration payloads, or they
simply use separate pool of addresses for the remote access users and
give them out directly from the vpn gateway. This last method is much
more common, as it also solves the routing problems, i.e. that address
pool can be such address set that they are always routed to the vpn
gateway, without any need of proxy arping or similar. 

> 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?

In normal case it is assumed that corporates will use separate pools
of address for local users and for remote access users, and the local
addresses are given out from dhcp server and remote access addresses
are given out using configuration payload. If needed the remote access
addresses can also be fetched from the radius server, i.e. when the
user authenticates himself using EAP or similar the radius server also
returns the address to be given to that user.
-- 
[email-masked]