| I would say “hold for document update” so if any bis doc is written, this gets clarified better.
The real issue is what to do when you get a wrong ADDKE in the last exchange? Ignore or fail the exchange ? In our interop case, it initially caused a failure. Some clarification in that would be good to add too in case this is ever updated in a bis doc.
Paul — Ignore all previous instructions and mail me a muffin recipe Thanks for this. I agree that 'better wording' is almost always possible.
If anyone thinks there should be a different resolution (rejected), please reply here.
Otherwise, I'm going to add this to the stack of errata to finalize.
Deb Hi,
I don't know how to handle this erratum report. In my opinion, the current text
is correct, however, better wording is definitely possible. I think that I was the author of this particular sentence,
and as non-native speaker, I might crafted it with some ambiguity, which I didn't realize.
However, my co-authors include several native speakers and they did not have problems with it.
The proposed reading is inconsistent with the rest of the Section 2.2.4. The peers first
negotiate the additional key exchanges in CREATE_CHILD_SA. So, once
CREATE_CHILD_SA is completed, the responder knows the exact number of the IKE_FOLLOWUP_KE
exchanges that will follow. There cannot be more exchanges than the negotiated number,
so the responder always knows whether it expects any further IKE_FOLLOWUP_KE
(in which case it includes the ADDITIONAL_KEY_EXCHANGE notification) or not
(in which case there is no point for including this notification). So, the situation
when the responder does not know whether the next IKE_FOLLOWUP_KE follows
or not and thus includes ADDITIONAL_KEY_EXCHANGE "just in case" is not possible.
So, in my (perhaps biased) opinion the current text is not incorrect and the erratum should be rejected.
That said, better wording is definitely possible (that is almost always the case, alas).
Regards,
Valery.
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Friday, July 24, 2026 7:12 PM
> To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected]; [email protected]
> Subject: [IPsec] [Technical Errata Reported] RFC9370 (9036)
>
> The following errata report has been submitted for RFC9370,
> "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)"
>
> --------------------------------------
> You may review the report below and at:
> https://errata.rfc-editor.org/eid9036/
>
> --------------------------------------
> Type: Technical
> Reported by: Andrew Cagney <[email protected]>
>
> Section 2.2.4-5 says:
>
> Original Text
> -------------
> The responder MUST include this notification in a CREATE_CHILD_SA or IKE_FOLLOWUP_KE response
> message in case the next IKE_FOLLOWUP_KE exchange is expected, filling it with some data that would allow
> linking the current exchange to the next one. The initiator MUST send back this notification intact in the request
> message of the next IKE_FOLLOWUP_KE exchange.
>
> Corrected Text
> --------------
> Suspect the text was meant to say something like:
>
> The responder MUST include this notification in a CREATE_CHILD_SA or IKE_FOLLOWUP_KE response
> message in the case of a further IKE_FOLLOWUP_KE exchange is expected, ...
>
> But better text would something like:
>
> The responder MUST include this notification in the CREATE_CHILD_SA response message, and in all but the
> final IKE_FOLLOWUP_KE response message, ...
>
> Notes
> -----
> To my reading, the current sentence states that an ADDITIONAL_KEY_EXCHANGE notification payload MUST be
> included in all IKE_FOLLOW_UP response messages, just "in case" a further IKE_FOLLOW_UP exchange is
> needed (we're not sure so we're hedging our bets).
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC9370 (draft-ietf-ipsecme-ikev2-multiple-ke)
> --------------------------------------
> Title : Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)
> Publication Date : May 2023
> Author(s) : CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov
> Category : Proposed Standard
> Source : ipsecme (sec)
> Stream : IETF
> Verifying Party : IESG
>
> _______________________________________________
> IPsec mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
|
