Subject: [IPsec] Issue #79: Remove CP from Create_Child_SA ?

From: Yaron Sheffer <[email-masked]>
Date: Mon, 27 Apr 2009 23:37:47 +0300

Yoav:

Patricia noted in a post to the IPsec mailing list (12/12/2008) that section
2.19 says that "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." 

IMO the normal way of doing things is in this message 3, so rather than a
parenthetical remark, it's really the only one anyone uses. I don't think it
makes sense to assign a different IP address for each SA, and I don't think
anyone actually intended for this to be implied. 

In RFC 4306 <http://tools.ietf.org/html/rfc4306> , section 3.15, one of the
attributes that can be sent in the CP payload is the
INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client
needs to renew the address with the gateway (probably renew the lease with a
DHCP server). With such an attribute, it made sense for the client to renew
the address along with rekeying some CHILD_SA. 

In the bis document, we've deprecated this attribute, and it is now marked
as "RESERVED". Since we've done that, I suggest we remove the CP payload
from the Create Child SA exchange in appendix A, and reword section 2.19 to
reflect that requesting an IP address is only acceptable during IKE_AUTH.

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 11:39:53 +0200

Yaron Sheffer wrote:

> Yoav:
>
> Patricia noted in a post to the IPsec mailing list (12/12/2008) that
> section 2.19 says that "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."
>
> IMO the normal way of doing things is in this message 3, so rather
> than a parenthetical remark, it's really the only one anyone uses. I
> don't think it makes sense to assign a different IP address for each
> SA, and I don't think anyone actually intended for this to be
> implied.
>
> In RFC 4306, section 3.15, one of the attributes that can be sent in
> the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the
> length of time before the client needs to renew the address with the
> gateway (probably renew the lease with a DHCP server). With such an
> attribute, it made sense for the client to renew the address along
> with rekeying some CHILD_SA.
>
> In the bis document, we've deprecated this attribute, and it is now
> marked as "RESERVED". Since we've done that, I suggest we remove the
> CP payload from the Create Child SA exchange in appendix A, and
> reword section 2.19 to reflect that requesting an IP address is only
> acceptable during IKE_AUTH.

Including a CP payload in CREATE_CHILD_SA request doesn't mean the CP
applies to that particular CHILD_SA (just like CP during IKE_AUTH
doesn't apply to that CHILD_SA only). IMHO it's semantics should be
exactly the same as first doing an INFORMATIONAL exchange with the CP,
immediately followed by a CREATE_CHILD_SA exchange without the CP.

So if we would remove CP from the CREATE_CHILD_SA exchange, we should
also remove it from the INFORMATIONAL exhange. But we do have an
example in Section 2.20 where CP is used in INFORMATIONAL exchange...

But perhaps we could add text saying that many implementations will
probably support INTERNAL_IP_ADDRESS only during IKE_AUTH, and are
likely to refuse it in any other exchange?

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 29 Apr 2009 13:52:15 +0300

> reflect that requesting an IP address is only acceptable during IKE_AUTH. 

I agree in the common case of doing configuration payloads only during
IKE_AUTH, but I do not think it is good idea to restrict it in such
way. In future we might make extensions (for example the ipv6-config
or similar) where we might want to do configuration payloads as
separate informational exchanges, or as part of another create child
sa exchange.

I am in favor of removing the CP from the appendix C.4 from create
child SA, but for example section 2.20 has example showing how
configuration payload can be used in separate INFORMATIONAL exchange.

The section 4 already mentions that minimal implementations are
required to send CP request in message 3, and servers understanding it
must return CP payload (it does not explictly mention it must be in
same message as where the other child SA specific payloads (SA, TSi,
TSr) are).

There is no requirement anywhere for implementations to process
Configuration payloads in any locations, but I do not think we should
forbid them in other locations. In other locations they might be
simply ignored if the other end does not support them in those
locations. 
-- 
[email-masked]