Yaron Sheffer writes: > 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.
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 protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
