{
  "draft": "draft-ietf-ipsecme-implicit-iv-11",
  "doc_id": "RFC8750",
  "title": "Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)",
  "authors": [
    "D. Migault",
    "T. Guggemos",
    "Y. Nir"
  ],
  "format": [
    "XML",
    "TEXT",
    "HTML",
    "PDF"
  ],
  "page_count": "8",
  "pub_status": "PROPOSED STANDARD",
  "status": "PROPOSED STANDARD",
  "source": "IP Security Maintenance and Extensions",
  "abstract": "Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet.  The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written.  When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, 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 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305.  This document describes how to do this.",
  "pub_date": "March 2020",
  "keywords": [
    "IKE",
    "IPsec",
    "GCM",
    "CCM",
    "ChaCha20"
  ],
  "obsoletes": [],
  "obsoleted_by": [],
  "updates": [],
  "updated_by": [],
  "see_also": [],
  "doi": "10.17487/RFC8750",
  "errata_url": null
}