Subject: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Jul 2009 23:12:41 +0300

Hi all.

This is the fourth iteration of this draft.  New in this iteration
 - Another co-author
 - Changed the name, so that this item is considered in the rechartering discussion
 - Fixed some notation and some discussion based on comments from the list

Yoav
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Wednesday, July 01, 2009 12:15
To: [email-masked]
Subject: I-D Action:draft-nir-ipsecme-childless-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : A Childless Initiation of the IKE SA
        Author(s)       : Y. Nir, et al.
        Filename        : draft-nir-ipsecme-childless-00.txt
        Pages           : 7
        Date            : 2009-07-01

This document describes an extension to the IKEv2 protocol that
allows an IKE SA to be created and authenticated without generating a
child SA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nir-ipsecme-childless-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Email secured by Check Point

---

From: Raj Singh <[email-masked]>
Date: Fri, 3 Jul 2009 19:21:02 +0530

Hi Yoav,

Mostly the Initiator will decide that it wants to bring UP only IKE SA
without child SA.
But currently there is no notify/VID from Initiator to Responder to indicate
that initiator wants to bring only IKE SA. Even if responder does not
supports "childless IKE_AUTH", it will process IKE_SA_INIT, involding CPU
intensive D-H calculations, and send IKE_SA_INIT response without "childless
VID" payload.

By introducing a notify/VID payload from Initiator that it wants to bring UP
only IKE SA without child SA wil ease the processing ar Responder side. If
responder does not support "childless IKE_AUTH", it can send INVALID_SYNTAX.
Then, Initiator will wait for "Child SA" info to be available to bring UP
both IKE and child SA, normally as mentioned in RFC 4306.

Thanks,
Raj

On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir <[email-masked]> wrote:

> From: [email-masked] [[email-masked]] On
> Behalf Of [email-masked] [[email-masked]]
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 3 Jul 2009 21:46:01 +0300

Hi Raj,

It sounds like you want a critical payload (RFC 4306, Sec. 2.5), probably a
payload with no data. In fact the draft could specify both options, the
current VID and such a payload, and leave it to the Initiator to decide
which behavior it prefers. Different scenarios might call for different
behaviors.

Thanks,

            Yaron

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Raj Singh
Sent: Friday, July 03, 2009 16:51
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Yoav,

Thanks,
Raj 

Hi all.

This is the fourth iteration of this draft.  New in this iteration
 - Another co-author
 - Changed the name, so that this item is considered in the rechartering
discussion
 - Fixed some notation and some discussion based on comments from the list

Yoav

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Scanned by Check Point Total Security Gateway.

---

From: Raj Singh <[email-masked]>
Date: Sat, 4 Jul 2009 16:06:47 +0530

Hi Yaron,

I agree with you.
Your suggestion of having "critical" bit set on childless notify/VID payload
from initiator in IKE_SA_INIT exchange will define the bahavior as mentioned
below.

If initiator want to childless IKE_AUTH, it will send  CHILDLESS_IKE_AUTH
notify/VID payload having "critical" flag SET in IKE_SA_INIT request.

1. It will help responder not to process the IKE_SA_INIT exchange if it does
not support childless IKE_AUTH.

"The responder MUST reject IKE_SA_INIT exchange if it receives
CHILDLESS_IKE_AUTH notify/VID payload in IKE_SA_INIT exchange from initiator
if responder does not support childless IKE_AUTH and in response to the
IKE_SA_INIT exchange containing CHILDLESS_IKE_AUTH it MUST send
UNSUPPORTED_CRITICAL_PAYLOAD, the notification data will contain two-octet
unsupported notify/VID payload type i.e. CHILDLESS_IKE_AUTH."

2. It will help initiator to not to go ahead with childless IKE_AUTH if
responder doesn't support it wtithout procesing IKE_SA_INIT response.

With Regards,
Raj

On Sat, Jul 4, 2009 at 12:16 AM, Yaron Sheffer <[email-masked]>wrote:

>   ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Raj Singh
> *Sent:* Friday, July 03, 2009 16:51
> *To:* Yoav Nir
> *Cc:* [email-masked]
> *Subject:* Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
>
>
>
> Hi Yoav,
>
> But currently there is no notify/VID from Initiator to Responder to
> indicate that initiator wants to bring only IKE SA. Even if responder does
> not supports "childless IKE_AUTH", it will process IKE_SA_INIT, involding
> CPU intensive D-H calculations, and send IKE_SA_INIT response without
> "childless VID" payload.
>
> By introducing a notify/VID payload from Initiator that it wants to bring
> UP only IKE SA without child SA wil ease the processing ar Responder side.
> If responder does not support "childless IKE_AUTH", it can send
> INVALID_SYNTAX. Then, Initiator will wait for "Child SA" info to be
> available to bring UP both IKE and child SA, normally as mentioned in RFC
> 4306.
>
> Thanks,
> Raj
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 4 Jul 2009 16:12:55 +0300

