Interesting. But if it's different IP addresses for different applications, then there are probably also different traffic selectors for these applications, and then possibly different IPsec SAs.
If that's the case, then maybe it does make sense to get IP addresses in the Create_Child SA exchange On Aug 26, 2009, at 10:40 AM, Raj Singh wrote: Hi Yoav, These applications are using same IKE SA for allocating IP to the application specific virtual interfaces, which can be more than one. Let me know if you further clarification. Thanks & Regards, Raj 2009/8/26 Yoav Nir <y...@checkpoint.com<mailto:y...@checkpoint.com>> Hi Raj. The issue is concerned with Config payload in Child SA only. Config in INFORMATIONAL will stay, or at least, there is no current proposal to remove it. It can be useful for querying the application version, which is still a defined attribute for CP. Can you elaborate on the cases where the application needs more than 1 IP address? Yoav On Aug 26, 2009, at 6:08 AM, Raj Singh wrote: Hi Yaron, Also, there are use cases when application needs more than 1 IP address for internal purpose. With current ikev2bis, this is possible as we can request address after session establishment using CP[CFG_REQUEST] in INFORMATIONAL exchange. If we say that we want to support in ONLY IKE_AUTH. Are we going to stop supporting CP payload via INFORMATION exchange ? Thanks & Regards, Raj On Wed, Aug 26, 2009 at 2:53 AM, Yaron Sheffer <yar...@checkpoint.com<mailto:yar...@checkpoint.com>> 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. 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 Email secured by Check Point Email secured by Check Point
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
