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.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot- > positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/ > > > > ---------------------------------------------------------------------- > 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 > _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
