[IPsec] Re: Mohamed Boucadair's Discuss on draft-ietf-ipsecme-ikev2-downgrade-prevention-06: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Valery, 

Thank you for this update. These changes resolve the issues. Will clear right now.

Cheers,
Med

> -----Message d'origine-----
> De : Valery Smyslov <[e-mail]>
> Envoyé : mercredi 1 juillet 2026 14:19
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> 'The IESG' <[e-mail]>
> Cc : [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-ipsecme-
> ikev2-downgrade-prevention-06: (with DISCUSS and COMMENT)
> 
> 
> Hi Med,
> 
> we decided to change the text in Section 7 to avoid using the
> normative language, so that the problematic references can be left
> informative. We hope this resolves your DISCUSS.
> 
> New version:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/08/

 
> The diff:
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-ipsecme-ikev2-
> downgrade-prevention-
> 08&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca726cb0330e245f
> 3dba908ded76b22d8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639
> 185052320149109%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl
> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
> %7C0%7C%7C%7C&sdata=MF5803sKKuiw1dufzwutTK4DkuVB9VJt00wh4nU8go0%3D
> &reserved=0
> 
> Regards,
> Chris & Valery.
> 
> > Hi Med,
> >
> > please, see inline.
> >
> > > Mohamed Boucadair has entered the following ballot position
> for
> > > draft-ietf-ipsecme-ikev2-downgrade-prevention-06: Discuss
> > >
> > > When responding, please keep the subject line intact and reply
> to
> > > all email addresses included in the To and CC lines. (Feel
> free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> > > w.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-
> ballot-po
> > >
> sitions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca726cb0
> 33
> > >
> 0e245f3dba908ded76b22d8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0
> %7
> > >
> C639185052320167079%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> Us
> > >
> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D
> > >
> %7C0%7C%7C%7C&sdata=tKKtCLW6jU%2FQHbkRlJnYHK%2BLIPI1H9HRZtDNZUQ9MG
> A%
> > > 3D&reserved=0 for more information about how to handle DISCUSS
> and
> > > COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found
> here:
> > >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> da
> > > tatracker.ietf.org%2Fdoc%2Fdraft-ietf-ipsecme-ikev2-downgrade-
> preven
> > >
> tion%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca726cb0330
> e2
> > >
> 45f3dba908ded76b22d8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 63
> > >
> 9185052320182281%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> lY
> > >
> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C
> > >
> 0%7C%7C%7C&sdata=4gypKVa67fAGGZr%2BMe1%2BVJP6IiCuFwc9EhltAU7yf20%3
> D&
> > > reserved=0
> > >
> > >
> > >
> > > --------------------------------------------------------------
> ------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------
> ------
> > > --
> > >
> > > Hi Valery and Christopher,
> > >
> > > Thank you for the effort put into this well-written spec.
> > >
> > > Thanks Dhruv Dhody for the OPSDIR review. Thanks to the
> authors for
> > > the follow-up. I saw that you added an ops cons section in
> your github copy. Thanks.
> > >
> > > I have two straightforward points to discuss. Let me know if I
> missed something:
> > >
> > > # IKE_INTERMEDIATE exchange
> > >
> > > CURRENT:
> > >    If peers
> > >    support the extension defined in this document, then they
> MUST treat
> > >    modified blocks of data to be signed (or MAC'ed) defined in
> Section 6
> > >    as replacements for blocks of data defined in Section 2.15
> of IKEv2
> > >    [RFC7296], so that in case of IKE_INTERMEDIATE the IntAuth
> is added
> > >    to these modified blocks.
> > >
> > > Adhering to this requires RFC9242. I think that RFC should be
> listed
> > > as normative.
> >
> > I understand your point, but it is questionable from our logic.
> >
> > Our logic is as follows - normative references must _absolutely_
> be
> > read to correctly implement the spec. If we make RFC 9242
> normative,
> > but (for some arbitrary reason) an implementer does not intend
> to
> > implement it, wanting to only add a downgrade prevention to the
> core
> > IKEv2, then reading RFC 9242 is not needed.
> >
> > Please, don't get me wrong - it's not a big deal to make RFC
> 9242
> > normative, but my internal feeling of consistency will suffer :-
> )
> >
> > We don't have conditional normative references, alas :-)
> >
> > Note that we previously published RFCs with sections describing
> > interactions with other IKEv2 extensions and RFCs listed there
> were
> > still listed as informative (even in presence of some normative
> > language). See Section 4 of RFC 9593 and SEction 4 of RFC 9242
> as examples.
> >
> > > # Resumption
> > >
> > > CURRENT:
> > >    The information of whether an implementation used the new
> > >    authentication logic for old SA MUST be stored in the
> ticket and the
> > >    implementation MUST act the same way when doing resumption.
> > >
> > > There is not ticket discussion in the base IKEv2 spec (or I
> missed
> > > it). Why
> > > RFC5723 isn't listed as normative here?
> >
> > For the same logic as above.
> >
> >
> > > --------------------------------------------------------------
> ------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------
> ------
> > > --
> > >
> > > # Full symmetry
> > >
> > > CURRENT:
> > >    1.  The attacker must be on the path with the ability to
> intercept
> > >        communications between the peers and to modify their
> messages.
> > >
> > > I think the condition is even stronger as the attacker has to
> be
> > > on-path for both directions and for the ** full ** exchanges.
> >
> > This is true, but does not the current text imply this? I mean
> that we
> > do not add any restrictions on message direction etc,, thus, in
> my
> > reading, it automatically means that an attacker must be able to
> read
> > and modify messages in both directions and for the unlimited
> > duration.Perhaps my reading is too liberal :-)
> >
> > > # Given the attack assumptions, how the initiator is expected
> to be
> > > behave if the attacker blocks received messages with the
> extension.
> > > Is it usual to disable some extensions when such failures are
> > > experienced by a peer? If so, the benefits of the new
> extension can be nullified by such attacker behavior.
> >
> > If both peers support this extension, then the attacker cannot
> _force_
> > peers to establish IKE SA as if this extension is not supported.
> > However, the attacker can always _prevent_ peers from
> establishing IKE
> > SA. If the attacker is on the path an can block IKE messages
> then it
> > is impossible to prevent this kind of attack, with or without
> this extension.
> >
> > > # Receiver side
> > >
> > > CURRENT:
> > >    If the responder supports this extension then it also
> includes this
> > >    notification in the response message regardless of whether
> it was
> > >    received in the request or not.
> > >
> > > ## What is the benefit of sending the extension back even if
> this is
> > > not offered by the initiator?
> > >
> > > ## I suspect this is to ease implementations and avoid
> conditional
> > > handling at the responder but I may be missing something here.
> >
> > No, this trick is the only way to prevent the attacker from
> disabling this extension.
> > Note, that the attacker has a lot of capabilities for this
> attack - it
> > can read and modify even encrypted IKE messages and can forge
> signature of one peer (but not both).
> > This "strange" behavior, when the responder always sends
> notification
> > even if it does not receive it makes it possible to prevent
> > notification stripping by the attacker even for the current
> IKEv2
> > authentication - thus the attacker cannot force peers to not use
> this
> > extension if they support it - otherwise SA won't be
> established.
> >
> > > # nits
> > >
> > > ## Conversation
> > >
> > > CURRENT:
> > >    on this protocol by having the peers confirm they have
> participated
> > >    in the same conversation.
> > >
> > > There is formally no such concept in the base spec. Do we
> refer to session?
> > > Something else?
> >
> > Hmm... IKE SA establishment? Session is more like SA, but we are
> > referring to the process of its establishment, which includes
> several exchanges.
> > Do you think that "conversation" is not clear for readers?
> >
> > > ##
> > >
> > > CURRENT:
> > >    The details of how authentication is performed in IKEv2 are
> defined
> > >    in Section 2.15 of IKEv2 [RFC7296].
> > >
> > > I would expect the same title is the cited RFC to be used here
> (and
> > > similar) but seems that the we are mixing reference labels and
> RFC numbers.
> >
> > Tero always asks for adding short RFC title (sometimes informal)
> > before references (that in most cases are RFC numbers). Just for
> readers' convenience.
> >
> > > ## I will send you a PR with some few suggestions [1]. Feel
> free to
> > > grab whatever useful for you.
> >
> > Thanks!
> >
> > Regards,
> > Valery (for authors).
> >
> > > Cheers,
> > > Med
> > >
> > > [1]
> > >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> gi
> > > thub.com%2Fsmyslov%2Fikev2-downgrade-
> prevention%2Fpull%2F54&data=05%
> > >
> 7C02%7Cmohamed.boucadair%40orange.com%7Ca726cb0330e245f3dba908ded7
> 6b
> > >
> 22d8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6391850523201964
> 23
> > >
> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM
> CI
> > >
> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda
> ta
> > > =Fwwgf4pBOJ1LMB%2BV56XQhJMM3Tt65jvjiSWPXeMPZC4%3D&reserved=0
> > >
> 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.