[IPsec] Re: draft-ietf-ipsecme-ikev2-downgrade-prevention-05 ietf last call Opsdir review
Christopher Patton <cpatton@cloudflare.com> Wed, 10 June 2026 14:56 UTC
Return-Path: <cpatton@cloudflare.com>
X-Original-To: ipsec@mail2.ietf.org
Delivered-To: ipsec@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 525CBFEC3B02 for <ipsec@mail2.ietf.org>; Wed, 10 Jun 2026 07:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781103418; bh=zV5M5cmF6GYuTTpM+eGsFtMeD7zBwxajbQvX8NmSMWA=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=MPm4eZqAa85PZVuVmwHldV77rOd4r+y+m5i2H2L9nq/uFDe15YZxmLIDcfwWeDht2 ymjkgrZLGPbi+OEG2vKGi795XF4wL194dwXI5/tLJfdJEkYaxw8OeNUnCffnLd+cgO BKgZm6xXEC2Edym8Is81TcjhNGlJrw/NswuDEFD0=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cloudflare.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mJu_7X7kwwe for <ipsec@mail2.ietf.org>; Wed, 10 Jun 2026 07:56:57 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D51FCFEC399D for <ipsec@ietf.org>; Wed, 10 Jun 2026 07:55:44 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-517dc520840so11573521cf.3 for <ipsec@ietf.org>; Wed, 10 Jun 2026 07:55:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1781103344; cv=none; d=google.com; s=arc-20240605; b=WOn1+GO5lGpmOCPXV3uGcbPfaVwef4pbDq4uEHAplOhPumrEmCNnp9SGYXZUFq7MYm 2nly1tP+OAoFdmIi+PXToYCBGF2om5ItAcd2P1LP9Hkg9uMZG6n9qsukEsoDgHBpqshG qzKmZcQAvNAPimapWSDe6WKJjzfuMKS0y6b8U7chOKLDZXuBQIWQumAP4xqGZBftxPwg uKRYcHZedDb29nbw4pmcXsIQBDnmgvoni7miuXYGuhBL+fRk0Ob2syYXutuhobiEFfTP 0BpZcOrU34LeiIRw195WpDyEL0m2EDyEZJAoBgZQvhXZgZeC4VvpoamIoeDrRJDir9fs fCeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=zV5M5cmF6GYuTTpM+eGsFtMeD7zBwxajbQvX8NmSMWA=; fh=9hOkccEsu7vf4IiUjeK/ZgNRMHrvNYjP5HTEn46EQ8s=; b=XRqVQvpMsZjntfG0PmE+LXpJ7JX6fS32ZhjHpWZQnuNci9pQ6pImZG3e4LWFWRrD4s wk39v6fVPNKfWEDpKE3ChfeTXwfbz10dY2ypj77mMRFDzQ4Ho2JmYh2BgpUlEcdWwAJu x2LCiKX21Pa47ODzKcIvJvNCznPDqAFHvjDsjE/C5RgkHzPYAXec9mo9nndDSJquYdQk vccMb7LaaeWrnMFDY34E9OnW8A0oyCzwYHQ8a84qWRagNp3edzFv8jvs83jEKont1veK GqOYH98peh1nFnrCxwoS5r39OXaVms5aevRQi2iVC7SqOrpk22vmkvqSDwslaiMQFAVr /AxQ==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1781103344; x=1781708144; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zV5M5cmF6GYuTTpM+eGsFtMeD7zBwxajbQvX8NmSMWA=; b=E+IeNdR63Szx1xz1cJHGNZTa1QmahDBrfqUD+imR5mcTy57zQZBNHj2NZYU2K0MS+X WOoKeP3Qyip2bIbi6hh/FXgkFNy+GjTWZcTR8jDMFilmzv4fJpM1oMMKjaXy58BAab4h tT9NIdUY7w7CEI7RUP4nbJGgDx2HPvTplCtMwwsXzK8hRO3av64mIjBKw2SM7RzXW7/i 3tTVoOp3lMl9PKzy1bOlxFl1b+pk+r1XUvaQG9nf+YYXjPqgWjcuCDMuJCYJs9Gx9CSx XLBo4H9Xo0rjitd9B+6FCG4XMM1nTfOv2j8a99XCN6RU3cQuSM+BfPjn8IZHQrkvcYZ9 hjWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781103344; x=1781708144; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zV5M5cmF6GYuTTpM+eGsFtMeD7zBwxajbQvX8NmSMWA=; b=tU0J5DowE1KjrnU5fxg3HtPZ56eI1KJlqHUHFR6Dw+K1Rt0P+QhJx+VTV3vWl/jo71 JariIAFjza6W3wBblZmwt40s62h1rwGWMoiTdWOz0nQ5vfarZVxgzW0422eYkCIP0nC1 o6Zs2uu9cPOtbffeVKk4CS/G9juz86YwUUmW93bPKNhaJegG9jJSeJ+rd/RsNVSRaT+Z ZpJtq3TaLZJvkbzdmsFl/omqdeY/KtoZ+4hc8ZiPW8EjFXNfe8UAhE6kRUnrzoLYyZdq w3uqefFSRutM543moZwkcFozy84D3oywa5aZDxOeMrx0DneI+It+L3iPzgasGq+iAVQm +Rig==
X-Forwarded-Encrypted: i=1; AFNElJ+6bRBETqzGlqmHtIdpVMmh6HwdtIgbUSSmgXael25JzkdwWjcwsW3WS6Osj7EvpPNbvBSmUQ==@ietf.org
X-Gm-Message-State: AOJu0YyoqALX+hLiOpKtoHCGcb2fgp3s7jVxXDY24HkqYgPpZ6TSVci0 lPjvqdRbZ4tddrYUp5Ju8uGqCQFoCOfzPfxB5g/rreifRQHCe/24X8agZKcbESoI4URno4y2t8F JtP4FfNJD9JmgRodGIsNpq3EoPzAWWt1tTleGi+uXxgUJiUA6dSLEpTk=
X-Gm-Gg: Acq92OGHfj/utCG2+1wbPD36V1MiHLntlTofWNAB4KCtGEmRJghRzoemMJDcVak6igB KNwDnn+EaxloM/9kGbCrYMladrYc3UyZROQGt83QjzA7dGkCxmJ5uDDmUju7hXrFi3rq6oxLdqB mL1A1+rB6OuED3MQauk8hDff3QiOFzR8id6O+KmeKbIOciWjM5t+HE2Zo9fvb+ar0VZ7SxZrusU HYLV3UXGBOliNgihvuTgQAQ6tB8/v4eXvXFZFnAZ3U3iciATtGx/GXbG4XOI2LTfyt3l8m8jOy2 WOYqmLBDP5q1Wc2PAR7JghySiuEAcTCvexCS9NLCpIvB/YuZtOpv6hncvxabc9g2T7mEmEyaIgZ A1IjptYSF47gsHwIdt3thgg==
X-Received: by 2002:ac8:5519:0:b0:517:9f03:a659 with SMTP id d75a77b69052e-5179f03cdb5mr244911491cf.12.1781103344120; Wed, 10 Jun 2026 07:55:44 -0700 (PDT)
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
X-Gm-Features: AVVi8Cc9_38CTVM4MinpM94abhAelXbM08RGjQM-YYI6kIBKSG5218Y_7jZ_-jk
Message-ID: <CAG2Zi223Ao4mM2ah8HA0YUtZZPT9fHD9UBDdub5LMwp7w6d8QQ@mail.gmail.com>
To: Dhruv Dhody <dd@dhruvdhody.com>
Content-Type: multipart/alternative; boundary="00000000000022a19d0653e7703f"
Message-ID-Hash: HAKRJWTCHUP2WHMCAZGVLH3PY63SHWL2
X-Message-ID-Hash: HAKRJWTCHUP2WHMCAZGVLH3PY63SHWL2
X-MailFrom: cpatton@cloudflare.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipsec.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ops-dir@ietf.org, draft-ietf-ipsecme-ikev2-downgrade-prevention.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [IPsec] Re: draft-ietf-ipsecme-ikev2-downgrade-prevention-05 ietf last call Opsdir review
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/J7HQFKcf5Jv8uqPcZQ6oPGvuGjA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Owner: <mailto:ipsec-owner@ietf.org>
List-Post: <mailto:ipsec@ietf.org>
List-Subscribe: <mailto:ipsec-join@ietf.org>
List-Unsubscribe: <mailto:ipsec-leave@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.
- [IPsec] draft-ietf-ipsecme-ikev2-downgrade-preven… Dhruv Dhody via Datatracker
- [IPsec] Re: draft-ietf-ipsecme-ikev2-downgrade-pr… Christopher Patton
- [IPsec] Re: [OPS-DIR]Re: draft-ietf-ipsecme-ikev2… Dhruv Dhody