Summary

  • RFC 9827 renames IKEv2 Transform Type 5 and its two original IDs without changing AH or ESP processing or any bit on the wire. It turns a narrow ESN choice into a namespace for sequence-number properties.
  • IDs 0 and 1 promise monotonically increasing, non-wrapping, SA-wide unique numbers at network entry. That makes them suitable for anti-replay, but a receiver still decides locally whether to enable a replay window.
  • Sender action, aggregate entry properties, received packets, authentication, window state, replay rejection and downstream safety are different facts. Implicit IV needs uniqueness; AGGFRAG/IP-TFS needs a stricter consecutive stream.

A new name exposed the old assumption

The smallest standards changes can reveal the largest operational shortcuts. RFC 9827, published on the Standards Track in November 2025, does not add a byte to an ESP packet. It does not alter the Authentication Header, change the IKEv2 transform encoding or replace a receiver algorithm. Its formal act is a rename.

Transform Type 5 used to be called Extended Sequence Numbers. Its value 0 meant “No Extended Sequence Numbers”; value 1 meant “Extended Sequence Numbers”. RFC 9827 calls the type Sequence Numbers instead. It calls value 0 “32-bit Sequential Numbers” and value 1 “Partially Transmitted 64-bit Sequential Numbers”. The old values keep their semantics. The packet bits and AH/ESP processing remain unchanged.

The rename matters because the earlier vocabulary made one implementation choice look like the whole subject. Type 5 was never only a switch between a visible 32-bit counter and an ESN. It was the place where peers stated which properties the protected packet stream would have. Once future formats could omit a field, transmit all 64 bits, tolerate several senders or admit that uniqueness was unavailable, the word “extended” became too small.

IANA's live registry now makes that expansion visible. IDs 0 and 1 retain the familiar point-to-point contracts. ID 2, added by RFC 9838 for G-IKEv2, is “32-bit Unspecified Numbers”: the field exists, but uniqueness for the SA is not guaranteed. Values 3–1023 are unassigned; 1024–65535 are private use. The registry can now name materially different sequence properties without pretending they are all variants of ESN.

That creates the central assurance question: what exactly does selecting one of those numbers prove?

The contract ends at network entry

RFC 9827 answers with unusual precision. Transform Type 5 defines the properties of sequence numbers of IPsec packets for a given Security Association when those packets enter the network.

Every phrase limits the claim. A “sequence number” may be a logical counter rather than the visible 32-bit header. Under ID 1, the low half travels in AH or ESP; the receiver reconstructs the high half from authenticated history. The property applies across the packets of the SA, not merely to the code path of one sender. If several unsynchronized transmitters share an SA, each can avoid repeating its own local values while the aggregate stream still collides.

The location is equally deliberate. The property is tested at entry, before the network can duplicate, lose or reorder packets. One packet bearing one unique number may be copied in transit and observed twice at the receiver. A monotonically generated stream may arrive out of order. Loss may create gaps. A capture at one egress, mirror port or tunnel boundary may see a different sequence from a capture at another.

This is not semantic evasiveness. It assigns a claim to the boundary where its owner can actually satisfy it. The sender side can control generation and injection. It cannot promise that a network will not copy a packet. The receiver can decide what to accept. It cannot retroactively change what entered elsewhere.

The distinction follows a useful operating discipline from Heng Lu's writing: a record should describe a bounded reality rather than claim authority over every downstream consequence. Here the accepted Transform ID records an agreed invariant at one boundary. Running packets and receiver decisions establish the later facts.

IDs 0 and 1 promise properties, not enforcement

For ID 0, RFC 9827 describes a monotonically increasing 32-bit counter carried in the AH or ESP Sequence Number field. It must not wrap and is unique for the SA. For ID 1, the counter is 64 bits, only the low 32 bits travel, and the receiver infers the high 32 bits. It too must increase, never wrap and remain unique.

Those properties make both choices suitable for replay protection. “Suitable” is the exact word that operations must preserve. RFC 4301, RFC 4302 and RFC 4303 make the anti-replay service optional and receiver-local, selected per SA. All compliant implementations must support the processing, but an individual receiver may disable it. When disabled, it performs no inbound check on the Sequence Number.

When enabled, the receiver maintains a sliding window. Numbers left of the window are too old. A number already marked inside the window is a duplicate. A newer authenticated number can advance the right edge. The window's size is local and is not notified to the sender. It therefore reflects an operating trade-off: a narrow window reduces state but may reject legitimate severe reordering; a wider window tolerates more disorder and changes the volume of history retained.

The check is also staged. A receiver may make a cheap preliminary comparison before cryptographic work, but it must not commit the new window state until integrity or authenticated decryption succeeds. Otherwise an attacker could inject an unauthenticated high value and push valid traffic out of the window. A log saying “sequence precheck passed” is not a receipt for authentication or durable window advancement.

ESN makes the separation sharper. The receiver needs its prior authenticated state to infer the high-order bits that were not transmitted. RFC 9827 therefore notes that incoming packets using ID 1 must be authenticated even if the receiver does not use replay protection. Authentication establishes that the counter input belongs to the SA; it still does not establish that the packet is new. Those are two decisions with different state.

Negotiation is not a packet trace

IKEv2 establishes Child SAs by exchanging proposals and selecting transforms. RFC 7296's older language shows the familiar pattern: an initiator that accepts both ordinary and extended numbers typically proposes both Type 5 values; a proposal containing only value 1 refuses the 32-bit alternative. A responder's accepted proposal determines the contract for the SA.

That receipt is necessary. Configuration intent alone is weaker. A policy may prefer ID 1 while the negotiated Child SA selects ID 0, or a private-use ID may enter a constrained deployment. The audit record should preserve both directions' proposals, the accepted Transform ID, the Child SA identity, direction, SPI, peer identity, software build and policy revision.

Yet successful negotiation is still not a packet trace. It does not show that the sender instantiated the right counter, that two packet engines allocated disjoint values, that failover preserved state, that a NIC offload queue and host stack agreed on ownership, or that rekey happened before exhaustion. It does not show that any receiver enabled anti-replay. It certainly does not show that a replay was attempted and rejected.

The important shift is from feature inventory to custody of state. A single-threaded sender can increment one counter easily. A high-throughput gateway may distribute work over cores, accelerators and queues. An active/standby pair may transfer an SA without transferring the latest allocation boundary. Two multicast senders may share keys without sharing one sequencer. Each component can report a healthy local counter while the SA-wide stream repeats a value.

RFC 9827 explicitly attributes the property to packets, not sender intentions. That is why “every sender increments” cannot replace evidence that the aggregate network-entry stream was unique.

The packet seen twice may have been sent once

Suppose a receiver captures two authenticated ESP packets with the same SPI and Sequence Number. Four explanations are immediately possible. The sender reused a value. The network duplicated one valid packet. Two capture points recorded the same packet. Or an adversary replayed a previously recorded packet.

The bytes alone do not distinguish them. A sender-entry trace can test collision before the network. Capture location and packet fingerprints can reveal observation duplication. Authentication can show whether both copies carry a valid integrity result. The replay-window verdict can show whether the later arrival was discarded as old or duplicate. Only the joined timeline supports a causal statement.

The reverse inference is also unsafe. An application receiving no duplicate does not prove anti-replay operated. The network may not have duplicated anything; an upstream device may have dropped the copy; the capture may be incomplete; the receiver may have disabled replay checks while the application naturally processed only one request. Absence of an effect is not the same as a recorded enforcement decision.

A useful replay receipt therefore names the SA and direction, SPI, full logical sequence value, authenticated packet fingerprint, receive time, capture point, window bounds before the decision, integrity result, replay verdict, window bounds afterward and disposition. For ID 1 it also records the inferred high bits and the authenticated history that made the inference possible.

Two consumers demand more than a green replay lamp

