RFC 9827

Renaming the Extended Sequence Numbers (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)

📅 published November 2025, from ietf

RFC 9827: Renaming the Extended Sequence Numbers (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2) 💖

Okay bestie, so this is RFC 9827 📜, a Standards Track doc from the IETF, written by V. Smyslov of ELVIS-PLUS and dated November 2025. It's ISSN 2070-1721, and it updates RFC 7296, which is the big IKEv2 spec 👑. The whole point is a rename, but a rename with a lot of meaning behind it 🦋.

Abstract 🦋

This doc clarifies and extends what Transform Type 5 means in IKEv2 ✨. It updates RFC 7296 by renaming Transform Type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)" 💅. It also renames the two values that are currently defined for this Transform Type: value 0 goes from "No Extended Sequence Numbers" to "32-bit Sequential Numbers", and value 1 goes from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers" 🌈.

Status of This Memo 📋

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF) 🫶. It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 🧚.

For info about the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9827 🔗.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License 🍓.

Table of Contents 📚

1.  Introduction
2.  Problem Description
3.  Extending the Semantics of Transform Type 5
4.  Security Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Author's Address

1. Introduction 🌸

Okay so IPsec has this whole security architecture, [RFC4301], and it defines a bunch of security services from the Authentication Header (AH) [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. One of those services is replay protection, which these docs call "anti-replay" 🙈. In IPsec, anti-replay is optional. Each receiver of AH and/or ESP packets can pick whether to turn it on, on a per Security Association (SA) basis 💜. The replay protection works because of a monotonically increasing counter that never wraps around. That counter gets sent in every AH or ESP packet in the Sequence Number field 🔥. The receiver keeps a sliding window so it can spot duplicate packets.

Both AH and ESP can use either a 32-bit counter or a 64-bit counter 👑. The 64-bit one is called Extended Sequence Numbers (ESN) in the AH and ESP specs. Here's the tea: the Sequence Number field in both headers is only 32 bits, so with ESN the high-order 32 bits of the counter aren't sent on the wire. The receiver figures them out from packets it already got ✨.

Whether the receiver turns on anti-replay depends only on its own local policy 💅. So, in line with the AH rules ([RFC4302], Section 3.3.2) and the ESP rules ([RFC4303], Section 3.3.3), the sender should always assume that replay protection is on at the receiving side. That means the sender should keep sending increasing counter values and should make sure the counter never wraps around 😭. The AH and ESP specs also talk about situations where replay protection just can't be achieved, even when senders do everything right. An example is a multicast SA with several unsynchronized senders 💀. Both specs also let a sender skip maintaining the counter if it has been told that the receiver has anti-replay turned off, or that it isn't possible to achieve 🦋.

AH and ESP SAs are usually set up with IKEv2 [RFC7296] 🎀. Setting up an SA means working out a shared key and negotiating SA parameters, like which cryptographic algorithms to use. In IKEv2, that negotiation happens through transforms (see Section 3.3.2 of [RFC7296]) 🧚. Each transform has a Transform Type, and the type says which parameter is being negotiated. Each Transform Type also has a list of possible values, called Transform IDs, that lay out the options. For the full list of Transform Types and their Transform IDs, check [IKEV2-IANA] 📚.

Transform Type 5 ("Extended Sequence Numbers (ESN)") is what IKEv2 uses to negotiate how sequence numbers for replay protection get generated, sent, and processed for an SA 🌈. Right now there are two values defined for it: "No Extended Sequence Numbers" and "Extended Sequence Numbers" 💖.

This document updates the IKEv2 spec [RFC7296] by renaming Transform Type 5 and the two Transform IDs tied to it 🫶.

2. Problem Description 💅

IKEv2 currently has no way to negotiate the case where both peers agree that replay protection isn't needed 😤. Even when both peers turn off anti-replay on the receiving side, they still have to keep increasing sequence numbers as senders, and make sure those never wrap around (see [ANTIREPLAY]) 💀.

There's also no way to tell receivers that replay protection isn't possible for a particular SA. A multicast SA with several unsynchronized senders is the classic example 🙈.

Future IPsec protocols may offer more ways to handle anti-replay counters. Examples are sending full 64-bit sequence numbers, or leaving them out of packets completely (see [EESP]) 🦋. Those options would need to be negotiated in IKEv2 🍓.

Transform Type 5 is the best candidate for solving these issues 👑. It's already used to negotiate how sequence numbers are handled for AH and ESP, and it's possible to define extra Transform IDs for the situations above ✨. The problem is that the current definition of Transform Type 5 is too narrow. Its name suggests it can only be used to negotiate ESN 😭.

3. Extending the Semantics of Transform Type 5 ✨

This document extends the semantics of Transform Type 5 in IKEv2 so it's defined like this:

Transform Type 5 defines the set of properties of sequence numbers of IPsec packets of a given SA when these packets enter the network.

This updated definition comes with some clarifications 🌸:

  • "Sequence numbers" in this definition aren't necessarily the content of the Sequence Number field in the IPsec packets. They can also be logical entities (for example, counters) that get built using info that isn't sent on the wire 🧚.
  • The properties are read as characteristics of IPsec SA packets, not as the results of what a sender does. For example, in a multicast SA with multiple unsynchronized senders, even if each sender makes sure the sequence numbers it generates are unique, uniqueness across all IPsec packets isn't guaranteed 💅.
  • The properties are defined for packets just entering the network, not for packets receivers get. The reason is that network behavior can break some of these properties. For example, packet duplication would break sequence number uniqueness 😭.
  • The properties of sequence numbers are read in a broad sense, which includes the case where sequence numbers are absent 🦋.

With this updated definition, Transform Type 5 in the "Transform Type Values" registry [IKEV2-IANA] has been renamed from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)". The reason is that it now defines the properties of sequence numbers in general 👑.

