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