Nope. The Critical bit refers to the payload, rather than to its contents,
and in fact cannot be set for payloads defined in RFC 4306 (such as VID and
Notify). So you need to define a NEW payload to benefit from it.

Thanks,

            Yaron

  _____  

From: Raj Singh [mailto:[email-masked]] 
Sent: Saturday, July 04, 2009 13:37
To: Yaron Sheffer
Cc: Yoav Nir; [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Yaron,

I agree with you. 

With Regards,
Raj

On Sat, Jul 4, 2009 at 12:16 AM, Yaron Sheffer <[email-masked]>
wrote:

Hi Raj,

Thanks,

            Yaron

  _____  

Hi Yoav,

Thanks,
Raj 

Hi all.

Yoav

---

From: Raj Singh <[email-masked]>
Date: Sat, 4 Jul 2009 22:09:11 +0530

Hi Yaron,

Its clear that critical bit refer to the payload, than to its content. Point
well taken.
But i am not able to understand why we can't define "critical" bit for new
CHILDLESS_IKE_AUTH notify/VID payload ?

With Regards,
Raj

On Sat, Jul 4, 2009 at 6:42 PM, Yaron Sheffer <[email-masked]> wrote:

>  Nope. The Critical bit refers to the payload, rather than to its
> contents, and in fact cannot be set for payloads defined in RFC 4306 (such
> as VID and Notify). So you need to define a NEW payload to benefit from it.
>
>
>
> Thanks,
>
>             Yaron
>
>
> *From:* Raj Singh [mailto:[email-masked]]
> *Sent:* Saturday, July 04, 2009 13:37
> *To:* Yaron Sheffer
> *Cc:* Yoav Nir; [email-masked]
>
> Your suggestion of having "critical" bit set on childless notify/VID
> payload from initiator in IKE_SA_INIT exchange will define the bahavior as
> mentioned below.
>
> 1. It will help responder not to process the IKE_SA_INIT exchange if it
> does not support childless IKE_AUTH.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 4 Jul 2009 22:19:14 +0300

Hi Raj,

We sure can. But it will not be any of the existing payloads, i.e. won't be
a Notify or a Vendor ID. It will be a completely new payload, presumably
with the same semantics.

Thanks,

            Yaron

  _____  

From: Raj Singh [mailto:[email-masked]] 
Sent: Saturday, July 04, 2009 19:39
To: Yaron Sheffer
Cc: Yoav Nir; [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Yaron,

With Regards,
Raj

Thanks,

            Yaron

  _____  

Hi Yaron,

I agree with you. 

With Regards,
Raj

Hi Raj,

Thanks,

            Yaron

  _____  

Hi Yoav,

Thanks,
Raj 

Hi all.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 5 Jul 2009 00:03:53 +0300

Hi Raj

The ordinary thing for a responder to do with unrecognized Notifies/VIDs is to ignore them. So the only responder that will behave as you suggest is one that supports this extension, but is configured not to.

At least for the remote access client, it makes sense for a client that faces both supporting and non-supporting gateways to have a "dummy" proposal for a useless child SA, for example ICMP from the client to the gateway. It doesn't really matter if the proposal is accepted or rejected, because the client does not need the traffic.

In any case, an initiator that insists on a childless IKE SA contacting a gateway that does not support the extension is a misconfiguration. I don't believe we should go to great lengths (especially the new critical payload that Yaron is proposing) to save work in such a misconfiguration case.

If we do think it's important, the "right" way is for the Initiator to send the VID, for the responder to only send the VID if it (a) supports the extension *and* (b) has seen the VID from the initiator. We could even require that the initiator be prepared to continue with a non-supporting gateway, but I'm not sure that's a good idea.

________________________________________
From: Raj Singh [[email-masked]]
Sent: Friday, July 03, 2009 16:51
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Yoav,

Mostly the Initiator will decide that it wants to bring UP only IKE SA without child SA.
But currently there is no notify/VID from Initiator to Responder to indicate that initiator wants to bring only IKE SA. Even if responder does not supports "childless IKE_AUTH", it will process IKE_SA_INIT, involding CPU intensive D-H calculations, and send IKE_SA_INIT response without "childless VID" payload.

By introducing a notify/VID payload from Initiator that it wants to bring UP only IKE SA without child SA wil ease the processing ar Responder side. If responder does not support "childless IKE_AUTH", it can send INVALID_SYNTAX. Then, Initiator will wait for "Child SA" info to be available to bring UP both IKE and child SA, normally as mentioned in RFC 4306.

Thanks,
Raj

On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Hi all.

Yoav
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 01, 2009 12:15
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action:draft-nir-ipsecme-childless-00.txt

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

---

From: Raj Singh <[email-masked]>
Date: Sun, 5 Jul 2009 07:31:56 +0530

Hi Yoav,

Please find my input inline <Raj>.

With Regards,
Raj

On Sun, Jul 5, 2009 at 2:33 AM, Yoav Nir <[email-masked]> wrote:

> Hi Raj
>
> The ordinary thing for a responder to do with unrecognized Notifies/VIDs is
> to ignore them. So the only responder that will behave as you suggest is one
> that supports this extension, but is configured not to.

<Raj> Yes, if responder understands childless IKE_AUTH from initiator, it
will behave as mentioned in my previous mail, if NOT and it does not support
childless IKE_AUTH [only responder not supporting childless extention], then
initiator will notice missing childless notify/VID and can stop the
transactions for the SA. But it will help responders, supporting this
extentions and applying policies.

>
>
> At least for the remote access client, it makes sense for a client that
> faces both supporting and non-supporting gateways to have a "dummy" proposal
> for a useless child SA, for example ICMP from the client to the gateway. It
> doesn't really matter if the proposal is accepted or rejected, because the
> client does not need the traffic.

 <Raj> What's the usecase ?

>
>
> In any case, an initiator that insists on a childless IKE SA contacting a
> gateway that does not support the extension is a misconfiguration. I don't
> believe we should go to great lengths (especially the new critical payload
> that Yaron is proposing) to save work in such a misconfiguration case.

<Raj> How it can be a misconfiguration, The gateway can put some policy to
enable/disable childless IKE_AUTH based on "load" on gateway. Yes, i agree,
new crittical payload, we can avoid.

>
>
> If we do think it's important, the "right" way is for the Initiator to send
> the VID, for the responder to only send the VID if it (a) supports the
> extension *and* (b) has seen the VID from the initiator. We could even
> require that the initiator be prepared to continue with a non-supporting
> gateway, but I'm not sure that's a good idea.

<Raj> The whole idea is:
initiator to send childless notify/VID when it want to bring up "ONLY" IKE
SA i.e. it is not hit by traffic or "dummy" payload. This will avoid
unnecessary processing of IKE_SA_INIT at responder when responder does not
support childless IKE_AUTH. This is most likely usecase of chiless IKE_AUTH
in VPN scenarios.
The behavior remains similar as mentioned in my previous mail except
"critical" bit as it needs to define new payload type which even i want to
avoid. Its just a simple notify/VID payload with no associated data and
easing the work at initiator and responder. Its can see goodness in idea.
When initiator has dummy proposal  ready, the initiator need not to send
childless notify/VID payload.

> From: [email-masked]<mailto:[email-masked]>
> [[email-masked]<mailto:[email-masked]>] On
> Behalf Of [email-masked]<mailto:[email-masked]> [
> [email-masked]<mailto:[email-masked]>]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Jul 2009 11:23:37 +0300

Inline with <ynir>

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Raj Singh
Sent: Sunday, July 05, 2009 5:02 AM
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Yoav,

With Regards,
Raj
On Sun, Jul 5, 2009 at 2:33 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Hi Raj

The ordinary thing for a responder to do with unrecognized Notifies/VIDs is to ignore them. So the only responder that will behave as you suggest is one that supports this extension, but is configured not to.
<Raj> Yes, if responder understands childless IKE_AUTH from initiator, it will behave as mentioned in my previous mail, if NOT and it does not support childless IKE_AUTH [only responder not supporting childless extention], then initiator will notice missing childless notify/VID and can stop the transactions for the SA. But it will help responders, supporting this extentions and applying policies.

At least for the remote access client, it makes sense for a client that faces both supporting and non-supporting gateways to have a "dummy" proposal for a useless child SA, for example ICMP from the client to the gateway. It doesn't really matter if the proposal is accepted or rejected, because the client does not need the traffic.
 <Raj> What's the usecase ?
<ynir> the usecase is that the client needs an IKE SA, but can't get it unless it negotiates a child SA - that's what you have now before implementing our draft.

In any case, an initiator that insists on a childless IKE SA contacting a gateway that does not support the extension is a misconfiguration. I don't believe we should go to great lengths (especially the new critical payload that Yaron is proposing) to save work in such a misconfiguration case.
<Raj> How it can be a misconfiguration, The gateway can put some policy to enable/disable childless IKE_AUTH based on "load" on gateway. Yes, i agree, new crittical payload, we can avoid.
<ynir> Well, we could add our own "critical" bit to the notify/VID. If that is on, the responder can either reply with a similar notification/VID, or else some error notify (NO_PROPOSAL_CHOSEN or a new one of our own)

If we do think it's important, the "right" way is for the Initiator to send the VID, for the responder to only send the VID if it (a) supports the extension *and* (b) has seen the VID from the initiator. We could even require that the initiator be prepared to continue with a non-supporting gateway, but I'm not sure that's a good idea.
<Raj> The whole idea is:
initiator to send childless notify/VID when it want to bring up "ONLY" IKE SA i.e. it is not hit by traffic or "dummy" payload. This will avoid unnecessary processing of IKE_SA_INIT at responder when responder does not support childless IKE_AUTH. This is most likely usecase of chiless IKE_AUTH in VPN scenarios.
The behavior remains similar as mentioned in my previous mail except "critical" bit as it needs to define new payload type which even i want to avoid. Its just a simple notify/VID payload with no associated data and easing the work at initiator and responder. Its can see goodness in idea.
When initiator has dummy proposal  ready, the initiator need not to send childless notify/VID payload.

________________________________________
From: Raj Singh [[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 03, 2009 16:51
To: Yoav Nir
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Yoav,

Thanks,
Raj
On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
Hi all.

Yoav
________________________________________
From: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>]
Sent: Wednesday, July 01, 2009 12:15
To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
Subject: I-D Action:draft-nir-ipsecme-childless-00.txt

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

---

From: "Raghunandan P (raghup)" <[email-masked]>
Date: Mon, 6 Jul 2009 16:13:14 +0530

Hi Yoav/Raj,
 
I think its a good idea for the initiator to announce its capabilities
about supporting just IKE SA without child SA. The responder will then
act accordingly.  Hence, this would make 4 scenarios:
[IKE_SA_ONLY] is the mode that will tell whether the device supports
bringing up IKE SA only or not. 
 
       Initiator                          Responder             Result
------------------------------------------------------------------------
---------------------------------
 a)  IKE_SA_ONLY              IKE_SA_ONLY                  Bring up the
IKE SA
 
 b)  IKE_SA_ONLY            Does not support            Send a Notify
with INVALID_SYNTAX
                                           IKE_SA_ONLY
 
c)  Does not support             IKE_SA_ONLY           IKE and child SA
would be brought UP
     IKE_SA_ONLY
 
