Hi all, I just wanted to add that we implemented this feature in our internal implementation of IKEv2 and have confirmed interop with strongswan's experimental branch:
git clone --depth 1 --branch downgrade-prevention https://github.com/strongswan/strongswan.git One thing we noticed is that the draft doesn't explicitly specify how to handle a malformed IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification (i.e., one that has a non-empty payload, a non-zero Protocol ID, or a non-zero SPI Size [1]). Our responder handles this case by sending an INVALID_SYNTAX error. (We don't implement an initiator.) My understanding is that this behavior is allowed by IKEv2, but other behaviors are allowed as well. If my understanding is correct, then I don't see a need to make the behavior explicit. Apart from that, I have no more changes for the WG to consider and I think this is ready to go. We look forward to getting a codepoint! Best, Chris P. [1] https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-downgrade-prevention-01.html#section-6-1 On Mon, Feb 16, 2026 at 9:49 AM Tero Kivinen via Datatracker < [email protected]> wrote: > This message starts a WG Last Call for: > draft-ietf-ipsecme-ikev2-downgrade-prevention-01 > > This Working Group Last Call ends on 2026-03-02 > > Abstract: > This document describes an extension to the Internet Key Exchange > protocol version 2 (IKEv2) that aims to prevent some kinds of > downgrade attacks on this protocol by having the peers confirm they > have participated in the same conversation. > > File can be retrieved from: > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping > [email protected] > in copy. Objections should be explained and suggestions to resolve them are > highly appreciated. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/ > > There is also an HTMLized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-downgrade-prevention-01 > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-downgrade-prevention-01 > > _______________________________________________ > IPsec 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]
