Subject: [IPsec] Re: draft-ietf-ipsecme-ikev2-downgrade-prevention-05 ietf last call Opsdir review
From: Christopher Patton <[email-masked]>
To: Dhruv Dhody <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 10 Jun 2026 07:55:31 -0700
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>

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.