Hi Valery, The changes/clarifications look good to me. Thank you.
Cheers, Med > -----Message d'origine----- > De : Valery Smyslov <s...@elvis.ru> > Envoyé : vendredi 16 mai 2025 11:02 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > 'The IESG' <i...@ietf.org> > Cc : draft-ietf-ipsecme-ikev2-qr-...@ietf.org; ipsecme- > cha...@ietf.org; ipsec@ietf.org; william.pan...@huawei.com > Objet : RE: Mohamed Boucadair's No Objection on draft-ietf-ipsecme- > ikev2-qr-alt-08: (with COMMENT) > > > Hi Med, > > please see inline. > > > Mohamed Boucadair has entered the following ballot position for > > draft-ietf-ipsecme-ikev2-qr-alt-08: No Objection > > > > 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.) > > > > ----------------------------------------------------------------- > > COMMENT: > > ----------------------------------------------------------------- > > > > Hi Valery, > > > > Thank you for the effort put into this specification. > > > > Also, thanks to Luis M. Contreras for the OPSDIR review (his > first > > review for the opsdir team, BTW) and to Valery for engaging with > Luis. > > > > Please find some comments below: > > > > # Guidance for those who will deploy > > > > From the perspective of those who will deploy, I found appendix > > useful.but somehow late. Putting aside that appendix was not > > referenced in the document, having an applicability section early > in > > the document with a guidance when to use this extension vs. > RFC8784 would be my preferred approach. > > I've added the following text at the end of Section 1 > (Introduction): > > This specification does not replace approach defined in RFC > 8784. > Both approaches for using PPKs in IKEv2 can be used depending on > the > circumstances (see Appendix A). > > Let me know if this is sufficient (I don't think a new > Applicability section is needed...). > > > # Guards against too frequent changes > > > > For example, we do have > > > > CURRENT: > > If a fresh PPK is available to both peers at the time when an > IKE SA > > is active, peers MAY use this fresh PPK without creating a new > IKE SA > > from scratch. > > > > Is there some kind of timer used as a guard to protect against > too > > frequent changes? > > Generally, the decision whether to rekey SAs is not driven by the > availability of a fresh PPK, but by the amount of time the SA is up > and/or the amount of protected data. > This is usually a local policy decision of each peer. The > availability of a fresh PPK may somewhat influence this decision > (e.g. peers may decide to rekey a bit early), but this is not the > main driver for it. > > In other words, if you are lucky to get fresh PPKs frequently, you > still are not obliged to use every new PPK to rekey SAs or create > new SAs. > > I can change the text to make it more clear: > > If a fresh PPK is available to both peers at the time when an > IKE SA > is active, peers MAY use this fresh PPK without creating a new > IKE SA > from scratch when they have a need to create additional IPsec > SAs or > to rekey existing SAs. > > Is it OK? > > > # Preference policy > > > > CURRENT: > > However, if the responder supports both specifications and is > > configured to use PPKs, it has to choose one to use, thus it > MUST > > return either USE_PPK_INT or USE_PPK notification in the > response, > > but not both. > > > > Is there any provision for policy support here? Also, can we > recommend > > a default value here? > > Each approach has its pros and contras. Appendix A lists them. > I don't think we should specify any default policy here, it will > depend on the circumstances. > > > # Exemplify shortcomings and situations > > > > It would be helpful to exemplify the shortcomings mentioned in: > > > > CURRENT: > > Instead, it is supposed to be > > used in situations where the approach defined there has a > significant > > shortcomings. > > Changed to: > > Instead, it is supposed to be > used in situations where the approach defined there does not > meet the > requirements, like the need to make the initial IKE SA quantum- > secure > or the need to choose between several available PPKs. > > > Likewise, do we have examples of situations mentioned in the > following excerpt? > > > > CURRENT: > > However, if the partners support both use PPKs in > > IKE_AUTH and this specification, then the latter MAY also be > used in > > situations where using PPKs in IKE_AUTH suffices. > > Added at the end of the sentence: > > (e.g., when initial IKE SA is not required to be quantum- > protected) > > > BTW, what is meant by "partners" mentioned in that text? Do we > mean > > initiator and responder? > > I changed: > > s/partners/peers > > Actually, the text in the following numbered list appears to be > outdated - the final version of G-IKEv2 wraps the keys, so they are > no longer transferred in the IKE SA in clear. I just noticed this > (thank you for bringing my attention to this Appendix). So, I > modified the first two items in the list to be factually correct: > > 1. The main advantage of using PPK in the IKE_INTERMEDIATE > exchange > instead of the IKE_AUTH exchange is that it allows IKE_AUTH > to be > fully protected. This means that the ID payloads and any > other > sensitive content sent in the IKE_AUTH are protected against > quantum computers. The same is true for the sensitive data > sent > in the GSA_AUTH exchange is the G-IKEv2 protocol > [I-D.ietf-ipsecme-g-ikev2]. > > 2. In addition to the IKE_AUTH exchange being fully protected, > the > initial IKE SA is also fully protected, which is important > when > sensitive information is transferred over initial IKE SA. > Examples of such situation are the CREATE_CHILD_SA exchange > of > IKEv2 and the GSA_REGISTRATION exchange of G-IKEv2 > [I-D.ietf-ipsecme-g-ikev2]. > > > # Terminology anchor > > > > As I'm there, maybe consider adding the following (or similar) to > Section 2: > > > > NEW: > > This document uses the terms defined in [RFC7296]. In > > particular, readers should be familiar with the terms > "initiator" and > > "responder" as used in that document. > > OK, done. > > All changes are made in my local copy. > > Regards, > Valery. > > > Cheers, > > Med > > > ____________________________________________________________________________________________________________ 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. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
