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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to