<?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 RFC0791 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
        <!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <!ENTITY RFC2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
        <!ENTITY RFC3095 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3095.xml">
        <!ENTITY RFC4301 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
        <!ENTITY RFC4303 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
        <!ENTITY RFC5225 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5225.xml">
        <!ENTITY RFC6282 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
        ]>

<rfc category="std"
     docName="draft-mglt-ipsecme-diet-esp-requirements-00.txt"
     ipr="trust200902">
    <front>
        <title abbrev="Diet-ESP">Diet-IPsec: Requirements for new IPsec/ESP protocols according to IoT use cases</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>
<!--
        <author fullname="Daniel Palomares" initials="D." surname="Palomares">
            <organization>Orange / LIP6 - UMPC</organization>
            <address>
                <postal>
                    <street>10, Rue du Moulin</street>
                    <city>92170 Vanves</city>
                    <region>Ille-de-France</region>
                    <country>France</country>
                </postal>
                <phone/>
                <facsimile/>
                <email>daniel.palomares@orange.com</email>
                <uri/>
            </address>
        </author>
-->
        <date/>
        <area>INTERNET</area>

        <workgroup>IPSECME</workgroup>

        <abstract>
            <t>IPsec/ESP is used to secure end-to-end communications. 
               This document lists the requirements Diet-ESP should 
               meet to design IPsec/ESP for IoT.</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>IoT devices can carry all kind of small applications and some of them require a secure communication. They can be life critical devices (like a fire alarm), security critical devices (like home theft alarms) and home automation devices. Smart grid is one application where supplied electricity is based on information provided by each home. Similarly, home temperature might be determined by servo-controls based on information provided by temperature sensors. </t>
            <t>Using IPsec <xref target="RFC4301"/> in the IoT world provides some advantages, such as:
                <list hangIndent="3" style="hanging">
                   <t hangText="-">IPsec secures application communications transparently as security is handled at the IP layer. As such, applications do not need to be modified to be secured.</t>
                   <t hangText="-">IPsec does not depend on the transport layer. As a result, the security framework remains the same for all transport protocols, like UDP or TCP.</t>
                   <t hangText="-">IPsec is well designed for sleeping nodes as there are no sessions.</t>
                   <t hangText="-">IPsec defines security rules for the whole device, which outsource the device security to a designated area. Therefore IPsec can be seen like a tiny firewall securing all communication for an IoT device.</t>
                </list>
            </t>

            <t>A common disadvantage of IPsec is that it is mostly implemented in the kernel, whereas application are in the user space. As there are no real distinctions between these two spaces in IoT and that IoT devices are mostly designed to a specific and unique task, this may not be an issue anymore.</t>

            <t>IoT constraints have not been considered in the early design of IPsec. In fact IPsec has mainly been designed to secure infrastructure. This document describes the requirements of Diet-ESP, the declination of IPsec/ESP for IoT, enabling optimized IPsec/ESP for the IoT.</t>
        </section>

        <section anchor="sec:terminology" title="Terminology">
            <t>
                <list hangIndent="3" style="hanging">
                    <t hangText="-">IoT: Internet of Things</t>
                </list>
            </t>
        </section>

<!--
        <section anchor="sec:iot" title="IoT Requirements">
            <section title="Communication costs">

-->
            <section title="Byte-Alignment">
 
                <t>IP extension headers MUST have 32 bit Byte-Alignment in IPv4 (section 3.1 of <xref target="RFC0791"/> - Padding description) and a 64 bit Byte-Alignment in IPv6 (section 4 of <xref target="RFC2460"/>). As ESP <xref target="RFC4303"/> is such an extension header, padding is mandatory to meet the alignment constraint. This alignment is mostly caused by compiler and OS requirements dealing with a 32 or 64 Bit processor. In the world of IoT, processors and compilers are highly specialized and alignment is often not necessary 32 Bit, but 16 or 8 bit.</t>
                <t>
                    <list style="format R%d:" counter="my_count">
                        <t>Diet-ESP SHOULD support Byte-Alignment that are different from 32 bits or 64 bits to prevent unnecessary padding. </t>
                        <t>Each peer SHOULD be able to advertise and negotiate the Byte-Alignment, used for Diet-ESP. This could be done for example during the IKEv2 exchange.</t>
                    </list>
                </t>

            </section>

            <section title="Crypto-Suites">
                <t>IEEE 802.15.4 defines AES-CCM*, that is AES-CTR and CBC-MAC, for link layer security with upper layer key-management. Therefore it is usually supported by hardware acceleration.</t>
