MIME-Version: 1.0
References: 
 <178098960101.792.3290089148688577218@dt-datatracker-56f887f959-j9c2v>
In-Reply-To: 
 <178098960101.792.3290089148688577218@dt-datatracker-56f887f959-j9c2v>
From: Christopher Patton <cpatton@cloudflare.com>
Date: Wed, 10 Jun 2026 07:55:31 -0700
Message-ID: 
 <CAG2Zi223Ao4mM2ah8HA0YUtZZPT9fHD9UBDdub5LMwp7w6d8QQ@mail.gmail.com>
To: Dhruv Dhody <dd@dhruvdhody.com>
Content-Type: multipart/alternative; boundary="00000000000022a19d0653e7703f"
Message-ID-Hash: HAKRJWTCHUP2WHMCAZGVLH3PY63SHWL2
CC: ops-dir@ietf.org,
 draft-ietf-ipsecme-ikev2-downgrade-prevention.all@ietf.org, ipsec@ietf.org,
 last-call@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BIPsec=5D_Re=3A_draft-ietf-ipsecme-ikev2-downgrade-prevention-05?=
 =?utf-8?q?_ietf_last_call_Opsdir_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ipsec/J7HQFKcf5Jv8uqPcZQ6oPGvuGjA>

--00000000000022a19d0653e7703f
Content-Type: text/plain; charset="UTF-8"

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.

--00000000000022a19d0653e7703f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Dhruv, thank you very much for the review! Respons=
es inline.</div><div class=3D"gmail_quote gmail_quote_container"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
## **General Operational Comments Alignment with RFC 5706bis**<br>
<br>
This document defines a mechanism for preventing downgrade attacks on IKEv2=
.<br>
While the technical approach is sound, it lacks an explicit operational<br>
considerations section.<br>
<br>
The authors could consider adding a brief section if they feel there is use=
ful<br>
operational guidance to be provided for upgrading to this extension,<br>
interoperability with legacy RFC7296 or on detecting &amp; logging attempts=
 of<br>
downgrade attack (is it even possible?), etc.<br></blockquote><div><br></di=
v><div>At the moment, Valery and I don&#39;t believe an operational conside=
rations section is needed. There are no interoperability issues with RFC729=
6 that we&#39;re aware of. There&#39;s a possibility that an incorrectly im=
plemented initiator or responder would handle the notify message incorrectl=
y, but this seems to us to be out of scope for the document.</div><div><br>=
</div><div>Detecting a downgrade attack doesn&#39;t seem possible. It would=
 manifest as an authentication failure: one party would attempt to verify a=
 message that its peer didn&#39;t actually sign. This case is indistinguish=
able from any signature verification failure.</div><div>=C2=A0</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
## **Minor Issues**<br>
<br>
- Section 1, consider clarifying &quot;the data to be authenticated&quot; m=
eans in the<br>
context of this document.<br></blockquote><div><br></div><div>Done:=C2=A0<a=
 href=3D"https://github.com/smyslov/ikev2-downgrade-prevention/pull/43">htt=
ps://github.com/smyslov/ikev2-downgrade-prevention/pull/43</a></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- Section 6, is it possible to clearly identify what text from RFC 7296 is<=
br>
being modified because of the update tag<br></blockquote><div><br></div><di=
v>Updates to RFC 7296 are addressed in this paragraph:<br><a href=3D"https:=
//www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-downgrade-prevention-05.=
html#section-1-2">https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-=
downgrade-prevention-05.html#section-1-2</a></div><div><br></div><div>It wo=
uld be hard to pinpoint the exact text that&#39;s being updated. As far as =
I understand, text about authentication logic is dispersed throughout RFC 7=
296.=C2=A0</div><div><br></div><div></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">
- Section 7, are you updating text in RFC 9242 or RFC 5723? If yes, then we=
<br>
should use the update tag; if not, it should be clearer to the reader why R=
FC<br>
7296 is the only one being updated.<br></blockquote><div><br></div><div>We =
introduce no changes to the RFC 9242 and RFC 5723 themselves. If an impleme=
ntation does not support this draft and implements only RFC 9242 (or RFC 57=
23) then it may follow these RFCs and ignore this draft without breaking in=
teroperability with an endpoint that does support this draft.</div><div><br=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
## **Nits**<br>
<br>
- Section 1, s/RFC 7296/[RFC7296]/<br></blockquote><div><br></div><div>Done=
:=C2=A0<a href=3D"https://github.com/smyslov/ikev2-downgrade-prevention/pul=
l/44">https://github.com/smyslov/ikev2-downgrade-prevention/pull/44</a></di=
v><br></div><div class=3D"gmail_quote gmail_quote_container">Best,</div><di=
v class=3D"gmail_quote gmail_quote_container">Chris P.</div></div>

--00000000000022a19d0653e7703f--