New Transform IDs are expected to be defined for this Transform Type later on, like in G-IKEv2 [RFC9838] for multicast SAs 🌈. Docs that define new Transform IDs should describe the properties the sequence numbers would have if that new Transform ID got selected. In particular, the descriptions should talk about whether those properties allow replay protection to be achieved 🫶.

Some existing protocols, like Implicit IV in ESP [RFC8750] or Aggregation and Fragmentation for ESP [RFC9347], rely on properties that are guaranteed for the currently defined Transform IDs. That might not hold for future Transform IDs 💀. When a new Transform ID is defined, its description should discuss whether it can be used in protocols that rely on particular sequence number properties 🎀.

The two currently defined Transform IDs for Transform Type 5 have these properties 💖:

  • Value 0 defines sequence numbers as monotonically increasing 32-bit counters that are sent in the Sequence Number field of AH and ESP packets. They never wrap around and are guaranteed to be unique, so they're suitable for replay protection. They can also be used with protocols that rely on sequence number uniqueness (e.g., [RFC8750]) or on monotonically increasing sequence numbers (e.g., [RFC9347]). The sender and receiver actions are defined in Sections 3.3.2 and 3.4.3 of [RFC4302] for AH, and in Sections 3.3.3 and 3.4.3 of [RFC4303] for ESP 🔥.
  • Value 1 defines sequence numbers as monotonically increasing 64-bit counters. The low-order 32 bits are sent in the Sequence Number field of AH and ESP packets, and the high-order 32 bits are implicitly figured out by receivers based on packets they already got. The sequence numbers never wrap around and are guaranteed to be unique, so they're suitable for replay protection. They can also be used with protocols that rely on sequence number uniqueness (e.g., [RFC8750]) or on their monotonic increase (e.g., [RFC9347]). To process incoming packets correctly, receivers need the packets to be authenticated, even when replay protection isn't used 😤. The sender and receiver actions are defined in Sections 3.3.2 and 3.4.3 of [RFC4302] for AH, and in Sections 3.3.3 and 3.4.3 of [RFC4303] for ESP 🌸.

Given those descriptions and the new definition of Transform Type 5, the two currently defined Transform IDs get renamed so the names better match the sequence number properties they assume ✨:

  • Transform ID 0 is renamed from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" 🧚.
  • Transform ID 1 is renamed from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers" 👑.

Just so you know, these descriptions don't change what the Transform IDs mean. They only clarify it 💅. Also, AH and ESP packet processing for these Transform IDs isn't affected, and the bits on the wire don't change 🦋.

4. Security Considerations ✨

Okay bestie, this section is short and sweet 🍓 This document does not affect the security of the AH, ESP, and IKEv2 protocols. No drama, no plot twist 💅

5. IANA Considerations 🎀

Okay so this document makes changes to registries in the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry group [IKEV2-IANA] 🌸

The "Transform Type Values" registry is getting a glow-up:

  • renamed Transform Type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)" ✨
  • added this RFC as a reference for Transform Type 5 🔗
  • added the following note 📝
