Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

[Valery Smyslov <[e-mail]>]

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 <[e-mail]>:
> 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:[e-mail]]
> Sent: Wednesday, July 08, 2009 7:18 AM
> To: Tero Kivinen
> Cc: Yaron Sheffer; [e-mail]; 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
> <[e-mail]<mailto:[e-mail]>> 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.
>
> --
> [e-mail]<mailto:[e-mail]>
>
> With Regards,
> Raj
>