Diet-IPsec: ESP Payload Compression of IPv6 / UDP / TCP / UDP-Lite
draft-mglt-6lo-diet-esp-payload-compression-00.txt

Abstract

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.

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.

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.

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 12, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Requirements notation
• 2. Introduction
• 3. Terminology
• 4. Diet-ESP Context Extension
• 5. Protocol Overview
• 6. IP Layer Compression
• 7. UDP Transport Layer Compression
• 8. UDP-Lite Transport Layer Compression
• 9. TCP Transport Layer Compression
• 10. IANA Considerations
• 11. Security Considerations
• 12. Acknowledgment
• 13. References
• 13.1. Normative References
• 13.2. Informational References
• Appendix A. Interaction with ROHC profiles
• Appendix B. Document Change Log
• Authors' Addresses

1. Requirements notation

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 [RFC2119].

2. Introduction

Diet-ESP [I-D.mglt-6lo-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 [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.

In fact, Diet-ESP avoids ROHC complexity as a lot of parameters have already been negotiated with IKEv2 [RFC7296].

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 [RFC5856].

[I-D.mglt-6lo-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.

The Diet-ESP Payload Compression Extension can be described as follows:

- 1.

Definition or Diet-ESP parameters: COMPRESS_ESP_PAYLOAD, TRANSPORT_CHECKSUM_LSB and TRANSPORT_SEQUENCE_NUMBER_LSB. COMPRESS_ESP_PAYLOAD indicates the peers expect the Clear Text Data to be compressed, TRANSPORT_CHECKSUM_LSB and TRANSPORT_SEQUENCE_NUMBER_LSB are additional parameters to perform the compression.

- 2.

Definition of a Diet-ESP Payload Compression algorithm.

The remaining of the document is as follows. Section 4 describes the new parameters for the Diet-ESP Context. Section 5 describes the protocol. Section 6, Section 7, Section 7 and Section 9 describe the compression of the IP layer and the transport layer (UDP, UDP-Lite.

3. Terminology

Diet-ESP Context: Like defined in Diet-ESP document.

SPD: Security Policy Database

SAD: Security Association Database

TS: Traffic Selector of a Security Association.

LSB: Least Significant Byte

MSB: Most Significant Byte

4. Diet-ESP Context Extension

This section describes the additional parameters of the Diet-ESP Context to implement the ESP Payload Compression extension.

<CODE BEGINS>
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, \
                                 TRANSPORT_CHECKSUM_LSB,\
                                 TRANSPORT_SEQUENCE_NUMBER_LSB):
    ## Compress IP header if the ipsec mode is tunnel and 
    ## the inner IP addresses can uniquely be derived from IPsec DB.
    ## In other words, subnets are not considered. 
    if clear_text_data has IP layer and \
       IP addresses is a unique Traffic Selector and \
       ipsec mode is tunnel:  
        compress the IP layer
    if clear_text_data has transport layer and \
       transport layer is a Traffic Selector:
        compress transport layer
<CODE ENDS>