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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec