<?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 RFC3095 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3095.xml">
        <!ENTITY RFC3843 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3843.xml">
        <!ENTITY RFC4019 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4019.xml">
        <!ENTITY RFC5225 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5225.xml">
        <!ENTITY RFC5795 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5795.xml">
        <!ENTITY RFC5856 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5856.xml">
        <!ENTITY RFC5996 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
        <!ENTITY RFC6846 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6846.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-payload-compression-00.txt"
     ipr="trust200902">

    <front>
        <title abbrev="Diet-ESP">Diet-IPsec: ESP Payload Compression of IPv6 / UDP / TCP / UDP-Lite</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>ESP is a IPsec protocol that takes as input a Clear Text Data and outputs an encrypted ESP packet according to IPsec rules and parameters stored in different IPsec databases.</t>
            <t>Diet-ESP compresses the ESP fields. However, Diet-ESP does not consider compression of the Clear Text Data. Instead, if compression of the Clear Text Data is expected protocols like ROHCoverIPsec can be used.</t>
            <t>ROHCoverIPsec remains complex to implement in IoT devices, as states, and negotiations are involved between the compressors and decompressors of the two IoT devices. Most of this complexity can be avoided by considering the parameters that have been negotiated by IPsec.</t>
            <t>This document describes an extension of the Diet-ESP Context that enables the compression of the Clear Text Data, without implementing the complex ROHCoverIPsec framework. As opposed to ROHCoverIPsec the compression is not generic and as such all communication will not benefit from this compression. However, we believe this extension addresses most of IoT communications.</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>This document describes the Diet-ESP Payload Compression Extension. It does not consider the compression of the ESP fields. Instead, it goes one step further and describes how to compress the Clear Text Data or ESP Payload before it is encrypted by Diet-ESP. The Clear Text Data is generally constituted by an IP packet with IP -- if IPsec tunnel mode is used --, transport and application layers. Similarly to Diet-ESP, compression takes advantage of the IPsec parameters -- like IP addresses, transport layer parameters -- that have been negotiated in order to establish the Security Association -- via IKEv2 for example. In addition, similarly to Diet-ESP, the compression is described using the ROHC terminology, but uses a very specific and simplified ROHC framework of Diet-ESP. This makes possible compression of the Clear Text Data without implementing a whole ROHC framework for ROHCoverIPsec <xref target="RFC5856"/>.</t>
            <t><xref target="I-D.mglt-ipsecme-diet-esp"/> clarifies the interactions of Diet-ESP with ROHC and 6LoWPAN. The Diet-ESP extension explained in this document replaces ROHCoverIPsec and 6LoWPANoverIPsec, protocols which offers similar functionality without using the IPsec databases. The Diet-ESP Payload Compression Extension uses the IPsec databases to avoid complex dialogues between compressors and decompressors.</t>

        <t>The Diet-ESP Payload Compression Extension can be described as follows:
                <list style="hanging" hangIndent="3">
                    <t hangText="- 1. ">Definition or Diet-ESP parameters: COMPRESS_ESP_PAYLOAD, CHECKSUM_LSB and SEQUENCE_NUMBER_LSB. COMPRESS_ESP_PAYLOAD indicates the peers expect the Clear Text Data to be compressed, CHECKSUM_LSB and SEQUENCE_NUMBER_LSB are additional parameters to perform the compression.</t>
                    <t hangText="- 2. ">Definition of a Diet-ESP Payload Compression algorithm.</t>
                </list>
        </t>

    <t>The remaining of the document is as follows. <xref target="sec-diet-esp-context-ext"/> describes the new parameters for the Diet-ESP Context. <xref target="sec-protocol"/> describes the protocol. <xref target="sec-profile-ip"/>, <xref target="sec-profile-udp"/>, <xref target="sec-profile-udp"/>  and <xref target="sec-profile-tcp"/> describe the compression of the IP layer and the transport layer (UDP, UDP-Lite.</t>

    </section>

        <section anchor="sec:terminology" title="Terminology">
            <t>Diet-ESP Context: Like defined in Diet-ESP document.</t>
            <t>SPD: Security Policy Database</t>
            <t>SAD: Security Association Database</t>
            <t>TS: Traffic Selector of a Security Association.</t>
            <t>LSB: Least Significant Byte</t>
            <t>MSB: Most Significant Byte</t>
        </section>

        <section anchor="sec-diet-esp-context-ext" title="Diet-ESP Context Extension">
            <t>This section describes the additional parameters of the Diet-ESP Context to implement the ESP Payload Compression extension.</t>

            <texttable anchor="table-diet-esp-context" title="Diet-ESP Context.">
                <ttcol align='left'>Context Field Name</ttcol>
                <ttcol align='left'>Overview</ttcol>

                <c>COMPRESS_ESP_PAYLOAD</c><c>Defines the use of the Traffic Selector for (de-)compression.</c>
                <c>CHECKSUM_LSB</c><c>LSB of the UDP, UDP-Lite or TCP checksum</c>
                <c>SEQUENCE_NUMBER_LSB</c><c>LSB of the TCP Sequence Number.</c>

            </texttable>


             <t>
                <list style="hanging" hangIndent="3">
                    <t hangText="COMPRESS_ESP_PAYLOAD:">
                        <vspace blankLines="0"/>
                        Defines if the ESP Payload MUST be compressed or not. Note that as detailed later, compression of the ESP Payload requires that IP addresses, or protocols are unique in the Security Association Databases. If not the compression does not compress does not output a compressed ESP Payload.
                    </t>
                    <t hangText="CHECKSUM_LSB:">
                        <vspace blankLines="0"/>
                        If an inner header provides a checksum this can be compressed by the LSB mechanism. How the checksum is compressed is specified by the related profiles, e.g. UDP <xref target="sec-profile-udp"/> , UDP-Lite <xref target="sec-profile-udp-lite"/> and TCP <xref target="sec-profile-tcp"/>.
                    </t>
                    <t hangText="SEQUENCE_NUMBER_LSB:">
                        <vspace blankLines="0"/>
                        If an inner header provides a Sequence Number, one MAY choose to use the SN stored in the SA for compression. Therefore the context provides the LSB of the Sequence Number which is used by all profiles, defining the Sequence Number as compressed with LSB, e.g. TCP <xref target="sec-profile-tcp"/>.
                    </t>
                </list>
            </t>
        </section>

    <section anchor="sec-protocol" title="Protocol Overview">

        <t>The Diet-ESP Payload Compression is described by the pseudo code in <xref target="fig-diest-esp-compression"/>. The Clear Text Data is compressed only if COMPRESS_ESP_PAYLOAD is set. Otherwise, it is left unchanged. When COMPRESS_ESP_PAYLOAD is set, compression is performed on the IP and transport layer if and only if two conditions are met. First the layer must exist. This means for example that the IP layer is compressed only for the tunnel mode. Then, the layer can be compressed if and only if the values are uniquely derived from the IPsec databases. More specifically, if a SPD match occurs with at least two different values, then the compression do not occurs.</t>

        <t>As a result, the IP layer can be compressed only if the IP address appears as a Traffic Selector. If the Traffic Selector is defined as a subnetwork, a SPD match occurs with more then one IP address, and then no compression occurs. Similarly, the transport layer is compressed if and only if it appears as a Traffic Selector. If a SPD match occurs with different transport protocol then the compression of the transport layer does not occurs.</t>

        <t>The Diet-ESP Payload Compression is straight forward, but may at some point not fits all the needs. At some point using alternative compression as those proposed by ROHCoverIPsec may be preferred. In these cases, Diet-ESP Payload Compression MUST NOT be performed and COMPRESS_ESP_PAYLOAD MUST be unset.</t>

<figure anchor="fig-diest-esp-compression" title="Diet-ESP Payload Compression Pseudo Code">
                    <artwork><![CDATA[
if COMPRESS_ESP_PAYLOAD is set :
         proceed to Diet-ESP Payload Compression
else:
        clear_text_data is left unchanged.

def diet_esp_payload_compression(clear_text_data, \
                                 CHECKSUM_LSB,\
                                 SEQUENCE_NUMBER_LSB):
    if clear_text_data has IP layer and \ ## i.e. IPsec mode Tunnel mode
       IP address is a Traffic Selector:  ## subnets are not considered
        compress the IP layer
    if clear_text_data has transport layer and \
       transport layer is a Traffic Selector:
        compress transport layer
                  ]]></artwork>
                </figure>

            <t>Roughly speaking Diet-ESP is able to remove all header fields which have unique values inside the Security Association Database. Most probably they are stored in the Traffic Selector, which defines the traffic which has to be secured with IPsec. <xref target="table-ipsec-sa-values"/> shows some header fields which can be adopted from the Traffic Selector. The table provides the ROHC class of these values, as we use the ROHC terminology to describe the compression algorithms.</t>

            <texttable anchor="table-ipsec-sa-values" title="This values are carried in the Security Association.">
                <ttcol align='left'>Field</ttcol>
                <ttcol align='left'>Protocol</ttcol>
                <ttcol align='left'>ROHC class</ttcol>

                <c>IP version</c><c>IP/IPv6</c><c>STATIC-KNOWN</c>

                <c>Source Address</c><c>IP/IPv6</c><c>STATIC-DEF</c>

                <c>Destination Address</c><c>IP/IPv6</c><c>STATIC-DEF</c>

                <c>Next Header</c><c>IP/IPv6</c><c>STATIC</c>

                <c>Source PORT</c><c>UPD/TCP</c><c>STATIC-DEF</c>

                <c>Destination PORT</c><c>UPD/TCP</c><c>STATIC-DEF</c>
            </texttable>

        </section>


            <section anchor="sec-profile-ip" title="IP Layer Compression">
                <t>This section describes how the compression of the IP layer is performed. The compression of this layer mostly occurs when the peers have negotiated the IPsec tunnel mode.</t>

                <t>The basic idea for IP layer compression is to remove the IP layer before Diet-ESP encrypts the Clear Text Data. Similarly, for incoming packet, Diet-ESP decrypts the ESP packet, and restores the IP layer by reading the IP address in the IPsec SAD. However, the IP address is not sufficient to restore the complete IP header as other fields must be considered. To appropriately describes the compression of the IP layer, this section uses the ROHC terminology and describes the associated profile.</t>

                <t>The IP header is classified as shown in <xref target="table-rohc-profile-ipv6"/> </t>
                <texttable anchor="table-rohc-profile-ipv6" title="Header classification for IPv6.">
                    <ttcol align='left'>Field</ttcol>
                    <ttcol align='left'>Class</ttcol>
                    <ttcol align='left'>Compression Method</ttcol>
                    <ttcol align='left'>Diet-ESP ROHC class</ttcol>
                    <ttcol align='left'>Data origin</ttcol>

                    <c>Version</c><c>STATIC</c><c>removed</c><c>STATIC</c><c>TS</c>

                    <c>Traffic Class</c><c>CHANGING</c><c>removed</c><c>INFERRED</c><c>outer IP</c>

                    <c>Flow Label</c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>outer IP</c>

                    <c>Payload Length</c><c>INFERRED</c><c>removed</c><c>INFERRED</c><c>outer IP</c>

                    <c>Next Header</c><c>STATIC</c><c>removed</c><c>STATIC</c><c>TS</c>

                    <c>Hop Limit</c><c>RACH</c><c>removed</c><c>INFERRED</c><c>outer IP</c>

                    <c>Source Address</c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>TS</c>

                    <c>Destination Address</c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>TS</c>
                </texttable>
                <t>
                    <list style="hanging" hangIndent="3">
                        <t hangText="Version:"><vspace blankLines="0"/> The IP version is specified in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>
                        <t hangText="Traffic Class:"><vspace blankLines="0"/> Traffic Class can be read from the outer IP header. Therefore the classification is changed to INFERRED.</t>
                        <t hangText="Flow Label:"><vspace blankLines="0"/> Flow Label can be read from the outer IP header. Therefore the classification is changed to INFERRED.</t>
                        <t hangText="Next Header"><vspace blankLines="0"/>The Next Header is stored in the protocol of the Traffic Selector and is fixed. It can be copied to the ROHC context, before the first packet is sent/received.</t>
                        <t hangText="Hop Limit"><vspace blankLines="0"/>The Hop Limit can be read from the outer IP header. Therefore the classification is changed to INFERRED.</t>
                        <t hangText="Source Address:"><vspace blankLines="0"/>The Source Address is fixed in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>
                        <t hangText="Destination Address:"><vspace blankLines="0"/>The Destination Address is fixed in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>
                    </list>
                </t>
            </section>

            <section anchor="sec-profile-udp" title="UDP Transport Layer Compression">
                <t>This section shows the compression of ESP payload for all ROHC profiles including an UDP header.</t>
                <t>The UDP header is classified as shown in <xref target="table-rohc-profile-udp"/> </t>
                <texttable anchor="table-rohc-profile-udp" title="Header classification for UDP.">
                    <ttcol align='left'>Field</ttcol>
                    <ttcol align='left'>Class</ttcol>
                    <ttcol align='left'>Compr. Method</ttcol>
                    <ttcol align='left'>Diet-ESP ROHC class</ttcol>
                    <ttcol align='left'>Data origin</ttcol>

                    <c>Source Port</c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>TS</c>

                    <c>Destination Port</c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>TS</c>

                    <c>Length</c><c>INFERRED</c><c>removed</c><c>INFERRED</c><c>IP payload length</c>

                    <c>Checksum</c><c>IRREGULAR</c><c>LSB</c><c>INFERRED</c><c>calc.</c>
                </texttable>
                <t>
                    <list style="hanging" hangIndent="3">
                        <t hangText="Source Port:"><vspace blankLines="0"/>The Source Port is fixed in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>
                        <t hangText="Destination Port:"><vspace blankLines="0"/>The Destination Port is fixed in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>
                        <t hangText="Length:"><vspace blankLines="0"/>The length of the UDP header can be calculated like: IP header - IP header length. Therefore there is no need to send it on the wire and it is defined as INFERRED.</t>
                        <t hangText="Checksum:"><vspace blankLines="0"/>The checksum can be calculated by Diet-ESP and proved by comparing the LSB sent on the wire. The number of bytes sent on the wire can be 0, 1 and 2 stored in CHECKSUM_LSB. If 0 LSB is chosen, the checksum MUST be decompressed with the value 0. If the UDP implementation of the sender chose to disable the UDP checksum by setting the checksum to 0 Diet-ESP SHOULD be used with CHECKSUM_LSB = 0.</t>
                    </list>
                </t>
            </section>


            <section anchor="sec-profile-udp-lite" title="UDP-Lite Transport Layer Compression">
                <t>This section shows the compression of ESP payload for all ROHC profiles including an UDP-Lite header.</t>

                <t>The UDP header is classified as shown in <xref target="table-rohc-profile-udp-lite"/> </t>
                <texttable anchor="table-rohc-profile-udp-lite" title="Header classification for UDP-Lite.">
                    <ttcol align='left'>Field</ttcol>
                    <ttcol align='left'>Class</ttcol>
                    <ttcol align='left'>Compression Method</ttcol>
                    <ttcol align='left'>Diet-ESP ROHC class</ttcol>
                    <ttcol align='left'>Data origin</ttcol>

                    <c>Source Port</c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>TS</c>

                    <c>Destination Port</c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>TS</c>

                    <c>Checksum Coverage</c><c>IRREGULAR</c><c>LSB</c><c>IRREGULAR</c><c>calc.</c>

                    <c>Checksum</c><c>IRREGULAR</c><c>LSB</c><c>INFERRED</c><c>calc.</c>
                </texttable>
                <t>
                    <list style="hanging" hangIndent="3">

                        <t hangText="Source Port:"><vspace blankLines="0"/>The Source Port is fixed in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>

                        <t hangText="Destination Port:"><vspace blankLines="0"/>The Destination Port is fixed in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>

                        <t hangText="Checksum Coverage:"><vspace blankLines="0"/>The Checksum specifies the number of octets carried by the UDP-Lite checksum. It can have the same value as the UDP length (0 or UDP length) or any value between 8 and UDP length. This field is compressed with CHECKSUM_LSB of 0, 1 or 2 bytes. If 0 or 1 LSB is chosen, the field MUST be decompressed with the UDP length. If 2 LSB is chosen, the checksum has to carry this behaviour.</t>

                        <t hangText="Checksum:"><vspace blankLines="0"/>The checksum can be calculated by Diet-ESP and proved by comparing the LSB sent on the wire. The number of bytes sent on the wire can be 0, 1 and 2 stored in CHECKSUM_LSB. If 0 LSB is chosen, the checksum MUST be decompressed with the value 0. If an UDP-lite implementation of the sender chose to disable the UDP checksum by setting the checksum to 0 Diet-ESP SHOULD be used with CHECKSUM_LSB = 0.</t>

                    </list>
                </t>
            </section>

            <section anchor="sec-profile-tcp" title="TCP Transport Layer Compression">
                <t> This section shows the compression of ESP payload for all ROHC profiles including a TCP header. The ROHC context is partly filled while the Diet-ESP context exchange, wherefore some values can be removed. Since TCP is not stateless only fields with the compression methods 'removed' and 'LSB' are allowed to be compressed, the other fields MUST be sent on the wire uncompressed.</t>

                <t>The UDP header is classified as shown in <xref target="table-rohc-profile-tcp"/> </t>

                <texttable anchor="table-rohc-profile-tcp" title="Header classification for TCP.">
                    <ttcol align='left'>Field</ttcol>
                    <ttcol align='left'>Class</ttcol>
                    <ttcol align='left'>Compression Method</ttcol>
                    <ttcol align='left'>Diet-ESP ROHC class</ttcol>
                    <ttcol align='left'>Data origin</ttcol>

                    <c>Source Port        </c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>TS</c>
                    <c>Destination Port   </c><c>STATIC-DEF</c><c>removed</c><c>STATIC-DEF</c><c>TS</c>
                    <c>Sequence Number    </c><c>CHANGING  </c><c>LSB</c><c>CHANGING</c><c>ESP SN</c>
                    <c>Acknowledgement Num</c><c>INFERRED  </c><c>N/A</c><c>INFERRED  </c><c></c>
                    <c>Data Offset        </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>Reserved           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>CWR flag           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>ECE flag           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>URG flag           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>ACK flag           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>PSH flag           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>RST flag           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>SYN flag           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>FIN flag           </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>Window             </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>Checksum           </c><c>IRREGULAR </c><c>LSB</c><c>INFERRED</c><c>calc.</c>
                    <c>Urgent Pointer     </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>
                    <c>Options            </c><c>CHANGING  </c><c>N/A</c><c>CHANGING  </c><c></c>

                </texttable>
                <t>
                    <list style="hanging" hangIndent="3">

                        <t hangText="Source Port:"><vspace blankLines="0"/>The Source Port is fixed in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>

                        <t hangText="Destination Port:"><vspace blankLines="0"/>The Destination Port is fixed in the SA and can be copied to the ROHC context, before the first packet is sent/received.</t>

                        <t hangText="Sequence Number:"><vspace blankLines="0"/>The Sequence Number can be compressed with a LSB by using the SN stored in the SA for the remaining MSB not sent on the wire.</t>

                        <t hangText="Checksum:"><vspace blankLines="0"/>The checksum can be calculated by Diet-ESP and proved by comparing the LSB sent on the wire. The number of bytes sent on the wire can be 0, 1 and 2 stored in CHECKSUM_LSB. If 0 LSB is chosen, the checksum MUST be decompressed with the value 0. If an UDP-lite implementation of the sender chose to disable the UDP checksum by setting the checksum to 0 Diet-ESP SHOULD be used with CHECKSUM_LSB = 0.</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">
        &RFC2119;
        &RFC3095;
        &RFC3843;
        &RFC4019;
        &RFC5225;
        &RFC5795;
        &RFC5996;
        &RFC6846;
        &I-D.mglt-ipsecme-diet-esp;
    </references>

        <references title="Informational References">
        &RFC5856;

        <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-diet-esp-protocol-details" title="Interaction with ROHC profiles">
            <t>Each ROHC profile defines compression rules for a set of protocol headers. <xref target="table-overview-rohc-profiles"/> clarifies how ROHC profiles can be mapped to Diet-ESP payload compression.</t>
            <texttable anchor="table-overview-rohc-profiles" title="Overview over currently existing ROHC profiles.">
                <ttcol align='left'>Profile Number</ttcol>
                <ttcol align='left'>ROHC version</ttcol>
                <ttcol align='left'>Protocol</ttcol>
                <ttcol align='left'>RFC</ttcol>
                <ttcol align="left">Diet-ESP compression</ttcol>

                <c>0x0000</c><c>ROHC</c><c>uncompressed IP</c><c><xref target="RFC3095"/> </c><c>no compression</c>

                <c>0x0001</c><c>ROHC</c><c>RTP/UDP/IP </c><c><xref target="RFC3095"/> </c><c>not used</c>

                <c>0x1001</c><c>ROHCv2</c><c>RTP/UDP/IP</c><c><xref target="RFC5225"/> </c><c>not used</c>

                <c>0x0002</c><c>ROHC</c><c>UDP/IP</c><c><xref target="RFC3095"/> </c><c>UDP and IP in Tunnel Mode</c>

                <c>0x1002</c><c>ROHCv2</c><c>UDP/IP</c><c><xref target="RFC5225"/> </c><c>UDP and IP in Tunnel Mode</c>

                <c>0x0003</c><c>ROHC</c><c>ESP/IP</c><c><xref target="RFC3095"/> </c><c>not used</c>

                <c>0x1003</c><c>ROHCv2</c><c>ESP/IP</c><c><xref target="RFC5225"/> </c><c>not used</c>

                <c>0x0004</c><c>ROHC</c><c>IP</c><c><xref target="RFC3843"/> </c><c>IP in Tunnel Mode</c>

                <c>0x1004</c><c>ROHCv2</c><c>IP</c><c><xref target="RFC5225"/> </c><c>IP in Tunnel Mode</c>

                <c>0x0006</c><c>ROHC</c><c>TCP/IP</c><c><xref target="RFC6846"/> </c><c>TCP and IP in Tunnel Mode</c>

                <c>0x0007</c><c>ROHC</c><c>RTP/UDP-Lite/IP</c><c><xref target="RFC4019"/> </c><c>not used</c>

                <c>0x1007</c><c>ROHCv2</c><c>RTP/UDP-Lite/IP</c><c><xref target="RFC5225"/> </c><c>not used</c>

                <c>0x0008</c><c>ROHC</c><c>UDP-Lite/IP</c><c><xref target="RFC4019"/> </c><c>UDP-Lite and IP in Tunnel Mode</c>

                <c>0x1008</c><c>ROHCv2</c><c>UDP-Lite/IP</c><c><xref target="RFC5225"/> </c><c>UDP-Lite and IP in Tunnel Mode</c>
            </texttable>
        </section>


        <section title="Document Change Log">
            <t>00-First version published</t>
        </section>
    </back>
</rfc>
