>  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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to