On Fri, 21 Dec 2018, D. Hugh Redelmeier wrote:
| From: Paul Wouters <[email protected]>
| 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
ignored.
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
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
