Renaming the Extended Sequence Numbers (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2) ELVIS-PLUS
Russian Federation svan@elvis.ru
SEC ipsecme replay protection anti-replay IPsec ESP AH This document clarifies and extends the meaning of Transform Type 5 in Internet Key Exchange Protocol Version 2 (IKEv2). It updates RFC 7296 by renaming Transform Type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)". It also renames two currently defined values for this Transform Type: value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 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). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice 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 () in effect on the date of publication of this document. Please review these documents carefully, as 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 are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
  • .  Problem Description
  • .  Extending the Semantics of Transform Type 5
  • .  Security Considerations
  • .  IANA Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Author's Address
Introduction The IP Security (IPsec) Architecture defines a set of security services provided by the Authentication Header (AH) and Encapsulating Security Payload (ESP) . One of these services is replay protection, which is referred to as "anti-replay" in these documents. In IPsec, the anti-replay service is optional; each receiver of AH and/or ESP packets can choose whether to enable it on a per Security Association (SA) basis. The replay protection in AH and ESP is achieved by means of a monotonically increasing counter that never wraps around and is sent in each AH or ESP packet in the Sequence Number field. The receiver maintains a sliding window that allows duplicate packets to be detected. Both AH and ESP allow use of either a 32-bit counter or a 64-bit counter. The latter case is referred to as Extended Sequence Numbers (ESN) in AH and ESP specifications. Since the Sequence Number field in both AH and ESP headers is only 32 bits in size, in case of ESN the high-order 32 bits of the counter are not transmitted and are determined by the receiver based on previously received packets. The receiver decides whether to enable the anti-replay service based only on the receiver's local policy, so the sender, in accordance with the specifications for AH () and ESP (), should always assume that the replay protection is enabled on the receiving side. Thus, the sender should always send the increasing counter values and should take care that the counter never wraps around. AH and ESP specifications also discuss situations in which replay protection is not possible to achieve, even if senders do all as prescribed -- like in multicast Security Associations with multiple unsynchronized senders. Both AH and ESP specifications allow the sender to avoid maintaining the counter if the sender has been notified that the anti-replay service is disabled by the receiver or is not possible to achieve. AH and ESP Security Associations are usually established using IKEv2 . The process of SA establishment includes calculation of a shared key and negotiation of various SA parameters, such as cryptographic algorithms. This negotiation in IKEv2 is performed via transforms (see ). The type of transform determines what parameter is being negotiated. Each Transform Type has an associated list of possible values (called Transform IDs) that determine the possible options for negotiation. See for the list of Transform Types and associated Transform IDs. Transform Type 5 ("Extended Sequence Numbers (ESN)") is used in IKEv2 to negotiate the way sequence numbers for replay protection are generated, transmitted, and processed in the context of an SA. There are two values are defined for this Transform Type -- "No Extended Sequence Numbers" and "Extended Sequence Numbers". This document updates the IKEv2 specification by renaming Transform Type 5 and the two associated Transform IDs.
Problem Description IKEv2 currently has no means to negotiate the case when both peers agree that replay protection is not needed. Even when both peers locally disable anti-replay service as receivers, they still need to maintain increasing sequence numbers as senders, taking care that they never wrap around (see ). There is also no way to inform receivers that replay protection is not possible for a particular SA (for example in case of a multicast SA with several unsynchronized senders). Future IPsec protocols may provide more options for the handling of anti-replay counters, like sending full 64-bit sequence numbers or completely omitting them in packets (see ). These options will require means to be negotiated in IKEv2. Transform Type 5 is the best candidate for addressing these issues: it is already used for negotiation of how sequence numbers are handled in AH and ESP, and it is possible to define additional Transform IDs that could be used in the corresponding situations. However, the current definition of Transform Type 5 is too narrow -- its name implies that this transform can only be used for negotiation of using ESN.
Extending the Semantics of Transform Type 5 This document extends the semantics of Transform Type 5 in IKEv2 to be defined as follows: 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 is clarified as follows:
  • "Sequence numbers" in this definition are not necessarily the content of the Sequence Number field in the IPsec packets; they may also be some logical entities (e.g., counters) that could be constructed taking some information that is not transmitted on the wire into account.
  • The properties are interpreted as characteristics of IPsec SA packets rather than the results of sender actions. For example, in multicast SA with multiple unsynchronized senders, even if each sender ensures the uniqueness of sequence numbers it generates, the uniqueness of sequence numbers for all IPsec packets is not guaranteed.
  • The properties are defined for the packets just entering the network and not for the packets that receivers get. This is because network behavior may break some of these properties (e.g., packet duplication would break sequence number uniqueness).
  • The properties of sequence numbers are interpreted in a broad sense, which includes the case when sequence numbers are absent.
Given this updated definition, Transform Type 5 in the "Transform Type Values" registry has been renamed from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense that it defines the properties of the sequence numbers in general. It is expected that new Transform IDs will be defined for this Transform Type in the future (like in G-IKEv2 for the case of multicast SAs). Documents defining new Transform IDs should include descriptions of the properties the sequence numbers would have if the new Transform ID was selected. In particular, the descriptions should include discussion of whether these properties allow replay protection to be achieved. Some existing protocols (like Implicit IV in ESP or Aggregation and Fragmentation for ESP ) rely on properties that are guaranteed for the currently defined Transform IDs; however, this might not be true for future Transform IDs. When a new Transform ID is defined, its description should include discussion about the possibility of using the Transform ID in protocols that rely on some particular properties of sequence numbers. The two currently defined Transform IDs for Transform Type 5 define the following properties of sequence numbers.
  • Value 0 defines sequence numbers as monotonically increasing 32-bit counters that are transmitted in the Sequence Number field of AH and ESP packets. They never wrap around and are guaranteed to be unique, thus they are suitable for replay protection. They can also be used with protocols that rely on sequence number uniqueness (e.g., ) or monotonically increasing sequence numbers (e.g., ). The sender and the receiver actions are defined in Sections and of for AH and in Sections and of for ESP.
  • Value 1 defines sequence numbers as monotonically increasing 64-bit counters. The low-order 32 bits are transmitted in the Sequence Number field of AH and ESP packets, and the high-order 32 bits are implicitly determined on receivers based on previously received packets. The sequence numbers never wrap around and are guaranteed to be unique, thus they are suitable for replay protection. They can also be used with protocols that rely on sequence number uniqueness (e.g., ) or their monotonic increase (e.g., ). To correctly process the incoming packets on receivers, the packets must be authenticated (even when the replay protection is not used). The sender and the receiver actions are defined in Sections and of for AH and in Sections and of for ESP.
Given the descriptions above and the new definition of Transform Type 5, the two currently defined Transform IDs are renamed to better reflect the properties of sequence numbers 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".
Note that the above descriptions do not change the existing semantics of these Transform IDs, they only provide clarification. Also note that ESP and AH packet processing for these Transform IDs is not affected, and bits on the wire do not change.
Security Considerations This document does not affect security of the AH, ESP, and IKEv2 protocols.
IANA Considerations This document makes changes to registries within the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry group . The "Transform Type Values" registry has been updated as follows:
  • renamed Transform Type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)".
  • added as a reference to this RFC 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 has been updated as follows:
  • 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]
  • 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:
    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].
References Normative References Internet Key Exchange Version 2 (IKEv2) Parameters IANA Security Architecture for the Internet Protocol This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] IP Authentication Header This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK] IP Encapsulating Security Payload (ESP) This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] Internet Key Exchange Protocol Version 2 (IKEv2) This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. Informative References IKEv2 Support for Anti-Replay Status Notification Huawei Technologies Huawei Technologies Aiven Although RFC 4302 and RFC 4303 don't prohibit using Extended Sequence Number (ESN) when the anti-replay function is not enabled, many IPsec implementations require ESN to be used only with anti-replay. Therefore, failing to negotiate the use of ESN when the anti-replay is disabled will cause the sequence numbers to exhaust rapidly in high-traffic-volume scenarios, leading to the frequent rekey of Child SAs. This document defines the REPLAY_PROT_AND_ESN_STATUS Notify Message Status Type Payload in the Internet Key Exchange Protocol Version 2 (IKEv2) to inform the peer of its replay protection status and capability of using ESN without anti-replay when creating the Child SAs, to address the above problem. Work in Progress Enhanced Encapsulating Security Payload (EESP) secunet Security Networks AG secunet Security Networks AG LabN Consulting, L.L.C. This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning and QoS support based on the inner traffic flow), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add Flow IDs and a crypt-offset to allow for exposing inner flow information for middlebox use. Work in Progress Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this. Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS) This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in Encapsulating Security Payload (ESP). This new payload type can be used for various purposes, such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IP Traffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel. The solution allows for congestion control, as well as nonconstant send-rate usage. Group Key Management Using the Internet Key Exchange Protocol Version 2 (IKEv2)
Acknowledgements This document was created as a result of discussions with , , , and about the best way to extend the meaning of the Extended Sequence Numbers transform in IKEv2.
Author's Address ELVIS-PLUS
Russian Federation svan@elvis.ru