skip to content

Why must an IPsec ESP SA be replaced before its 32-bit sequence number wraps, and how do extended sequence numbers avoid that?

level: middleimportance: nice to knowfreq 12%

answer

  1. anti-replay assumes numbers never repeat
  2. first packet is number 1
  3. divide 2^32 by the packet rate
  4. high half kept, not sent

basics

~20 s

With anti-replay on, an ESP sender MUST NOT let the sequence number cycle: an SA carries at most 2^32 − 1 packets, about 72 minutes at 1 Mpps. Extended sequence numbers count in 64 bits but send only the low 32.

solid answer

~50 s

Anti-replay works only if no sequence number repeats under one key, so RFC 4303 says that with anti-replay enabled — the sender's default assumption — the counter MUST NOT cycle: sender and receiver counters are reset by establishing a new SA, and thus a new key, before the 2^32nd packet. Numbering starts at 1, so an SA can carry 4,294,967,295 packets; at 1,000,000 packets per second that is about 4,295 seconds, roughly 72 minutes. **Extended sequence numbers** (ESN) make the counter 64 bits while still transmitting only the low-order 32 bits. Both ends track the high-order half, it is folded into the ICV so it is authenticated, and the receiver infers it from its anti-replay window. In IKEv2, ESN is negotiated as transform type 5. At 1 Mpps a 64-bit counter lasts about 585,000 years.

go deeper

for a junior

Remember that every ESP packet carries an increasing sequence number and that an SA must be replaced before that number would repeat.

for a middle

Compute the packet budget of a 32-bit counter at a given rate, and explain how ESN keeps 64 bits of state while sending only 32.

for a senior

Connect fast links to frequent rekeys, check that ESN was actually negotiated, and know why a rebooted manually keyed peer is rejected as replaying.

for a principal

Decide how SA lifetimes, ESN and rekey load should be set across high-throughput gateways so the counter is never the binding limit.

## What the sequence number is for AH and ESP both carry a 32-bit **Sequence Number**. The sender's counter starts at 0 when the security association (SA) is created and is incremented before each packet, so the first packet carries 1. The field is always sent, even when the receiver has chosen not to check it. A receiver that does enable **anti-replay** uses the number to reject a packet it has already accepted — which is only sound if no number is ever reused under the same key. ## The no-wrap rule RFC 4303 is explicit: - if anti-replay is enabled — and the sender assumes it is unless the receiver said otherwise during SA establishment — the transmitted number **must never be allowed to cycle**; - the sender **MUST NOT** send a packet that would make the counter cycle, and an attempt to do so is an auditable event; - sender and receiver counters are reset only **by establishing a new SA and thus a new key**, before the 2^32nd packet. So one SA carries at most 2^32 − 1 = **4,294,967,295** packets. In practice the key-management protocol replaces the SA ahead of that point, alongside any packet, byte or time lifetime the operator configured. ## Computing the budget Time to exhaustion = 4,294,967,295 ÷ packet rate: | Packet rate | Example traffic | Time until the counter would cycle | |---|---|---| | 100,000 pps | about 1 Gbit/s of 1,250-byte packets | 42,950 s, about 11.9 hours | | 1,000,000 pps | about 10 Gbit/s of 1,250-byte packets | 4,295 s, about 71.6 minutes | | 4,000,000 pps | about 40 Gbit/s of 1,250-byte packets | 1,074 s, about 17.9 minutes | The check: 10 Gbit/s ÷ (1,250 bytes × 8 bits) = 1,000,000 packets per second. Small packets make it worse — the same link full of 64-byte packets runs through the space many times faster. On a fast link, 32-bit numbering alone forces a new SA every few minutes to every hour. ## Extended sequence numbers RFC 4303 (§2.2.1 and Appendix A) defines **extended sequence numbers** (`ESN`), which implementations SHOULD support: 1. Both ends keep a **64-bit** counter. 2. Only the **low-order 32 bits** go on the wire, so the header does not grow. 3. The **high-order 32 bits** are still authenticated. With a separate integrity algorithm they are appended after `Next Header` as an implicit trailer — included in the ICV computation but never transmitted. With AES-GCM (RFC 4106) the full 64-bit number goes into the additional authenticated data. 4. The receiver reconstructs the high half from its anti-replay window: if the low bits received are lower than its own low bits, it assumes the high half has advanced. This tolerates gaps of up to 2^32 − 1 lost packets; a longer gap needs the resynchronisation heuristics the appendix allows. With a 64-bit space, 2^64 − 1 packets at 1,000,000 pps is about 1.8 × 10^13 seconds — roughly 585,000 years. ## Negotiating it - In **IKEv2** (RFC 7296), ESN is **transform type 5**, a mandatory transform type in every ESP and AH proposal, with value 0 for no ESN and 1 for ESN. An initiator that supports both usually offers both; offering only 1 means 32-bit numbering is unacceptable. - IKEv1 needed an addendum (RFC 4304) to negotiate ESN; IKEv1 itself is now deprecated by RFC 9395. ## What ESN does not change - Keys still have to be replaced on schedule; ESN removes the sequence-number deadline, not the policy lifetime. - A receiver that will not enable anti-replay SHOULD NOT negotiate ESN, because inferring the high half depends on running the window. - With anti-replay disabled, the counter may simply roll over to zero — the behaviour RFC 4303 recommends for multi-sender multicast SAs. - With **manually keyed** SAs, RFC 4303 says implementations SHOULD NOT provide anti-replay; anyone who enables it must keep the sender's counter across reboots until the key changes, or the restarted numbers are rejected as replays.

  • An ESP sender reboots and restarts its counter at 1 on the same SA; what does a receiver with anti-replay enabled do?
    It rejects the packets as replays. The receiver's window still sits at the highest number it validated before the reboot, so the restarted numbers fall to its left — or inside it, already marked as seen. That is why RFC 4303 says manually keyed SAs SHOULD NOT use anti-replay, and that if they do the counter must survive reboots until the key is replaced.
  • If the high-order half of an extended sequence number is never transmitted, how is it protected against tampering?
    It is fed into the integrity computation. With a separate integrity algorithm it is appended after the Next Header field as an implicit trailer; with AES-GCM the 64-bit number goes into the additional authenticated data. If the receiver infers the wrong high half, its ICV check fails and the packet is dropped, so the value is authenticated without costing header bytes.

saying these in an interview costs you the question

  • The sequence number simply wraps to zero and the SA keeps running.
  • Extended sequence numbers put a 64-bit field on the wire.
  • The high half of an ESN is unprotected because it is never sent.
  • A sender may reset its counter after a reboot without changing the key.
  • Running out of sequence numbers is only a theoretical concern on real links.