Hi Raj,
if responder doesn't support this extension, initiator will determine it after
IKE_SA_INIT
and continue with current approach (dummy IPsec proposals). If initiator cannot
do it, they won't communicate anyway. In this case initiator is broken, because
it cannot deal with old (unsupported) responders.
Again, I think that this extension is just a minor protocol optimization for
such
situations, when child SA is not really necessary. Supporting this extension
for initiator doesn't mean that current approach must be fully abandoned.
Regards,
Valery Smyslov.
----- Original Message -----
From: Raj Singh
To: Valery Smyslov
Cc: Yoav Nir ; Tero Kivinen ; ipsec@ietf.org
Sent: Thursday, July 09, 2009 12:55 PM
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
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
