Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)
Extracted elements (15)
AES-CBC is explicitly excluded because it requires an unpredictable IV; deriving the IV from the packet counter is insecure for CBC and has led to real-world chosen-plaintext attacks such as BEAST.
Implicit IV is motivated by IoT use cases where saving the 8-byte IV per packet is significant. Since counter-based AEAD algorithms (AES-GCM, AES-CCM, ChaCha20-Poly1305) require the IV to be unique but not unpredictable, the ESP Sequence Number can directly serve as the IV source.
The IIV transforms are defined for ESP only and cannot be used in IKEv2 because IKEv2 messages lack a unique per-message value suitable for IV generation; the IKEv2 Message-ID can repeat due to extensions RFC 6311 and RFC 7383.
Because the SA payload processing rules require the IKEv2 responder to select algorithms only from the initiator's proposal, a responder will never send an IIV transform to an initiator that did not propose it, ensuring safe negotiation with non-supporting peers.
An IKEv2 initiator supporting implicit IV SHOULD propose IIV algorithms in the Transform Type 1 Encryption Algorithm Substructure of the SA payload.
Implicit IV MUST NOT be used in setups where there is a chance that the Sequence Number overlaps for one SA, since IV reuse under a given key breaks security of counter-mode ciphers.
Implicit IV MUST NOT be used with Multicast unless mechanisms are employed that prevent Sequence Number overlap for one SA, since many senders share a single SA in multicast scenarios.
The 8-byte IV MUST NOT repeat for a given key when using AES-GCM, AES-CCM, or ChaCha20-Poly1305 with implicit IV.
The sender's and receiver's counters MUST be reset (by establishing a new SA and thus a new key) prior to transmission of the 2^32nd packet for an SA without Extended Sequence Numbers, and prior to the 2^64th packet for an SA using Extended Sequence Numbers.
To facilitate backward compatibility, the initiator SHOULD also include the same algorithms with explicit IV as separate transforms in the IKEv2 SA payload.
Three new ESP-only encryption transforms are defined: ENCR_AES_CCM_8_IIV (29), ENCR_AES_GCM_16_IIV (30), and ENCR_CHACHA20_POLY1305_IIV (31). These transforms use implicit IV and are not allowed for IKEv2.
Three new code points (29: ENCR_AES_CCM_8_IIV, 30: ENCR_AES_GCM_16_IIV, 31: ENCR_CHACHA20_POLY1305_IIV) have been added to the IKEv2 'Transform Type 1 - Encryption Algorithm Transform IDs' subregistry, each marked as ESP-only and not allowed for IKEv2.
The implicit IV mechanism provides an explicit and normative nonce generation method meeting the security requirements of AES-GCM, AES-CCM, and ChaCha20-Poly1305, closing an ambiguity left in prior specifications where nonce generation was implementation-defined.
When using a 4-byte Sequence Number, the implicit IV is constructed as a 4-byte zero field followed by the 4-byte ESP Sequence Number, forming an 8-byte IV total.
When using an 8-byte Extended Sequence Number, the implicit IV is the full 8-byte Extended Sequence Number of the Security Association; only the four low-order bytes are carried in the ESP packet.