RFC 9827 warns that other protocols consume sequence-number properties for purposes beyond replay filtering. The first is implicit IV in ESP, specified by RFC 8750 for selected counter-mode AEAD transforms. It constructs the per-packet initialization value from the sequence number instead of sending an explicit IV. Under a given key, that IV must never repeat.

The security dependency is absolute. If two senders reuse the same sequence under one SA and key, turning off the replay window does not make the collision harmless. The cryptographic nonce has repeated. RFC 8750 therefore forbids implicit IV wherever sequence overlap is possible and requires an explicit prevention mechanism for multicast. The selected Type 5 property, the actual generator design and rekey boundary all belong in the cipher's safety case.

The second consumer is RFC 9347's ESP Aggregation and Fragmentation mode, used by IP-TFS. Reassembly of one inner packet follows the logical order of outer ESP packets. Ordinary ESP promises increasing values but does not require consecutive ones: a sender could legally emit only even numbers. AGGFRAG adds the stricter requirement that subsequent packets increase by exactly one, with defined treatment of all-pad packets. Its reordering window and replay window may have different sizes and purposes.

An ID 0 or 1 selection supplies monotonicity and uniqueness, but the deployment must also prove +1 allocation, fragment continuity and a clean SA transition. Initial fragments cannot use one SA while later fragments move to another because sequence state resets at rekey. A product that validates only “Type 5 is supported” can therefore accept a combination whose consumer requires more than the chosen property bundle states.

Future Transform IDs must make these dependencies explicit. The right compatibility question is not whether both features exist in a release. It is whether the selected sequence-number contract satisfies every property assumed by the selected encryption and payload modes.

ID 2 proves why the rename was necessary

RFC 9838 supplies a concrete counterexample to the old mental model. Its 32-bit Unspecified Numbers choice keeps a 32-bit field in AH/ESP packets but does not guarantee uniqueness. A group controller uses it for multi-sender multicast SAs where replay protection is not expected to be possible. A group member still decides locally whether to enable a check, but the negotiated contract warns that the input cannot support conventional replay filtering.

The dependent consequences follow immediately. RFC 9838 prohibits sequence-derived implicit-IV encryption where uniqueness is absent. It also excludes AGGFRAG from multi-sender multicast because that mode depends on a single monotonically increasing stream. These are not optional editorial interpretations. They are compatibility boundaries carried by the broader Type 5 semantics.

ID 2 also prevents a dangerous shortcut in telemetry. “Sequence field present” does not mean “sequence unique”; “sequence transform selected” does not mean “replay protection possible”; “replay setting enabled” does not mean “the incoming number space can make it effective”. Syntax, negotiated property and local enforcement have to be stored separately.

The eight receipts

An operational claim about RFC 9827 should be reconstructible through eight records:

  1. Registry semantics: the current IANA name, Transform ID, defining RFC and private-use boundary.
  2. Negotiation: offered values, selected value, Child SA, direction, SPI, peer and policy version.
  3. Sender behavior: the generator owner, allocation method, persistence, failover and rekey threshold.
  4. Entry properties: the aggregate stream at every injection point for the SA, not just each worker's local log.
  5. Receiver policy: replay enabled or disabled, integrity prerequisite, window size and ESN reconstruction state.
  6. Observed packets: capture point, authenticated packet identity, order, gaps, copies and inferred high bits.
  7. Replay rejection: the explicit verdict and state transition after authentication.
  8. Dependent safety: nonce uniqueness, AGGFRAG consecutiveness, SA-transition discipline and future-ID compatibility.

No row can be filled by copying the previous one. The chain is valuable precisely because a failure at one stage does not rewrite what was true at another.

RFC 9827 is modest about its own effect. It changes registry language, widens a negotiation namespace and clarifies old values. That modesty is an operational advantage. It gives teams vocabulary precise enough to stop calling a negotiated counter format “anti-replay enabled”, stop calling a duplicate capture “sender collision”, and stop calling a receiver drop “application protection” without the missing evidence.

Sources