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:rsjen...@gmail.com] Sent: Wednesday, July 08, 2009 7:18 AM To: Tero Kivinen Cc: Yaron Sheffer; ipsec@ietf.org; 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 <kivi...@iki.fi<mailto:kivi...@iki.fi>> wrote: Raj Singh writes: > 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. 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 initiator want to childless IKE_AUTH, it will send CHILDLESS_IKE_AUTH > 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... <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. -- kivi...@iki.fi<mailto:kivi...@iki.fi> With Regards, Raj
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
