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] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
