Hi Yoav, Yaron,
Sorry, I disagree. This notification is concerned with both "old" IKE SA (as
Child SAs "sponsor") and
"new" IKE SA (as "acceptor"). So, to remain in concent with RFC5996 and to
be logically consistent,
I'd suggest to make SPI field empty (and Protocol ID zero) and to move SPI
for "new" IKE SA to Notification Data.
No new values for Protocol ID is needed.
Regards,
Valery.
So we can creatively interpret "the IKE SA" to be different from "an IKE
SA", or we can ask IANA to add a new value with meaning "other IKE SA".
Agree it's a corner case.
> Hi Yoav,
>
> Regarding the notification syntax, it is actually a bit worse than that.
> This is a corner case in the RFC, but if you read Sec. 3.10 literally,
> there are exactly 2 allowed values for the Protocol ID field (or 3
> values, if you read RFC 4306).
> There is no extensibility defined, and no IANA registry either. So a
> responder would be correct if it replied with an INVALID_SYNTAX rather
> than ignoring your
> notification, if it doesn't recognize it.
>
> And the value you are using (1) comes from RFC 2407 and has never
> existed in IKEv2. Ugh.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
