Subject: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange

From: Patricia <[email-masked]>
Date: Fri, 12 Dec 2008 15:39:46 +0800

Hi,
When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. According
to RFC4306 2.19,
"A request for such a temporary address can be included in any request to
create a CHILD_SA (including the implicit request in message 3) by including
a CP payload."
But I'm a little confused about how it is used with CREATE-CHILD-SA exchange
and what it is used for. Does it mean that the IRAS is going to assign a
different IP for each of CREATE-CHILD-SA exchange? If so, since there is no
EAP at this stage, the IP can be got only from local pool but not from
external server. Is it such case?

Thanks,
Patricia
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Dec 2008 10:21:54 +0200

On Dec 12, 2008, at 9:39 AM, Patricia wrote:

> Hi,
> When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP.  
> According to RFC4306 2.19,
> "A request for such a temporary address can be included in any  
> request to create a CHILD_SA (including the implicit request in  
> message 3) by including a CP payload."
> But I'm a little confused about how it is used with CREATE-CHILD-SA  
> exchange and what it is used for. Does it mean that the IRAS is  
> going to assign a different IP for each of CREATE-CHILD-SA exchange?  
> If so, since there is no EAP at this stage, the IP can be got only  
> from local pool but not from external server. Is it such case?
>
> Thanks,
> Patricia

Hi Patricia.

I'm a little confused myself. The text you quoted is also present in  
the IKEv2bis document ( http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-01.txt 
  )

It is somewhat misleading, as it implies just what you are saying,  
that the IRAS might assign a different IP for each IPsec SA.  Even if  
this is permitted by the standard (more on in a few lines) this is not  
the way CP works.

The usual way of doing things is to only assign one IP address during  
the IKE_AUTH exchange. That address persists at least until the  
deletion of the IKE SA (although if the SA is rekeyed or  
reauthenticated, the new IKE SA gets the old address)

No implementation that I know of assigns an address at any other  
time.  It actually makes no sense to assign several IP addresses like  
that, as IKEv2 does not have real address management features - there  
is no way to release the IP address other than tearing down the IKE SA.

If you go to section 3.15 of RFC 4306, you'll see that the  
configuration payload can pass an attribute called  
INTERNAL_ADDRESS_EXPIRY. The theory was that you would pass that  
number to the client (probably the lifetime you got from the DHCP  
server) and the client would in a timely manner, ask the gateway to  
renew the address, and extend the DHCP lease. This may be the reason  
why CP payloads would be needed in CCSA and Informational exchanges.  
That option was deprecated in the bis document, so may be that CP-in- 
CCSA should be deprecated as well.

If you are implementing IKEv2 client-side, you should probably not  
request an additional IP address in a CCSA exchange, only the IKE_AUTH  
exchange.  If you are writing a server-side, you can probably safely  
ignore a CP payload in CCSA.

Hope this helps

Yoav

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 16 Dec 2008 18:54:36 +0200

Hi Yoav,

Please open an issue to cover this case.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yoav Nir
> Sent: Tuesday, December 16, 2008 10:22
> To: Patricia
> Cc: [email-masked]
> Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange
> 
> Scanned by Check Point Total Security Gateway.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Dec 2008 00:52:12 +0200

OK. #79

---

From: Patricia <[email-masked]>
Date: Fri, 19 Dec 2008 13:56:40 +0800

Thanks all and I agree with you totally.

Patricia

2008/12/17 Yoav Nir <[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 31 Dec 2008 18:57:26 -0800

At 10:21 AM +0200 12/16/08, Yoav Nir wrote:
>>When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. According to RFC4306 2.19,
>>"A request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload."
>>But I'm a little confused about how it is used with CREATE-CHILD-SA exchange and what it is used for. Does it mean that the IRAS is going to assign a different IP for each of CREATE-CHILD-SA exchange? If so, since there is no EAP at this stage, the IP can be got only from local pool but not from external server. Is it such case?
>>
>>Thanks,
>>Patricia
>
>Hi Patricia.
>
>I'm a little confused myself. The text you quoted is also present in the IKEv2bis document ( http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-01.txt )
>
>It is somewhat misleading, as it implies just what you are saying, that the IRAS might assign a different IP for each IPsec SA.  Even if this is permitted by the standard (more on in a few lines) this is not the way CP works.
>
>The usual way of doing things is to only assign one IP address during the IKE_AUTH exchange. That address persists at least until the deletion of the IKE SA (although if the SA is rekeyed or reauthenticated, the new IKE SA gets the old address)
>
>No implementation that I know of assigns an address at any other time.  It actually makes no sense to assign several IP addresses like that, as IKEv2 does not have real address management features - there is no way to release the IP address other than tearing down the IKE SA.
>
>If you go to section 3.15 of RFC 4306, you'll see that the configuration payload can pass an attribute called INTERNAL_ADDRESS_EXPIRY. The theory was that you would pass that number to the client (probably the lifetime you got from the DHCP server) and the client would in a timely manner, ask the gateway to renew the address, and extend the DHCP lease. This may be the reason why CP payloads would be needed in CCSA and Informational exchanges. That option was deprecated in the bis document, so may be that CP-in-CCSA should be deprecated as well.
>
>If you are implementing IKEv2 client-side, you should probably not request an additional IP address in a CCSA exchange, only the IKE_AUTH exchange.  If you are writing a server-side, you can probably safely ignore a CP payload in CCSA.

Unfortunately, I don't see how to fix this in the document without breaking interop with implementations that follow 4306. The doc is clear that the responder doesn't have to support this (or CP at all), but I am hesitant to change this at this point without knowing how it will break older systems.

--Paul Hoffman, Director
--VPN Consortium