One document matched: draft-mglt-ipsecme-diet-esp-iv-generation-00.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 -->
<!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 RFC4303 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4434 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4434.xml">
<!ENTITY RFC5795 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5795.xml">
<!ENTITY RFC5996 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY I-D.mglt-ipsecme-diet-esp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mglt-ipsecme-diet-esp.xml">
]>
<rfc category="std"
docName="draft-mglt-ipsecme-diet-esp-iv-generation-00.txt"
ipr="trust200902">
<front>
<title abbrev="Diet-ESP">Diet-ESP: Generating compressed IV and SN</title>
<author fullname="Daniel Migault" initials="D." surname="Migault" role="editor">
<organization>Orange</organization>
<address>
<postal>
<street>38 rue du General Leclerc</street>
<city>92794 Issy-les-Moulineaux Cedex 9</city>
<country>France</country>
</postal>
<phone>+33 1 45 29 60 52</phone>
<facsimile/>
<email>daniel.migault@orange.com</email>
<uri/>
</address>
</author>
<author fullname="Tobias Guggemos" initials="T." surname="Guggemos" role="editor">
<organization>Orange / LMU Munich</organization>
<address>
<postal>
<street>Am Osteroesch 9</street>
<city>87637 Seeg</city>
<region>Bavaria</region>
<country>Germany</country>
</postal>
<phone/>
<facsimile/>
<email>tobias.guggemos@gmail.com</email>
<uri/>
</address>
</author>
<date/>
<area>INTERNET</area>
<workgroup>IPSECME</workgroup>
<abstract>
<t>Diet-ESP describes how to compress the various ESP fields, thanks to the Diet-ESP Context. This document describes how the IV fields that belong to the encrypted payload can be compressed.</t>
<t>The document describes the extensions of the the Diet-ESP Context as well as the compression protocol.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in<xref target="RFC2119"/>.
</t>
</section>
<section title="Introduction">
<t>Diet-ESP <xref target="I-D.mglt-ipsecme-diet-esp"/> describes how to compress ESP fields. Fields are compressed according to a Diet-ESP Context. Diet-ESP has been described as a specific ROHC <xref target="RFC5795"/> framework that has no IR, IR-DYN nor any feed back ROHC message. It works in the Unidirectional mode of operation (U mode), and all necessary parameters are transmitted via the Diet-ESP Context that is negotiated between the two peers. As a result Diet-ESP defines a very specific and simplified ROHC framework which makes possible to implement Diet-ESP without implementing the whole ROHC.</t>
<t>In fact, Diet-ESP avoids ROHC complexity as a lot of parameters have already been negotiated with IKEv2 <xref target="RFC5996"/>.</t>
<t>The Initialization Vector (IV) is defined as a input for AES encryption and decryption. In order to provide the appropriated IV value AES-CBC <xref target="RFC3602"/> and AES-CTR <xref target="RFC3686"/> sends the IV in each IP packet as shown in figure <xref target="fig-iv-in-ctr"/>. In fact the output of AES-CTR and AES-CBC outputs a payload where the encrypted data is appended to the IV.</t>
<t>The IV MUST have to properties 1) they MUST be unpredictable by someone observing the network, then 2) the IV MUST be unique. The size of the IV differs depending on the encryption algorithm. AES-CTR has an 8 byte IV and AES-CBC a 16 byte IV.</t>
<t>This document defines a way to avoid sending the IV in each packet. Instead peers agree on a suite of pseudo random bytes. This makes the IV predictable by both peers only, and random to the rest of the world. As the IV can be derived by both peers, it may be removed completely from each IP packet. Another way is to only provide the LSB of the generated IV so receiver can better identify the appropriated IV used for decryption.</t>
<t>Note that the ICV of standard ESP <xref target="RFC4303"/> and Diet-ESP ICV includes the whole IV. As a result, the IV MUST be restored prior to the ICV check.</t>
<figure anchor="fig-iv-in-ctr" title="The IV in the ESP payload.">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |Int.
~ Initialization Vector (variable) ~ |Cov-
| | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
~ Encrypted Payload (variable) ~ |
| | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| |
~ Authentication Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><xref target="sec-ctx"/> describes the new parameters for the Diet-ESP Context. <xref target="sec-prf"/> describes how the Pseudo Random Function is derived, and <xref target="sec-protocol"/> describes the protocol.</t>
</section>
<section anchor="sec:terminology" title="Terminology">
<t>
<list hangIndent="3" style="hanging">
<t hangText="-">IoT: Internet of Things</t>
<t hangText="-">IV: Initialization Vector</t>
<t hangText="-">ICV: Integrity Check Value</t>
<t hangText="-">PRF: Pseudo Random Function</t>
</list>
</t>
</section>
<section anchor="sec-ctx" title="Diet-ESP context extension">
<t>To enable the compression of the IV, the Diet-ESP context defined in <xref target="I-D.mglt-ipsecme-diet-esp"/> is extended with to values:
<list style="hanging" hangIndent="3">
<t hangText="IV_COMPRESSION:"><vspace blankLines="0"/>Defines if the IV is generated and compresses.</t>
<t hangText="IV_PRFT (optional):"><vspace blankLines="0"/>
Defines the Pseudo Random Function Transform used for the Pseudo Random Function. Available IDs are defined in <eref target="http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-6"></eref> Section Transform Type 2 - Pseudo random Function Transform IDs. Section 2.13 <xref target="RFC5996"/> defines how the PRF is derived. By default PRF_AES_128_CBC is the Pseudo Random Function Transform considered.
</t>
<t hangText="IV_LSB:"><vspace blankLines="0"/>
Defines the number of Least Significant Bytes of the IV carried by the payload.
</t>
</list>
</t>
</section>
<section anchor="sec-prf" title="Pseudo Random Function">
<t>The Pseudo Random Function (PRF) is defined from the Pseudo Random Function Transform in Section 2.13 <xref target="RFC5996"/>. Unless specified otherwise PRF_AES128_XCBC <xref target="RFC4434"/> is the default Pseudo Random Function Transform.</t>
<t>The PRF "prf+" described in Section 2.13 <xref target="RFC5996"/> takes two arguments designated as K and S. In this document K is the encryption key and S is the authentication key appended to the string "IV random generation". The string results in non null S value even if no integrity algorithms are negotiated.</t>
<!--
<t>For the explicit generation of the IV we consider the following parameters:
<list style="hanging" hangIndent="5">
<t hangText="- PRF:">The PRF is the same one, used for the integrity in IPsec/ESP. If it is used, the ESP_INTEG_ALGORITHM in the IPsec Security Association MUST NOT be NULL, even if authentication is disabled in the SA.</t>
<t hangText="- P:">The password is the encryption key.</t>
<t hangText="- S:">The SN of the packet.</t>
<t hangText="- c:">The number of iterations can be small, as the password is really strong (at least 128 Bit for AES). Since the value is not negotiated, the value 1 MUST be used.</t>
<t hangText="- dkLen:">The output length is defined by the size of the implicit IV of the encryption algorithm (e.g. 8 Bytes for AES-CTR, 16 Bytes for AES-CBC).</t>
</list>
</t>
-->
</section>
<section anchor="sec-protocol" title="Protocol Description">
<t>IV generation and compression is performed only and only if IV_COMPRESSION is set. Otherwise, the IV is embedded into the packet and sent on the wire as described in <xref target="RFC4303"/>.</t>
<t>When IV_COMPRESSION is set, the PRD is defined as described in <xref target="sec-prf"/>. On the sending part, the ICV or Diet-ESP ICV is computed, the IV is compressed to its LSB, before it is sent on the wire. On te receiver part, the IV is decompress prior to the ICV check, then decryption is performed with the decompressed IV.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA consideration for this document.</t>
</section>
<section anchor="sec-security-considerations" title="Security Considerations">
</section>
<section title="Acknowledgment">
<t>The current draft represents the work of Tobias Guggemos while his internship at Orange <xref target="GUGG14"/> .</t>
<t>Diet-ESP is a joint work between Orange and Ludwig-Maximilians-Universitaet Munich. We thank Daniel Palomares and Carsten Bormann for their useful remarks, comments and guidance.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3602;
&RFC3686;
&RFC4303;
&RFC4434;
&RFC5795;
&RFC5996;
&I-D.mglt-ipsecme-diet-esp;
</references>
<references title="Informational References">
<reference anchor="GUGG14" target="">
<front>
<title>Diet-ESP: Applying IP-Layer Security in Constrained Environments (Masterthesis)</title>
<author initials="TG" fullname="Tobias Guggemos" surname="Guggemos">
<organization />
</author>
<date month="September" year="2014" />
</front>
</reference>
</references>
<section title="Document Change Log">
<t>[draft-mglt-ipsecme-diet-esp-IV-generation-00.txt]: First version published.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:50:47 |