Counter-based AES modes of operation such as AES-CCM [RFC 4309
] and AES-GCM [RFC 4106
] require the specification of a nonce for each ESP packet. The same applies for ChaCha20-Poly1305 [RFC 7634
]. Currently, this nonce is generated thanks to the initialization vector (IV) provided in each ESP packet [RFC 4303
]. This practice is designated in this document as "explicit IV".
In some contexts, such as the Internet of Things (IoT), it may be preferable to avoid carrying the extra bytes associated to the IV and instead generate it locally on each peer. The local generation of the IV is designated in this document as "implicit IV".
The size of this IV depends on the specific algorithm, but all of the algorithms mentioned above take an 8-octet IV.
This document defines how to compute the IV locally when it is implicit. It also specifies how peers agree with the Internet Key Exchange version 2 (IKEv2) [RFC 7296
] on using an implicit IV versus an explicit IV.
This document limits its scope to the algorithms mentioned above. Other algorithms with similar properties may later be defined to use similar mechanisms.
This document does not consider AES-CBC [RFC 3602
], as AES-CBC requires the IV to be unpredictable. Deriving it directly from the packet counter as described below is insecure, as mentioned in Section 6
of RFC 3602
, and has led to real-world chosen plaintext attacks such as BEAST [BEAST
This document does not consider AES-CTR [RFC 3686
], as it focuses on the recommended Authenticated Encryption with Associated Data (AEAD) suites provided in [RFC 8221