Subject: Last Call: <draft-ietf-ipsecme-implicit-iv-07.txt> (Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 23 Sep 2019 11:07:28 -0700

The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'Implicit IV
for Counter-based Ciphers in Encapsulating Security
   Payload (ESP)'
  <draft-ietf-ipsecme-implicit-iv-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2019-10-07. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   Encapsulating Security Payload (ESP) sends an initialization vector
   (IV) or nonce 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, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do
   not require an unpredictable nonce.  When using such algorithms the
   packet counter value can be used to generate a nonce.  This avoids
   sending the nonce itself, and saves in the case of AES-GCM, AES-CCM,
   AES-CTR and ChaCha20-Poly1305 8 octets per packet.  This document
   describes how to do this.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ballot/

No IPR declarations have been submitted directly on this I-D.