|  The "Sequence Numbers (SN)" Transform Type was originally named
|  "Extended Sequence Numbers (ESN)" and was referenced by that
|  name in a number of RFCs published prior to [RFC9827], which
|  gave it the current title.

The "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry is also getting a makeover 💖

  • renamed the registry from "Transform Type 5 - Extended Sequence Numbers Transform IDs" to "Transform Type 5 - Sequence Numbers Transform IDs" and added this document as a reference 🦋
  • split the "Reserved" (2-65535) range of numbers as shown below 🧚
+============+==========================+===========+
| Number     | Name                     | Reference |
+============+==========================+===========+
| 2-1023     | Unassigned                           |
+------------+--------------------------+-----------+
| 1024-65535 | Reserved for Private Use | [RFC9827] |
+------------+--------------------------+-----------+

Table 1

  • renamed Transform ID 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" 👑
  • renamed Transform ID 1 from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers" 🌈
  • added a reference to this RFC for Transform ID 0 and Transform ID 1 🫶
  • added the following registry notes, because the history matters 🙈
|  This registry was originally named "Transform Type 5 - Extended
|  Sequence Numbers Transform IDs" and was referenced using that
|  name in a number of RFCs published prior to [RFC9827], which
|  gave it the current title.
|  The "32-bit Sequential Numbers" Transform ID was originally
|  named "No Extended Sequence Numbers" and was referenced by that
|  name in a number of RFCs published prior to [RFC9827], which
|  gave it the current title.
|  The "Partially Transmitted 64-bit Sequential Numbers" Transform
|  ID was originally named "Extended Sequence Numbers" and was
|  referenced by that name in a number of RFCs published prior to
|  [RFC9827], which gave it the current title.
|  Numbers in the range 2-65535 were originally marked as
|  "Reserved" and were reclassified as "Unassigned" and "Reserved
|  for Private Use" by [RFC9827].

6. References 📚

6.1. Normative References

[IKEV2-IANA]
           IANA, "Internet Key Exchange Version 2 (IKEv2)
           Parameters",
           <http://www.iana.org/assignments/ikev2-parameters>.

[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
           Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
           December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
           DOI 10.17487/RFC4302, December 2005,
           <https://www.rfc-editor.org/info/rfc4302>.

[RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
           RFC 4303, DOI 10.17487/RFC4303, December 2005,
           <https://www.rfc-editor.org/info/rfc4303>.

[RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
           Kivinen, "Internet Key Exchange Protocol Version 2
           (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
           2014, <https://www.rfc-editor.org/info/rfc7296>.

6.2. Informative References

[ANTIREPLAY]
           Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti-
           Replay Status Notification", Work in Progress, Internet-
           Draft, draft-pan-ipsecme-anti-replay-notification-01, 21
           October 2024, <https://datatracker.ietf.org/doc/html/
           draft-pan-ipsecme-anti-replay-notification-01>.

[EESP]     Klassert, S., Antony, A., and C. Hopps, "Enhanced
           Encapsulating Security Payload (EESP)", Work in Progress,
           Internet-Draft, draft-ietf-ipsecme-eesp-02, 19 October
           2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
           ipsecme-eesp-02>.

[RFC8750]  Migault, D., Guggemos, T., and Y. Nir, "Implicit
           Initialization Vector (IV) for Counter-Based Ciphers in
           Encapsulating Security Payload (ESP)", RFC 8750,
           DOI 10.17487/RFC8750, March 2020,
           <https://www.rfc-editor.org/info/rfc8750>.

[RFC9347]  Hopps, C., "Aggregation and Fragmentation Mode for
           Encapsulating Security Payload (ESP) and Its Use for IP
           Traffic Flow Security (IP-TFS)", RFC 9347,
           DOI 10.17487/RFC9347, January 2023,
           <https://www.rfc-editor.org/info/rfc9347>.

[RFC9838]  Smyslov, V. and B. Weis, "Group Key Management Using the
           Internet Key Exchange Protocol Version 2 (IKEv2)",
           RFC 9838, DOI 10.17487/RFC9838, November 2025,
           <https://www.rfc-editor.org/info/rfc9838>.

Acknowledgements 🫶

This document came together after some great chats with Russ Housley, Tero Kivinen, Paul Wouters, and Antony Antony about the best way to extend the meaning of the Extended Sequence Numbers transform in IKEv2. Big thanks, you all are iconic 👑

Author's Address 💌

Valery Smyslov ELVIS-PLUS Russian Federation Email: svan@elvis.ru

📦 where this page comes from