Hi Valery, On Thu, Jul 9, 2009 at 1:13 PM, Valery Smyslov <sva...@gmail.com> wrote:
> 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). The problem with this approach is if responder does not support this extension, then also it will process IKE_SA_INIT, (involving CPU intensive D-H calculation) which will be eventually dropped by initiator, if initiator wants to do only childless IKE_AUTH. Its good to be backward compatible. > > > Regards, > Valery Smyslov. > With Regards, Raj > > > 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
