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:rsjen...@gmail.com] 
Sent: Saturday, July 04, 2009 19:39
To: Yaron Sheffer
Cc: Yoav Nir; ipsec@ietf.org
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

 

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 <yar...@checkpoint.com> 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:rsjen...@gmail.com] 
Sent: Saturday, July 04, 2009 13:37
To: Yaron Sheffer
Cc: Yoav Nir; ipsec@ietf.org


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

 

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 <yar...@checkpoint.com>
wrote:

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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Raj Singh
Sent: Friday, July 03, 2009 16:51
To: Yoav Nir
Cc: ipsec@ietf.org
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 <y...@checkpoint.com> 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: i-d-announce-boun...@ietf.org [i-d-announce-boun...@ietf.org] On
Behalf Of internet-dra...@ietf.org [internet-dra...@ietf.org]
Sent: Wednesday, July 01, 2009 12:15
To: i-d-annou...@ietf.org
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


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




Scanned by Check Point Total Security Gateway. 




Scanned by Check Point Total Security Gateway. 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to