{"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":["HTML","TEXT","PDF","XML"],"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\r\n(IV) in each packet. The size of the IV depends on the applied\r\ntransform and is usually 8 or 16 octets for the transforms defined at\r\nthe time this document was written. When used with IPsec, some\r\nalgorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the\r\nIV to generate a nonce that is used as an input parameter for\r\nencrypting and decrypting. This IV must be unique but can be\r\npredictable.  As a result, the value provided in the ESP Sequence\r\nNumber (SN) can be used instead to generate the nonce. This avoids\r\nsending the IV itself and saves 8 octets per packet in the case of\r\nAES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how\r\nto 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}