[Swan-dev] pluto: emit_v2N's "critical" parameter since it was identical in each call

Paul Wouters paul at nohats.ca
Fri Dec 21 16:24:58 UTC 2018

On Fri, 21 Dec 2018, D. Hugh Redelmeier wrote:

> | From: Paul Wouters <paul at nohats.ca>
> | Hugh commited:
> |
> |     pluto: emit_v2N's "critical" parameter since it was identical in each call
> |
> | I think this is a mistake. Rather, we probably have some notifies which
> | are not critical.
> OK.  I've reverted the chanage.
> I take this as a commitment from you to make sure that this feature
> actually gets used.
> The other functions that emit notifications don't have this parameter.

I think I was wrong. Rereading RFC 7296:

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

So I guess this actually means, since we all must understand the Notify
type payload, even if we dont understand the content (notify type +
payload), all notify payloads do not have a critical flag.

So I guess your commit was actually correct :P


More information about the Swan-dev mailing list