d) Does not support           Does not support          IKE and child SA
would be brought UP.
     IKE_SA_ONLY                  IKE_SA_ONLY
 
My question is related to the scenario c) discussed above.
Is the result to bring up IKE and IPSec SA  or would the responder send
a Notify with INVALID_SYNTAX to the initiator since responder wants to
bring up IKE SA only and not the child SA.
 
It might be good to add a Notify (IKE_SA_ONLY) than the VID.
 
Regards
Raghu

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoav Nir
Sent: Monday, July 06, 2009 1:54 PM
To: 'Raj Singh'
Cc: [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Inline with <ynir>

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Raj Singh
Sent: Sunday, July 05, 2009 5:02 AM
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Yoav,

With Regards,
Raj

Hi Raj

The ordinary thing for a responder to do with unrecognized Notifies/VIDs
is to ignore them. So the only responder that will behave as you suggest
is one that supports this extension, but is configured not to.

<Raj> Yes, if responder understands childless IKE_AUTH from initiator,
it will behave as mentioned in my previous mail, if NOT and it does not
support childless IKE_AUTH [only responder not supporting childless
extention], then initiator will notice missing childless notify/VID and
can stop the transactions for the SA. But it will help responders,
supporting this extentions and applying policies.

	At least for the remote access client, it makes sense for a
client that faces both supporting and non-supporting gateways to have a
"dummy" proposal for a useless child SA, for example ICMP from the
client to the gateway. It doesn't really matter if the proposal is
accepted or rejected, because the client does not need the traffic.

<ynir> the usecase is that the client needs an IKE SA, but can't get it
unless it negotiates a child SA - that's what you have now before
implementing our draft.

	In any case, an initiator that insists on a childless IKE SA
contacting a gateway that does not support the extension is a
misconfiguration. I don't believe we should go to great lengths
(especially the new critical payload that Yaron is proposing) to save
work in such a misconfiguration case.

<Raj> How it can be a misconfiguration, The gateway can put some policy
to enable/disable childless IKE_AUTH based on "load" on gateway. Yes, i
agree, new crittical payload, we can avoid.

<ynir> Well, we could add our own "critical" bit to the notify/VID. If
that is on, the responder can either reply with a similar
notification/VID, or else some error notify (NO_PROPOSAL_CHOSEN or a new
one of our own)

	
	If we do think it's important, the "right" way is for the
Initiator to send the VID, for the responder to only send the VID if it
(a) supports the extension *and* (b) has seen the VID from the
initiator. We could even require that the initiator be prepared to
continue with a non-supporting gateway, but I'm not sure that's a good
idea.

<Raj> The whole idea is:
initiator to send childless notify/VID when it want to bring up "ONLY"
IKE SA i.e. it is not hit by traffic or "dummy" payload. This will avoid
unnecessary processing of IKE_SA_INIT at responder when responder does
not support childless IKE_AUTH. This is most likely usecase of chiless
IKE_AUTH in VPN scenarios.
The behavior remains similar as mentioned in my previous mail except
"critical" bit as it needs to define new payload type which even i want
to avoid. Its just a simple notify/VID payload with no associated data
and easing the work at initiator and responder. Its can see goodness in
idea.
When initiator has dummy proposal  ready, the initiator need not to send
childless notify/VID payload.

	Subject: Re: [IPsec] FW: I-D
Action:draft-nir-ipsecme-childless-00.txt

	Hi Yoav,
	
	Mostly the Initiator will decide that it wants to bring UP only
IKE SA without child SA.
	But currently there is no notify/VID from Initiator to Responder
to indicate that initiator wants to bring only IKE SA. Even if responder
does not supports "childless IKE_AUTH", it will process IKE_SA_INIT,
involding CPU intensive D-H calculations, and send IKE_SA_INIT response
without "childless VID" payload.
	
	By introducing a notify/VID payload from Initiator that it wants
to bring UP only IKE SA without child SA wil ease the processing ar
Responder side. If responder does not support "childless IKE_AUTH", it
can send INVALID_SYNTAX. Then, Initiator will wait for "Child SA" info
to be available to bring UP both IKE and child SA, normally as mentioned
in RFC 4306.
	
	Thanks,
	Raj

	On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir
<[email-masked]<mailto:[email-masked]>> wrote:
	Hi all.
	
	This is the fourth iteration of this draft.  New in this
iteration
	 - Another co-author
	 - Changed the name, so that this item is considered in the
rechartering discussion
	 - Fixed some notation and some discussion based on comments
from the list
	
	Yoav

	From:
[email-masked]<mailto:[email-masked]>
[[email-masked]<mailto:[email-masked]>] On
Behalf Of [email-masked]<mailto:[email-masked]>
[[email-masked]<mailto:[email-masked]>]

	
	A New Internet-Draft is available from the on-line
Internet-Drafts directories.

	This document describes an extension to the IKEv2 protocol that
	allows an IKE SA to be created and authenticated without
generating a
	child SA.

	
	
	Below is the data which will enable a MIME compliant mail reader
	implementation to automatically retrieve the ASCII version of
the
	Internet-Draft.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Jul 2009 16:14:35 +0300

Hi Raghu

I think in scenario (c) the initiator will propose a full child SA proposal, and the responder will accept the IKE SA and reply with a NO_PROPOSAL_CHOSEN for the child SA.

________________________________
From: Raghunandan P (raghup) [mailto:[email-masked]]
Sent: Monday, July 06, 2009 1:43 PM
To: Yoav Nir; Raj Singh
Cc: [email-masked]
Subject: RE: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Yoav/Raj,

I think its a good idea for the initiator to announce its capabilities about supporting just IKE SA without child SA. The responder will then act accordingly.  Hence, this would make 4 scenarios:
[IKE_SA_ONLY] is the mode that will tell whether the device supports bringing up IKE SA only or not.

       Initiator                          Responder             Result
---------------------------------------------------------------------------------------------------------
 a)  IKE_SA_ONLY              IKE_SA_ONLY                  Bring up the IKE SA

 b)  IKE_SA_ONLY            Does not support            Send a Notify with INVALID_SYNTAX
                                           IKE_SA_ONLY

