%% You should probably cite rfc8750 instead of this I-D. @techreport{ietf-ipsecme-implicit-iv-10, number = {draft-ietf-ipsecme-implicit-iv-10}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/10/}, author = {Daniel Migault and Tobias Guggemos and Yoav Nir}, title = {{Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)}}, pagetotal = 8, year = ** No value found for 'doc.pub_date.year' **, month = ** No value found for 'doc.pub_date' **, day = ** No value found for 'doc.pub_date.day' **, abstract = {Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself, and saves in the case of AES-GCM, AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this.}, }