IPSec: Extended (64-bit) Sequence Numbers (ESN)

RFC 4302: IP Authentication Header
http://tools.ietf.org/html/rfc4302#page-8

2.5. Sequence Number
This unsigned 32-bit field contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number.
(.....)
The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA.
(.....)
Thus, the sender MUST always transmit this field, but the receiver need not act upon it.

The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.2 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.

2.5.1. Extended (64-bit) Sequence Number
To support high-speed IPsec implementations, a new option for sequence numbers SHOULD be offered, as an extension to the current, 32-bit sequence number field. Use of an Extended Sequence Number (ESN) MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit sequence numbers are explicitly negotiated. (The ESN feature is applicable to multicast as well as unicast SAs.)

The ESN facility allows use of a 64-bit sequence number for an SA. (See Appendix B, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in the AH header of each packet, thus minimizing packet overhead. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV, but are not transmitted.

3.3.3.2.2. Implicit Packet Padding and ESN
If the ESN option is elected for an SA, then the high-order 32 bits of the ESN must be included in the ICV computation. For purposes of ICV computation, these bits are appended (implicitly) immediately after the end of the payload, and before any implicit packet padding.

For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH and the 32 high-order bits of the ESN, if enabled) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's blocksize.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.

Appendix B: Extended (64-bit) Sequence Numbers
http://tools.ietf.org/html/rfc4302#page-28

B3. Handling Loss of Synchronization due to Significant Packet Loss

RFC 4303: IP Encapsulating Security Payload (ESP)
http://tools.ietf.org/html/rfc4303

(skipping parts alike to AH)
2.2.1. Extended (64-bit) Sequence Number
(...)
The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV (if the integrity service is selected). If a separate integrity algorithm is employed, the high order bits are included in the implicit ESP trailer, but are not transmitted, analogous to integrity algorithm padding bits. If a combined mode algorithm is employed, the algorithm choice determines whether the high-order ESN bits are transmitted or are included implicitly in the computation. See Section 3.3.2.2 for processing details.

3.3.2.1. Separate Confidentiality and Integrity Algorithms
4. Compute the ICV over the ESP packet minus the ICV field. Thus, the ICV computation encompasses the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header. (Note that the last 4 fields will be in ciphertext form, because encryption is performed first.) If the ESN option is enabled for the SA, the high-order 32 bits of the sequence number are appended after the Next Header field for purposes of this computation, but are not transmitted.

3.3.2.2. Combined Confidentiality and Integrity Algorithms

- The Sequence Number (or Extended Sequence Number, as appropriate) and the SPI are inputs to the algorithm, as they must be included in the integrity check computation. The means by which these values are included in this computation are a function of the combined mode algorithm employed and thus not specified in this standard.

3.3.3. Sequence Number Generation
If ESN (see Appendix) is selected, only the low-order 32 bits of the sequence number are transmitted in the Sequence Number field, although both sender and receiver maintain full 64-bit ESN counters. The high order 32 bits are included in the integrity check in an algorithm/mode-specific fashion, e.g., the high-order 32 bits may be appended after the Next Header field when a separate integrity algorithm is employed.

Appendix A: Extended (64-bit) Sequence Numbers
http://tools.ietf.org/html/rfc4303#page-38

RFC 4106 - The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
http://tools.ietf.org/html/rfc4106#page-5

5. AAD Construction

RFC 4543 - The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
http://tools.ietf.org/html/rfc4543#page-5

3.3. AAD Construction

RFC 5084 - Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)
http://tools.ietf.org/html/rfc5084

1.5. AES-GCM
(......)
AES-GCM has four inputs: an AES key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). AES-GCM generates two outputs: a ciphertext and message
(......)
AAD is authenticated but not encrypted. Thus, the AAD is not included in the AES-GCM output. It can be used to authenticate plaintext packet headers. In the CMS authenticated-enveloped-data content type, authenticated attributes comprise the AAD.

RFC 4304 - Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
http://tools.ietf.org/html/rfc4304

A Cryptographic Tour of the IPsec Standards
http://eprint.iacr.org/2006/097.pdf

3.2 AH Sequence Number Field
(.....)
RFC 4302 allows an optional Extended Sequence Number (ESN) to be used. This is helpful in high-speed networks, where a 32-bit counter could easily overflow during normal operations. ESNs are 64 bits long, and the entire 64 bits is used in the MAC calculation by AH even though only the least significant 32 bits of the ESN are carried in the Sequence Number Field. For the purposes of MAC calculation, the most significant 32 bits are placed after the payload, meaning that the ESN is actually split into two parts rather than appearing as a sequence of 64 consecutive bits in the input to the MAC. This is somewhat unusual, but does allow the AH format to remain the same as that specified in RFC 2402 when 32 bit sequence numbers are used. The transmission of only half the ESN in AH leads to the need for a synchronization mechanism in the event that more than 232 consecutive packets are lost. This is addressed in [22, Appendix B3]. RFC 4302 indicates that the default setting is to use ESNs rather than 32 bit sequence numbers; RFC 4304 [24] explains how IKE can be modi¯ed to allow negotation of ESNs.

4.2 ESP Sequence Number Field
Sequence numbers, including Extended Sequence Numbers (ESNs), are treated in largely the same way in RFC 4303 as they are in the AH RFC, RFC 4302. In particular, their use by the receiver is optional, but their inclusion in ESP headers is mandatory. The only real difference is that sequence numbers must be ignored by the recipient if the relevant ESP SA specifies the NULL integrity protection algorithm (in other words, if the SA only offers encryption). In this situation, ESP cannot offer an anti-replay service. If a combined mode algorithm is in use, the most significant bits of an ESN may actually be transmitted; if separate integrity and encryption algorithms are used, these bits are not transmitted, but are included in the MAC calculation by placing them in the ESP trailer, so they are split into two parts (as in AH).