Thanks Chris! On Wed, Jun 10, 2026 at 8:27 PM Christopher Patton <cpatton= [email protected]> wrote:
> Hi Dhruv, thank you very much for the review! Responses inline. > > >> ## **General Operational Comments Alignment with RFC 5706bis** >> >> This document defines a mechanism for preventing downgrade attacks on >> IKEv2. >> While the technical approach is sound, it lacks an explicit operational >> considerations section. >> >> The authors could consider adding a brief section if they feel there is >> useful >> operational guidance to be provided for upgrading to this extension, >> interoperability with legacy RFC7296 or on detecting & logging attempts of >> downgrade attack (is it even possible?), etc. >> > > At the moment, Valery and I don't believe an operational considerations > section is needed. There are no interoperability issues with RFC7296 that > we're aware of. There's a possibility that an incorrectly implemented > initiator or responder would handle the notify message incorrectly, but > this seems to us to be out of scope for the document. > > Detecting a downgrade attack doesn't seem possible. It would manifest as > an authentication failure: one party would attempt to verify a message that > its peer didn't actually sign. This case is indistinguishable from any > signature verification failure. > > > >> ## **Minor Issues** >> >> - Section 1, consider clarifying "the data to be authenticated" means in >> the >> context of this document. >> > > Done: https://github.com/smyslov/ikev2-downgrade-prevention/pull/43 > > >> >> - Section 6, is it possible to clearly identify what text from RFC 7296 is >> being modified because of the update tag >> > > Updates to RFC 7296 are addressed in this paragraph: > > https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-downgrade-prevention-05.html#section-1-2 > > It would be hard to pinpoint the exact text that's being updated. As far > as I understand, text about authentication logic is dispersed throughout > RFC 7296. > > > >> - Section 7, are you updating text in RFC 9242 or RFC 5723? If yes, then >> we >> should use the update tag; if not, it should be clearer to the reader why >> RFC >> 7296 is the only one being updated. >> > > We introduce no changes to the RFC 9242 and RFC 5723 themselves. If an > implementation does not support this draft and implements only RFC 9242 (or > RFC 5723) then it may follow these RFCs and ignore this draft without > breaking interoperability with an endpoint that does support this draft. > > > >> ## **Nits** >> >> - Section 1, s/RFC 7296/[RFC7296]/ >> > > Done: https://github.com/smyslov/ikev2-downgrade-prevention/pull/44 > > Best, > Chris P. > _______________________________________________ > OPS-DIR 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]
