ESP Header Compression Profile
draft-ietf-ipsecme-diet-esp-01
| Document | Type | Active Internet-Draft (ipsecme WG) | |
|---|---|---|---|
| Authors | Daniel Migault , Maryam Hatami , Sandra Cespedes , J. William Atwood , Tobias Guggemos , Carsten Bormann , David Schinazi | ||
| Last updated | 2024-07-08 | ||
| Replaces | draft-mglt-ipsecme-diet-esp | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ipsecme-diet-esp-01
IPsecme D. Migault
Internet-Draft Ericsson
Intended status: Standards Track M. Hatami
Expires: 9 January 2025 S. Céspedes
W. Atwood
Concordia University
T. Guggemos
LMU
C. Bormann
Universitaet Bremen TZI
D. Schinazi
Google LLC
8 July 2024
ESP Header Compression Profile
draft-ietf-ipsecme-diet-esp-01
Abstract
This document defines how to compress/decompress communications
protected with IPsec/ESP using Static Context Header Compression and
fragmentation (SCHC). SCHC uses static information from IPv6 headers
to reduce redundancy and size of packets on the wire. This
specification provides guidelines on the application of SCHC to
compress/decompress at different levels of the ESP/IPv6 protected
packets, leveraging the information already shared by the peers.
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 https://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 9 January 2025.
Migault, et al. Expires 9 January 2025 [Page 1]
Internet-Draft EHCP July 2024
Copyright Notice
Copyright (c) 2024 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. SCHC Integration into the IPsec Stack . . . . . . . . . . . . 6
5. SCHC parameters . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. SCHC Context Initialization . . . . . . . . . . . . . . . 8
5.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . . . 9
5.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9
5.6. SCHC parameterization for ESP . . . . . . . . . . . . . . 9
5.7. New SCHC CDA . . . . . . . . . . . . . . . . . . . . . . 12
6. Inner IP Compression (IIPC) . . . . . . . . . . . . . . . . . 13
6.1. Inner IPv4 Compression . . . . . . . . . . . . . . . . . 14
7. Clear Text ESP Compression (CTEC) . . . . . . . . . . . . . . 14
7.1. Inner Packet Payload Compression . . . . . . . . . . . . 15
7.2. ESP Compression . . . . . . . . . . . . . . . . . . . . . 16
8. Encrypted ESP Compression (EEC) . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Illustrative Example . . . . . . . . . . . . . . . . 18
A.1. Single UDP Session IoT VPN . . . . . . . . . . . . . . . 18
A.2. Single TCP session IoT VPN . . . . . . . . . . . . . . . 22
A.3. Traditional VPN . . . . . . . . . . . . . . . . . . . . . 24
A.4. IPv6 in IPv6 . . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. JSON format Context . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
Migault, et al. Expires 9 January 2025 [Page 2]
Internet-Draft EHCP July 2024
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Introduction
The Encapsulating Security Payload (ESP) [RFC4303] protocol can
provide confidentiality, data origin authentication, integrity, anti-
replay, and traffic flow confidentiality. The set of services ESP
provides depends on the Security Association (SA) parameters
negotiated between devices.
ESP has two modes: Tunnel and Transport. Tunnel mode is commonly
used for VPNs, with the ESP header placed after the outer IP header
and before the inner IP packet headers. In Transport mode, the ESP
Payload Data consists of the IP Payload, with the ESP header placed
after the inner IP packet header and any IP extensions headers.
This document defines the ESP Header Compression profile (EHCP) for
compression/decompression (C/D) of IPsec/ESP [RFC4301] / [RFC4303]
packets, represented by the structure shown in Figure 1, using Static
Context Header Compression and fragmentation (SCHC) [RFC8724].
Compression with SCHC is based on using a set of Rules, which
constitutes the Context of SCHC C/D, to compress or decompress
headers. The motivation is to avoid sending information that has
already been shared by the peers, thus reducing the ESP packet size
on the wire. To better understand ESP, the reader might be
interested in reading Minimal ESP [RFC9333], a simplified version of
ESP.
Migault, et al. Expires 9 January 2025 [Page 3]
Internet-Draft EHCP July 2024
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) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Top-Level Format of an ESP Packet
This document provides the ESP Header Compression profile (EHCP)
architecture with the integration of SCHC into various levels of the
IPsec stack. The three levels of compression are defined below:
1. Inner IP Compression (IIPC): This level happens directly on the
inner IP packet. For example, in the case of a UDP packet with
ports determined by the SA, fields such as UDP ports and
checksums are typically compressed. If no compression of the
inner packet is possible, the resulting SCHC packet contains the
uncompressed IP packet, as per [RFC8724], Section 7.2.
2. Clear Text ESP Compression (CTEC): This level compresses fields
of the ESP payload right before being encrypted.
3. Encrypted ESP Compression (EEC): This level compresses ESP fields
that remain after encryption, that is, the ESP header.
Note that the descriptions of the three levels of compression
provided in this document meet the general purpose of ESP. It is
possible that in some specific deployments, SCHC contexts from
different levels can be merged. Typically, a specific implementation
may merge IIPC and CTEC.
For each compressor/decompressor level, it defines the ESP fields to
be considered in the rules of its corresponding SCHC context. In
addition, it defines how the SCHC contexts are initialized from the
Migault, et al. Expires 9 January 2025 [Page 4]
Internet-Draft EHCP July 2024
SA and provides the corresponding SCHC rules (RuleID, SCHC
MAX_PACKET_SIZE, new SCHC Compression/Decompression Actions (CDA),
and fragmentation). The appendix provides illustrative examples of
applications of EHC using an implementation in openschc.
3. Terminology
ESP Header Compression Profile (EHCP): A method to reduce the size
of ESP headers using predefined compression rules and contexts to
improve efficiency.
Inner IP C/D (IIPC): Expressed via the SCHC framework, IIPC
compresses/decompresses the inner IP packet headers.
Clear Text ESP C/D (CTEC): Expressed via the SCHC framework, CTEC
compresses/decompresses all fields that will later be encrypted by
ESP.
Encrypted ESP C/D (EEC): Expressed via the SCHC framework, EEC
compresses/decompresses ESP fields that will not be encrypted by
ESP.
Security Parameters Index (SPI): As defined in [RFC4301],
Section 4.1.
Sequence Number (SN): As defined in [RFC4303], Section 2.2.
Static Context Header Compression (SCHC): A framework for header
compression designed for LPWANs, as defined in [RFC8724].
Static Context Header Compression Rules (SCHC Rules): As defined in
[RFC8724], Section 5.
RuleID: A unique identifier for each SCHC rule, as defined in
[RFC8724], Section 5.1.
SCHC Context: The set of parameters and rules shared between
communicating entities, as defined in [RFC8724], Section 5.3.
It is assumed that the reader is familiar with other SCHC terminology
defined in [RFC8376] and [RFC8724].
Migault, et al. Expires 9 January 2025 [Page 5]
Internet-Draft EHCP July 2024
4. SCHC Integration into the IPsec Stack
The main principle of the ESP Header Compression Profile (EHCP) is to
avoid sending information that has already been shared by the peers.
Different profiles and technologies, such as those defined by
[RFC4301] and [RFC4303], ensure that ESP can be tailored to various
network requirements and security policies. However, ESP is not
optimized for bandwidth efficiency because it has been designed as a
general-purpose protocol. EHCP aims to address this by leveraging a
profile, expressed via the SCHC framework, to optimize the ESP header
sizes for better efficiency in constrained environments.
Profiles for compression are derived from parameters associated with
the Security Association (SA) and agreed upon via IKEv2 [RFC7296], as
well as specific compression parameters defined in IKEv2
[I-D.mglt-ipsecme-ikev2-diet-esp-extension]. As depicted in
Figure 2, this document defines three levels of compression, as
previously described: IIPC, CTEC, and EEC. The terminology of
"levels" is used consistently throughout the document for clarity.
The Figure 2 illustrates the integration of SCHC into the IPsec
stack, detailing the different levels and components involved in the
compression and decompression processes. The diagram is divided into
two entities, each representing an endpoint of a communication link.
While the scope of this compression profile currently does not extend
beyond the transport layer (i.e., UDP), there will eventually be a
need to compress the application layer as well.
The decompression of the inbound packet follows a reverse process.
First, the Encrypted ESP C/D (EEC) decompresses the encrypted ESP
header fields. After the ESP packet is decrypted, the Clear Text ESP
C/D (CTEC) decompresses the Clear Text fields of the ESP packet.
Note that implementations MAY differ from the architectural
description but it is assumed the outputs will be the same.
Migault, et al. Expires 9 January 2025 [Page 6]
Internet-Draft EHCP July 2024
+--------------------------------+
| ESP Header Compression Context |
| - Security Association |
| - Additional Parameters |
+--------------------------------+
|
Endpoint | Endpoint
|
+----------------+ | +----------------+
| Inner IP packet| | | Inner IP packet|
+----------------+ | +----------------+
| SCHC |+---------IIPC level--------------+| SCHC |
+----------------+ C {IIP} +----------------+
| ESP | | | ESP |
| (encapsulation)| | | (unwrapping) |
+----------------+ v +----------------+
| SCHC |+---------CTEC level--------------+| SCHC |
+----------------+ EH, C {C {IIP}, ET} +----------------+
| ESP | | | ESP |
| (encryption) | | | (decryption) |
+----------------+ v +----------------+
| SCHC |+-----------EEC level-------------+| SCHC |
+----------------+ IP, C {EH, C {C {IIP}, ET}} +----------------+
| IPv6 + ESP | | IPv6 + ESP |
+----------------+ +----------------+
| L2 | | L2 |
+----------------+ +----------------+
Figure 2: SCHC Integration into the IPsec Stack. Packets are
described for the tunnel mode and C designates the Compressed
header for the fields inside. IIP designates the Inner IP
packet, EH and ET respectively the ESP Header and the ESP Trailer
5. SCHC parameters
If ESP incorporates SCHC, it is essential that these scenarios use
the SCHC header compression [RFC8724] capability to optimize data
transmission.
In order to work properly, the different levels of C/D need to be
configured similarly with the same SCHC Context Initialization. This
involves defining variables such as SCHC MAX_PACKET_SIZE or
Fragmentation that are invariants in our case, as well as SCHC Rules
that are expected to be set on a per SA basis.
Migault, et al. Expires 9 January 2025 [Page 7]
Internet-Draft EHCP July 2024
The EHCP Context provides the necessary information to generate the
SCHC Rules. Most pieces of information are already available from
the negotiated SA [RFC4301]. Other pieces of information need to be
specifically configured or agreed via other mechanisms, such as
[I-D.mglt-ipsecme-ikev2-diet-esp-extension].
The reference column in Figure 3 indicates how the information is
defined. The C/D column specifies in which of the compression levels
the parameter is being used.
Note that additional Compression might be performed especially on the
inner IP packet - for example, including the TCP layer. However,
this profiles limits the scope of the compression to the inner IP
header, and possibly UDP headers. We believe this is a reasonable
scope for ESP to address both IoT UDP packets as well as large VPN
traffic. If further compression is needed, this should be achieved
by sending an IP packet with a SCHC payload, where the expected
compression is achieved outside ESP.
5.1. SCHC Context Initialization
SCHC Context Initialization involves setting up the initial
parameters and values that will be used for compressing and
decompressing ESP headers. This includes defining the static
context, which contains all the rules and parameters necessary for
the SCHC operations. The context is shared between the sender and
receiver to ensure consistent compression and decompression
processes. Initialization ensures that both ends have a common
understanding of the fields, their possible values, and how to handle
them during communication.
5.2. SCHC Rules
SCHC Rules are predefined sets of instructions that specify how to
compress and decompress the header fields of an ESP packet. Each
rule is designed to handle specific patterns and variations in the
header fields, allowing for efficient compression by eliminating
redundancy and leveraging the static context. Rules are identified
by RuleIDs and are crucial for mapping the fields correctly during
the compression and decompression processes.
5.3. Rule ID
The RuleID is a unique identifier for each SCHC rule, included in
packets to ensure the receiver applies the correct decompression
rule, maintaining consistency in packet processing. Note that the
Rule ID does not need to be explicitly agreed upon and can be defined
independently by each party.
Migault, et al. Expires 9 January 2025 [Page 8]
Internet-Draft EHCP July 2024
5.4. SCHC MAX_PACKET_SIZE
This field defines the largest size of a compressed ESP packet that
can be handled. It ensures packets fit within network limits,
optimizing transmission and avoiding unnecessary fragmentation. Note
that the SCHC MAX_PACKET_SIZE varies based on the packet because it
is not specific to any particular lower-layer (LL) technology. This
flexibility allows SCHC to be adapted to various network environments
and constraints.
5.5. Fragmentation
The resulting IP/ESP packet size is variable. In some networks, the
packet will require fragmentation before transmission over the wire.
Fragmentation is out of the scope of this document since it is
dependant on the layer 2 technology.
5.6. SCHC parameterization for ESP
The following attributes are considered in the EHCP Context.
Implementations may consider different expressions of the parameters
but their behavior is expected to remain compatible with this
specification.
SCHC Context parameterization:
Migault, et al. Expires 9 January 2025 [Page 9]
Internet-Draft EHCP July 2024
+===================+==========================+===========+=======+
| EHC Context | Possible Values | Reference | C / D |
+===================+==========================+===========+=======+
| alignment | "8 bit", "32 bit" | ThisRFC | CTEC |
| ipsec_mode | "Tunnel", "Transport" | RFC4301 | CTEC |
| tunnel_ip | IPv4, IPv6 address | RFC4301 | CTEC |
| esp_spi | ESP SPI | RFC4301 | EEC |
| esp_spi_lsb | 0, 1, 2, 3, 4* | ThisRFC | EEC |
| esp_sn | ESP Sequence Number | RFC4301 | EEC |
| esp_sn_lsb | 0, 1, 2, 3, 4* | ThisRFC | EEC |
| esp_encr | ESP Encryption Algorithm | RFC4301 | CTEC |
| ts_flow_label | True, False | ThisRFC | CTEC |
| ts_ip_version | 4, 6 | ThisRFC | CTEC |
| ts_ip_src_start | IP4 or IPv6 address | ThisRFC | CTEC |
| ts_ip_src_end | IP4 or IPv6 address | ThisRFC | CTEC |
| ts_ip_dst_start | IPv4 or IPv6 address | ThisRFC | CTEC |
| ts_ip_dst_end | IPv4 or IPv6 address | ThisRFC | CTEC |
| ts_proto_list | TCP, UDP, ..., 0 | ThisRFC | CTEC |
| ts_port_src_start | Port number | ThisRFC | CTEC |
| ts_port_src_end | Port number | ThisRFC | CTEC |
| ts_port_dst_start | Port number | ThisRFC | CTEC |
| ts_port_dst_end | Port number | ThisRFC | CTEC |
| ts_dsp_list | DSCP number | RFCYYYY | CTEC |
+-------------------+--------------------------+-----------+-------+
Figure 3: EHCP related parameters
alignment: indicates the byte alignement supported by the OS for the
ESP extension. By default, the alignement is 32 bit for IPv6, but
some systems may also support an 8 bit alignement. Note that when
a block cipher such as AES-CCM is used, an 8 bit alignment is
overwritten by the block size.
ipsec_mode: designates the IPsec mode defined in [RFC4301]. In this
document, the possible values are "tunnel" for the Tunnel mode and
"transport" for the Transport mode.
tunnel_ip: designates the IP address of the tunnel defined in
[RFC4301]. This field is only applicable when the Tunnel mode is
used. That IP address can be an IPv4 or IPv6 address.
esp_spi: designates the Security Policy Index defined in [RFC4301].
esp_spi_lsb: designates the LSB to be considered for the compressed
Migault, et al. Expires 9 January 2025 [Page 10]
Internet-Draft EHCP July 2024
SPI. This parameter is defined by this specification and can take
the following values 0, 1, 2, 4 respectively meaning that the
compressed SPI will consist of the esp_spi_lsb LSB bytes of the
original SPI. A value of 4 for esp_spi_lsb will leave the SPI
unchanged.
esp_sn: designates the Sequence Number (SN) field defined in
[RFC4301].
esp_sn_lsb: designates the LSB to be considered for the compressed
SN and is defined by this specification. It works similarly to
esp_spi_lsb.
esp_encr: designates the encryption algorithm used. For the purpose
of compression it is RECOMMENDED to use [RFC8750].
ts_ *: Any parameter starting with "ts_". These parameters are
associated with the Traffic Selectors of the SA and are introduced
by this specification. This specification limits the expression
of the Traffic Selector to be of the form (IP source range, IP
destination range, Port source range, Port destination range,
Protocol ID list, DSCP list). This limits the original
flexibility of the expression of TS, but we believe that it
provides sufficient flexibility. Following shows detail
information of these parameters.
ts_flow_label: indicates the Flow Label field of the inner IPv6
packet or the Identification field of the inner IPv4 packet is
copied from the outer IP address.
ts_ip_version: designates the IP version of the Traffic Selectors
and its value is set to 4 when only IPv4 IP addresses are
considered and to 6 when only IPv6 addresses are considered.
Practically, when IKEv2 is used, it means that the agreed TSi or
TSr results only in a mutually exclusive combination of
TS_IPv4_ADDR_RANGE or TS_IPV6_ADDR_RANGE payloads. When the
traffic selectors result in a combination of IPv4 and IPv6
addresses, ts_ip_version is undefined.
ts_ip_src_start: designates the starting value range of source IP
addresses of the inner packet and has the same meaning as the
Starting Address field of the Traffic Selector payload defined in
[RFC7296], Section 3.13. Note however that in this specification,
ts_ip_src_start applies for all agreed Traffic Selector payloads.
When the IP addresses cannot be expressed as a range, that can be
exactly expressed as [ ts_ip_src_start, ts_ip_src_end ],
ts_ip_src_start is undefined.
Migault, et al. Expires 9 January 2025 [Page 11]
Internet-Draft EHCP July 2024
ts_ip_src_end: designates the high end value range of source IP
addresses of the inner packet and has the same meaning as the
Ending Address field of the Traffic Selector payload defined in
[RFC7296], Section 3.13. Similarly to ts_ip_src_end, when the IP
addresses cannot be expressed as a range, ts_ip_src_end is
undefined.
ts_port_src_start: designates the starting value of the port range
of the inner packet and has the same meaning as the Start Port
field of the Traffic Selector payload defined in [RFC7296],
Section 3.13.
ts_port_src_end: designates the starting value of the port range of
the inner packet and has the same meaning as the End Port field of
the Traffic Selector payload defined in [RFC7296], Section 3.13.
ts_proto_list: designates the list of Protocol ID field, whose
meaning is defined in [RFC7296], Section 3.13.
ts_dscp_list: designates the list of DSCP values used by the Traffic
Selector and has the same meaning as the List of DSCP Values
defined in [I-D.mglt-ipsecme-ts-dscp].
IP addresses and ports are defined as a range and compressed using
the LSB. For a range defined by start and end values, msb( start,
end ) is defined as the function that returns the MSB that remains
unchanged while the value evolves between start and end. Similarly,
lsb( start, end ) is defined as the function that returns the LSB
that changes while the value evolves between start and end. Finally,
len( x ) is defined as the function that returns the number of bits
of the bit array x.
Protocol IDs and DSP are defined as lists of non consecutive values.
A target value is defined when the list contains a single element.
5.7. New SCHC CDA
In addition to the Compression / Decompression Actions defined in
[RFC8724], Section 7.4, this specification uses the CDA as presented
in Figure 4. These CDA are either a refinement of the compute- * CDA
or the result of combined CDA.
Migault, et al. Expires 9 January 2025 [Page 12]
Internet-Draft EHCP July 2024
+=================+=====================+=============================+
| Action | Compression | Decompression |
+=================+=====================+=============================+
| lower | elided | Get from lower layer |
| checksum | elided | Compute checksum |
| padding | elided | Compute padding |
+-----------------+---------------------+-----------------------------+
Figure 4: EHCP ESP related parameter
More specifically, when the list contains 0 or a single element, that
value can be decompressed without ambiguity and as such an index does
not need to be sent. When more than one value is present in the
list, the index needs to be sent.
6. Inner IP Compression (IIPC)
When ts_ip_src/dst range is defined and ts_ipversion is set to
"IPv6," IPv6 addresses of the inner IP packet are compressed. This
inner packet compression always occurs. FL is set to 128, TV to
msb(ip_src) or msb(ip_dst), the MO is set to "MSB," and the CDA is
set to "LSB."
The IPv6 Hop Limit is compressed/decompressed. FL is set to 8 bits,
TV is omitted, MO is set to "ignore," and CDA is set to "lower."
The last Next Header with a transport protocol value is compressed/
decompressed. FL is set to 8 bits. If ts_proto_list contains the
value 0, TV is not set, MO is set to "ignore," and CDA is set to
"value-sent." If "proto_id" does not contain 0 and the list contains
one or fewer values, TV is set to that value, MO is set to "equal,"
and CDA is set to "not-sent." In any other case, TV is set to the
proto_list, MO is set to "match-mapping," and CDA is set to "mapping-
sent."
The IPv6 Total Length is compressed/decompressed. FL is set to 16
bits, TV is not set, MO is set to "ignore," and CDA is set to
"lower."
Traffic Class is compressed/decompressed similarly to the DSP and ECN
fields. FL is set to 8 bits. When the DSP and ECN are defined by
the SA via [I-D.mglt-ipsecme-ts-dscp] and ts_dsp_list contains a
single element, TV is set to that element, MO is set to "equal," and
CDA is set to "not-sent." When the DSP and ECN are defined by the SA
via [I-D.mglt-ipsecme-ts-dscp] and ts_dsp_list contains more than one
element, TV is set to the list, MO is set to "match-mapping," and CDA
is set to "mapping-sent." When the DSP and ECN are not defined by
the SA, MO is set to "ignore," and the CDA is set to "lower."
Migault, et al. Expires 9 January 2025 [Page 13]
Internet-Draft EHCP July 2024
When ts_ip_version can be inferred from the ts, the IP version is
elided. FL is set to 4 bits, TV is set to ts_ip_version, MO is set
to "equal," and CDA to "not-sent."
When the inner IP address has the same version as the outer_ip and
ts_traffic_flow is defined and set to True, the Identification field
of the IPv4 inner packet or the Traffic Flow field of the IPv6 packet
is elided and read from the outer IP address field. For IPv6, FL is
set to 20 bits, TV is ignored, MO is set to "ignore," and CDA is set
to "lower."
When the inner IP is IPv6 and the outer IP is IPv4 and
ts_traffic_flow is set to True, the LSB 16 bits of the inner Traffic
Flow fields are set to the outer Identification field and the
remaining 4 MSB bits are set to 0. Such compression is not lossless
and needs to be considered cautiously. Note that the Flow Label of
the inner packet arriving at the destination may have another value
than the initial Flow Label. However, the Flow Label value set at
the source ends up with the same value at the destination, with, of
course, a lower entropy.
6.1. Inner IPv4 Compression
The compression/decompression of IPv4 fields are similar to IPv6,
with some differences. IPv4 addresses are compressed/decompressed
similarly to IPv6 addresses except that FL is set to 32.
The IPv4 Header checksum is elided. FL is set to 16, TV is omitted,
MO is set to "ignore," and CDA is set to "checksum."
The IPv4 TTL field is derived from the IPv4 TTL field of the outer
IPv4 address or the IPv6 Hop Limit. FL is set to 8 bits, TV is
omitted, MO is set to "ignore," and CDA is set to "lower."
The IPv4 Total Length is elided. FL is set to 16 bits, TV is not
set, MO is set to "ignore," and CDA is set to "lower."
7. Clear Text ESP Compression (CTEC)
The Clear Text ESP Compression is performed on the ESP fields not yet
encrypted, that is the ESP Payload Data, the ESP padding field, the
Pad Length field as well as the Next Header field, which indicates
the type of the inner packet.
When ipsec_mode is set to "Transport", the Clear Text ESP packet that
corresponds to an IPv4 packet will have the Payload Data set to the
IPv4 Payload and the Next Header set to the Protocol ID - that is
typically UDP, TCP or SCHC when the payload results from an SCHC
Migault, et al. Expires 9 January 2025 [Page 14]
Internet-Draft EHCP July 2024
compression. The Clear Text ESP packet that corresponds to an IPv6
packet will have the Payload Data set may include some IPv6
extensions that precede the IP payload. In that case, the Next
Header will have the value that corresponds to that first IPv6
extension being encrypted.
When ipsec_mode is set to "Tunnel", the Clear Text ESP packet has the
Payload Data set to the IP packet with the Next Header field
indicating whether this is an IPv4, an IPv6 or an SCHC packet.
SA are unidirectional and the Direction Indicator (DI) reflects that
direction and is set to Up for outbound SA and Down for inbound SA.
Fields that are not compressed have no Target Value (TV), their
Matching Operator (MO) is set to ignore and Compression/Decompression
Actions (CDA) to "value-sent". Unless specified the Field Position
(FP) is set to 1.
Note that for both the IP payload and the IP header, some fields are
Compressed / Decompressed independently of the value of Traffic
Selectors EHC Context, while some other fields require the Traffic
Selectors to be expressed under a specific format.
7.1. Inner Packet Payload Compression
An SCHC payload is not compressed.
If the inner IP payload is an UDP or TCP packet the checksum is
elided. For both TCP or UDP, FL is set to 16 bit, TV is not set, MO
is set to "ignore" and CDA is set to "checksum". This may result in
decompressing a zero-checksum UDP packet with a valid checksum, but
this has no impact as a valid checksum is universally accepted.
If the inner packet is an UDP or UDP-Lite the length field is elided.
FL is set to 16, TV is not set, MO is set to "ignore" and CDA is set
to "lower" as the length field of the decompressed UDP packet is
expressed in bytes and is derived from the length of the compressed
UDP packet by adding the 16 bit UDP Checksum, the 16 bit UDP Length
field as well as the respective length of the respective source MSB
port and destination MSB ports.
UDP.Length = ( len( compressed UDP) + 16 + 16 + len( lsb( port_src ) ) \
+ len( lsb( port_src ) ) ) / 8
Note that for each SA, LSB and MSB are of fixed length. When the
port has a single value this is equivalent to TV containing the port
value, MO is set to "equal" and CDA set to not_sent.
Migault, et al. Expires 9 January 2025 [Page 15]
Internet-Draft EHCP July 2024
7.2. ESP Compression
When ipsec_mode is set to "Tunnel" and ts_ip_version can be
determined, the Next Header Field is elided. FL is set to 8 bits, TV
is set to IPv4 or IPv6 depending on the ts_ip_version, MO is set to
"equal" and CDA is set to "not-sent".
If the esp_encr does not require a specific block size, Padding and
Pad Length are elided. FL is defined by the type that is to (Pad
Length + 1 ) * 8 bits, TV is unset, MO is set to "ignore" and CDA is
set to padding.
Encryption may require require the clear text to respect a given size
block. In addition, IP networking may also require a special
alignment which is 32 bits by default for IPv6 Extensions, but may
also be overwritten by the EHC Context. The Padding is defined by
pad_value and pad_size appended to the clear text payload - similarly
to what ESP does with Padding and Pad Len. An 8 bit alignment is
interpreted by SCHC as a Word of 8 bits, and a 32 bit alignment is
interpreted as a Word of 32 bits. The padding size pad_size is
defined by the alignment and set to 3 bits for an 8 bit alignment
(23) and 5 bits for 32 bit alignment (2**5). If pad designates the
number of bits to be padded, the pad value is set to pad_value = (
pad + len( pad_size ) % Word. This results in an additional
pad_value + pad_size bits.
8. Encrypted ESP Compression (EEC)
SPI is compressed to its LSB. FL is set to 32 bits, TV is not set,
MO is set to "MSB( 4 - esp_spi_lsb)" and CDA is set to "LSB".
If the esp_encr considers implicit IV [RFC8750], Sequence Numbers are
not compressed. Otherwise, SN are compressed to their LSB similarly
to the SPI. FL is set to 32 bits, TV is not set, MO is set to "MSB(
4 - esp_spi_lsb)" and CDA is set to "LSB".
Note that the use of implicit IV always result in a better
compression as a 64 bit IV to be sent while compression of the SN
alone results at best in a reduction of 32 bits.
The IPv6 Next Header field or the IPv4 Protocol that contains the
"ESP" value is changed to "SCHC".
9. IANA Considerations
There are no IANA parameters to be registered.
Migault, et al. Expires 9 January 2025 [Page 16]
Internet-Draft EHCP July 2024
10. Security Considerations
There is no specific considerations associated with the profile other
than the security considerations of ESP [RFC4303] and those of SCHC
[RFC8724].
11. Acknowledgements
We would like to thank Laurent Toutain for its guidance on SCHC.
Robert Moskowitz for inspiring the name "Diet-ESP" from Diet-HIP.
12. References
12.1. Normative References
[I-D.mglt-ipsecme-ikev2-diet-esp-extension]
Migault, D., Guggemos, T., and D. Schinazi, "Internet Key
Exchange version 2 (IKEv2) extension for the ESP Header
Compression (EHC)", Work in Progress, Internet-Draft,
draft-mglt-ipsecme-ikev2-diet-esp-extension-04, 18 March
2024, <https://datatracker.ietf.org/doc/html/draft-mglt-
ipsecme-ikev2-diet-esp-extension-04>.
[I-D.mglt-ipsecme-ts-dscp]
Migault, D., Halpern, J. M., Parkholm, U., and D. Liu,
"Traffic Selector for Internet Key Exchange version 2 to
add support Differentiated Services Field Codepoints
(DSCP)", Work in Progress, Internet-Draft, draft-mglt-
ipsecme-ts-dscp-03, 26 July 2023,
<https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-
ts-dscp-03>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
Migault, et al. Expires 9 January 2025 [Page 17]
Internet-Draft EHCP July 2024
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit
Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP)", RFC 8750,
DOI 10.17487/RFC8750, March 2020,
<https://www.rfc-editor.org/info/rfc8750>.
12.2. Informative References
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, DOI 10.17487/RFC4309, December 2005,
<https://www.rfc-editor.org/info/rfc4309>.
[RFC9333] Migault, D. and T. Guggemos, "Minimal IP Encapsulating
Security Payload (ESP)", RFC 9333, DOI 10.17487/RFC9333,
January 2023, <https://www.rfc-editor.org/info/rfc9333>.
Appendix A. Illustrative Example
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 with a server, and sets a VPN to connect its
secure domain - like a home gateway. The home gateway will be
responsible to decompress the compress packet and provides
interoperability with standard application server.
The EHC Context is defined as mentioned below:
Migault, et al. Expires 9 January 2025 [Page 18]
Internet-Draft EHCP July 2024
* alignment is set to 8 bits
* ipsec_mode is set to "Tunnel"
* tunnel_ip_srct is set to the IPv6_m, the IPv6 address of the mote.
* tunnel_ip_dst is set to IPv6_gw, the IPv6 of the security gateway.
* esp_spi is agreed by the IKEv2.
* esp_spi_lsb is set to 0 as IPv6_m provides sufficient context to
associate the right SA.
* esp_sn results from the standard IPsec, and not impacted.
* esp_sn_lsb is set to 2 even though we are considering AES-
CCM_8_IIV [RFC8750] which uses the ESP Sequence Number to
generated the IV. This results in a 8 bytes reduction compared to
the AES-CCM_8 [RFC4309].
* esp_encr is configured with AES-CCM_8_IIV [RFC8750]. This cipher
suite does not require a block size and so no padding is required
and does not support SN compression.
* ts_flow_label As the inner traffic and the encrypted traffic are
very correlated, it makes sense to re-use the flow label and
ts_flow_label is set to True.
* ts_ip_version is set to IPv6.
* ts_ip_src_start is set to IPv6_m. In this example, the SA is
associated to messages sent by the mote to the application server
(IPv6_server)
* ts_ip_src_end is set to IPv6_m
* ts_ip_dst_end the IPv6 address of the application server
(IPv6_server).
* ts_ip_dst_end IPv6_server
* ts_proto_list [ UDP ], in the case of a very constraint mote, only
UDP messages are considered.
* ts_port_src_start port_m. The mote and the application server are
using dedicated ports.
Migault, et al. Expires 9 January 2025 [Page 19]
Internet-Draft EHCP July 2024
* ts_port_src_end port_m. The mote and the application server are
using dedicated ports. The use of a specific single port enables
their elision.
* ts_port_dst_end port_server
* ts_port_dst_end port_server
* ts_dsp_list [ 0 ] the default standard value, we MAY assume that
value has been negotiated via IKEv2 or that it as been set as the
default value left to the lower layers.
Figure 5 illustrates an UDP packet being protected by ESP in the
tunnel mode using AES-CCM_8_IIV. This packet is compressed as
depicted in Figure 6.
EHC reduces the packet size by 53 bytes.
Migault, et al. Expires 9 January 2025 [Page 20]
Internet-Draft EHCP July 2024
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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
U| source port | dest port |d t
D+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| length | checksum || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
-| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |v v
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Standard ESP packet for IoT UDP in Tunnel mode more
with AES- CCM_8_IIV
Migault, et al. Expires 9 January 2025 [Page 21]
Internet-Draft EHCP July 2024
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| Sequence Number | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | aut
| | hen
~ APPLICATION DATA ~ tic
| (encrypted) | ate
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | V
+-+-+-+-+-+-+-+-+ |--
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 6: EHC ESP packet for IoT UDP in Tunnel mode more with
AES-CCM_8_IIV
A.2. Single TCP session IoT VPN
This section is very similar to Appendix A.1 except that a TCP
session is used instead.
The compression on the TCP payload is very limited, and in a case
where the TCP end point is the same as the ESP end point additionnal
compression could be performed. Additional fields such as TCP
options, urgent pointers, the SN and ACK Number could be compressed
by a specific profile agreed at the TCP level as opposed to the ESP
level.
The ESP encapsulated TCP packet described in Figure 7 is compressed
by EHCP using th esam eEHCP context as in Appendix A.1 and EHCP
reduces that packet by 55 bytes, as depicted in Figure 6.
Migault, et al. Expires 9 January 2025 [Page 22]
Internet-Draft EHCP July 2024
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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
T| source port | dest port |d t
C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| Sequence Number (SN) || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| ACK Sequence Number || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
|Off. | Rserv | Flags | Window Size || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| Checksum | Urgent Pointer || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |V V
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Standard ESP packet for IoT TCP in Tunnel mode more
with AES- CCM_8_IIV
Migault, et al. Expires 9 January 2025 [Page 23]
Internet-Draft EHCP July 2024
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Sequence Number (SN) (ESP) | Sequence Number ~ ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
~ (SN) (TCP) | ACK ~^ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| a
~ Sequence Number |Off. | Rserv | Flags || u
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e t
| Window Size | Urgent Pointer |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c |
| Urgent Pointer | |r |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |y |
| ~p |
~ APPLICATION DATA |t |
| || |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| | |v v
+-+-+-+-+-+-+-+-+ |---
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 8: EHC ESP packet for IoT TCP in Tunnel mode more with
AES-CCM_8_IIV
A.3. Traditional VPN
This section illustrates the case of an company VPN that allows web
browsing. The VPN is typically set by a remote host that forwards
all its traffic to the security gateway.
In this case, the SA does not specify the protocol (TCP and UDP
packet can be sent), nor the ports. Regarding ports it could be
possible to restrict the user to only use high range ports (0 - 2 **
10) - especially if the VPN is only supporting web browsing - but we
did not consider this in this example. The destination IP address is
also expect to take any value, while the IPv6 source in the case of a
road warrior scenarios us expected to take a single value. We
consider the VPN client is using an IPv4 or an IPv6 address.
Regarding ESP, we considered the VPN client is using AES-GCM_16,
though AES-GCM_IIV would be the RECOMMENDED transform. The VPN
client is also expected to have a reasonably low throughput which
enables the SN to be coded over 16 bits as opposed to 32 bits.
Similarly, the number of connection is expected to remain
sufficiently low so that a 16 bit SPI remains sufficient.
The EHC Context is defined as mentioned below:
Migault, et al. Expires 9 January 2025 [Page 24]
Internet-Draft EHCP July 2024
* alignment is set to 8 bits
* ipsec_mode is set to "Tunnel"
* tunnel_ip_src is set to the IPv6_user, the IPv6 address of the
mote.
* tunnel_ip_dst is set to IPv6_gw, the IPv6 of the security gateway.
* esp_spi: is agreed by the IKEv2.
* esp_spi_lsb: is set to 2 bytes.
* esp_sn: results from the standard IPsec, and not impacted.
* esp_sn_lsb: is set to 16 bits. Note that such compression is
possible since AES-GCM_16 is used instead of AES-GCM_16_IIV.
While this results in better performances for EHC, it is not an
optimal choice as IIV transforms results always in better
comprehensions.
* esp_encr: is configured with AES-GCM_16 [RFC8750].
* ts_flow_label: is set to True, note as the outer IP address is
IPv6, the compression is lossless.
* ts_ip_version: is set not set as the VPN user can use either an
IPv4 or an IPv6 address.
* ts_ip_src_start: is set to IPv6_user or IPv4_user. Note that the
version can be inferred by the Next Header, and the version can
deterministically determine the IP in use.
* ts_ip_src_end: is set to IPv6_user or IPv4_user
* ts_ip_dst_end: IP destination is set to take any value, so the
range is unspecified and the start/ end addresses are undefined.
* ts_ip_dst_end: undefined.
* ts_proto_list: undefined
* ts_port_src_start: undefined.
* ts_port_src_end: undefined.
* ts_port_dst_end: undefined
Migault, et al. Expires 9 January 2025 [Page 25]
Internet-Draft EHCP July 2024
* ts_port_dst_end: undefined
* ts_dsp_list: [ 0 ] the default standard value, we MAY assume that
value has been negotiated via IKEv2 or that it as been set as the
default value left to the lower layers.
A.4. IPv6 in IPv6
Figure 9 represents the original ESP TCP packet with IPv6 inner IP
addresses and Figure 10 represents the corresponding packet
compressed with EHC.
The compression with Diet-ESP results in a reduction of 32 bytes.
Migault, et al. Expires 9 January 2025 [Page 26]
Internet-Draft EHCP July 2024
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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| IV | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
T| source port | dest port |d t
C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| Sequence Number (SN) || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| ACK Sequence Number || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
|Off. | Rserv | Flags | Window Size || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| Checksum | Urgent Pointer || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
-| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |V V
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| |
| Integrity Check Value-ICV (variable) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Migault, et al. Expires 9 January 2025 [Page 27]
Internet-Draft EHCP July 2024
Figure 9: Standard ESP packet for VPN traffic mode with AES-GCM_16
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 || |
| || |a
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u
| | source port | destination ~|e|t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h
~ port | TCP Sequence Number (SN) ~|c|e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|r|n
~ (continue) | ACK Sequence Number (SN) ~|y|t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|p|i
~ (continue) |Off. | Rserv | Flags | Window ~|t|c
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|a
~ Size | Urgent Pointer | ~|d|t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |e
| || |d
~ APPLICATION DATA ~| |
| || |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || |
| | Next Header | Integrity ~v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---
| |
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Compressed IPv6 in IPv6 ESP packet for VPN traffic
mode with AES- GCM_16
Migault, et al. Expires 9 January 2025 [Page 28]
Internet-Draft EHCP July 2024
Appendix B. JSON format Context
The JSON file defines a set of rules within the SCHC_Context that are
used for compressing and decompressing ESP headers. Each rule has a
RuleID, a Description, and a set of Fields. Each field specifies how
a particular part of the packet should be handled during compression
or decompression. Note that the RuleID can be set by the user in any
numeric order.
Rule 1: Clear Text ESP Compression Rule 1 compresses the fields of
the ESP packet before encryption. The Payload Data field, which is
variable in length, is not sent during compression (CDA: "not-sent").
This means that the data payload itself is excluded from the
compressed packet and will be handled separately. The Padding field,
also variable in length, is computed during decompression to meet
alignment requirements (CDA: "padding"). The Pad Length field is an
8-bit field indicating the length of the padding, and it is sent as-
is (CDA: "value-sent"). The Next Header field, which indicates the
type of the next protocol header, is also an 8-bit field sent without
modification (CDA: "value-sent").
Rule 2: Encrypted ESP Compression Rule 2 focuses on compressing
fields of the ESP packet after encryption. The SPI (Security
Parameters Index) is a 32-bit field that is compressed using the Most
Significant Bits (MSB) technique based on the number of least
significant bytes to be considered (MO: "MSB(4 - esp_spi_lsb)", CDA:
"LSB"). Similarly, the Sequence Number, another 32-bit field, is
compressed using the MSB technique, reducing its size by only sending
the least significant bits as defined in the context (MO: "MSB(4 -
esp_sn_lsb)", CDA: "LSB"). This rule ensures that only the necessary
parts of these large fields are transmitted, reducing the overall
packet size.
Rule 3: Clear Text ESP Decompression Rule 3 handles the decompression
of the clear text fields of the ESP packet after decryption. The
Payload Data field, which is variable in length and was not sent
during compression, is restored in its original form (CDA: "not-
sent"). The Padding field, also variable, is recalculated to ensure
correct alignment as per the network requirements (CDA: "padding").
The Pad Length field, an 8-bit indicator of padding length, is
received as-is (CDA: "value-sent"). Similarly, the Next Header
field, which specifies the next protocol header, is decompressed
directly from the received value (CDA: "value-sent"). This rule
ensures that the original structure of the ESP packet is accurately
reconstructed.
Migault, et al. Expires 9 January 2025 [Page 29]
Internet-Draft EHCP July 2024
Rule 4: Inner Packet Compression Rule 4 is responsible for
compressing the IP source and destination addresses of the inner
packet. The IP Source field is compressed using the MSB technique,
where only the most significant bits that change are sent (MO: "MSB",
CDA: "LSB"). This reduces the amount of data transmitted by
leveraging the static context of the IP addresses. Similarly, the IP
Destination field is compressed using the same MSB technique,
ensuring efficient compression of the IP addresses (MO: "MSB", CDA:
"LSB"). By focusing on the most significant bits, this rule
minimizes the data needed to represent the IP addresses.
Rule 5: Inner Packet Decompression Rule 5 decompresses the IP source
and destination addresses of the inner packet. The IP Source field,
which was compressed using the MSB technique, is decompressed by
reconstructing the full address from the received least significant
bits (MO: "MSB", CDA: "LSB"). The same process applies to the IP
Destination field, where the original address is reconstructed from
the compressed data (MO: "MSB", CDA: "LSB"). This rule ensures that
the IP addresses in the inner packet are accurately restored to their
original form, maintaining the integrity of the packet structure.
removed as it is basic and can be found in SCHC RFC8724:
## Detailed Field Explanation
Each field in the rules has the following properties:
- FieldID: The identifier of the field.
- FL: Field length, which can be fixed (e.g., 8, 32 bits) or variable.
- FP: Field position in the packet.
- DI: Direction indicator (Up for outbound, Down for inbound).
- TV: Target value, used for matching during compression/decompression.
- MO: Matching operator, which specifies how to match the field (ignore, MSB, etc.).
- CDA: Compression/Decompression action, which defines what to do with the field (e.g., not-sent, padding, value-sent, LSB).
Alignment: Ensures that the length of the compressed data plus
padding aligns correctly according to network requirements. Padding
and Pad Length: Handled dynamically based on alignment and the length
of the payload data.
For Rule 1, ignoring PadLen and Padding is an optimal choice when
possible, but it is not always feasible as IPv6 typically requires
ESP to have a 32-bit alignment. The alignment is determined by the
network's requirements. We have:
len(Payload Data) + len(Padding) + len(Pad Length) + len(Next Header)
= 0 mod ALIGN
Migault, et al. Expires 9 January 2025 [Page 30]
Internet-Draft EHCP July 2024
* len(Next Header) = 1 or 0 if compressed. It can be compressed if
the type of inner packet is known. For example, in Tunnel mode,
the IP range determines if it is an IPv6 or IPv4 packet. In
Transport mode, the upper layer protocol type (TCP or UDP)
determines this.
* Payload Data has been compressed by IIPC.
* len(Padding) = Pad Length
If alignment is set to 8 bits:
len(Padding) = Pad Length = 0 len(Pad Length) = 0
Otherwise: - If Compressed Payload Data has a fixed size:
len(Pad Length) = 0 len(Padding) = Pad Length = ALIGN - len(Payload
Data) - len(Next Header) mod ALIGN
* Otherwise:
len(Pad Length) = 1 len(Padding) = Pad Length = ALIGN - len(Payload
Data) - 1 - len(Next Header) mod ALIGN
Overall, this means that the SCHC_Context is dynamically generated
from the EHCP Context. Additionally, a rule is required to compress
the inner packet. IP source and IP destination should be compressed
using LSB.
{
"SCHC_Context": {
"Rules": [
{
"RuleID": 1,
"Description": "Clear Text ESP Compression",
"Fields": [
{
"FieldID": "Payload Data",
"FL": "variable",
"FP": 1,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "not-sent"
},
{
"FieldID": "Padding",
"FL": "variable",
Migault, et al. Expires 9 January 2025 [Page 31]
Internet-Draft EHCP July 2024
"FP": 2,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "padding"
},
{
"FieldID": "Pad Length",
"FL": 8,
"FP": 3,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
},
{
"FieldID": "Next Header",
"FL": 8,
"FP": 4,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
}
]
},
{
"RuleID": 2,
"Description": "Encrypted ESP Compression",
"Fields": [
{
"FieldID": "SPI",
"FL": 32,
"FP": 1,
"DI": "Up",
"TV": null,
"MO": "MSB(4 - esp_spi_lsb)",
"CDA": "LSB"
},
{
"FieldID": "Sequence Number",
"FL": 32,
"FP": 2,
"DI": "Up",
"TV": null,
"MO": "MSB(4 - esp_sn_lsb)",
"CDA": "LSB"
}
Migault, et al. Expires 9 January 2025 [Page 32]
Internet-Draft EHCP July 2024
]
},
{
"RuleID": 3,
"Description": "Clear Text ESP Decompression",
"Fields": [
{
"FieldID": "Payload Data",
"FL": "variable",
"FP": 1,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "not-sent"
},
{
"FieldID": "Padding",
"FL": "variable",
"FP": 2,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "padding"
},
{
"FieldID": "Pad Length",
"FL": 8,
"FP": 3,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
},
{
"FieldID": "Next Header",
"FL": 8,
"FP": 4,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
}
]
},
{
"RuleID": 4,
"Description": "Inner Packet Compression",
"Fields": [
Migault, et al. Expires 9 January 2025 [Page 33]
Internet-Draft EHCP July 2024
{
"FieldID": "IP Source",
"FL": "variable",
"FP": 1,
"DI": "Up",
"TV": "msb(ip_src)",
"MO": "MSB",
"CDA": "LSB"
},
{
"FieldID": "IP Destination",
"FL": "variable",
"FP": 2,
"DI": "Up",
"TV": "msb(ip_dst)",
"MO": "MSB",
"CDA": "LSB"
}
]
},
{
"RuleID": 5,
"Description": "Inner Packet Decompression",
"Fields": [
{
"FieldID": "IP Source",
"FL": "variable",
"FP": 1,
"DI": "Down",
"TV": "msb(ip_src)",
"MO": "MSB",
"CDA": "LSB"
},
{
"FieldID": "IP Destination",
"FL": "variable",
"FP": 2,
"DI": "Down",
"TV": "msb(ip_dst)",
"MO": "MSB",
"CDA": "LSB"
}
]
}
]
}
}
Migault, et al. Expires 9 January 2025 [Page 34]
Internet-Draft EHCP July 2024
Authors' Addresses
Daniel Migault
Ericsson
Email: daniel.migault@ericsson.com
Maryam Hatami
Concordia University
Email: maryam.hatami@mail.concordia.ca
Sandra Cespedes
Concordia University
Email: sandra.cespedes@concordia.ca
J. William Atwood
Concordia University
Email: william.atwood@concordia.ca
Tobias Guggemos
LMU
Email: guggemos@nm.ifi.lmu.de
Carsten Bormann
Universitaet Bremen TZI
Email: cabo@tzi.org
David Schinazi
Google LLC
Email: dschinazi.ietf@gmail.com
Migault, et al. Expires 9 January 2025 [Page 35]