c)  Does not support             IKE_SA_ONLY           IKE and child SA would be brought UP
     IKE_SA_ONLY

d) Does not support           Does not support          IKE and child SA would be brought UP.
     IKE_SA_ONLY                  IKE_SA_ONLY

My question is related to the scenario c) discussed above.
Is the result to bring up IKE and IPSec SA  or would the responder send a Notify with INVALID_SYNTAX to the initiator since responder wants to bring up IKE SA only and not the child SA.

Regards
Raghu

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, July 06, 2009 1:54 PM
To: 'Raj Singh'
Cc: [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
Inline with <ynir>

Hi Yoav,

With Regards,
Raj

Hi Yoav,

Thanks,
Raj

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Jul 2009 22:30:02 +0300

> from initiator in IKE_SA_INIT exchange will define the bahavior as mentioned

That is not correct way of using critical bit. Critical bit means that
if it is set and the PAYLOAD TYPE is not understood, then
UNSUPPORTED_CRITICAL_PAYLOAD error is reported. Every implementation
will understand Notify and Vendor ID payloads, thus they will never
return UNSUPPORTED_CRITICAL_PAYLOAD regardless what the contents of
those payloads are.

> notify/VID payload having "critical" flag SET in IKE_SA_INIT request.

And complient implentation will do what to do as RFC4306 says ie:

      ... MUST be ignored by the recipient if the recipient
      understands the payload type code. MUST be set to zero for
      payload types defined in this document. Note that the critical
      bit applies to the current payload rather than the "next"
      payload whose type code appears in the first octet. The
      reasoning behind not setting the critical bit for payloads
      defined in this document is that all implementations MUST
      understand all payload types defined in this document and
      therefore must ignore the Critical bit's value. Skipped payloads
      are expected to have valid Next Payload and Payload Length
      fields.

The correct way to do is to make new exchange type for this new
childless IKE_SA_INIT & IKE_AUTH. That way old implenentations will
then know that they do not understand this new type and will drop the
packets. This is if you really want the property that if responder
does not understand chieldless IKE_AUTH you do not want to continue at
all. 

I have not yet read the draft, as I have been too busy with working
group drafts already, and I still do not know if this is really needed
at all...
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Wed, 8 Jul 2009 09:48:02 +0530

Hi Tero,

Thanks for your valuable inputs.
Please find re inputs inline. <Raj>

On Wed, Jul 8, 2009 at 1:00 AM, Tero Kivinen <[email-masked]> wrote:

> payload

<Raj>
I  was under impression that we can have "critical" bit in childless
IKE_AUTH notify/VID.
Even Yaron also clarified in same thread that we need new exchange type to
have "critical" bit on it.

> group drafts already, and I still do not know if this is really needed

<Raj>
If we can't have "critical" bit inside associated data of childless
notify/VID,  then
new exchange type is a near possibility.
Please have a look at the use cases in the draft for need of this draft.

With Regards,
Raj

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jul 2009 08:49:54 +0300

Hi Raj

What Yaron suggested, was to create a new payload type, and mark that as critical.

I don't like either Yaron's or Tero's suggestions, as both lead to a kind of "take it or leave it" behavior. The initiator proposes doing "childless", and if the responder does not agree, the IKE SA breaks.

At least for the remote access case, where we want a stand-by IKE SA so that eventually we can have child SAs, this does not make sense. If the responder does not support childless, the initiator can still propose universal selectors, and the responder will narrow them down to a (possibly useless) valid SA.

I think a better option is to have a notify/VID payload, with flags indicating whether a childless exchange is wanted, required or prohibited, and whether subsequent child SAs should be permitted.  This does still have a problem where the initiator requires that the IKE_AUTH be childless and the responder does not support the extension.

Alternatively, we could adopt Yaron's suggestion, and make a new payload, with a critical bit turned on or off according to requirement level. I don't like having empty payloads, but I can't back up this dislike with any good argument.

Maybe when we make version 2.1 of IKE, we can add a "critical type" bit to the notification payload.
________________________________
From: Raj Singh [mailto:[email-masked]]
Sent: Wednesday, July 08, 2009 7:18 AM
To: Tero Kivinen
Cc: Yaron Sheffer; [email-masked]; Yoav Nir
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Tero,

Thanks for your valuable inputs.
Please find re inputs inline. <Raj>
On Wed, Jul 8, 2009 at 1:00 AM, Tero Kivinen <[email-masked]<mailto:[email-masked]>> wrote:
That is not correct way of using critical bit. Critical bit means that
if it is set and the PAYLOAD TYPE is not understood, then
UNSUPPORTED_CRITICAL_PAYLOAD error is reported. Every implementation
will understand Notify and Vendor ID payloads, thus they will never
return UNSUPPORTED_CRITICAL_PAYLOAD regardless what the contents of
those payloads are.
<Raj>
I  was under impression that we can have "critical" bit in childless IKE_AUTH notify/VID.
Even Yaron also clarified in same thread that we need new exchange type to have "critical" bit on it.

If we can't have "critical" bit inside associated data of childless notify/VID,  then

--
[email-masked]<mailto:[email-masked]>

With Regards,
Raj

---

From: Raj Singh <[email-masked]>
Date: Thu, 9 Jul 2009 09:03:24 +0530

Hi Yoav,

So, we have 2 solutions:

1. New "Childless" payload with "critical" bit send by initiator
   Pros:
        i. Helps initiator and responder to have finer policy to allow/deny
childless IKE_AUTH.
        ii. Responder will not process IKE_SA_INIT if Initiator wants only
childless IKE_AUTH.
        iii. Backward compatible.

   Cons:
        i. Requires a NEW payload with NOT MUCH data in it.

2. New "childless" notify/VID with "critial" bit in associated data.
   Pros:
        i. No need for NEW payload type.
   Cons:
        i. NOT backward compatible.

The solution 1 looks GOOD to me.

With regards,
Raj

On Wed, Jul 8, 2009 at 11:19 AM, Yoav Nir <[email-masked]> wrote:

>  I don’t like either Yaron’s or Tero’s suggestions, as both lead to a kind
> of “take it or leave it” behavior. The initiator proposes doing “childless”,
> and if the responder does not agree, the IKE SA breaks.
>

>
> At least for the remote access case, where we want a stand-by IKE SA so
> that eventually we can have child SAs, this does not make sense. If the
> responder does not support childless, the initiator can still propose
> universal selectors, and the responder will narrow them down to a (possibly
> useless) valid SA.
>
>
>
> I think a better option is to have a notify/VID payload, with flags
> indicating whether a childless exchange is wanted, required or prohibited,
> and whether subsequent child SAs should be permitted.  This does still have
> a problem where the initiator requires that the IKE_AUTH be childless and
> the responder does not support the extension.
>
>
>
> Alternatively, we could adopt Yaron’s suggestion, and make a new payload,
> with a critical bit turned on or off according to requirement level. I don’t
> like having empty payloads, but I can’t back up this dislike with any good
> argument.
>
>
>
> Maybe when we make version 2.1 of IKE, we can add a “critical type” bit to
> the notification payload.
> *Sent:* Wednesday, July 08, 2009 7:18 AM
> *To:* Tero Kivinen
> *Cc:* Yaron Sheffer; [email-masked]; Yoav Nir

---

From: Gaurav Poothia <[email-masked]>
Date: Thu, 9 Jul 2009 04:56:40 +0000

Hello Yoav,
Are you suggesting that in this scenario the initiator will not tear down the IKE SA on getting a CHILD SA specific error (NO_PROPOSAL_CHOSEN) for the AUTH exchange response ?
Shouldn't the IKE SA also be torn down because while the error notify doesn't explicitly fail the AUTH there is no explicit indication of success either.
Or did you have a response in mind that had all the relevant IKE SA related payloads intact and a single error notify for the CHILD SA?

BTW perhaps the authors should consider motivating scenario ( c ) where it is the responder that wants a childless IKE SA instead of the initiator, with usage scenarios or alternatively consider making it an explicit non-goal.
I was under the impression it's the initiator that requests this feature and the responder might/might not oblige based on whether it implements the extension.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, July 06, 2009 6:15 AM
To: 'Raghunandan P (raghup)'; Raj Singh
Cc: [email-masked]
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Raghu

Hi Yoav/Raj,

Regards
Raghu

Hi Yoav,

With Regards,
Raj

Hi Yoav,

Thanks,
Raj

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Jul 2009 08:08:02 +0300

As it is, RFC 4306 mandates that if the problem is only with the CHILD SA payloads, then all the IKE SA payloads (including the AUTH and CFG) should be returned, followed by a child SA error (like NO_PROPOSAL_CHOSEN) which fails only the child SA.

I agree that scenario (c) is not really solvable, because the policies actually conflict.

________________________________
From: Gaurav Poothia [mailto:[email-masked]]
Sent: Thursday, July 09, 2009 7:57 AM
To: Yoav Nir; 'Raghunandan P (raghup)'; Raj Singh
Cc: [email-masked]
Subject: RE: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hello Yoav,

Hi Raghu

Hi Yoav/Raj,

Regards
Raghu

Hi Yoav,

With Regards,
Raj

Hi Yoav,

Thanks,
Raj

Yoav

---

From: Valery Smyslov <[email-masked]>
Date: Thu, 9 Jul 2009 11:43:11 +0400

Hi all,

I think, adding new payload or exchange type is a real overkill for
such a small extension.
IKE has well defined mechanism for advertising/negotiating new
extensions via VID or Notify.
Other extensions (like MOBIKE) use it, so why multiply entities unnecessarily?

Then, I'd rather leave a decision whether to proceed with childless or
full versions
of IKE_AUTH exchange completely at initiator's discretion. After all,
it is he/she, who
knows what happened - either user pressed "connect" button or there
was a real packet.
I think, responder should not have any policy on this - just capability.
How could, for example, he/she insist on childless IKE SA if initiator
has a real
packet to protect? In this case it will either lead to denial of communication
or initiator will probably create childless IKE SA following by CREATE_CHILD_SA,
increasing unnecessary load on responder. Prohibiting childless IKE SA
by responder
doesn't make much sense either - nothing prevents initiator from following
current behaviour - creating dummy IPsec SA and immediately deleting it.
All responder has in this case is again unnecessary load on herself/himself.

>From my point of view, childless mode is just a usefull protocol optimization,
and it is initiator, who must decide whether to use it. For this purpose
peers must exchange VID/Notify payloads during IKE_SA_INIT, claiming their
capabilities to proceed with childless IKE_AUTH. Then, if both
sides support it, initiator decides whether to use it. In this case responder
must be prepared to both versions of IKE_AUTH. If responder doesn't
support this extension, it naturally doesn't send corresponding VID/Notify.
At this point initiator must either proceed with current behaviour - dummy IPsec
proposal (if she/he really wants IKE SA) or terminate exchange if she/he
doesn't support current behaviour (in which case it is a misconfiguration).

Regards,
Valery Smyslov.

2009/7/8, Yoav Nir <[email-masked]>:
> I don't like either Yaron's or Tero's suggestions, as both lead to a kind of
> "take it or leave it" behavior. The initiator proposes doing "childless",
> At least for the remote access case, where we want a stand-by IKE SA so that
> eventually we can have child SAs, this does not make sense. If the responder
> does not support childless, the initiator can still propose universal
> selectors, and the responder will narrow them down to a (possibly useless)
> valid SA.
>
> Alternatively, we could adopt Yaron's suggestion, and make a new payload,
> with a critical bit turned on or off according to requirement level. I don't
> like having empty payloads, but I can't back up this dislike with any good
> argument.
>
> On Wed, Jul 8, 2009 at 1:00 AM, Tero Kivinen
> <[email-masked]<mailto:[email-masked]>> wrote:
> Raj Singh writes:

---

From: Raj Singh <[email-masked]>
Date: Thu, 9 Jul 2009 14:25:23 +0530

Hi Valery,

> doesn't support current behaviour (in which case it is a misconfiguration).

The problem with this approach is if responder does not support this
extension,
then also it will process IKE_SA_INIT, (involving CPU intensive D-H
calculation)
which will be eventually dropped by initiator, if initiator wants to do only
childless IKE_AUTH.
Its good to be backward compatible.

With Regards,
Raj

> that
> > Maybe when we make version 2.1 of IKE, we can add a "critical type" bit
> to

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 9 Jul 2009 13:09:27 +0400

Hi Raj,

if responder doesn't support this extension, initiator will determine it after IKE_SA_INIT
and continue with current approach (dummy IPsec proposals). If initiator cannot
do it, they won't communicate anyway. In this case initiator is broken, because
it cannot deal with old (unsupported) responders.

Again, I think that this extension is just a minor protocol optimization for such
situations, when child SA is not really necessary. Supporting this extension
for initiator doesn't mean that current approach must be fully abandoned.

Regards,
Valery Smyslov.
  ----- Original Message ----- 
  From: Raj Singh 
  To: Valery Smyslov 
  Cc: Yoav Nir ; Tero Kivinen ; [email-masked] 
  Sent: Thursday, July 09, 2009 12:55 PM
  Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

  Hi Valery,

    Hi all,

    From my point of view, childless mode is just a usefull protocol optimization,
    and it is initiator, who must decide whether to use it. For this purpose
    peers must exchange VID/Notify payloads during IKE_SA_INIT, claiming their
    capabilities to proceed with childless IKE_AUTH. Then, if both
    sides support it, initiator decides whether to use it. In this case responder
    must be prepared to both versions of IKE_AUTH. If responder doesn't
    support this extension, it naturally doesn't send corresponding VID/Notify.
    At this point initiator must either proceed with current behaviour - dummy IPsec
    proposal (if she/he really wants IKE SA) or terminate exchange if she/he
    doesn't support current behaviour (in which case it is a misconfiguration).
  The problem with this approach is if responder does not support this extension,
  then also it will process IKE_SA_INIT, (involving CPU intensive D-H calculation)
  which will be eventually dropped by initiator, if initiator wants to do only childless IKE_AUTH.
  Its good to be backward compatible.

    Regards,
    Valery Smyslov.

  With Regards,
  Raj