I would repeat my comment from April: http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html
If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), it should be allowed in CREATE_CHILD_SA, too (with exactly same semantics). Best regards, Pasi From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Yaron Sheffer Sent: 26 August, 2009 00:23 To: ipsec@ietf.org Subject: [IPsec] #79: Remove CP from Create_Child_SA? 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. Everyone, please comment on the above, even if you support Yoav's proposal. This would be a protocol change (even if we don't understand what the current semantics is...), so we shouldn't do it unless we're quite sure. Thanks, Yaron
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec