wdiff rfc8750xml2.original.xml rfc8750.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3602 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3602.xml">
<!ENTITY RFC3686 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml">
<!ENTITY RFC4104 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4104.xml">
<!ENTITY RFC4106 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4106.xml">
<!ENTITY RFC4302 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY RFC4303 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4309 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY RFC4434 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4434.xml">
<!ENTITY RFC5374 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5374.xml">
<!ENTITY RFC6311 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6311.xml">
<!ENTITY RFC6407 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6407.xml">
<!ENTITY RFC7296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY RFC7383 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7383.xml">
<!ENTITY RFC7634 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7634.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8247 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8247.xml">
<!ENTITY RFC8221 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8221.xml">
<!ENTITY I-D.yeung-g-ikev2 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.yeung-g-ikev2.xml">
]> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8750" category="std"
     consensus="true" docName="draft-ietf-ipsecme-implicit-iv-11"
     ipr="trust200902">
     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
     xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
     version="3">

  <front>
    <title abbrev="Implicit IV in ESP">Implicit IV Initialization Vector (IV) for Counter-based Counter-Based
Ciphers in Encapsulating Security Payload (ESP) </title>

<seriesInfo name="RFC" value="8750"/>
    <author fullname="Daniel Migault" initials="D." surname="Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC H4S 0B6</city> Laurent</city>
          <region>QC</region>
          <code>H4S 0B6</code>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>
    <author fullname="Tobias Guggemos" initials="T." surname="Guggemos">
      <organization>LMU Munich</organization>
      <address>
        <postal>
          <street>Oettingenstr. 67</street>
                    <city>80538 Munich</city>
          <city>Munich</city>
          <region>Bavaria</region>
          <code>80538</code>
          <country>Germany</country>
        </postal>
        <phone/>
                <facsimile/>
                <email>guggemos@mnm-team.org</email>
        <email>guggemos@nm.ifi.lmu.de</email>
        <uri>http://mnm-team.org/~guggemos</uri>
      </address>
    </author>
    <author initials="Y." surname="Nir" fullname="Yoav Nir">
      <organization >Dell EMC</organization>
      <organization>Dell Technologies</organization>
      <address>
        <postal>
          <street>9 Andrei Sakharov St</street>
          <city>Haifa</city>
          <code>3190500</code>
          <country>Israel</country>
        </postal>
        <email>ynir.ietf@gmail.com</email>
      </address>
    </author>

        <date/>
    <date month="March" year="2020"/>
    <area>INTERNET</area>
    <workgroup>IPSECME</workgroup>

<keyword>IKE</keyword>
<keyword>IPsec</keyword>
<keyword>GCM</keyword>
<keyword>CCM</keyword>
<keyword>ChaCha20</keyword>

    <abstract>
      <t>Encapsulating Security Payload (ESP) sends an initialization vector
      (IV) in each packet. The size of the IV depends on the applied transform,
being transform
      and is usually 8 or 16 octets for the transforms defined by at the time
      this document is was written. Some algorithms When used with IPsec, some algorithms, such
      as AES-GCM, AES-CCM AES-CCM, and
ChaCha20-Poly1305 when used with IPsec, 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, itself and saves 8
      octets per packet in the case of AES-GCM, AES-CCM AES-CCM, and ChaCha20-Poly1305 8 octets per packet.
      ChaCha20-Poly1305. This document describes how to do this.</t>
    </abstract>
  </front>
  <middle>

    <section title="Requirements notation">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described BCP 14
<xref target="RFC2119"/>, <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>

</section>

<section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Counter-based AES modes of operation such as AES-CCM (<xref
target="RFC4309"/>), <xref
      target="RFC4309" format="default"/> and AES-GCM (<xref target="RFC4106"/>) <xref target="RFC4106"
      format="default"/> require the specification of an a nonce for each ESP
      packet. The same applies for ChaCha20-Poly1305 (<xref target="RFC7634"/>). Currently <xref target="RFC7634"
      format="default"/>. Currently, this nonce is generated thanks to the Initialization Vector
      initialization vector (IV) provided in each ESP packet (<xref target="RFC4303"/>). <xref
      target="RFC4303" format="default"/>. This practice is designated in
      this document as "explicit IV".</t>

      <t>In some contexts, such as IoT, the Internet of Things (IoT), it may be
      preferable to avoid carrying the extra bytes associated to the IV and
      instead generate it locally on each peer. The local generation of the IV
      is designated in this document as "implicit IV".</t>
      <t>The size of this IV depends on the specific algorithm, but all of the
      algorithms mentioned above take an 8-octet IV.</t>
      <t>This document defines how to compute the IV locally when it is
      implicit. It also specifies how peers agree with the Internet Key
      Exchange version 2 (IKEv2 - (IKEv2) <xref target="RFC7296"/>) target="RFC7296" format="default"/> on
      using an implicit IV versus an explicit IV.</t>
      <t>This document limits its scope to the algorithms mentioned above.
      Other algorithms with similar properties may later be defined to use
      similar mechanisms.</t>
      <t> This document does not consider AES-CBC (<xref target="RFC3602"/>) <xref target="RFC3602"
      format="default"/>, as AES-CBC requires the IV to be
      unpredictable. Deriving it directly from the packet counter as described
      below is insecure insecure, as mentioned in
Security Consideration of <xref target="RFC3602"/> target="RFC3602"
      sectionFormat="of" section="6"/>, and has led to real
world real-world chosen plain-text attack
      plaintext attacks such as BEAST <xref target="BEAST"/>.</t> target="BEAST"
      format="default"/>.</t>
      <t>This document does not consider AES-CTR <xref target="RFC3686"/> target="RFC3686" format="default"/>, as
it focuses on the recommended AEAD Authenticated Encryption with Associated Data (AEAD) suites provided in <xref
target="RFC8221"/>.</t> target="RFC8221" format="default"/>.</t>
    </section>

    <section anchor="sec:terminology" title="Terminology">

<t><list style="symbols">

<t>IoT: Internet of Things.</t>

<t>IV: Initialization Vector.</t>

<t>IIV: Implicit numbered="true" toc="default">
      <name>Requirements Notation</name>

        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>

    <section anchor="sec_terminology" numbered="true" toc="default">
      <name>Terminology</name>

      <dl newline="false" indent="9" spacing="normal">
        <dt>IoT:</dt> <dd>Internet of Things</dd>
        <dt>IV:</dt> <dd>Initialization Vector</dd>
        <dt>IIV:</dt> <dd>Implicit Initialization Vector.</t>

<t>Nonce: a Vector</dd>

        <dt>Nonce:</dt> <dd>A fixed-size octet string used only once. In our case, the nonce takes this
        document, the IV as input and is provided as an used to generate the nonce input parameter for the
        encryption/decryption. </t>

</list></t> </dd>
      </dl>

    </section>

<!--

        <section anchor="sec-aes-cbc" title="Implicit IV with AES CBC"> anchor="sec-aes-ctr-ccm-cgm" numbered="true" toc="default">
      <name>Implicit IV</name>
      <t>With AES-CBC, the IV is 16 bytes, random and unpredictable. In this
document, algorithms listed in <xref target="intro"
      format="default"/>, the 8-byte IV <bcp14>MUST NOT</bcp14> repeat for a
      given key. The binding between IV and an ESP packet and its IV is performed provided
      using the Sequence Number or the Extended Sequence Number. A clear text payload is
derived from

Figures <xref target="fig-aes-ctr-ccm-gcm-iv-sn" format="counter"/> and <xref
target="fig-aes-ctr-ccm-gcm-iv-esn" format="counter"/> represent the IV with a
regular 4-byte Sequence Number or the and an 8-byte Extended Sequence Number. In
order to generate the Number,
respectively.</t>
      <figure anchor="fig-aes-ctr-ccm-gcm-iv-sn">
        <name>Implicit IV randomly, AES is used as with a random permutation.
A dedicated 16 byte key is used for each peer. key_iv_initiator (resp.
key_iv_responder) is used to derive the IV emitted by the initiator
(resp. the responder).</t>

<t>Keys key_iv_initiator and key_iv_responder MUST be agreed prior IPsec
packets are exchanged. When IKEv2 <xref target="RFC7296"/> is used these
keys are derived from the KEYMAT. key_iv_initiator is the first key
generated, followed by key_iv_responder.</t>

<t><xref target="fig-aes-cbc-ct-sn"/> (resp. <xref
target="fig-aes-cbc-ct-esn"/>) defines a clear text payload derived from
a 4 byte Sequence Number (resp. a 8-byte Extended Sequence Number)</t>

<figure anchor="fig-aes-cbc-ct-sn" title="Clear Text Payload for AES-CBC">
<artwork><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                              Zero                             |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>

<t>Where,
<list hangIndent="3" style="hanging">
    <t hangText="-">Sequence Number: the 4 byte Sequence Number carried in the ESP packet.</t>
    <t hangText="-">Zero: a 12 byte array with all bits set to zero.</t>

</list></t>

<figure anchor="fig-aes-cbc-ct-esn" title="Clear Text Payload for AES-CBC with Extended 4-Byte Sequence Number">
<artwork><![CDATA[ Number</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Zero                             |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Extended                              |
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
      </figure>

<t>Where,
<list hangIndent="3" style="hanging">

<t hangText="-">Extended Sequence Number: the 8-byte Extended Sequence
Number of the Security Association. The 4 byte low order bytes are
carried in the ESP packet.</t>

<t hangText="-">Zero: a 8-byte array with all bits set to zero.</t>

</list></t>

        </section>
-->

        <section anchor="sec-aes-ctr-ccm-cgm"  title="Implicit IV">

<t>With the algorithms listed in <xref target="intro"/>, the 8-byte
IV MUST NOT repeat for a given key. The binding between an ESP packet
and its IV is provided using the Sequence Number or the Extended
Sequence Number.  <xref target="fig-aes-ctr-ccm-gcm-iv-sn"/> and <xref
target="fig-aes-ctr-ccm-gcm-iv-esn"/> represent the IV with a regular

      <dl newline="true" spacing="normal">
        <dt>Sequence Number:</dt>
        <dd>The 4-byte Sequence Number and with an 8-byte Extended Sequence Number
respectively.</t>

<figure anchor="fig-aes-ctr-ccm-gcm-iv-sn" title="Implicit IV with a 4 byte Sequence Number">
        <artwork><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Zero                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
</figure>
<t><list style="symbols">

<t>Sequence Number: the 4 byte Sequence Number carried in the ESP packet.</t>

<t>Zero: a 4 byte packet.</dd>

        <dt>Zero:</dt>
        <dd>A 4-byte array with all bits set to zero.</t>

</list></t> zero.</dd>
      </dl>

      <figure anchor="fig-aes-ctr-ccm-gcm-iv-esn" title="Implicit anchor="fig-aes-ctr-ccm-gcm-iv-esn">
        <name>Implicit IV with an 8-byte 8-Byte Extended Sequence Number">
        <artwork><![CDATA[ Number</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Extended                              |
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
      </figure>

        <t><list style="symbols">

<t>Extended
      <dl newline="true" spacing="normal">
        <dt>Extended Sequence Number: the Number:</dt> <dd>The 8-byte Extended Sequence
        Number of the Security Association. The 4 byte low order bytes are carried in the ESP
packet.</t>

</list></t>

<t> This document solely defines the IV generation of the algorithms
defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634]
for ChaCha20-Poly1305. All other aspects and parameters of those algorithms
are unchanged, and are used as defined in their respective
specifications.</t>

<!--
<t>Section
3.5 of <xref target="RFC6407"/> provides a mechanism that MAY be used to
prevent IV collisions when the same key is used by multiple users. The
mechanism consists in partitioning the IV space between users by
assigning the most significant byte to a user. When implicit IV
transforms are used, such mechanism cannot be applied as the IV is not
sent, but instead it is derived from the Sequence Number. A similar
mechanism could be used by associating the most significant byte of the
Sequence Number to a sender, while the 3 remaining bytes will be used to
carry the counter value. Such mechanism prevents the use of Extended
Sequence Number and limits the number of packet to be sent to 2** 24 =
16777216, that is 16 M. Note that associating instead the least
significant byte of the Sequence Number to the sender, would enable the
system to use Extended Sequence Number and as such extend the limit of
packet to be sent to 2 ** ( 24 + 32 ) = 72057594037927936, that is 72 P.
Note also that in both cases the Sequence Number are not interpreted as
numeric values which impacts the replay window processing defined in
<xref target="RFC4302"/> and <xref target="RFC4302"/>.</t>

<t>Unless some mechanism are provided to avoid collision between
Sequence Number, ( and so IV ), Implicit IV MUST NOT be used. As such,
it is NOT RECOMMENDED to use Implicit IV with Multicast.</t>
-->

</section>

<!--
    <section anchor="nego" title="Implicit IV Agreement">

<t>NOTE: THIS SECTION SHOWS SEVERAL WAYS TO DO THE SAME THING. OBVIOUSLY
THIS DOCUMENT WILL NOT BE PUBLISHED LIKE THAT. WE EXPECT WG DISCUSSION
TO PARE THIS DOWN TO JUST ONE WAY OF NEGOTIATING THE USE OF IMPLICIT IV
(IIV).</t>

<t>Negotiation of the use of implicit IV can be done in 3 different
ways: <list style="symbols">

<t> An IMPLICIT IV Transform Type. A proposal that contains this
transform type requires (if accepted) that IPsec use the implicit IV and
not include an explicit IV in the packets. To facilitate backward
compatibility with non-supporting implementations the Initiator SHOULD
add another proposal that does not include this transform type as well
as cryptographic suite the Initiator does not support Association. The four low-order bytes are
        carried in the implicit
IV.</t> ESP packet.</dd>
      </dl>
      <t> An IMPLICIT IV Transform ID. This doubles document solely defines the number of ENCR
transform IDs by creating an ENCR_AES_CCM_16_IIV for each
ENCR_AES_CCM_16.</t>

<t> An IMPLICIT IV Transform Attribute, which would be associated to a
Transform Type ID, specifying the use generation of an implicit IV. marks a
particular ENCR transform as using implicit IVs. To facilitate backward
compatibility with non-supporting implementations the Initiator SHOULD
add another ENCR transform algorithms
      defined in <xref target="RFC4106"/> for each algorithm so marked. In other words, AES-GCM, <xref
      target="RFC4309"/> for each ENCR_AES_CCM_16 with keylength=256 AES-CCM, and IIV=1, there will need
to be an ENCR_AES_CCM_16 with keylength=256 <xref target="RFC7634"/> for
      ChaCha20-Poly1305. All other aspects and no IIV attribute.</t>

</list> </t> parameters of those algorithms
      are unchanged and are used as defined in their respective
      specifications.</t>

</section>
-->

    <section title="IKEv2 numbered="true" toc="default">
      <name>IKEv2 Initiator Behavior"> Behavior</name>
      <t>An initiator supporting this feature SHOULD <bcp14>SHOULD</bcp14> propose implicit IV (IIV)
algorithms in the Transform Type 1 (Encryption Algorithm) Substructure
of the Proposal Substructure inside the Security Association Payload (SA
Payload) (SA)
payload in the IKEv2 Exchange. To facilitate backward compatibility
with non-supporting peers peers, the initiator SHOULD <bcp14>SHOULD</bcp14> also include those same
algorithms with explicit IV as separate transforms.</t>
    </section>
    <section title="IKEv2 numbered="true" toc="default">
      <name>IKEv2 Responder Behavior"> Behavior</name>
      <t>The rules of SA Payload payload processing require that the responder picks pick its
algorithms from the proposal sent by the initiator, thus this will
ensure
ensuring that the responder will never send an SA payload containing the
IIV transform to an initiator that did not propose it.</t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>Nonce generation for these algorithms has not been explicitly
      defined. It has been left to the implementation as long as certain
      security requirements are met. Typically, for AES-GCM, AES-CCM AES-CCM, and
      ChaCha20-Poly1305, the IV is not allowed to be repeated for one
      particular key. This document provides an explicit and normative way to
      generate IVs. The mechanism described in this document meets the IV
      security requirements of all relevant algorithms.</t>
      <t> As the IV must not repeat for one SA when Counter-Mode ciphers are
      used, implicit IV as described in this document MUST NOT <bcp14>MUST NOT</bcp14>
      be used in setups with the chance that the Sequence Number overlaps for
      one SA.

The sender's counter and the receiver's counter MUST <bcp14>MUST</bcp14> be reset
(by establishing a new SA and thus a new key) prior to the transmission of the
2^32nd packet for an SA that uses a non extended does not use an Extended Sequence Number
(respectively and
prior to the transmission of the 2^64nd 2^64th packet for an SA that uses does use an
Extended Sequence
Number). Number. This prevents sequence number Sequence Number overlaps for the
mundane point-to-point case. Multicast as described in <xref
target="RFC5374"/>, target="RFC5374"
format="default"/>, <xref target="RFC6407"/> target="RFC6407" format="default"/>, and <xref
target="I-D.yeung-g-ikev2"/>
target="I-D.ietf-ipsecme-g-ikev2" format="default"/> is a prominent example, where example in which
many senders share one secret and thus one SA.  As such, Implicit implicit IV may only
be used with Multicast if some mechanisms are employed that prevent the
Sequence Number to overlap from overlapping for one SA, otherwise Implicit SA; otherwise, implicit IV MUST NOT
<bcp14>MUST NOT</bcp14> be used with Multicast.  </t>

      <t>This document defines three new encryption transforms that use
      implicit IV. Unlike most encryption transforms defined to date, which
      can be used for both ESP and IKEv2, these transforms are defined for ESP
      only and cannot be used in IKEv2. The reason for this is that IKEv2 messages
      don't contain a unique per-message value that can be used for IV
      generation. The Message-ID field in the IKEv2 header is similar to the SN
      field in the ESP header, but recent IKEv2 extensions (<xref
target="RFC6311"/>, <xref target="RFC7383"/>) target="RFC6311"
      format="default"/> <xref target="RFC7383" format="default"/> do allow
      it to repeat, so there is not an easy way to derive unique IV from IKEv2
      header fields.</t>
    </section>
    <section title="IANA Considerations">

<t>The IANA numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has updated the "Internet Key Exchange Version 2 (IKEv2)
      Parameters" registry <xref target="RFC7296"/> target="RFC7296" format="default"/> by adding
      the following new code points to the "Transform Type Values"/"Transform Type 1 - Encryption
      Algorithm Transform IDs" subregistry under the "Transform Type Values"
      registry <xref target="IANA"/>:

<list hangIndent="3" style="hanging">
<t hangText="-">ENCR_AES_CCM_8_IIV: 29</t>
<t hangText="-">ENCR_AES_GCM_16_IIV: 30</t>
<t hangText="-">ENCR_CHACHA20_POLY1305_IIV: 31</t>
</list></t>

<t>These algorithms should be added with this document as ESP Reference
and "Not Allowed" for IKEv2 Reference.</t> target="IANA" format="default"/>:

</t>

<table anchor="iana-registry" align="left">
  <name>Additions to "Transform Type 1 - Encryption Algorithm Transform IDs" Registry</name>
  <thead>
    <tr>
      <th>Number</th>
      <th>Name</th>
      <th>ESP Reference</th>
      <th>IKEv2 Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>29</td>
      <td>ENCR_AES_CCM_8_IIV</td>
      <td>RFC 8750</td>
      <td>Not allowed</td>
    </tr>
    <tr>
      <td>30</td>
      <td>ENCR_AES_GCM_16_IIV</td>
      <td>RFC 8750</td>
      <td>Not allowed</td>
    </tr>
    <tr>
      <td>31</td>
      <td>ENCR_CHACHA20_POLY1305_IIV</td>
      <td>RFC 8750</td>
      <td>Not allowed</td>
    </tr>
  </tbody>
</table>

    </section>

  </middle>
  <back>

<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEv2"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3602.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4106.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4309.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5374.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6311.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6407.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7634.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7383.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8221.xml"/>
      </references>
      <references>
        <name>Informational References</name>

<!-- draft-yeung-g-ikev2 Replaced by draft-ietf-ipsecme-g-ikev2, which is I-D Exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-g-ikev2.xml"/>

        <reference anchor="BEAST" target="https://www.researchgate.net/publication/266529975_Here_Come_The_Ninjas">
          <front>
            <title>Here Come The xor Ninjas</title>
            <author initials="T." surname="Duong" fullname="Thai Duong">
              <organization/>
            </author>
            <author initials="J." surname="Rizzo" fullname="Juliano Rizzo">
              <organization/>
            </author>
            <date  month="May" year="2011"/>
          </front>
        </reference>

        <reference anchor="IANA" target="https://www.iana.org/assignments/ikev2-parameters">
          <front>
            <title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author><organization>IANA</organization></author>

          </front>
        </reference>
      </references>

    </references>

    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>We would like to thank  Valery Smyslov, Eric Vyncke, Alexey Melnikov,
Adam Roach, Magnus Nystrom <contact fullname="Valery Smyslov"/>, <contact
      fullname="Éric Vyncke"/>, <contact fullname="Alexey Melnikov"/>,
      <contact fullname="Adam Roach"/>, and <contact fullname="Magnus
      Nyström"/> (security directorate), directorate) as well as our three Security ADs Eric Rescorla, Benjamin Kaduk and Roman Danyliw --
      <contact fullname="Eric Rescorla"/>, <contact fullname="Benjamin
      Kaduk"/>, and <contact fullname="Roman Danyliw"/> -- for their valuable
      comments. We also would like to thank David Schinazi <contact fullname="David
      Schinazi"/> for its
implementation, his implementation as well as the ipseceme chairs Tero Kivinen and David
Waltermire
      <contact fullname="Tero Kivinen"/> and <contact fullname="David
      Waltermire"/> (the IPSECME Chairs) for moving this work forward.</t>

<t>NOTE TO THE EDITOR Eric has a accent on E and Magnus has double
points on o.</t>

    </section>
    </middle>
    <back>
        <references title="Normative References">
            &RFC2119;
            &RFC3602;
            &RFC3686;
            &RFC4106;
            <!-- &RFC4302; -->
            &RFC4303;
            &RFC4309;
            &RFC5374;
            &RFC6311;
            &RFC6407;
            &RFC7296;
            &RFC7634;
            &RFC7383;
            <!-- &RFC8247; -->
            &RFC8174;
            &RFC8221;
        </references>

        <references title="Informational References">
            &I-D.yeung-g-ikev2;

     <reference anchor="BEAST"
target="https://www.researchgate.net/publication/266529975_Here_Come_The_Ninjas">
        <front>
            <title>Here Come The xor Ninjas</title>
            <author initials="T. Duong" surname="Thai" fullname="Thai
Duong">
                <organization />
            </author>
            <author initials="J. Rizzo" surname="Juliano"
fullname="Juliano Rizzo">
                <organization />
            </author>
            <date day="13" month="May" year="2011" />
        </front>
        <seriesInfo name="" value="" />
    </reference>

    <reference anchor="IANA"
target="https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5">

    <front>
    <title>IANA IKEv2 Parameter - Type 1 - Encryption Algorithm
Transform IDs </title>
    <author/>
    <date/>
    </front>

    </reference>
        </references>

  </back>
</rfc>