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

The IESG <iesg-secretary@ietf.org> Mon, 23 September 2019 18:07 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Sender: iesg-secretary@ietf.org
CC: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen <kivinen@iki.fi>, kivinen@iki.fi, ipsec@ietf.org, alexey.melnikov@isode.com
Content-Transfer-Encoding: 7bit
Reply-To: ietf@ietf.org
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <156926204805.17123.14844528696780230612.idtracker@ietfa.amsl.com>
Date: Mon, 23 Sep 2019 11:07:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/dhA4NxWOe_hpz7_fI7xUFOS3S-I>
Subject: [IPsec] Last Call: <draft-ietf-ipsecme-implicit-iv-07.txt> (Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)) to Proposed Standard

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
ietf@ietf.org mailing lists by 2019-10-07. Exceptionally, comments may be
sent to iesg@ietf.org 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.

[IPsec] Last Call: <draft-ietf-ipsecme-implicit-i… The IESG