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

[Pasi.Eronen]

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) 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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, 
mailto:pasi.ero...@nokia.com>> 
mailto:pasi.ero...@nokia.com>> wrote:

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




Email secured by Check Point

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yaron Sheffer]

I'll second that.

 

Yaron

 

  _  

From: pasi.ero...@nokia.com [mailto:pasi.ero...@nokia.com] 
Sent: Thursday, August 27, 2009 14:06
To: Yaron Sheffer; ipsec@ietf.org
Subject: RE: #79: Remove CP from Create_Child_SA?

 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Pasi.Eronen]

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

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

[Tero Kivinen]

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. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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

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

[Raj Singh]

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 

> 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 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
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Raj Singh]

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 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
>
>
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec