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