ipsecme D. Migault, Ed.
Internet-Draft Ericsson
Intended status: Standards Track T. Guggemos, Ed.
Expires: April 7, 2017 LMU Munich
C. Bormann
Universitaet Bremen TZI
October 4, 2016
ESP Header Compression and Diet-ESP
draft-mglt-ipsecme-diet-esp-02.txt
Abstract
ESP Header Compression (EHC) defines a flexible framework to compress
communications protected with IPsec/ESP. Compression and
decompression is defined by EHC Rules orchestrated by EHC Strategies.
The document specifies the Diet-ESP EHC Strategy and associated EHC
Rules. Diet-ESP compresses up to 32 bytes per packet for traditional
IPv6 VPN and up to 66 bytes for IPv6 VPN set over a single TCP or UDP
session.
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 April 7, 2017.
Copyright Notice
Copyright (c) 2016 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
Migault, et al. Expires April 7, 2017 [Page 1]
Internet-Draft Diet-ESP October 2016
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 . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Diet-ESP EHC Context . . . . . . . . . . . . . . . . . . . . 5
5.1. Diet-ESP Context Parameters for ESP . . . . . . . . . . . 6
5.2. Diet-ESP Context Parameters for Inner IP . . . . . . . . 6
5.3. Diet-ESP Context Parameters for Transport Protocol . . . 8
6. Diet-ESP EHC Rules . . . . . . . . . . . . . . . . . . . . . 8
6.1. EHC Rules for ESP . . . . . . . . . . . . . . . . . . . . 10
6.2. EHC Rules for inner IPv4 . . . . . . . . . . . . . . . . 12
6.3. EHC Rules for inner IPv6 . . . . . . . . . . . . . . . . 14
6.4. EHC Rules for UDP . . . . . . . . . . . . . . . . . . . . 16
6.5. EHC Rules for UDP-Lite . . . . . . . . . . . . . . . . . 17
6.6. EHC Rules for TCP . . . . . . . . . . . . . . . . . . . . 18
7. Diet-ESP EHC Strategy . . . . . . . . . . . . . . . . . . . . 19
7.1. Outbound Packet Processing . . . . . . . . . . . . . . . 19
7.2. Inbound Packet Processing . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informational References . . . . . . . . . . . . . . . . 26
Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 27
A.1. Single UDP Session IoT VPN . . . . . . . . . . . . . . . 27
A.2. Single TCP session IoT VPN . . . . . . . . . . . . . . . 30
A.3. Traditional VPN . . . . . . . . . . . . . . . . . . . . . 33
Appendix B. EHC Classification (Informative) . . . . . . . . . . 36
B.1. ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.2. IPv6 (Inner) . . . . . . . . . . . . . . . . . . . . . . 38
B.3. IPv4 (Inner) . . . . . . . . . . . . . . . . . . . . . . 38
B.4. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.5. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 40
B.6. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix C. Document Change Log . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
Migault, et al. Expires April 7, 2017 [Page 2]
Internet-Draft Diet-ESP October 2016
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
IPsec/ESP [RFC4303] secures communications either using end-to-end
security or by building a VPN where the traffic is carried to a
secure domain via the security gateway.
IPsec/ESP has not been designed to reduce the networking overhead of
the communications. In fact saving bandwidth comes with additional
operation that may affect or impact large infrastructure where
bandwidth usage is not an issue. On the other hand, IoT emerged with
completely different constraints. IoT communications are different
in many ways and a few important differences may be that sending any
extra byte impact significantly the life time of these devices. In
addition, these devices are also expected to be sleeping nodes where
communications are hardly based on sessions as we used to.
This document defines ESP Header Compression (EHC), a framework that
compresses ESP protected communications. EHC is highly flexible to
address any use case where compression is necessary. EHC takes
advantage of the negotiation between the communication endpoint to
agree on the cryptographic parameters. In some cases, the agreement
already includes parameters that remain constant during the
communications (like port value, or IP address value). EHC takes
advantage of these already agreed parameters, and defines addition
parameters that could be agreed for the purpose of compression.
Similarly, EHC also defines EHC Rules which define how fields may be
compressed and decompressed given the provided parameters. Finally,
EHC defines EHC Strategy which defines how a set of EHC Rule is
coordinated.
The document specifies the Diet-ESP EHC Strategy and associated EHC
Rules. Diet-ESP compresses up to 32 bytes per packet for traditional
VPN and up to 66 bytes for VPN set over a single TCP or UDP session.
3. Terminology
This document uses the following terminology:
- IoT Internet of Things
- IP If not stated otherwise, IP means IPv6.
- LSB Least Significant Bytes
- MSB Most Significant Bytes
Migault, et al. Expires April 7, 2017 [Page 3]
Internet-Draft Diet-ESP October 2016
- SAD IPsec Security Association Database
- SA IPsec Security Association
- SPD IPsec Security Policy Database
- TS IPsec Traffic Selector
- SPI ESP Security Parameter Index
- SN ESP Sequence Number
- PAD ESP Padding
- PL ESP Pad Length
- NH Next Header
- IV Initialization Vector
- IIV Implicit Initialization Vector
- ICV Integrity Check Value
- VPN Virtual Private Network
4. Protocol Overview
ESP Header Compression (EHC) compresses IPsec ESP packets, thus
reducing the size of the packet sent on the wire, while carrying an
equivalent level of information with an equivalent level of security.
The primarily motivation for payload size reduction was IoT were the
cost of sending extra bytes largely overcomes additional computations
and thus considerably reduces the life time of battery powered
devices. As a result, IoT communication rather favor expensive
compression over additional bandwidth. Standard IPsec VPN may also
consider reduction of their bandwidth, but on the other hand, the
acceptable computation overhead must remain very low. The ESP Header
Compression designated in this document as Diet-ESP attempts to reach
theses two goals.
ESP Header Compression compresses the standard ESP payload by
compressing different fields with a specific compression rules
performed in the ESP stack. Concerned fields include fields of the
ESP protocol, as well as other protocols in the ESP payload such as
the IP header when the tunnel mode is used, the UDP or the TCP
header. In fact non ESP fields may be compressed by ESP under
certain circumstances, and ESP Header Compression is not intended to
provide a generic way, outside of ESP to compress these protocols.
Further compression of the ESP payload may be performed by generic
mechanism and outside ESP with more generic mechanisms such as for
example ROHCoverIPsec [RFC5858] or SCHC
[I-D.toutain-6lpwa-ipv6-static-context-hc] which are orthogonal to
ESP Header Compression.
As depicted in Figure 1, in order to compress the ESP packets, the
two peers are expected to agree on the EHC Strategy - Diet-ESP in our
case - as well as some extra parameters needed to derive the EHC
Rules and EHC Context.
Migault, et al. Expires April 7, 2017 [Page 4]
Internet-Draft Diet-ESP October 2016
EHC Strategy, EHC Strategy,
EHC Context <==================> EHC Context
| |
EHC Rules | EHC Rules |
| | | |
v v v v
+====================+ +====================+
| ESP | | ESP |
+====================+ +====================+
| < pre-esp > | | < pre-esp > |
+--------------------+ +--------------------+
| < clear text esp > | | < clear text esp > |
+--------------------+ +--------------------+
| < encryption > | | < encryption > |
+--------------------+ +--------------------+
| < post-esp > | | < post-esp > |
+--------------------+ +--------------------+
Figure 1: ESP Header Compression Overview
In Figure 1, the ESP stack is represented by various sub layers
describing the packet processing inside the ESP. The "pre-esp" layer
represents treatment performed to a non ESP packet, i.e. before ESP
encapsulation or decapsulation is being proceeded. "clear text esp"
designates the ESP encapsulation / decapsulation processing performed
on an non encrypted ESP packet. "encryption" designates the
encryption/decryption phase and "post-esp" the processing performed
on an ESP encrypted packet. EHC Rules may be processed at any of
these layers - except for "encryption" layer, and thus impact
differently the standard ESP. More specifically, EHC Rules performed
at the "pre-esp" or "post-esp" layer does not require the current ESP
stack to be updated and can simply be appended to the current ESP
stack. On the other hand, EHC Rules at the "clear text esp" may
require modification of the current ESP stack.
The set of EHC rules described in this document as well as the EHC
Strategies may be extended in the future. There is nothing to
prevent such EHC Rules and Strategies to be updated.
5. Diet-ESP EHC Context
The EHC Context provides the necessary information so the two peers
can proceed to the appropriated compression and decompression defined
by the EHC Strategy. As this document is limited to the Diet-ESP
strategy, the EHC Context in this section is also designated as Diet-
ESP Context and is used by the Diet-ESP Strategy to activate specific
EHC Rules as well as to execute the EHC Rule by providing the
necessary parameters..
Migault, et al. Expires April 7, 2017 [Page 5]
Internet-Draft Diet-ESP October 2016
The Diet-ESP Context is defined on a per-SA basis. It is composed of
attributes that are not Diet-ESP specific, as well as attributes that
are Diet-ESP specific. Attributes that are not Diet-ESP specific are
already stored in some form in the SA. Such attributes are
designated by "Yes" in the "In SA" column. Diet-ESP specific
attributes may need to be specified so Diet-ESP can be executed
properly.
5.1. Diet-ESP Context Parameters for ESP
+-------------------+-------+--------------------------+
| Context Attribute | In SA | Possible Values |
+-------------------+-------+--------------------------+
| esp_mode | Yes | "Tunnel" or "Transport" |
| outer_version | Yes | "IPv4" "IPv6" |
| esp_spi | Yes | ESP SPI |
| esp_spi_lsb | No | 0, 1, 2, 3, 4 |
| esp_sn | Yes | ESP Sequence Number |
| esp_sn_lsb | No | 0, 1, 2, 3, 4 |
| esp_sn_gen | No | "Time", "Incremental" |
| esp_align | No | 8, 16, 24, 32 |
| esp_encr | Yes | ESP Encryption Algorithm |
+-------------------+-------+--------------------------+
5.2. Diet-ESP Context Parameters for Inner IP
Parameters associated to the Inner IP addresses are only specified
when the SA has been configured with the tunnel mode. As a result
when esp_mode is set to "Transport" the parameters below MUST NOT be
considered and are considered as "Undefined"
+-------------------+-------+-----------------+
| Context Attribute | In SA | Possible Values |
+-------------------+-------+-----------------+
| ip_version | Yes | "IPv4" "IPv6" |
+-------------------+-------+-----------------+
5.2.1. Diet-ESP Context Parameters for inner IPv6
Migault, et al. Expires April 7, 2017 [Page 6]
Internet-Draft Diet-ESP October 2016
+-------------------+-------+------------------------------+
| Context Attribute | In SA | Possible Values |
+-------------------+-------+------------------------------+
| ip6_tcfl_comp | No | "Outer", "Value", "UnComp" |
| ip6_tc | No | IPv6 Traffic Class |
| ip6_fl | No | IPv6 Flow Label |
| ip6_hl_comp | No | "Outer", "Value", "UnComp" |
| ip6_hl | No | Hop Limit Value |
| ip6_src | Yes | IPv6 Source Address |
| ip6_dst | Yes | IPv6 Destination Address |
+-------------------+-------+------------------------------+
ip6_tcfl_comp indicates how Traffic Class and Flow Label fields of
the inner IP Header are expected to be compressed. When set to
"UnComp", or "Outer", values associated to ip6_tc and ip6_fl MUST NOT
be considered and are considered as "Undefined". Values associated
to ip6_tc and ip6_fl are only considered when ip6_tcfl_comp is set to
"Provide Values".
ip6_hl_comp indicates how Hop Limit field of the inner IP Header is
not expected to be compressed. When set to "Outer" or "UnComp",
values associated to ip6_hl MUST NOT be considered and is considered
as "Undefined". ip6_hl is only considered when ip6_hl_comp is set to
"Value".
ip6_dst designates the Destination IPv6 Address of the inner IP
header. The IP address is provided by the TS, and can be defined as
a range of IP addresses. Compression is only considered when ip6_dst
indicates a single IP Address. When the TS defines more than a
single IP address ip6_dst is considered as "Unspecified" and its
value MUST NOT be considered for compression.
5.2.2. Diet-ESP Context Parameters for inner IPv4
+---------------------+-------+------------------------------+
| Context Attribute | In SA | Possible Values |
+---------------------+-------+------------------------------+
| ip4_options | No | "Options", "No_Options" |
| ip4_id | No | IPv4 Identification |
| ip4_id_lsb | No | 0,1,2 |
| ip4_ttl_compression | No | "Outer", "Value", "UnComp" |
| ip4_ttl | No | IPv4 Time To Live |
| ip4_src | yes | IPv4 Source Address |
| ip4_dst | yes | IPv4 Destination Address |
| ip4_frag_enable | No | "True", "False" |
+---------------------+-------+------------------------------+
Migault, et al. Expires April 7, 2017 [Page 7]
Internet-Draft Diet-ESP October 2016
5.3. Diet-ESP Context Parameters for Transport Protocol
The following parameters are provided by the SA but the SA may
specify single value or a range of values. When the SA specifies a
range of values, these parameters MUST NOT be considered and are
considered as Unspecified.
+-------------------+-------+------------------------------------+
| Context Attribute | In SA | Possible Values |
+-------------------+-------+------------------------------------+
| l4_proto | Yes | IPv6/ESP Next Header,IPv4 Protocol |
| l4_src | Yes | UDP/UDP-Lite/TCP Source Port |
| l4_dst | Yes | UDP/UDP-Lite/TCP Destination Port |
+-------------------+-------+------------------------------------+
5.3.1. Diet-ESP Context Parameters for UDP-Lite
+-------------------+-------+-----------------------------+
| Context Attribute | In SA | Possible Values |
+-------------------+-------+-----------------------------+
| udplite_coverage | No | 8-16535, "Length", "UnComp" |
+-------------------+-------+-----------------------------+
5.3.2. Diet-ESP Context Parameters for TCP
+-------------------+-------+---------------------------+
| Context Attribute | In SA | Possible Values |
+-------------------+-------+---------------------------+
| tcp_sn | No | TCP Sequence Number |
| tcp_ack | No | TCP Acknowledgment Number |
| tcp_lsb | No | 0, 1, 2, 3, 4 |
| tcp_options | No | "True" "False" |
| tcp_urgent | No | "True" "False" |
+-------------------+-------+---------------------------+
6. Diet-ESP EHC Rules
This section describes the EHC Rules involved in Diet-ESP. The EHC
Rules defined by Diet-ESP may be used in the future by EHC Strategies
other than Diet-ESP, so they are described in an independent way.
EHC Rule defines the compression and decompression of one or more
fields and EHC Rules are represented this way:
Migault, et al. Expires April 7, 2017 [Page 8]
Internet-Draft Diet-ESP October 2016
+---------------+-------+---------+----------------+
| EHC Rule | Field | Action | Parameters |
+---------------+-------+---------+----------------+
| | f1 | a1 | p1_1, ... p1_n |
| +-------+---------+----------------+
| EHC_RULE_NAME ~ ... ~
| +-------+---------+----------------+
| | fm | am | pm_1, ... pm_n |
+---------------+-------+---------+----------------+
Figure 2: EHC Rules
The EHC Rule is designated by a name (EHC_RULE_NAME) which indicates
the concerned Fields (f1, ..., fm). Each field compression and
decompression is represented by an Action (a1, ..., am). Parameters
indicates the necessary parameters for the action to be completed,
i.e, to perform both the compression and the decompression.
The table below provides a high level description of the Actions used
by Diet-ESP. As these Action may take different arguments and may
operate differently for each field a compete description is provided
in the next sections as part of the EHC Rule description.
+-----------------+-----------------+----------------------+
| Function | Compression | Decompression |
+-----------------+-----------------+----------------------+
| send-value | No | No |
| elided | Not send | Get from EHC Context |
| lsb(_lsb_size) | Sent LSB | Get from EHC Context |
| lower | Not send | Get from lower layer |
| checksum | Not send | Compute checksum. |
| padding(_align) | Compute padding | Get padding |
+-----------------+-----------------+----------------------+
a. send-value designates an action that does not perform any
compression or decompression of a field.
b. elided designates an action where both peers have a local value
of the field. The compression of the field consists in removing
the field, and the decompression consists in retrieving the field
value from a known local value. The local value may be stored in
a EHC Context or defined by the EHC Rule (like a zero value for
example).
c. lsb designates an action where both peers have a local value of
the field, but the compression consists in sending only the LSB
bytes instead of the whole field. The decompression consists in
retrieving the field from the LSB sent as well as some other
additional local values.
Migault, et al. Expires April 7, 2017 [Page 9]
Internet-Draft Diet-ESP October 2016
d. lower designates an action where the compression consists in not
sending the field. The decompression consists in retrieving the
field from the lower layers of the packet. A typical example is
when both IP and UDP carry the length of the payload, then the
length of the UDP payload can be inferred from the one of the IP
layer.
e. checksum designates an action where the compression consists in
not sending a checksum field. The decompression consists in re-
computing the checksum. ESP provides an integrity-check based on
signature of the ESP payload (ICV). This makes removing checksum
possible, without harming the checksum mechanism.
f. padding designates an action that computes the padding of the ESP
packet. The function is specific to the ESP.
For all actions, the function can be performed only when the
appropriated parameters and fields are provided. When a field or a
parameters does not have an appropriated value its value is
designated as "Unspecified". Specifically some fields such as inner
IP addresses, ports or transport protocols are agreed during the SA
negotiation and are specified by the SA. Their value in the SA may
take various values that are not appropriated to enable a
compression. For example, when these fields are defined as a range
of values, or by selectors such as OPAQUE or ANY these fields cannot
be retrieved from a local value. Instead, when they are defined as a
"Single" value (i.e a single IP address, or a single port number or a
single transport protocol number) compression and decompression can
be performed. These SA related fields are considered as
"Unspecified" when not limited to a "Single" value.
When a field or a parameter is "Unspecified", the EHC Rule MUST NOT
be activated. This is the purpose of the EHC Strategy to avoid
ending in such case. In any case, when one of these condition is not
met, the EHC Rule MUST NOT perform any compression or decompression
action and the packet MUST be discarded. When possible, an error
SHOULD be raised and logged.
6.1. EHC Rules for ESP
This section describes the EHC Rules for ESP which are summed up in
the table below.
Migault, et al. Expires April 7, 2017 [Page 10]
Internet-Draft Diet-ESP October 2016
+---------+-------------------+---------+---------------------------+
| EHC | Field | Action | Parameters |
| Rule | | | |
+---------+-------------------+---------+---------------------------+
| ESP_SPI | SPI | lsb | esp_spi_lsb, esp_spi |
| ESP_SN | Sequence Number | lsb | esp_sn_lsb, esp_sn_gen, |
| | | | esp_sn |
| ESP_NH | Next Header | elided | l4_proto, ipsec_mode |
| ESP_PAD | Pad Length, | padding | esp_align, esp_encr |
| | Padding | | |
+---------+-------------------+---------+---------------------------+
ESP_SPI designates the EHC Rule compressing / decompressing the SPI.
ESP_SPI is performed in the "post-esp" phase. The SPI is compressed
using "lsb". The sending peer only places the LSB bytes of the SPI
and the receiving peer retrieve the SPI from the LSB bytes carried in
the packets as well as from the SPI value stored in the SA. The SPI
MUST be retrieved as its full value is included in the signature
check. The two peers MUST agree on the number of LSB bytes to be
sent: "esp_spi_lsb". Upon agreeing on "esp_spi_lsb", the receiving
peer MUST NOT agree on a value not carrying sufficient information to
retrieve the full SPI.
ESP_SN designates the EHC Rule compressing / decompressing the ESP
Sequence Number. ESP_SN is performed in the "post-esp" phase.
ESP_SN is only activated if the SN ("esp_sn"), the LSB significant
bytes ("esp_sn_lsb") and the method used to generate the SN
("esp_sn_gen") are defined. The Sequence Number is compressed using
"lsb". Similarly to the SPI, the Sequence Number MUST be retrieved
in order to complete the signature check of the ESP packet. Unlike
the SPI, the Sequence Number is not agreed by the peers, but is
changing for every packet. As a result, in order to retrieve the
Sequence Number from the LSB "esp_sn_lsb", the peers MUST agree on
generating Sequence Number in a similar way. This is negotiated with
"esp_sn_gen" and the receiver MUST ensure that "esp_sn_lsb" is big
enough to absorb minor packet losses or time differences between the
peers.
ESP_NH designates the EHC Rule compressing / decompressing the ESP
Next Header. ESP_NH is performed in the "clear text esp" phase.
ESP_NH is only activated if the Next Header is specified. The Next
Header can be specified as IP (IPv4 or IPv6) when the IPsec tunnel
mode is used ("esp_mode" set to "Tunnel") or when the transport mode
is used when the Traffic Selectors defines a "Single" Protocol ID
("l4_proto"). The Next Header, is compressed using "elided". The
Next Header indicates the Header in the Payload Data. When the
Tunnel mode is chosen, the type of the header is known to be an IP
header. Similarly, the TS may also hold transport layer protocol,
Migault, et al. Expires April 7, 2017 [Page 11]
Internet-Draft Diet-ESP October 2016
which specifies the Next Header value for Transport mode. The Next
Header value is only there to provide sufficient information for
decapsulating ESP. In other words decompressing this fields would
occur in the "clear text esp" phase and striped but directly removed
again by the ESP stack. For these reasons, implementation may simply
omit decompressing this field.
ESP_PAD designates the EHC Rule compressing / decompressing the Pad
Length and Padding fields. ESP_PAD is performed in the "clear text
exp" phase. Pad Length and Padding define the padding. The purpose
of padding is to respect a 32 bit alignment for ESP or block sizes of
the used cryptographic suite. As the ESP trailer is encrypted,
Padding and Pad Length MUST to be performed by ESP and not by the
encryption algorithm. Thus, ESP_PAD always needs to respect the
cipher alignment ("esp_encr"), if applicable. Compression may be
performed especially when device support alignment smaller than 32
bit. Such alignment is designated as "esp_align" and the padding
bytes are the necessary bytes so the ESP packet has a length that is
a multiple of "esp_align".
When "esp_align" is set to an 8-bit alignment padding bytes are not
necessary, and Padding as well as Pad Length are removed. For values
that are different from 8-bit alignment, padding bytes needs to be
computed according to the ESP packet length why ESP_PAD MUST be the
last action of "clear text esp". The resulting number of padding
byte is then expressed in Padding and Pad Length fields with Pad
Length set to padding bytes number - 1 and Padding is generated as
described in [RFC4303].
Combining the Pad Length and Padding fields could potentially add an
overhead on fixed size padding. In fact some applications may only
send the same type of fixed size data, in which case the Pad Length
would not be necessary to be specified. However, the only corner
case Pad Length fields would actually add an overhead is when padding
is expected to be of zero size. In this case, specifying an 8-bit
alignment solve this issue.
6.2. EHC Rules for inner IPv4
All IPv4 EHC Rules MUST be performed during the "clear text esp"
phase. The EHC Rules are only defined for compressing the inner IPv4
header and thus can only be used when the SA is using the Tunnel
mode.
Migault, et al. Expires April 7, 2017 [Page 12]
Internet-Draft Diet-ESP October 2016
+---------------+-----------------+----------+--------------------+
| EHC Rule | Field | Action | Parameters |
+---------------+-----------------+----------+--------------------+
| IP4_OPT_DIS | Version | elided | ip_version |
| | Header Length | elided | |
| IP4_LENGTH | Total Length | lower | |
| IP4_ID | Identification | lsb | ip4_id, ip4_id_lsb |
| IP4_FRAG_DIS | Flags | elided | |
| | Fragment Offset | elided | |
| IP4_TTL_OUTER | Time To Live | elided | ip4-ttl |
| IP4_TTL_VALUE | Time To Live | elided | ip4-ttl |
| IP4_PROT | Protocol | elided | l4_proto |
| IP4_CHECK | Header Checksum | checksum | |
| IP4_SRC | Source Address | elided | ipv4-source |
| IP4_DST | Dest. Address | elided | ipv4-dest |
+---------------+-----------------+----------+--------------------+
IP4_OPT_DIS designates that the IPv4 header does not include any
options and indicates if the first byte of the IPv4 header -
consisting of IP version and IPv4 Header Length, are compressed. The
Version "ip_version" is defined by the SA and is thus compressed
using "elided". The Header Length is static, if the header does not
contain any options, thus it is compressed with "elided" and
decompressed "20", the default length of the IPv4 header.
IP4_LENGTH designates the EHC Rule compressing / decompressing the
Total Length Field of the inner IPv4 header. The Total Length is
compressed by the sender and not sent. The receiver decompresses it
by recomputing the Total Length from the outer IP header. The outer
IP header can be IPv4 or IPv6 and IP4_LENGTH MUST support both
versions if both versions are supported by the device. Note that the
length of the inner IP payload may also be subject to updates if
decompression of the upper layers occurs.
IP4_ID designates the EHC Rule compressing / decompressing the
Identification Field. IP4_ID is only activated if the ID ("ip4_id"),
the LSB significant bytes ("ip4_id_lsb") are defined. Upon agreeing
on "ip4_id_lsb", the receiving peer MUST NOT agree on a value not
carrying sufficient information to retrieve the full IP
Identification. Note also that unlike the ESP SN, the IPv4
Identification is not part of the SA. As a result, when the ID is
compressed, its value MUST be stored in the EHC Context. The
reserved attribute for that is "ip4_id"
IP4_FRAG_DIS designates that the inner IPv4 header does not support
fragmentation. If activated, IP4_FRAG_DIS indicates compression of
Flags and Fragment Offset field in the IPv4 header which consists of
2 bytes. Both fields are compressed with "elided" and decompressed
Migault, et al. Expires April 7, 2017 [Page 13]
Internet-Draft Diet-ESP October 2016
with their default value according to [RFC0791], which is 0b010 for
Flags and 0 for Fragment Offset.
IP4_TTL_OUTER designates an EHC Rule compressing / decompressing the
Time To Live field of the inner IP header. IP4_TTL_OUTER is only
activated when both the outer and inner IP header are IPv6 header.
The Time To Live field is compressed / decompressed using the
"lower". More specifically, the field is not sent. The receiver
decompresses them by reading their value from the outer IPv4 header.
IP4_TTL_VALUE designates an EHC Rule compressing / decompressing the
Time To Live field of the inner IP header. IP4_TTL_VALUE is only
activated when the Hop Limit ("ip4_ttl") has been agreed. Time To
Live is compressed / decompressed using the "elided" method.
IP4_PROTO designates the EHC Rule compressing / decompressing the
Protocol field of the inner IPv4 header. IP4_PROTO is only activated
if the Protocol is specified, that is when the Traffic Selectors
defines a "Single" Protocol ID ("l4_proto"). When the Protocol ID
identified by the SA has a "Single" value, the Protocol is compressed
and decompressed using the "elided" method.
IP4_CHECK designates the EHC rule compressing / decompressing the
Header Checksum field of the inner IPv4 header. The IPv4 header
checksum is not sent by the sender and the receiver computes from the
decompressed inner IPv4 header. IP4_CHECK MUST compute the checksum
and not fill the checksum field with zeros. As a result, IP4_CHECK
is the last decompressing EHC Rule to be performed on the
decompressed IPv4 header.
IP4_SRC compresses the source IP address of the inner IPv4 header.
IP4_SRC_IP is only be activated when the Traffic Selectors agreed by
the SA defines a "Single" source IP address ("ip4_src"). The Source
IP address is compressed / decompressed using the "elided" method.
IP4_DST works in a similar way as IP4_SRC_IP but for the destination
IP address ("ip4_dst")
6.3. EHC Rules for inner IPv6
All IPv6 EHC Rules MUST be performed during the "clear text esp"
phase. The EHC Rules are only defined for compressing the inner IPv6
header and thus can only be used when the SA is using the Tunnel
mode.
Migault, et al. Expires April 7, 2017 [Page 14]
Internet-Draft Diet-ESP October 2016
+--------------+----------------+--------+------------+
| EHC Rule | Field | Action | Parameters |
+--------------+----------------+--------+------------+
| IP6_OUTER | Version | elided | ip_version |
| | Traffic Class | lower | |
| | Flow Label | lower | |
| IP6_VALUE | Version | elided | ip_version |
| | Traffic Class | elided | ip6_tc |
| | Flow Label | elided | ip6_fl |
| IP6_LENGTH | Payload Length | lower | |
| IP6_NH | Next Header | elided | l4_proto |
| IP6_HL_OUTER | Hop Limit | lower | |
| IP6_HL_VALUE | Hop Limit | elided | ip6_hl |
| IP6_SRC | Source Address | elided | ip6_source |
| IP6_DST | Dest. Address | elided | ip6_dest |
+--------------+----------------+--------+------------+
IP6_OUTER designates an EHC Rule for compressing / decompressing the
first 32 bits of the inner IPv6 header formed by the Version, Traffic
Class and Flow Label. IP6_OUTER is only activated when both the
outer and inner IP header are IPv6 header. The Version "ip_version"
is defined by the SA and is thus compressed using "elided". The
other parameters Traffic Class and Flow Label are compressed using
"lower". More specifically, the fields are not sent. The receiver
decompresses them by reading their value from the outer IPv6 header.
IP6_VALUE designates an EHC Rule for compressing / decompressing the
first 32 bits of the inner IPv6 header formed by the Version, Traffic
Class and Flow Label. IP6_VALUE is only activated if the Version of
the inner IP header agreed by the SA is set to "Version 6"
("ip_version" set to "Version 6") and the specific values of the
Traffic Class ("ip6_tc") and the Flow Label ("ip6_fl") are specified.
With IP6_VALUE all fields are compressed and decompressed using
"elided". Version is provided by the SA ("ip_version") while other
fields are explicitly provided (ip6_tc, ip6_fl.
IP6_LENGTH designates the EHC Rule compressing / decompressing the
Payload Length Field of the inner IPv6 header. The Payload Length is
compressed by the sender and is not sent. The receiver decompress it
by recomputing the Payload Length from the outer IP header. The IP
header can be IPv4 or IPv6 and IP6_LENGTH MUST support both versions
if both versions are supported by the device. Note that the length
of the inner IP payload may also be subject to updates if
decompression of the upper layers occurs.
IP6_NH designates the EHC Rule compressing / decompressing the Next
Header field of the inner IPv6 header. IP6_NH is only activated if
the Next Header is specified, that is when the Traffic Selectors
Migault, et al. Expires April 7, 2017 [Page 15]
Internet-Draft Diet-ESP October 2016
defines a "Single" Protocol ID ("l4_proto"). When the Protocol ID
identified by the SA has a "Single" value, the Next Header is
compressed and decompressed using the "elided" method.
IP6_HL_OUTER designates an EHC Rule compressing / decompressing the
Hop Limit field of the inner IP header. IP6_HL_OUTER is only
activated when both the outer and inner IP header are IPv6 header.
The Hop Limit field is compressed / decompressed using the "lower".
More specifically, the fields are not sent. The receiver
decompresses them by reading their value from the outer IPv6 header.
IP6_HL_VALUE designates an EHC Rule compressing / decompressing the
Hop Limit field of the inner IP header. IP6_HL_VALUE is only
activated when the Hop Limit ("ip6_hl") has been agreed. The Hop
Limit is compressed / decompressed using the "elided" method.
IP6_SRC compresses the source IP address of the inner IP header.
IP6_SRC_IP is only be activated when the Traffic Selectors agreed by
the SA defines a "Single" source IP address ("ip6_src"). The Source
IP address is compressed / decompressed using the "elided" method.
IP6_DST works in a similar way as IP6_SRC_IP but for the destination
IP address ("ip6_dst")
6.4. EHC Rules for UDP
All UDP EHC Rules MUST be performed during the "pre-esp" phase. The
EHC Rules are only defined when the Traffic Selectors agreed during
the SA negotiation results in "Single" Protocol ID ("l4_proto") which
is set to UDP (17).
+------------+--------------+----------+------------+
| EHC Rule | Field | Action | Parameters |
+------------+--------------+----------+------------+
| UDP_SRC | Source Port | elided | l4_source |
| UDP_DST | Dest. Port | elided | l4_dest |
| UDP_LENGTH | Length | lower | |
| UDP_CHECK | UDP Checksum | checksum | |
+------------+--------------+----------+------------+
UDP_SRC designates the EHC Rule that compresses / decompresses the
UDP Source Port. UDP_SRC is only activated when the Source Port
agreed by the SA negotiation ("l4_src") is "Single". The Source Port
is then compressed / decompressed using the "elided" method.
UDP_DST works in a similar way as UDP_SRC but for the Destination
Port ("l4_dst").
Migault, et al. Expires April 7, 2017 [Page 16]
Internet-Draft Diet-ESP October 2016
UDP_LENGTH designates the EHC Rule compressing / decompressing the
Length Field of the UDP header. The length is compressed by the
sender and is not sent. The receiver decompresses it by recomputing
the Length from the IP address header. The IP address can be IPv4 or
IPv6 and UDP_LENGTH MUST support both versions if both versions are
supported by the device.
UDP_CHECK designates the EHC Rule compressing / decompressing the UDP
Checksum. The UDP Checksum is not sent by the sender and the
receiver computes from the decompressed UDP payload. UDP_CHECK MUST
compute the checksum and not fill the checksum field with zeros. As
a result, UDP_CHECK is the last decompressing EHC Rule to be
performed on the decompressed UDP Payload.
6.5. EHC Rules for UDP-Lite
All UDP-lite EHC Rules MUST be performed during the "pre-esp" phase.
The EHC Rules are only defined when the Traffic Selectors agreed
during the SA negotiation results in a "Single" Protocol ID
("l4_proto") which is set to UDPLite (136).
+-------------------+-----------------+----------+------------------+
| EHC Rule | Field | Action | Parameters |
+-------------------+-----------------+----------+------------------+
| UDP-LITE_SRC | Source Port | elided | l4_source |
| UDP-LITE_DST | Dest. Port | elided | l4_dest |
| UDP-LITE_COVERAGE | Checksum | elided | udplite_coverage |
| | Coverage | | |
| UDP-LITE_CHECK | UDP-Lite | checksum | |
| | Checksum | | |
+-------------------+-----------------+----------+------------------+
UDP-LITE_SRC works similarly to UDP_SRC
UDP-LITE_DST works similarly to UDP_DST
UDP-LITE_COVERAGE designates the EHC Rule compressing / decompressing
the UDP-Lite Coverage field. UDP-LITE_COVERAGE is only activated
when the Coverage ("udplite_coverage") has been agreed with a valid
value. The Coverage is compressed / decompressed using the "elided"
method.
UDP-LITE_CHECK designates the EHC Rule compressing / decompressing
the UDP-Lite checksum. UDP-LITE_CHECK is only activated if the
Coverage is defined either elided or sent. UDP-LITE_CHECK computes
the checksum using "checksum" according to the uncompressed UDP
packet and the value of the Coverage.
Migault, et al. Expires April 7, 2017 [Page 17]
Internet-Draft Diet-ESP October 2016
6.6. EHC Rules for TCP
All TCP EHC Rules MUST be performed during the "pre-esp" phase. The
EHC Rules are only defined when the Traffic Selectors agreed during
the SA negotiation results in a"Single" Protocol ID ("l4_proto")
which is set to TCP (6).
+-------------+---------------------+------------+------------------+
| EHC Rule | Field | Action | Parameters |
+-------------+---------------------+------------+------------------+
| TCP_SRC | Source Port | elided | l4_source |
| TCP_DST | Dest. Port | elided | l4_dest |
| TCP_SN | Sequence Number | lsb | tcp_sn, tcp_ls |
| TCP_ACK | Acknowledgment | lsb | tcp_ack, tcp_lsb |
| | Number | | |
| TCP_OPTIONS | Data Offset | elided | tcp_options |
| | Reserved Bits | elided | |
| TCP_CHECK | TCP Checksum | checksum | |
| TCP_URGENT | elided | tcp_urgent |
+-------------+---------------------+------------+------------------+
TCP_SRC works similarly to UDP_SRC.
TCP_DST works similarly to UDP_DST.
TCP_SN designates the EHC Rule compressing / decompressing the TCP
Sequence Number. TCP_SN is only activated if the SN ("tcp_sn") and
the LSB significant bytes ("tcp_lsb") are defined. The TCP SN is
compressed using "lsb". The sending peer only places the LSB bytes
of the TCP SN ("tcp_sn") and the receiving peer retrieve the TCP SN
from the LSB bytes carried in the packets as well as from the TCP SN
value stored in EHC Context ("tcp_sn"). The two peers MUST agree on
the number of LSB bytes to be sent: "tcp_lsb". Upon agreeing on
"tcp_lsb", the receiving peer MUST NOT agree on a value not carrying
sufficient information to retrieve the full TCP SN. Note also that
unlike the ESP SN, the TCP SN is not part of the SA. As a result,
when the SN is compressed, the value of the TCP SN MUST be stored in
the EHC Context. The reserved attribute for that is "tcp_sn"
TCP_ACK designates the EHC Rule compressing / decompressing the TCP
Acknowledgment Number and works similarly to TCP SN. Note that
"tcp_lsb" is agreed for both TCP SN and TCP Acknowledgment.
Similarly the value of the complete TCP Acknowledgment Number MUST be
stored in the "tcp_ack" attribute of the EHC Context.
TCP_OPTIONS designates the EHC Rule compressing / decompressing TCP
options related fields such as Data Offset and Reserved Bits.
TCP_OPTION can only be activated when the TCP Option ("tcp_options")
Migault, et al. Expires April 7, 2017 [Page 18]
Internet-Draft Diet-ESP October 2016
is defined. When "tcp_options" is set to "False" and indicates there
are no TCP Options, the Data Offsets and Reserved Bits are compressed
/ decompressed using the "elided" method with Data Offset and
Reserved Bits set to zero.
TCP_CHECK designates the EHC Rule compressing / decompressing the TCP
Checksum. TCP_CHECK works similarly as UDP_CHECK.
TCP_URGENT designates the EHC Rule compressing / decompressing the
urgent related information. When "tcp_urgent" is set to "False" and
indicates there are no TCP Urgent related information, the Urgent
Pointer is then "elided" and filled with zeros.
7. Diet-ESP EHC Strategy
From the attributes of the EHC Context, Diet-ESP, defines as an EHC
Strategy which EHC Rules to apply. The EHC Strategy is defined both
for outbound packets which compresses the packet as well as for
inbound packet where the decompression occurs.
Implementation may differ from the description below. However, the
outcome MUST remain the same.
7.1. Outbound Packet Processing
Diet-ESP compression is defined as follows:
1. In phase "pre-esp": Match the inbound packet with the SA and
determine if the Diet-ESP EHC Strategy has been activated. If
the Diet-ESP HEC Strategy has been activated proceed to next
step, otherwise skip all steps associated to Diet-ESP and proceed
to the standard ESP as defined in [RFC4303]
2. In phase "pre-esp": If "l4_proto" designates a "Single" Protocol
ID (UDP, TCP or UDP-Lite), proceed to the compression of the
specific layer. Otherwise, the transport layer is not
compressed.
3. In phase "clear text esp": If "esp_mode" is set to "Tunnel" mode,
determine "ip_version" the IP version of the inner IP addresses
and proceed to the appropriated inner IP address compression.
4. In phase "clear text esp" and "post-esp": Proceed to the ESP
compression.
UDP compression is defined as below:
1. If the "l4_src" designates a "Single" Source Port, apply UDP_SRC
to compress the Source Port.
2. If the "l4_dst" designates a "Single" Destination Port, apply
UDP_DST to compress the Destination Port.
Migault, et al. Expires April 7, 2017 [Page 19]
Internet-Draft Diet-ESP October 2016
3. Apply UDP_CHECK to compress the Checksum.
4. Apply UDP_LENGTH to compress the Length.
UDP-lite compression is defined as below:
1. If the "l4_src" designates a "Single" Source Port, apply the UDP-
LITE_SRC to compress the Source Port.
2. If the "l4_dst" designates a "Single" Destination Port, apply the
UDP-LITE_DST, to compress the Destination Port.
3. If "udplite_coverage" is specified, apply the UDP-LITE_COVERAGE,
to compress the Coverage.
4. Apply UDP-LITE_CHECK to compress the Checksum.
TCP compression is defined as below:
1. If the "l4_src" designates a "Single" Source Port than apply the
TCP_SRC to compress the Source Port.
2. If the "l4_dst" designates a "Single" Destination Port than apply
the TCP_DST to compress the Destination Port.
3. If "tcp_lsb" is lower than 4, then "tcp_sn" "tcp_ack" attributes
of the Diet-ESP Context are updated with the value provided from
the packet before applying the TCP_SN and the TCP_ACK EHC Rules.
4. If "tcp_options" is set to "False" apply the TCP_OPTIONS EHC
Rule.
5. If "tcp_urgent" is set to "False" apply the TCP_URGENT EHC Rule.
6. Apply TCP_CHECK to compress the Checksum.
Inner IPv6 Header compression is defined as below:
1. If the "ip6_src" designates a "Single" Source IP address, apply
the IP6_SRC to compress the IPv6 Source Address.
2. If the "ip6_dst" designates a "Single" Destination IP address,
apply the IP6_DST to decompress the IPv6 Destination Address.
3. Hop Limit compression is performed as follows:
1. If "outer_version" is set to "IPv6" and "ip6_hl_comp" is set
to "Outer" apply IP6_HL_OUTER.
2. If "outer_version" is set to "IPv4" and "ip6_hl_comp" is set
to "Outer" raise an error and discard the packet.
3. If "ip6_hl_comp" is set to "Value" apply IP6_HL_VALUE.
4. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP-
Lite), apply IP6_NH to compress the Next Header.
5. Apply, IP6_LENGTH to compress the Length.
6. Version, Traffic Class and Flow Label are compressed as follows:
1. If "outer_version" is set to "IPv6" and "ip6_tcfl_comp" is
set to "Outer" apply IP6_OUTER.
Migault, et al. Expires April 7, 2017 [Page 20]
Internet-Draft Diet-ESP October 2016
2. If "outer_version" is set to "IPv4" and "ip6_tcfl_comp" is
set to "Outer" raise an error and discard the packet.
3. If "ip6_tcfl_comp" is set to "Value" apply IP6_VALUE.
ESP compression is defined as below:
1. In phase "clear text esp": If "esp_mode" is set to "Tunnel" or
"l4_proto" is set to a "Single value - eventually different from
TCP, UDP or UDP-Lite, apply ESP_NH, to compress the Next Header.
2. In phase "clear text esp": If "esp_encr" specify an encryption
algorithm that does not provide padding, then apply ESP_ALIGN to
compress the Pad Length and Padding.
3. Proceed to the ESP encryption as defined in [RFC4303].
4. In phase "post-esp: If "esp_sn_lsb" is different from 4, then
apply ESP_SN. To compress the ESP SN.
5. In phase "post-esp": If "esp_spi_lsb" is different from 4, then
apply ESP_SPI to compress the SPI.
7.2. Inbound Packet Processing
Diet-ESP decompression is defined as follows:
1. Match the inbound packet with the SA and determine if the Diet-
ESP EHC Strategy has been activated. When Diet-ESP is activated
this means that the "esp_spi_lsb" are sufficient to index the SA
and proceed to next step, otherwise skip all steps associated to
Diet-ESP and proceed to the standard ESP as defined in [RFC4303]
2. In phase "clear text esp" and "post-esp": Proceed to the ESP
decompression.
3. In phase "clear text esp": If "esp_mode" is set to "Tunnel" mode,
determine "ip_version" the IP version of the inner IP addresses
and proceed to the appropriated inner IP address decompression,
except for the computation of the checksums and length.
4. In phase "pre-esp": If "l4_proto" designates a "Single" Protocol
ID (UDP, TCP or UDP-Lite), proceed to the decompression of the
specific layer, except for the computation of the checksums and
length replaced by zero fields.
5. In phase "pre-esp": Proceed to the decompression of the checksums
and length.
ESP decompression is defined as follows:
1. In phase "post-esp": If "esp_spi_lsb" is different from 4, then
apply ESP_SPI to decompress the SPI.
2. In phase "post-esp: If "esp_sn_lsb" is different from 4, then
apply ESP_SN. To decompress the ESP SN.
3. Proceed to the ESP signature validation and decryption as defined
in [RFC4303].
Migault, et al. Expires April 7, 2017 [Page 21]
Internet-Draft Diet-ESP October 2016
4. In phase "clear text esp": If "esp_mode" is set to "Tunnel" or
"l4_proto" is set to a "Single value - eventually different from
TCP, UDP or UDP-Lite, apply ESP_NH, to decompress the Next
Header.
5. In phase "clear text esp": If "esp_encr" specify an encryption
algorithm that does not provide padding, then apply ESP_ALIGN to
compress the Pad Length and Padding.
6. Extract the ESP Data Payload and apply decompression EHC Rule to
the ESP Data Payload.
Inner IPv6 decompression is defined as follows:
1. Version, Traffic Class and Flow Label are decompressed as
follows:
1. If "outer_version" is set to "IPv6" and "ip6_tcfl_comp" is
set to "Outer" apply IP6_OUTER to decompress Version, Traffic
Class and Flow Label.
2. If "outer_version" is set to "IPv4" and "ip6_tcfl_comp" is
set to "Outer" raise an error and discard the packet.
3. If "ip6_tcfl_comp" is set to "Value" apply IP6_VALUE to
Version, Traffic Class and Flow Label.
4. If "ip6_tcfl_comp" is set to "UnComp", Version, Traffic Class
and Flow Label are already provided in the packet.
2. Set the Length to zero.
3. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP-
Lite), apply IP6_NH to decompress the Next Header.
4. Hop Limit decompression is performed as follows:
1. If "outer_version" is set to "IPv6" and "ip6_hl_comp" is set
to "Outer" apply IP6_HL_OUTER to decompress Hop Limit.
2. If "outer_version" is set to "IPv4" and "ip6_hl_comp" is set
to "Outer" raise an error and discard the packet.
3. If "ip6_hl_comp" is set to "Value" apply IP6_HL_VALUE to
decompress the Hop Limit.
4. If "ip6_hl_comp" is set to "UnComp", Hop Limit is already
provided in the packet.
5. If the "ip6_src" designates a "Single" Source IP address, apply
the IP6_SRC to de compress the IPv6 Source Address.
6. If the "ip6_dst" designates a "Single" Destination IP address
than apply the IP6_DST to decompress the IPv6 Destination
Address.
7. Apply, IP6_LENGTH to provide the replace the zero length value by
its appropriated appropriated value. The Length value considers
the length provided by the lower layers to which are added the
additional bytes due to the decompression, minus the length of
the inner IP6 Header. The value computed from the lower layer
will have to be overwritten in case further decompression occurs.
Migault, et al. Expires April 7, 2017 [Page 22]
Internet-Draft Diet-ESP October 2016
UDP decompression is defined as follows:
1. If the "l4_src" designates a "Single" Source Port, apply UDP_SRC
to decompress the Source Port.
2. If the "l4_dst" designates a "Single" Destination Port, apply
UDP_DST to decompress the Destination Port.
3. Apply UDP_LENGTH to compress the Length. The length value is
computed from the length provided by the lower layer, with the
additional added bytes during the UDP decompression including the
length size.
4. Apply UDP_CHECK to decompress the Checksum.
5. Update the Length of the lower layers:
1. If "esp_mode" is set to "Transport" mode, update the Length
of the outer IP header (IPv4 or IPv6). The Length is
incremented by the number of bytes generated by the
decompression of the transport layer.
2. If "esp_mode" is set to "Tunnel" mode, update the Length of
the inner IP address (IPv4 or IPv6) as well as the outer IP
header (IPv4 or IPv6). The Length is incremented by the
number of bytes generated by the decompression of the
transport layer.
UDP-Lite decompression is defined as follows:
1. If the "l4_src" designates a "Single" Source Port, apply the UDP-
LITE_SRC to decompress the Source Port.
2. If the "l4_dst" designates a "Single" Destination Port, apply the
UDP-LITE_DST, to decompress the Destination Port.
3. If "udplite_coverage" is specified, apply the UDP-LITE_COVERAGE,
to decompress the Coverage.
4. Apply UDP-LITE_CHECK to compress the Checksum.
5. Update the Length of the lower layers as defined in UDP.
TCP decompression is defined as follows:
1. If the "l4_src" designates a "Single" Source Port than apply the
TCP_SRC to decompress the Source Port.
2. If the "l4_dst" designates a "Single" Destination Port than apply
the TCP_DST to decompress the Destination Port.
3. If "tcp_lsb" is lower than 4, apply TCP_SN and the TCP_ACK to
decompress the TCP Sequence Number and the TCP Acknowledgment
Number.
4. If "tcp_options" is set to "False" apply TCP_OPTIONS to
decompress Data Offset and Reserved Bits.
5. If "tcp_urgent" is set to "False" apply the TCP_URGENT to
decompress the Urgent Pointer.
6. Apply TCP_CHECK to decompress the Checksum.
Migault, et al. Expires April 7, 2017 [Page 23]
Internet-Draft Diet-ESP October 2016
8. IANA Considerations
There are no IANA consideration for this document.
9. Security Considerations
This section lists security considerations related to the Diet-ESP
protocol.
Security Parameter Index (SPI):
The Security Parameter Index (SPI) is used by the receiver to
index the Security Association that contains appropriated
cryptographic material. If the SPI is not found, the packet is
rejected as no further checks can be performed. In EHC, the value
of the SPI is not reduced, but compressed why the SPI value may
not be fully provided between the compressor and the de-
compressor. On the other hand, its uncompressed value is provided
to the ESP-procession and no weakness is introduced to ESP itself.
On an implementation perspective, it is strongly recommended that
decompression is deterministic. Compression and decompression
adds some additional treatment to the ESP packet, which might be
used by an attacker. In order to minimize the load associated to
decompression, decompression is expected to be deterministic. The
incoming compressed SPI with the associated IP addresses should
output a single and unique uncompressed SPI value. If an
uncompressed SPI values have to be considered, then the receiver
could end in n signature checks which may be used by an attacker
for a DoS attack.
Sequence Numer (SN):
The Sequence Number (SN) is used as an anti-replay attack
mechanism. Compression and decompression of the SN is already
part of the standard ESP namely the Extended Sequence Number
(ESN). The SN in a standard ESP packet is 32 bit long, whether
EHC enables to reduce it to 0 bytes and the main limitation to the
compression a deterministic decompression. SN compression
consists in indicating the least significant bits of the
uncompressed SN on the wire. The size of the compressed SN must
consider the maximum reordering index such that the probability
that a later sent packet arrives before an earlier one. In
addition the size of SN should also consider maximum consecutive
packets lost during transmission. In the case of ESP, this number
is set to 2^32 which is, in most real world case, largely over-
provisioned. When the compression of the SN is not appropriately
provisioned, the most significant bit value may be de-synchronized
between the sending and receiving parties. Although IKEv2
provides some re-synchronization mechanisms, in case of IoT the
de-synchronization will most likely result in a renegotiation and
thus DoS possibilities. Note that IoT communication may also use
Migault, et al. Expires April 7, 2017 [Page 24]
Internet-Draft Diet-ESP October 2016
some external parameters, i.e. other than the compressed SN, to
define whether a packet be considered or not and eventually derive
the SN. One such scenario may be the use of time windows.
Suppose a device is expected to send some information every hour
or every week. In this case, for example, the SN may be
compressed to zero bytes. Instead the SN may be derived by
incrementing the SN every hour after the last received valid
packet. Considering the time the packet is received make it
possible to consider the time derivation of the sensor clock. If
TIME is used as the method to generate the SN, the receiver MUST
ensure that the esp_sn_lsb is big enough to resist time
differences between the nodes. Note also that the anti-replay
mechanism needs to define the size of the anti-replay
window.[RFC4303] provides guidance to set the window size and are
similar to those used to define the size of the compressed SN.
10. Privacy Considerations
Security Parameter Index (SPI):
Until Diet-ESP is not deployed outside the scope of IoT and small
devices, the use of a compressed SPI may provide an indication
that one of the endpoint is a sensor. Such information may be
used, for example, to evaluate the number of appliances deployed,
or - in addition with other information, such as the time
interval, the geographic location - be used to derive the type of
data transmitted.
Sequence Number (SN): If incremented for each ESP packet, the SN may
leak some information like the amount of transmitted data or the
age of the sensor. The age of the sensor may be correlated with
the software used and the potential bugs. On the other hand, re-
keying will re-initialize the SN, but the cost of a re-keying may
not be negligible and thus, frequent re-keying can be considered.
In addition to the re-key operation, the SN may be generated in
order to reduce the accuracy of the information leaked. In fact,
the SN does not have to be incremented by one for each packet it
just has to be an increasing function. Using a function such as a
TIME may prevent characterizing the age or the use of the sensor.
Note that the use of such function may also impact the compression
efficiency and result in larger compressed SN.
11. Acknowledgment
We thank Orange and Universitee Pierre et Marie Curie for initiating
the work on Diet-ESP. We Would like to thank Sylvain Killian for
implementing an open source Diet-ESP on Contiki and testing it on the
FIT IoT-LAB [fit-iot-lab] funded by the French Ministry of Higher
Education and Research. We thank the IoT-Lab Team and the INRIA for
Migault, et al. Expires April 7, 2017 [Page 25]
Internet-Draft Diet-ESP October 2016
maintaining the FIT IoT-LAB platform and for providing feed backs in
an efficient way.
We would like to thank Rob Moskowitz for not copyrighting Diet HIP.
The "Diet" terminology is from him.
We woudl like to thank those we received many useful feed backs among
others: Dominique Bartel, Anna Minaburo, Suresh Krishnan, Samita
Chakrabarti, Michael Richarson, Tero Kivinen.
12. References
12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, DOI 10.17487/RFC4309, December 2005,
<http://www.rfc-editor.org/info/rfc4309>.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008,
<http://www.rfc-editor.org/info/rfc5225>.
[RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec
Extensions to Support Robust Header Compression over
IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010,
<http://www.rfc-editor.org/info/rfc5858>.
12.2. Informational References
[I-D.toutain-6lpwa-ipv6-static-context-hc]
Minaburo, A. and L. Toutain, "6LPWA Static Context Header
Compression (SCHC) for IPV6 and UDP", draft-toutain-6lpwa-
ipv6-static-context-hc-01 (work in progress), June 2016.
Migault, et al. Expires April 7, 2017 [Page 26]
Internet-Draft Diet-ESP October 2016
[I-D.mglt-ipsecme-implicit-iv]
Migault, D., Guggemos, T., and Y. Nir, "Implicit IV for
Counter-based Ciphers in IPsec", draft-mglt-ipsecme-
implicit-iv-00 (work in progress), June 2016.
[fit-iot-lab]
"Future Internet of Things (FIT) IoT-LAB",
<https://www.iot-lab.info>.
Appendix A. Illustrative Examples
A.1. Single UDP Session IoT VPN
This section considers a IoT IPv6 probe hosting a UDP application.
The probe is dedicated to a single application and establishes a
single UDP session. As a result, inner IP addresses and UDP Ports
have a "Single" value and can be easily compressed. The probes sets
an IPsec VPN using IPv6 addresses in order to connect its secure
domain - typically a Home Gateway. The use of IPv6 for inner and
outer IP addresses, enables to infer inner IP fields from the outer
IP address. The probes encrypts with AES-CCM_8 [RFC4309]. AES-CCM
does not have padding, so the padding is performed by ESP. The
probes uses an 8 bit alignment which enables to fully compress the
ESP Trailer. In addition, as the probe SA is indexed using the outer
IP addresses (or eventually the radio identifiers) which enables to
fully compress the SPI. As the probe provides information every
hour, the Sequence Number using time can be derived from the received
time, which enables to fully compress the SN.
Figure 3 represents the original UDP packet and Figure 4 represents
the corresponding packet compressed with Diet-ESP. The compression
with Diet-ESP results in a reduction of 61 bytes overhead. With IPv4
inner IP addressed Diet-ESP results in an 45 byte overhead reduction.
Further compression may be done for example by using an implicit IV
[I-D.mglt-ipsecme-implicit-iv] and by compressing the outer IP
addresses (not represented) on the figure. In addition, application
data may also be compressed with mechanisms outside of the scope of
Diet-ESP.
Migault, et al. Expires April 7, 2017 [Page 27]
Internet-Draft Diet-ESP October 2016
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) | ESP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| traffic class | flow label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload length | next header | hop limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Inner
| inner source IP | IP
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| inner destination IP |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| source port | dest port | UDP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ APPLICATION DATA ~
| |
| +-+-+-+-+-+-+-+-+---
| | Padding | ESP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Trai-
| Padding (continue) | Pad Length | Next Header | ler
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Standard ESP VPN Packet Description
Migault, et al. Expires April 7, 2017 [Page 28]
Internet-Draft Diet-ESP October 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ APPLICATION DATA ~
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Diet-ESP Single UDP Session IoT VPN Packet Description
The following table illustrates the activated rules and the
attributes of the Diet-ESP Context that needs an explicit agreement
to achieve the compression. All other attributes used by the rules
are part of the SA agreement. Parameters of not activated rules are
left "Unspecified".
+--------------+-------------------+---------------+
| EHC Rule | Context Attribute | Value |
+--------------+-------------------+---------------+
| ESP_SPI | esp_spi_lsb | 0 |
| ESP_SN | esp_sn_lsb | 0 |
| | esp_sn_gen | "Incremental" |
| ESP_NH | | |
| ESP_PAD | esp_align | 8 |
| | | |
| IP6_OUTER | ip6_tcfl_comp | "Outer" |
| | ip6_hl_comp | "Outer" |
| IP6_LENGTH | | |
| IP6_NH | | |
| IP6_HL_OUTER | | |
| IP6_SRC | | |
| IP6_DST | | |
| | | |
| UDP_SRC | | |
| UDP_DST | | |
| UDP_LENGTH | | |
| UDP_CHECK | | |
+--------------+-------------------+---------------+
Migault, et al. Expires April 7, 2017 [Page 29]
Internet-Draft Diet-ESP October 2016
A.2. Single TCP session IoT VPN
This section considers the same probe as described in Appendix A.1
but instead of using UDP as a transport layer, the probe uses TCP.
In this case TCP is used with no options, no urgent pointers and the
SN and ACK Number are compressed to 2 bytes as the throughput is
expected to be low.
Figure 5 represents the original TCP packet and Figure 6 represents
the corresponding packet compressed with Diet-ESP. The compression
with Diet-ESP results in a reduction of 66 bytes overhead. With IPv4
inner address Diet-ESP results in a 50 byte overhead reduction.
Migault, et al. Expires April 7, 2017 [Page 30]
Internet-Draft Diet-ESP October 2016
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) | ESP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| traffic class | flow label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload length | next header | hop limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Inner
| inner source IP | IP
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| inner destination IP |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| source port | dest port | TCP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Off. | Rserv | Flags | Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ APPLICATION DATA ~
| |
| +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (continue) | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Standard IoT Single TCP Session VPN Packet Description
Migault, et al. Expires April 7, 2017 [Page 31]
Internet-Draft Diet-ESP October 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (SN) | ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Window Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~
~ APPLICATION DATA |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Diet-ESP Single TCP Session IoT VPN Packet Description
The following table illustrates the activated rules and the
attributes of the Diet-ESP Context that needs an explicit agreement
to achieve the compression. All other attributes used by the rules
are part of the SA agreement. Parameters of not activated rules are
left "Unspecified". Note for simplicity, tcp_sn and tcp_ack are
negotiated to start with 0, but it could be any other value as well.
Migault, et al. Expires April 7, 2017 [Page 32]
Internet-Draft Diet-ESP October 2016
+--------------+-------------------+---------------+
| EHC Rule | Context Attribute | Value |
+--------------+-------------------+---------------+
| ESP_SPI | esp_spi_lsb | 0 |
| ESP_SN | esp_sn_lsb | 0 |
| | esp_sn_gen | "Incremental" |
| ESP_NH | | |
| ESP_PAD | esp_align | 8 |
| | | |
| IP6_OUTER | ip6_tcfl_comp | "Outer" |
| | ip6_hl_comp | "Outer" |
| IP6_LENGTH | | |
| IP6_NH | | |
| IP6_HL_OUTER | | |
| IP6_SRC | | |
| IP6_DST | | |
| | | |
| TCP_SRC | | |
| TCP_DST | | |
| TCP_SN | tcp_lsb | 2 |
| | tcp_sn | 0 |
| TCP_ACK | tcp_lsb | 2 |
| | tcp_ack | 0 |
| TCP_OPTIONS | tcp_options | "False" |
| TCP_CHECK | | |
| TCP_URGENT | tcp_urgent | "False" |
+--------------+-------------------+---------------+
A.3. Traditional VPN
This section illustrates the case of an company VPN. The VPN is
typically set by a remote host that forwards all its traffic to the
security gateway. As transport protocols are "Unspecified",
compression is limited to ESP and the inner IP header. For the inner
IP header, the Destination IP address is "Unspecified" so the
compression of the inner IP address excludes the Destination IP
address. Similarly, the inner IP Next Header cannot be compressed as
the transport layer is not specified. For ESP, the security gateway
may only have a sufficiently low number of remote users with
relatively low throughput in which case SPI and SN can be compressed
to 2 bytes. As throughput remains relatively low, the alignment may
also set to 8 bits.
Figure 7 represents the original TCP packet with IPv6 inner IP
addresses and Figure 8 represents the corresponding packet compressed
with Diet-ESP. The compression with Diet-ESP results in a reduction
of 32 bytes overhead. For IPv4 compression results in a 24 byte
overhead compression.
Migault, et al. Expires April 7, 2017 [Page 33]
Internet-Draft Diet-ESP October 2016
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) | ESP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| traffic class | flow label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload length | next header | hop limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Inner
| inner source IP | IP
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| inner destination IP |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| source port | dest port | TCP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Off. | Rserv | Flags | Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ APPLICATION DATA ~
| |
| +-+-+-+-+-+-+-+-+---
| | Padding | ESP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Trai-
| Padding (continue) | Pad Length | Next Header | ler
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Standard ESP VPN Packet Description
Migault, et al. Expires April 7, 2017 [Page 34]
Internet-Draft Diet-ESP October 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | SN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | |
+-+-+-+-+-+-+-+-+ |
| |
| inner destination IP |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | source port | dest. port ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
~ (continue) | TCP Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ (continue) | Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ (continue) |Off. | Rserv | Flags | Window Size ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ (continue) | Checksum | Urgent ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pointer | |
+-+-+-+-+-+-+-+-+ |
~ APPLICATION DATA ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Diet-ESP VPN Packet Description
The following table illustrates the activated rules and the
attributes of the Diet-ESP Context that needs an explicit agreement
to achieve the compression. All other attributes used by the rules
are part of the SA agreement. Parameters of not activated rules are
left "Unspecified".
Migault, et al. Expires April 7, 2017 [Page 35]
Internet-Draft Diet-ESP October 2016
+--------------+-------------------+---------------+
| EHC Rule | Context Attribute | Value |
+--------------+-------------------+---------------+
| ESP_SPI | esp_spi_lsb | 2 |
| ESP_SN | esp_sn_lsb | 2 |
| | esp_sn_gen | "Incremental" |
| ESP_NH | | |
| ESP_PAD | esp_align | 8 |
| | | |
| IP6_OUTER | ip6_tcfl_comp | "Outer" |
| | ip6_hl_comp | "Outer" |
| IP6_LENGTH | | |
| IP6_HL_OUTER | | |
| IP6_SRC | | |
+--------------+-------------------+---------------+
Appendix B. EHC Classification (Informative)
EHC Rules for Header fields depends on the property of the given
field. The complete classification for all supported protocols is
provided in Appendix B The current classification is based on the
classification provided by ROHC (see Appendix A of [RFC5225]).
However, as EHC agrees on a context out of band, not all
classifications provided by ROHC are necessary and classification may
end up differently.
A key difference between ROHC and ESP Header Compression is that ESP
needs an explicit agreement between the peers, whereas ROHC does not
proceed to any out-of-band agreement. Instead ROHC learns some
values by reading them from an initial packet. This learning phase
is not anymore needed with ESP Header Compression as these fields can
be agreed. For that reason fields classified as STATIC-DEF by ROHC
becomes classified as STATIC-KNOWN for ESP Header Compression. In
addition, the EHC classification also differs from the ROHC
classification as EHC may be able to segment classes according to the
ESP context. In that sense, EHC does not consider a single class -
which is the one with the least constraints, as ROHC does. Instead,
the EHC classification intends to associate the different classes to
the ESP context.
EHC requires these four classes, in order to classify the different
header fields:
STATIC-KNOWN These fields are expected to remain constant throughout
the lifetime of the flow. As a result, they can be negotiated
out of band and stored in a context.
Migault, et al. Expires April 7, 2017 [Page 36]
Internet-Draft Diet-ESP October 2016
INFERRED These fields contain values that can be inferred from other
values, for example the size of the frame carrying the packet,
and thus do not have to be included in compressed packets.
PATTERN These are fields that change between each packet, but change
in a predictable pattern.
IRREGULAR These are the fields for which no useful change pattern
can be identified and should be transmitted uncompressed in all
compressed packets.
This section details the classification for the currently supported
protocol fields. Bbeing ESP encapsulated, a given field may end up
with a different classification than without encapsulation. In order
to point out these differences, this section also provides for
information the classification provided by ROHC. In addition, given
the context associated to ESP, a given field may be classified
differently. In that case, the multiple classifications are
mentioned.
B.1. ESP
This section provides a EHC classification for the fields of the ESP
protocol.
+-----------------------+---------------------------+------------+
| Field | EHC Class | ROHC class |
+-----------------------+---------------------------+------------+
| Security Policy Index | STATIC-KNOWN | STATIC-DEF |
| Sequence Number | PATTERN | PATTERN |
| Padding | INFERRED / STATIC-KNOWN | |
| Pad Length | INFERRED / STATIC-KNOWN | |
| Next Header | STATIC-KNOWN / IRREGULAR | |
+-----------------------+---------------------------+------------+
Fields Padding, Pad Length, Next Header were not classified by ROHC
because, they could not be compressed by either ROHCoverIPsec or
ROHC. ROHCoverIPsec compresses protocols encapsulated by ESP. These
fields are part of ESP and so cannot be compressed by ROHCoverIPsec.
ROHC compresses fields sent on the wire but these fields are
encrypted by ESP and so cannot be compressed by ROHC.
In EHC, when present, Padding and Pad Length are INFERRED from the
necessary protocol alignment, the cipher alignment and the ESP packet
length before the encryption occurs. For packet with fixed size,
these values will not changed during the session and as a result, may
be classified as STATIC-KNOWN. Similarly, for some specific
alignment values, such as 8 bit alignment, these fields may also have
fixed values and thus may be classified as STATIC-KNOWN too.
Migault, et al. Expires April 7, 2017 [Page 37]
Internet-Draft Diet-ESP October 2016
Next Header is STATIC-KNOWN when it is part of the TS, in which case
it has been agreed between the peers. Otherwise, NH is IRREGULAR and
thus cannot be compressed.
B.2. IPv6 (Inner)
This section provides a EHC classification for the fields of the IPv6
protocol. The IPv6 address only considers the inner IP header when
used in conjunction of the tunnel mode.
+-------------------+--------------------------------+--------------+
| Field | EHC Class | ROHC class |
+-------------------+--------------------------------+--------------+
| Version | STATIC-KNOWN | STATIC-KNOWN |
| Traffic Class | STATIC-KNOWN / INFERRED / | RACH |
| | IRREGULAR | |
| Flow Label | STATIC-KNOWN / INFERRED / | STATIC-DEF |
| | IRREGULAR | |
| Payload Length | INFERRED | INFERRED |
| Next Header | STATIC-KNOWN / IRREGULAR | STATIC-DEF |
| Hop Limit | STATIC-KNOWN / INFERRED | RACH |
| Source Address | STATIC-KNOWN | STATIC-DEF |
| Destination | STATIC-KNOWN | STATIC-DEF |
| Address | | |
+-------------------+--------------------------------+--------------+
Traffic Class, Flow Label, Hop Limit are STATIC-KNOWN when part of
the TS, in which case it has been agreed between the peers in the EHC
context. Alternatively, the inner IPv6 header is INFERRED from the
outer IP header if the outer IP header is an IPv6 header. In any
other cases, these fields are IRREGULAR.
Next Header is STATIC-KNOWN when it is part of the TS, in which case
it has been agreed between the peers. Otherwise, NH is IRREGULAR and
thus cannot be compressed.
B.3. IPv4 (Inner)
This section provides a EHC classification for the fields of the IPv6
protocol. The IPv6 address only considers the inner IP header when
used in conjunction of the tunnel mode.
Migault, et al. Expires April 7, 2017 [Page 38]
Internet-Draft Diet-ESP October 2016
+---------------------+--------------------------+--------------+
| Field | EHC Class | ROHC class |
+---------------------+--------------------------+--------------+
| Version | STATIC-KNOWN | STATIC-KNOWN |
| Header Length | | |
| . Options enabled | IRREGULAR | RACH |
| . Options disabled | STATIC-KNOWN | STATIC-KNOWN |
| Type of Service | STATIC-KNOWN | RACH |
| Total Length | INFERRED | INFERRED |
| Identification | | |
| . Sequential | PATTERN | PATTERN |
| . Seq. swap | PATTERN | PATTERN |
| . Random | IRREGULAR | IRREGULAR |
| . Zero | STATIC-KNOWN | STATIC-KNOWN |
| Flags | STATIC-KNOWN / IRREGULAR | |
| . Reserved | | STATIC-KNOWN |
| . Don't Fragment | | RACH |
| . More Fragment | | STATIC-KNOWN |
| Fragment offset | STATIC-KNOWN / IRREGULAR | STATIC-KNOWN |
| Time To Live | STATIC-KNOWN / INFERRED | INFERRED |
| Protocol | STATIC-KNOWN / IRREGULAR | STATIC-DEF |
| Header Checksum | INFERRED | INFERRED |
| Source Address | STATIC-KNOWN | STATIC-DEF |
| Destination Address | STATIC-KNOWN | STATIC-DEF |
| Options | IRREGULAR | |
| Padding | IRREGULAR | |
+---------------------+--------------------------+--------------+
Version, Source and Destination Address and Protocol STATIC-KNOWN
when part of the TS, in which case it has been agreed between the
peers in the EHC context. Otherwise, they are IRREGULAR and thus
cannot be compressed.
Traffic Class, Flow Label, Time To Live and Flags are STATIC-KNOWN if
agreed between the two peers. Otherwise the inner IPv4 header may
also be inferred from the outer IP header if the outer IP header is
an IPv4 header. In any other cases, these fields are IRREGULAR.
Header Length depends on the options, thus when peers agree on
disabling options, the Header Length becomes STATIC-KNOWN and
IRREGULAR otherwise.
Type of Service (DSCP and ECN) are optional and may be disabled in
which case they can be classified as STATIC-KNOWN.
Identification, Flags and Fragment Offset are used to deal with
fragmentation. When fragmentation is disabled, these fields may be
classified as STATIC-KNOWN. When fragmentation is actived,
Migault, et al. Expires April 7, 2017 [Page 39]
Internet-Draft Diet-ESP October 2016
Identification may be classified as PATTERN or IRREGULAR. Flags or
Fragment offset may be classified as IRREGULAR.
Type of Service, Options and Padding cannot be compressed in a static
way without in-band signalling, thus they are classified as
IRREGULAR.
B.4. UDP
This section provides an EHC classification for the fields of the UDP
header.
+------------------+--------------------------+-------------------+
| Field | EHC Class | ROHC class |
+------------------+--------------------------+-------------------+
| Source Port | STATIC-KNOWN / IRREGULAR | STATIC-DEF |
| Destination Port | STATIC-KNOWN / IRREGULAR | STATIC-DEF |
| Length | INFERRED | INFERRED |
| Checksum | STATIC-KNOWN / INFERRED | STATIC, IRREGULAR |
+------------------+--------------------------+-------------------+
Source and Destination Port are STATIC-KNOWN when part of the TS, in
which case it has been agreed between the peers. Otherwise, they are
IRREGULAR and thus cannot be compressed.
When peers have agreed to disable UDP checksum, the checksum is
always zero and so its value is STATIC-KNOWN. Otherwise the checksum
needs to be computed once the packet has been decompressed. UDP
checksum can be computed as ESP provides an integrity check, thus the
received packet is believed to be unchanged. Note also that
integrity check does not enable error correction which CRC does, but
in case of a bit error encryption will fail, thus this case is
considered as irrelevant.
B.5. UDP-Lite
This section provides an EHC classification for the fields of the
UDP-Lite header.
+-------------------+----------------------------------+------------+
| Field | EHC Class | ROHC class |
+-------------------+----------------------------------+------------+
| Source Port | STATIC-KNOWN | STATIC-DEF |
| Destination Port | STATIC-KNOWN | STATIC-DEF |
| Checksum Coverage | STATIC-KNOWN / INFERRED / | IRREGULAR |
| | IRREGULAR | |
| Checksum | INFERRED | IRREGULAR |
+-------------------+----------------------------------+------------+
Migault, et al. Expires April 7, 2017 [Page 40]
Internet-Draft Diet-ESP October 2016
See Appendix B.4 for classification of Source and Destination Port.
The Checksum Coverage is the part of the UDP-Lite packet, and
indicates the number of bytes covered by the checksum. The minimal
value is 8, which is the UDP-Lite Header. The maximum value is the
size of the UDP-Lite packet, which means that the checksum is the
same as in UDP. The Coverage can be agreed to be a fixed value or a
value that is function of the total length o fthe UDP packet. In
these cases, Coverage can be classified as STATIC-KNOWN or INFERRED.
Otherwise it is classified as IRREGULAR.
In UDP-Lite the checksum cannot be disabled, but its coverage
changes. Thus it will never appear as zero, but it can be INFERRED
in every case, according to the value of Checksum Coverage.
B.6. TCP
This section provides an EHC classification for the fields of the TCP
header.
+------------------------+--------------+---------------------+
| Field | EHC Class | ROHC class RFC4413 |
+------------------------+--------------+---------------------+
| Source Port | STATIC-KNOWN | STATIC-DEF |
| Destination Port | STATIC-KNOWN | STATIC-DEF |
| Sequence Number | PATTERN | CHANGING |
| Acknowledgement Number | PATTERN | CHANGING |
| Data Offset | | INFERRED |
| . Options enabled | IRREGULAR | |
| . Options disabled | STATIC-KNOWN | |
| Reserved Bits | IRREGULAR | CHANGING |
| Flags | IRREGULAR | CHANGING |
| Window | IRREGULAR | CHANGING |
| Checksum | | |
| . Disabled | STATIC-KNOWN | STATIC |
| . Enabled | INFERRED | IRREGULAR |
| Urgent Pointer | IRREGULAR | CHANGING |
| Options | IRREGULAR | CHANGING |
+------------------------+--------------+---------------------+
See Appendix B.4 for classification of Source and Destination Port.
The TCP Sequence and Acknowledgement Number increase in a PATTERN but
caused by the different TCP-Flags the increase is not performed in
every packet.
Data Offset contains the length of the TCP header including the
options. If options are agreed to be disabled it is STATIC-KNOWN.
Migault, et al. Expires April 7, 2017 [Page 41]
Internet-Draft Diet-ESP October 2016
If Options are enabled it cannot be decompressed without in-band
signalling, thus it is classified as IRREGULAR in that case.
See Appendix B.4 for the checksum classification.
Flags, Windows, Urgent Pointer and Options cannot be compressed
without in-band signalling, thus classified as IRREGULAR in every
case.
Appendix C. Document Change Log
[draft-mglt-6lo-diet-esp-00.txt]:
Changing affiliation
[draft-mglt-6lo-diet-esp-00.txt]:
Updating references
[draft-mglt-ipsecme-diet-esp-01.txt]:
Diet ESP described in the ROHC framework
ESP is not modified.
[draft-mglt-ipsecme-diet-esp-00.txt]:
NAT consideration added.
Comparison actualized to new Version of 6LoWPAN ESP.
[draft-mglt-dice-diet-esp-00.txt]: First version published.
Authors' Addresses
Daniel Migault (editor)
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Email: daniel.migault@ericsson.com
Tobias Guggemos (editor)
LMU Munich
Oettingenstr. 67
80538 Munchen, Bavaria
Germany
Email: guggemos@mnm-team.org
URI: http://www.mnm-team.org/~guggemos
Migault, et al. Expires April 7, 2017 [Page 42]
Internet-Draft Diet-ESP October 2016
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Migault, et al. Expires April 7, 2017 [Page 43]