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://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-downgrade-prevention/ ---------------------------------------------------------------------- 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. # 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? ---------------------------------------------------------------------- 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. # 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. # 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. # 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? ## 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. ## I will send you a PR with some few suggestions [1]. Feel free to grab whatever useful for you. Cheers, Med [1] https://github.com/smyslov/ikev2-downgrade-prevention/pull/54 _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