<!--The key management is shift to the upper layer, which can be done with IKEv2 <xref target="RFC5996"/>.
-->
                <t>
                    <list style="format R%d:" counter="my_count">
                        <t>Diet-ESP MUST support AES-CCM and MUST be able to take advantage of AES-CCM hardware acceleration. Diet-ESP MAY support other modes.</t>
                    </list>
                </t>


<!--take advanatge of . The use of AES-CCM is already described in <xref target="RFC4309"/>. Any implementation SHOULD be aware of the hardware acceleration supported by the device.</t>
-->
            </section>

            <section title="Compression">
                <t>Sending data is very expensive regarding to power consumption, as illustrated in <xref target="sec-power-consumption"/>. Compression can be performed at different layers. An encrypted ESP packet is an ESP Clear Text Data encrypted and eventually concatenated with the Initialization Vector IV to form an Encrypted Data Payload. This encrypted Data Payload is then placed between an ESP Header and an ESP Trailer. Eventually, this packet is authenticated with an ICV appended to ESP Trailer. Compression can be performed at the ESP layer that is to say for the fields of the ESP Header, ESP Trailer and the ICV. In addition, ESP Clear Text Data may also be compressed with non ESP mechanisms like ROHC <xref target="RFC3095"/>, <xref target="RFC5225"/> for example, resulting in a smaller payload to be encrypted. If ESP is using encryption, these mechanisms MUST be performed over the ESP Clear Text Data before the ESP/Diet-ESP processing as missing of encrypted fields make decryption harder.</t>

                <t>
                    <list style="format R%d:" counter="my_count">
                        <t>Diet-ESP SHOULD be able to compress/remove all static ESP fields (SPI, Next Header) as well as the other fields SN, PADDING, Pad Length or ICV.</t>
                        <t>Diet-ESP SHOULD also allow compression mechanisms before the IPsec/ESP processing.</t> 

                        <!-- To me we meet this goal in the inner-payload compression graph, as we negociate profiles with IKEv2. Another way to see that is to consider that DIet-ESP is based on ROHC overIPsec which make thispossible. ANy opinion?--> 
                        <t>Diet-ESP SHOULD NOT allow compressed fields, not aligned to 1 byte in order to prevent alignment complexity. In other words, Diet-ESP do not consider finer granularity than the byte.</t>
                    </list>
                </t>
            </section>

            <section title="Flexibility">
                <t>Diet-ESP can compress some of the ESP fields as Diet-ESP is optimized for IoT. Which field may be compressed or not, depends on the scenario and current and future scenarios cannot been foreseen. In fact Diet-ESP and ESP differs in the following point: ESP has been designed so that any ESP secured communication on any device is able to communicate with another. This means that ESP has been designed to work for large Security Gateway under thousands of connections, as well as devices with a single ESP communication. Because, ESP has been designed not to introduce any protocol limitations, counters and identifiers may become over-sized in an IoT context.</t>

                <t>
                    <list style="format R%d:" counter="my_count">
                        <t>The developer SHOULD be able to specify the maximum level of compression.</t>
                        <t>Diet-ESP SHOULD be able to compress any field independent from another.</t>
                        <t>Diet-ESP SHOULD be able to define different compression method, when appropriated.</t>
                        <t>Each peer SHOULD be able to announce and negotiate the different compressed fields as well as the used method.</t>
                    </list>
                </t>
            </section>

            <section title="Code Complexity"> 
                <t>IoT devices have limited space for memory and storage.</t>

                <t>
                    <list style="format R%d:" counter="my_count">
                        <t>Diet-ESP SHOULD be able to be implemented with minimal complexity. More especially, Diet-ESP SHOULD consider small implementation that implement only a subset of all Diet-ESP capabilities without requiring involving standard ESP, specific compressors and de-compressors.</t>
                    </list>
                </t>
            </section>

            <section title="Usability">
                <t>Application Developer usually do not want to take care about the underlying protocols and security. Standard ESP addresses the goal by providing a framework that secures communication in any circumstances. Although application developers for IoT are expected to pay more attention to the device security and system requirements, we do not expect them to be security aware developers. As a result, some default parameters that provides a standard secure framework for most cases should be provided. This is of course performed at the expense of some optimization, but it makes possible for application developers to have "standard" security and standard Diet-ESP compression by setting a single bit "DIET-ESP secure". More advanced developers will be able to tune the security parameters for their needs.</t>

                <t>
                    <list style="format R%d:" counter="my_count">
                        <t>Diet-ESP SHOULD provide default configurations, which can be easily set up by a developer.</t>
                    </list>
                </t>
            </section>

            <section title="Compatibility with IP compression Protocols">
                <t>There are different protocols providing IP layer compression for constraint devices like IoT (6LoWPAN <xref target="RFC6282"/> ) or Mobile Devices (ROHC).</t>
                <t>
                    <list style="format R%d:" counter="my_count">
                        <t>Diet-ESP SHOULD be able to interact with IP compression protocols. More especially, this means that a Diet-ESP packet SHOULD be able to be sent in a ROHC or a 6LowPAN packet. Diet-ESP document should explicitly detail how this can be achieved.</t>
                        <t>Diet-ESP SHOULD also detail how compression of layers above IP with ROHC or 6LowPAN is compatible with Diet-ESP.</t>
                    </list>
                </t>
            </section>

            <section title="Compatibility with Standard ESP">
                <t>IPsec/ESP is widely deployed by different vendors on different machines. IoT devices MAY have to communicate with Standard ESP implementations.</t>
                <t>
                    <list style="format R%d:" counter="my_count">
                        <t>Diet-ESP SHOULD be able to interact with Standard ESP implementations on a single platform.</t>
                        <t>Diet-ESP SHOULD be able to communicate with Standard ESP.</t>
                    </list>
                </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">
            &RFC0791;
            &RFC2119;
            &RFC2460;
            &RFC3095;
            &RFC4301;
            &RFC4303;
            &RFC5225;
            &RFC6282;
        <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 anchor="sec-power-consumption" title="Power Consumption Example">
                <t>IoT devices are often installed once and left untouched for a couple of years. Furthermore they often do not have a power supply wherefore they have to be fueled by a battery. This battery may have a limited capacity and maybe not replaceable. Therefore, power can be a limited resource in the world of IoT. <xref target="table-power-transmission"/> and <xref target="table-power-computing"/> shows the costs for transmitting data and computation 
</t>
<!--
We need additional reference. It would be nice to have a URL or mention the device
-->

<t>Note these data are mentioned here with an illustrative purpose, for our motivations. These data may vary from one device to another, and may change over time.</t>

                <texttable anchor="table-power-transmission" title="Power consumption for data transmission.">
                    <ttcol align='left'></ttcol>
                    <ttcol align='left'>power consumption</ttcol>
                    <c>low-power radios &lt; 10mW</c>
                    <c>(100nJ - 1uJ) / bit</c>
                </texttable>
                <texttable anchor="table-power-computing" title="Power consumption for computation.">
                    <ttcol align='left'></ttcol>
                    <ttcol align='left'>power consumption</ttcol>
                    <c>energy-efficient microprocessors</c>
                    <c>0.5nJ / instruction</c>
                    <c>high-performance microprocessors</c>
                    <c>200nJ / instruction</c>
                </texttable>
                <t>From these tables, sending 1 bit costs as much as 10-100 instructions in the CPU. Therefore there is a high interest to reduce the number of bits sent on the wire, even if it generates costs for computation.</t>

        </section>

        <section title="Document Change Log">
            <t>[draft-mglt-ipsecme-diet-ipsec-requirements-00.txt]: First version published.</t>
        </section>
    </back>
</rfc>
