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