<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-ipsecme-implicit-iv" target="https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-03">
   <front>
      <title>Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)</title>
      <author initials="D." surname="Migault" fullname="Daniel Migault">
         <organization>Ericsson</organization>
      </author>
      <author initials="T." surname="Guggemos" fullname="Tobias Guggemos">
         <organization>LMU Munich</organization>
      </author>
      <author initials="Y." surname="Nir" fullname="Yoav Nir">
         <organization>Dell EMC</organization>
      </author>
      <date month="May" day="9" year="2018" />
      <abstract>
	 <t>   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.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-implicit-iv-03" />
   
</reference>
