IKEv2 SN rename: Renaming the Extended Sequence Numbers (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)
IKEv2 Transform Type 5 stops being only about 'extended' sequence numbers and becomes a general way to describe IPsec sequence numbers.
Smyslov, V., "Renaming the Extended Sequence Numbers (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9827, DOI 10.17487/RFC9827, November 2025, <https://www.rfc-editor.org/info/rfc9827>.
@misc{rfc9827,
series = {Request for Comments},
number = 9827,
howpublished = {RFC 9827},
publisher = {RFC Editor},
doi = {10.17487/RFC9827},
url = {https://www.rfc-editor.org/info/rfc9827},
author = {V. Smyslov},
title = {{Renaming the Extended Sequence Numbers (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)}},
pagetotal = 8,
year = 2025,
month = nov,
} RFC text
Contents
Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 9827 ELVIS-PLUS
Updates: 7296 November 2025
Category: Standards Track
ISSN: 2070-1721
Renaming the Extended Sequence Numbers (ESN) Transform Type in the
Internet Key Exchange Protocol Version 2 (IKEv2)
Abstract
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
https://www.rfc-editor.org/info/rfc9827.
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
(https://trustee.ietf.org/license-info) 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
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
The IP Security (IPsec) Architecture [RFC4301] defines a set of
security services provided by the Authentication Header (AH)
[RFC4302] and Encapsulating Security Payload (ESP) [RFC4303]. 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 ([RFC4302], Section 3.3.2) and ESP
([RFC4303], Section 3.3.3), 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
[RFC7296]. 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 Section 3.3.2 of [RFC7296]). 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 [IKEV2-IANA] 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 [RFC7296] by renaming
Transform Type 5 and the two associated Transform IDs.
2. 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 [ANTIREPLAY]).
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 [EESP]). 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.
3. 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 [IKEV2-IANA] 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 [RFC9838] 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 [RFC8750] or
Aggregation and Fragmentation for ESP [RFC9347]) 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., [RFC8750]) or monotonically increasing sequence
numbers (e.g., [RFC9347]). The sender and the 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 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., [RFC8750]) or their monotonic
increase (e.g., [RFC9347]). 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 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 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.
4. Security Considerations
This document does not affect security of the AH, ESP, and IKEv2
protocols.
5. IANA Considerations
This document makes changes to registries within the "Internet Key
Exchange Version 2 (IKEv2) Parameters" registry group [IKEV2-IANA].
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] |
+------------+--------------------------+-----------+
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:
| 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 was created as a result of discussions 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.
Author's Address
Valery Smyslov
ELVIS-PLUS
Russian Federation
Email: svan@elvis.ru
AI ELI5
On this page
§1Introduction
This RFC is a naming and clarification change to the Internet Key Exchange Protocol Version 2 (IKEv2). It updates RFC 7296 by renaming Transform Type 5 and the two Transform IDs defined for it.
IKEv2 is the usual way to set up IPsec Security Associations (SAs) for the Authentication Header (AH) and the Encapsulating Security Payload (ESP). During setup the peers negotiate parameters through transforms. The Transform Type says what is being negotiated, and each type has a list of Transform IDs that are the possible choices.
Two computers agree on the rules for talking securely before they start. This RFC fixes the name of one of those rules so the name matches what the rule really covers.
§2Replay Protection in AH and ESP
IPsec offers an optional service called anti-replay. It works with a counter that only goes up, never wraps around, and is sent in the Sequence Number field of each AH or ESP packet. The receiver keeps a sliding window to spot duplicate packets.
The counter can be 32 bits or 64 bits. The 64-bit form is called Extended Sequence Numbers (ESN). Because the packet field is only 32 bits wide, with ESN the high-order 32 bits are not sent. The receiver works them out from packets it has already received.
The receiver alone decides whether to enable anti-replay, so a sender should always assume it is on. It should send increasing values and never let the counter wrap. The AH and ESP specifications allow a sender to skip keeping the counter only if it has been told anti-replay is disabled or cannot be achieved.
Think of numbered tickets at a deli counter. A number that has already been called is thrown away, so nobody can reuse an old ticket. Long numbers just mean the counter will not run out.
§3The Problem with the Old Name
Transform Type 5 was named "Extended Sequence Numbers (ESN)" and had two values: "No Extended Sequence Numbers" and "Extended Sequence Numbers". IKEv2 therefore has no way to say that both peers agree replay protection is not needed. Even when both turn anti-replay off as receivers, each still has to keep increasing its sequence numbers as a sender.
There is also no way to tell receivers that replay protection is not possible for an SA, for example a multicast SA with several unsynchronized senders. Future IPsec protocols may also send full 64-bit sequence numbers or omit them from packets entirely, and those options would need to be negotiated.
Transform Type 5 is the natural place to do this, since it already negotiates how sequence numbers are handled. Its name, however, implies it only chooses whether to use ESN.
Imagine a menu item called 'Extra Large or Not'. If the cafe wants to offer a tiny size too, the name gets in the way. This RFC gives the menu item a name that allows more choices later.
§4The New Meaning of Transform Type 5
The RFC redefines Transform Type 5 as the set of properties of the sequence numbers of IPsec packets of a given SA when those packets enter the network. It then clarifies the definition:
- "Sequence numbers" may be logical entities such as counters built from information that is not sent on the wire, not only the content of the Sequence Number field.
- The properties describe the packets of the SA, not the result of sender actions. With several unsynchronized senders, each may keep its own numbers unique, yet uniqueness across all packets is not guaranteed.
- The properties apply to packets entering the network, not to what receivers get, because the network can break them (packet duplication breaks uniqueness).
- The properties are read broadly, including the case where sequence numbers are absent.
Documents that define new Transform IDs should describe the properties of the sequence numbers and whether they allow replay protection. They should also say whether the new ID can be used with protocols that rely on particular properties, such as RFC 8750 (implicit IV in ESP) and RFC 9347 (aggregation and fragmentation for ESP). The RFC names G-IKEv2 (RFC 9838) as an example of a future Transform ID for multicast SAs.
The rule's name now says it is about how packets are numbered in general, including having no numbers at all. Anyone who invents a new numbering style has to explain what it does and does not guarantee.
§5The Two Existing Transform IDs
The two existing values keep their meaning, and only get names that describe it.
Value 0 is renamed from "No Extended Sequence Numbers" to "32-bit Sequential Numbers". These are monotonically increasing 32-bit counters carried in the Sequence Number field of AH and ESP packets. They never wrap, are unique, and so suit replay protection and protocols that need uniqueness or monotonic increase.
Value 1 is renamed from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers". These are monotonically increasing 64-bit counters. The low-order 32 bits travel in the Sequence Number field and the receiver infers the high-order 32 bits. They also never wrap and are unique. To process incoming packets correctly, receivers must authenticate them, even when replay protection is not used.
Sender and receiver actions stay as defined in RFC 4302 for AH and RFC 4303 for ESP.
The two old settings are now called 'short counter' and 'long counter, only half shown'. They count the same way as before. Only the labels are clearer.
| Transform ID | Old name | New name | Counter |
|---|---|---|---|
| 0 | No Extended Sequence Numbers | 32-bit Sequential Numbers | 32-bit, fully transmitted |
| 1 | Extended Sequence Numbers | Partially Transmitted 64-bit Sequential Numbers | 64-bit, low 32 bits transmitted |
| 2-1023 | Reserved | Unassigned | None defined |
| 1024-65535 | Reserved | Reserved for Private Use | None defined |
§6Security Considerations
The RFC states that it does not affect the security of the AH, ESP and IKEv2 protocols. It also notes that the descriptions do not change the existing semantics of the Transform IDs, that AH and ESP packet processing is unaffected, and that the bits on the wire do not change.
Because only the labels changed and nothing about how things work, nothing becomes more or less safe.
§7IANA Registry Changes
IANA updated the registries in the IKEv2 Parameters group. In the "Transform Type Values" registry, Transform Type 5 is renamed to "Sequence Numbers (SN)", this RFC is added as a reference, and a note records the old name.
The registry "Transform Type 5 - Extended Sequence Numbers Transform IDs" is renamed "Transform Type 5 - Sequence Numbers Transform IDs". Transform IDs 0 and 1 get their new names, and notes record the old names. The range 2-65535, formerly "Reserved", is split. Numbers 2-1023 become Unassigned and 1024-65535 become Reserved for Private Use.
The official list of names kept by IANA was updated with the new labels. It also keeps a note of the old labels so older documents still make sense.