Renaming the Extended Sequence Numbers (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)
updates
- rfc-7296 — Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (15)
For 64-bit sequence numbers (Transform ID 1), only the low-order 32 bits are transmitted in the AH/ESP Sequence Number field because that field is only 32 bits wide. The high-order bits are reconstructed by the receiver, making authentication of incoming packets a requirement even without active replay protection.
Future IPsec protocols such as Enhanced ESP (EESP) may introduce options for sending full 64-bit sequence numbers or omitting them entirely. Transform Type 5 is the designated negotiation vehicle for these future modes because it already governs how sequence numbers are handled.
IKEv2 currently lacks a mechanism to negotiate the case where both peers agree replay protection is not needed, or to signal that replay protection is not achievable (e.g., multicast SAs with multiple unsynchronized senders). Extending Transform Type 5 is the chosen vehicle to address these gaps via future Transform IDs.
Transform Type 5 is renamed because its original name ('Extended Sequence Numbers') implied it could only negotiate ESN usage, which was too narrow. The rename enables future Transform IDs to cover additional sequence number handling modes, such as full 64-bit transmission, omitted counters, and multicast SA cases where replay protection is not possible.
Protocols that rely on properties guaranteed by the current Transform IDs—such as Implicit IV in ESP (RFC 8750) and Aggregation and Fragmentation for ESP (RFC 9347)—may not be compatible with future Transform IDs. New Transform ID definitions must discuss applicability to protocols that depend on specific sequence number properties.
The renaming of Transform Type 5 and its Transform IDs does not change existing semantics or on-the-wire behavior. ESP and AH packet processing for Transform IDs 0 and 1 is unaffected and bits on the wire do not change.
Documents defining new Transform IDs for Transform Type 5 SHOULD include descriptions of the sequence number properties that result from selecting the new Transform ID, including whether those properties allow replay protection to be achieved.
The anti-replay service in IPsec AH and ESP uses a monotonically increasing counter that never wraps, sent in the Sequence Number field of each packet. The receiver maintains a sliding window to detect duplicates; enabling anti-replay is optional and per-SA at the receiver.
Transform ID 0 (renamed from 'No Extended Sequence Numbers' to '32-bit Sequential Numbers') defines monotonically increasing 32-bit counters transmitted in the AH/ESP Sequence Number field that never wrap and are guaranteed unique, suitable for replay protection.
Transform ID 1 (renamed from 'Extended Sequence Numbers' to 'Partially Transmitted 64-bit Sequential Numbers') defines 64-bit monotonically increasing counters where only the low-order 32 bits are transmitted; the high-order 32 bits are inferred by the receiver from prior packets. Incoming packets must be authenticated even when replay protection is not used.
Transform Type 5 in IKEv2 is redefined as negotiating 'the set of properties of sequence numbers of IPsec packets of a given SA when these packets enter the network.' Sequence numbers may be logical entities not fully transmitted on the wire, and properties are assessed at network ingress, not at the receiver.
The 'Transform Type 5 - Extended Sequence Numbers Transform IDs' registry is renamed to 'Transform Type 5 - Sequence Numbers Transform IDs'. The previously Reserved range 2-65535 is split: 2-1023 becomes Unassigned and 1024-65535 becomes Reserved for Private Use.
The 'Transform Type Values' registry in the IKEv2 Parameters registry group is updated: Transform Type 5 is renamed from 'Extended Sequence Numbers (ESN)' to 'Sequence Numbers (SN)' with a note documenting the original name used in prior RFCs.
Transform ID 0 is renamed from 'No Extended Sequence Numbers' to '32-bit Sequential Numbers', and Transform ID 1 is renamed from 'Extended Sequence Numbers' to 'Partially Transmitted 64-bit Sequential Numbers', with notes in the registry documenting the prior names used in older RFCs.
This document does not affect the security of the AH, ESP, and IKEv2 protocols. The renaming and semantic extension of Transform Type 5 is purely clarificatory with respect to existing behavior.