Subject: [IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_INIT

From: Yaron Sheffer <[email-masked]>
Date: Mon, 27 Apr 2009 22:51:58 +0300

>  2.5.  Version Numbers and Forward Compatibility

...

>     IKEv2 adds a 'critical' flag to each payload header for further

>     flexibility for forward compatibility.  If the critical flag is set

>     and the payload type is unrecognized, the message MUST be rejected

>     and the response to the IKE request containing that payload MUST

>     include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an

>     unsupported critical payload was included. {{ 3.10.1-1 }} In that

>     Notify payload, the notification data contains the one-octet payload

>     type.  If the critical flag is not set and the payload type is

>     unsupported, that payload MUST be ignored.  Payloads sent in IKE

>     response messages MUST NOT have the critical flag set.  Note that the

>     critical flag applies only to the payload type, not the contents.  If

>     the payload type is recognized, but the payload contains something

>     which is not (such as an unknown transform inside an SA payload, or

>     an unknown Notify Message Type inside a Notify payload), the critical

>     flag is ignored.

Tero:

What if such UNSUPPORTED_CRITICAL_PAYLOAD error happens during the

initial IKE_SA_INIT message, or do we forbid enhancements and

modifications which might cause such error?

Paul: Not done. This is interesting, but should be discussed on the list.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 30 Apr 2009 10:15:10 +0300

I don't think we should really prohibit such extensions and enhancements.  It's just that IKE will fail if you try it with a peer that does not support it.

As far as the end-user is concerned, this is not different from an UNSUPPORTED_CRITICAL_PAYLOAD in IKE_AUTH.  Either way, the tunnel setup fails.

Do you see any cause for concern in the UNSUPPORTED_CRITICAL_PAYLOAD being sent in a non-encrypted unauthenticated message?  Or in a response to such?

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Monday, April 27, 2009 10:52 PM
To: IPsecme WG
Subject: [IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_INIT

...

Tero:

Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Apr 2009 14:59:10 +0300

Yoav Nir writes:
> I don't think we should really prohibit such extensions and
> enhancements.  It's just that IKE will fail if you try it with a
> peer that does not support it.

Yes, but most likely it will ignore unauthenticated error
notifications too, so it will fail only after timeout. 

> As far as the end-user is concerned, this is not different from an
> UNSUPPORTED_CRITICAL_PAYLOAD in IKE_AUTH.  Either way, the tunnel
> setup fails. 

Yes.

> Do you see any cause for concern in the UNSUPPORTED_CRITICAL_PAYLOAD
> being sent in a non-encrypted unauthenticated message?

It can be sent, but as the UNSUPPORTED_CRITICAL_PAYLOAD contains the
payload number in, it might be good idea to say that if the payload
which had that critical payload was encrypted, then the notification
must also be encrypted (this applies to the especially to IKE_AUTH).

If such error happens during IKE_SA_INIT, then response will be in
clear anyways, and it will most likely be ignored by the initiator
anyways (it could use it to shorten its timeouts, but must not fail
the negotiation immediately). 

Question really is, if we want to add something about this to the
document or not?
-- 
[email-masked]