Subject: [IPsec] #79: Remove CP from Create_Child_SA?

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Aug 2009 00:23:00 +0300

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

---

From: Raj Singh <[email-masked]>
Date: Wed, 26 Aug 2009 08:38:01 +0530

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 <[email-masked]>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."
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Aug 2009 09:10:56 +0300

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 <[email-masked]<mailto:[email-masked]>> 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

---

From: Raj Singh <[email-masked]>
Date: Wed, 26 Aug 2009 13:10:41 +0530

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 <[email-masked]>

> 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.
>
>> 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
>> 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
>>
>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Aug 2009 11:07:48 +0300

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 <[email-masked]<mailto:[email-masked]>>
Hi Raj.

Yoav

Hi Yaron,

Thanks & Regards,
Raj

Yoav:

Thanks,

            Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 26 Aug 2009 16:10:45 +0300

Yoav Nir writes:
> 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.

Most likely, but it is still most likely going to be few -> many
mapping, i.e. you have few (1-3? or so IP-addresses), but you can have
many SAs each using few of those addresses.

I do not really see any need to use configuration payloads along with
create child SA exchanges. The reason we do configuration payloads in
the IKE_AUTH is to avoid extra round trips for the most common case
when creating IKE SA, getting IP address, and creating IPsec SA.

If some implementation needs more IP-addresses, then it can first use
INFORMATIONAL exchange with configuration payloads to get the
IP-addresses it needs, and then use create child SA to create the
IPsec SA using that address. For the GW it is enough to check that
traffic selectors for the source address is one of the addresses
allocated for the client (or otherwise address allowed by policy).

Draft-ietf-ispecme-ikev2-ipv6-config might need configuration payloads
in information exchanges also, especially if you use the sharing of
VPN access (section 3.4), as in that case you most likely need one new
perfix per interface where you share the address, and all of your
interfaces might not be up and in use when you first create the IKE
SA. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 13:05:43 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Yaron Sheffer
Sent: 26 August, 2009 00:23
To: [email-masked]
Subject: [IPsec] #79: Remove CP from Create_Child_SA?

Yoav:

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

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 27 Aug 2009 14:26:23 +0300

I'll second that.

            Yaron

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, August 27, 2009 14:06
To: Yaron Sheffer; [email-masked]
Subject: RE: #79: Remove CP from Create_Child_SA?

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: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Yaron Sheffer
Sent: 26 August, 2009 00:23
To: [email-masked]
Subject: [IPsec] #79: Remove CP from Create_Child_SA?

Yoav:

 

Thanks,

            Yaron

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Aug 2009 14:47:45 +0300

I disagree.

Payloads in a particular CREATE_CHILD_SA exchange should be specifically related to the SA being created.  The IKE_AUTH exchange is different, because it is used to set up everything we need to get an IPsec SA going.

We do not use the CREATE_CHILD_SA to delete old SAs, to query application versions or to advertise capabilities through notifications or Vendor IDs, so it should also not include IP address maintenance.  That's what INFORMATIONAL exchanges are for.

On Aug 27, 2009, at 2:05 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,
Pasi

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Yaron Sheffer
Sent: 26 August, 2009 00:23
To: [email-masked]<mailto:[email-masked]>
Subject: [IPsec] #79: Remove CP from Create_Child_SA?

Yoav:

Thanks,
            Yaron

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 21:28:41 +0200

Yoav Nir wrote:
> I disagree.
>
> Payloads in a particular CREATE_CHILD_SA exchange should be
> specifically related to the SA being created.  The IKE_AUTH exchange
> is different, because it is used to set up everything we need to get
> an IPsec SA going.

If we were designing IKEv2 from scratch, I would agree with you.  But
we're not, so we're not discussing what would be the best design here,
but rather whether this part of RFC 4306 is so horribly broken it
absolutely needs to be changed (RFC 4306 is unambiguous that CPs
are allowed in CREATE_CHILD_SA exchange). I think it's not broken, 
just somewhat ugly and inelegant...

Best regards,
Pasi
(not wearing any hats)