Hi Yoav,
So, we have 2 solutions:
1. New "Childless" payload with "critical" bit send by initiator
Pros:
i. Helps initiator and responder to have finer policy to allow/deny
childless IKE_AUTH.
ii. Responder will not process IKE_SA_INIT if Initiator wants only
childless IKE_AUTH.
iii. Backward compatible.
Cons:
i. Requires a NEW payload with NOT MUCH data in it.
2. New "childless" notify/VID with "critial" bit in associated data.
Pros:
i. No need for NEW payload type.
Cons:
i. NOT backward compatible.
The solution 1 looks GOOD to me.
With regards,
Raj
On Wed, Jul 8, 2009 at 11:19 AM, Yoav Nir <y...@checkpoint.com> wrote:
> 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> 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
>
>
> With Regards,
> Raj
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
