IPsecme D. Migault
Internet-Draft Ericsson
Intended status: Standards Track M. Hatami
Expires: 30 July 2025 S. Céspedes
W. Atwood
Concordia University
D. Liu
Ericsson
T. Guggemos
LMU
C. Bormann
Universitaet Bremen TZI
D. Schinazi
Google LLC
26 January 2025
ESP Header Compression Profile
draft-ietf-ipsecme-diet-esp-04
Abstract
The document specifies Diet-ESP, an ESP Header Compression Profile
(EHCP) that compresses IPsec/ESP communications using Static Context
Header Compression (SCHC).
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 30 July 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Migault, et al. Expires 30 July 2025 [Page 1]
Internet-Draft EHCP January 2025
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 . . . . . . . . . . . . 7
4.1. SCHC Parameters for Diet-ESP . . . . . . . . . . . . . . 9
4.2. Set of Rules (SoR) for Diet-ESP . . . . . . . . . . . . . 10
4.3. Attributes for Rules Generation . . . . . . . . . . . . . 10
4.3.1. Compression/Decompression Actions in Diet-ESP . . . . 16
5. SCHC Compression for IPsec in Tunnel mode . . . . . . . . . . 17
5.1. Inner IP Compression (IIPC) . . . . . . . . . . . . . . . 17
5.1.1. Inner IP Payload Compression . . . . . . . . . . . . 17
5.1.2. Inner IPv6 Header Compression . . . . . . . . . . . . 17
5.1.3. Inner IPv4 Header Compression . . . . . . . . . . . . 19
5.2. ESP Payload Data Byte Alignment . . . . . . . . . . . . . 20
5.3. Clear Text ESP Compression (CTEC) . . . . . . . . . . . . 20
5.4. Encrypted ESP Compression (EEC) . . . . . . . . . . . . . 21
6. SCHC Compression for IPsec in Transport mode . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 26
A.1. JSON Representation of SCHC Rules for Diet-ESP Header
Compression . . . . . . . . . . . . . . . . . . . . . . . 27
A.2. Example Outcome . . . . . . . . . . . . . . . . . . . . . 29
A.2.1. Input Packet . . . . . . . . . . . . . . . . . . . . 29
A.2.2. Compression Process . . . . . . . . . . . . . . . . . 29
A.2.3. Decompression Process . . . . . . . . . . . . . . . . 30
A.2.4. Final Output Packet . . . . . . . . . . . . . . . . . 31
A.2.5. GitHub Repository: Diet-ESP SCHC Implementation . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Migault, et al. Expires 30 July 2025 [Page 2]
Internet-Draft EHCP January 2025
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 is part
of the IPsec [RFC4301] suite of protocols and 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.
An ESP packet is composed of the ESP Header, the ESP Payload, the ESP
Trailer, and the Integrity Check Value (ICV). ESP has two modes of
operation: Transport and Tunnel. In Transport mode, the ESP Payload
consists of the payload of the original IP packet; the ESP Header is
inserted after the original IP packet header. In Tunnel mode,
commonly used for VPNs, the ESP Header is placed after an outer IP
header and before the inner IP packet headers of the original
datagram. This ensures both the original IP headers and payload are
protected. Consequently, the ESP Payload field contains either the
payload from the original IP packet or the fully-encapsulated IP
packet, in transport mode or tunnel mode, respectively.
The ESP Trailer, placed at the end of the encrypted payload, includes
fields such as Padding and Pad Length to ensure proper alignment, and
Next Header to indicate the protocol following the ESP header. The
ICV, calculated over the ESP Header, ESP Payload, and ESP Trailer, is
appended after the ESP Trailer to ensure packet integrity. For a
simplified overview of ESP, readers are referred to Minimal ESP
[RFC9333].
While ESP is effective in securing traffic, further optimization can
reduce packet sizes, enhancing performance in networks with limited
bandwidth. In such environments, reducing the size of transmitted
packets is essential to improve efficiency. This document defines
the ESP Header Compression Profile (EHCP), namely Diet-ESP, for
compression/decompression (C/D) of IPsec/ESP [RFC4301] / [RFC4303]
packets using the Static Context Header Compression and Fragmentation
(SCHC) framework [RFC8724]. The structure of Diet-ESP is shown in
Figure 1. Compression with SCHC is based on one or more SCHC
instances, each with its Set of Rules (SoR) for C/D operations
[I-D.ietf-schc-architecture]. In the case of IPsec, the SoR and the
Migault, et al. Expires 30 July 2025 [Page 3]
Internet-Draft EHCP January 2025
Set of Variables (SoR) for a SCHC session can be agreed via IKEv2
[RFC7296] and its specific extension
[I-D.ietf-ipsecme-ikev2-diet-esp-extension].
As a result of the application of the same SoR, header values shared
by the end-points do not need to be sent on the wire. At the
receiver, header information is re-generated from the received
compressed packet and the application of the proper SoR retrieved
from the SCHC Instance.
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 defines the application of the SCHC Architecture for
ESP Header Compression. C/D operations occur at various layers of
the IPsec stack, where each layer is treated in this document as a
SCHC Stratum. Diet-ESP operates over three strata, defined as
follows:
Migault, et al. Expires 30 July 2025 [Page 4]
Internet-Draft EHCP January 2025
1. Inner IP Compression (IIPC): The SCHC Payload Instance used in
this stratum applies its SoR directly to the headers of 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. The compressed inner IP packet becomes the
Payload portion of the SCHC Packet, comprising the RuleID and the
Compressed Residue (i.e., compression residue plus the inner IP
packet payload). If no compression of the inner packet is
possible, the No Compression rule is used and the uncompressed IP
packet is placed in the Compressed Residue. The resulting SCHC
packet may contain a SCHC Header generated with the SoR defined
in the SCHC Header Instance.
2. Clear Text ESP Compression (CTEC): This SCHC stratum containes a
SCHC Payload Instance with the SoR used to compress the fields of
the ESP Clear Text Packet, right before being encrypted, as the
encapsulated traffic in tunnel mode. The resulting SCHC packet
does not contain a SCHC Header since the encryption at the next
layer occurs in the same entity.
3. Encrypted ESP Compression (EEC): This SCHC stratum contains a
SCHC Payload Instance with the SoR to compress the ESP packet
fields that remain visible after encryption, that is, the ESP
Header. The resulting SCHC packet may contain a SCHC Header
generated with the SoR defined in the SCHC Header Instance.
Note that the descriptions of the three SCHC strata provided in this
document meet the general purpose of ESP. It is possible that in
some deployments, the SCHC instances from different SCHC layers can
be merged. Typically, a specific implementation may merge the
compression of IIPC and CTEC layers.
The Rules of type C/D describe the behavior of each header field in
the ESP header.A SCHC Session manager provides the management of SCHC
Instances with a definition of how the SoR and the SoV are
initialized from the SA (i.e., RuleID, SCHC MAX_PACKET_SIZE, new SCHC
Compression/Decompression Actions (CDA), and fragmentation). The
appendix provides illustrative examples of applications of Diet-ESP
implemented with the OpenSCHC [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.
ESP Trailer: A set of fields added at the end of the ESP payload,
Migault, et al. Expires 30 July 2025 [Page 5]
Internet-Draft EHCP January 2025
including Padding, Pad Length, and Next Header, used to ensure
alignment and indicate the next protocol.
SCHC Stratum: Refers to the specific layer where SCHC operates with
the Set of Rules of a SCHC instance. In this document, each SCHC
Stratum covers different parts of the ESP packet structure for
compression and decompression purposes.
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, which include the ESP Data and ESP Trailer.
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 Rule part of the Set of Rules.
SCHC Parameters: A set of predefined values used for SCHC
compression and decompression, ensuring byte alignment and proper
packet formatting based on the SCHC profile.
SCHC MAX_PACKET_SIZE: The maximum size of a SCHC-compressed packet
that can be transmitted without fragmentation.
Traffic Selector (TS): A set of parameters (e.g., IP address range,
port range, and protocol) used to define which traffic should be
protected by a specific Security Association (SA).
It is assumed that the reader is familiar with other SCHC terminology
defined in [RFC8376], [RFC8724], and [I-D.ietf-schc-architecture].
Migault, et al. Expires 30 July 2025 [Page 6]
Internet-Draft EHCP January 2025
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 architecture, to optimize the ESP
header sizes for better efficiency in constrained environments.
Figure 2 illustrates the integration of SCHC into the IPsec stack,
detailing the different layers and components involved in the
compression and decompression processes. The diagram is divided into
two entities, each representing an endpoint of a communication link.
Compression rules are derived from Security Association (SA)
parameters negotiated through IKEv2 [RFC7296], such as Traffic
Selectors (TS) and IPsec mode, as well as additional parameters
explicitly defined in this document as Attributes for Rules
Generation (AfRG) (see Section 4.3). While TS and IPsec mode serve
as inputs for compression, they are not traditionally categorized as
AfRG. This document introduces the concept of AfRG to unify these
inputs and define the compression process. To facilitate complete
negotiation, any remaining AfRG parameters requiring explicit
agreement are addressed through the IKEv2 extension
[I-D.ietf-ipsecme-ikev2-diet-esp-extension].
Upon establishing the SA, Diet-ESP uses the AfRGs listed in Table 1
for derivation of the SoR applicable to the SCHC Instance of a given
stratum. The reference column in Table 1 indicates the source where
the parameter value is defined. The C/D column specifies in which of
the SCHC strata the parameter is being used.
EHCP defines three SCHC strata for compression: Inner IP Compression
(IIPC), Clear Text ESP Compression (CTEC), and Encrypted ESP
Compression (EEC). The compression operations for each stratum are
described in Section 5.1, Section 5.3, and Section 5.4.
EHCP essentially limits the scope of the compression to the inner IP
headers and specific fields such as ports and checksums of transports
like UDP, UDP-Lite, TCP, SCTP. Further and more specific compression
profiles may be defined in the future to cover compression of headers
of different upper layer protocols.
Migault, et al. Expires 30 July 2025 [Page 7]
Internet-Draft EHCP January 2025
At the receiver endpoint, 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 that the outputs will be the same.
+----------------------------------------+
| ESP Header Compression Session Manager |
| - Security Association |
| - Additional Parameters |
+----------------------------------------+
|
Endpoint | Endpoint
|
+-----------------+ | +-----------------+
| Inner IP packet | | | Inner IP packet |
+-----------------+ | +-----------------+
| SCHC(IIP + UDP | | | SCHC(IIP + UDP |
| or ...) |+--------IIPC layer-----------+| or ...) |
+-----------------+ C {IIP} +-----------------+
| ESP | | | ESP |
| (Encapsulation) | | | (unwrapping) |
+-----------------+ | +-----------------+
| SCHC | v | SCHC |
| (ESP Clear Text | | (ESP Clear Text |
| Packet) |+--------- CTEC layer --------+| Packet) |
+-----------------+ EH, C {C {IIP}, ET} +-----------------+
| ESP | | | ESP |
| (Encryption) | | | (decryption) |
+-----------------+ v +-----------------+
| SCHC(ESP Header)|+--------- EEC layer ---------+| SCHC(ESP Header)|
+-----------------+ 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 IPsec in tunnel mode. C designates the Compressed
header for the fields inside. IIP refers to the Inner IP packet,
EH refers to the ESP Header, and ET refers to the ESP Trailer.
The labels “SCHC (IIPC: Compress Inner IP),†“SCHC (CTEC:
Compress Trailer),†and “SCHC (EEC: Compress ESP Header)†are
added to indicate that different SCHC instances are applied at
the IIPC, CTEC, and EEC layers, respectively.
Migault, et al. Expires 30 July 2025 [Page 8]
Internet-Draft EHCP January 2025
4.1. SCHC Parameters for Diet-ESP
The SCHC Payload section of a compressed SCHC packet is always in the
form:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+---------...----------+~~~~~~~~~+---------------+
| RuleID | Compression Residue | Payload | SCHC padding |
+-+-+-+-+-+-+-+---------...----------+~~~~~~~~~+---------------+
|-------- Compressed Header ---------| |-- as needed --|
Figure 3: Diet-ESP Compressed Header Format
The SCHC Profile for Diet-ESP is defined as follows:
RuleID: The RuleID is a unique identifier for each SCHC rule. It is
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. The RuleID in
Diet-ESP is expressed as 1 byte.
Maximum Packet Size: MAX_PACKET_SIZE is determined by the specific
IPsec ESP configuration and the underlying transport, but it is
typically aligned with the network’s MTU. The size constraints
are optimized based on the available link capacity and negotiated
parameters between endpoints.
SCHC Padding: Padding in SCHC is used to align data to a specific
boundary (typically byte-aligned or 8-bit aligned) to meet the
requirements of the underlying link layer protocol or encryption
algorithm. Padding bits are often zero or follow a pattern but do
not contain significant data. In Diet-ESP, the SCHC padding is
added in the CTEC strata to align the packet for encryption.
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
dependent on the layer 2 technology.
Figure 4 illustrates how the final compressed packet looks when using
SCHC compression for ESP headers in the Diet-ESP profile.
Migault, et al. Expires 30 July 2025 [Page 9]
Internet-Draft EHCP January 2025
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCHC EEC Header (EEC stratum) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| SCHC CTEC Header (CTEC stratum) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SCHC IIP Header (IIPC stratum) | |
+---------------------------------------------------------------+ En-
| Inner IP Payload Data* (variable) | cry-
~ ~ pted
| | |
+---------------------------------------------------------------+ |
| SCHC CTEC Padding | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| |
| ICV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Diet-ESP Compressed Packet Format with SCHC
4.2. Set of Rules (SoR) for Diet-ESP
SCHC SoR are predefined sets of instructions that specify how to
compress and decompress the header fields of an ESP packet. The
identification of a particular SoR will follow the specification in
[I-D.ietf-schc-architecture].
A rule describes all the header fields required for a certain
transformation (e.g., compression, decompression, fragmentation,
reassembly, etc). The fields are identified by a Field ID (FID).
Fields may include a Direction Indicator (DI), which in Diet-ESP is
set to Up for an outbound SA and Down for an inbound SA. Each field
also contains a Field Position parameter that is set to 1, unless
specified otherwise.
4.3. Attributes for Rules Generation
The list of attributes for the Rules Generation (AfRG) is shown in
Table 1. These attributes are used to express the various
compressions that operate at the IIPC, CTEC, and EEC layers.
As outlined in Section 4, this specification does not detail the
process by which the AfRG are established between peers. Instead,
such negotiations are addressed in
[I-D.ietf-ipsecme-ikev2-diet-esp-extension]. However, the AfRG can
be classified into two distinct categories. The first category
encompasses AfRG that are negotiated through a specific IKEv2
Migault, et al. Expires 30 July 2025 [Page 10]
Internet-Draft EHCP January 2025
extension tailored for the negotiation of AfRG linked to a particular
profile, the Diet-ESP profile in this context. The AfRG referenced
in Table 1 in this category are: the DSCP Compression/Decompression
Action (CDA) dscp_cda, the ECN CDA ecn_cda, the Flow Label CDA
flow_label_cda, the ESP alignment alignment, the ESP SPI Least
Significant Bits (LSB) esp_spi_lsb, and the ESP Sequence Number LSB
esp_sn_lsb.
The second category pertains to AfRG that are negotiated through
IKEv2 exchanges or extensions that are not specifically designed for
compression purposes. This category includes AfRG associated with
TS, as identified in Table 1, which are the TS IP Version
ts_ip_version, the TS IP Source Start ts_ip_src_start, the TS IP
Source End ts_ip_src_end, the TS IP Destination Start
ts_ip_dst_start, the TS IP Destination End ts_ip_dst_end, the TS
Protocol ts_proto, the TS Port Source Start ts_port_src_start, the TS
Port Source End ts_port_src_end, the TS Port Destination Start
ts_port_dst_start, and the TS Port Destination End ts_port_dst_end.
These AfRG are derived from the Traffic Selectors established through
TSi/TSr payloads during the IKEv2 CREATE_CHILD_SA exchange, as
described in [RFC7296], Section 3.13. The AfRG IPsec Mode designated
as ipsec_mode in Table 1 is determined by the presence or absence of
the USE_TRANSPORT_MODE Notify Payload during the CREATE_CHILD_SA
exchange, as detailed in [RFC7296], Section 1.3.1. The AfRG Tunnel
IP designated as tunnel_ip in Table 1 is obtained from the IP address
of the IKE messages exchanged during the CREATE_CHILD_SA process, as
noted in [RFC7296], Section 1.1.3. The AfRGs designated as ESP
Encryption Algorythm esp_encr and ESP Security Parameter Index (SPI)
esp_spi in Table 1 are established through the SAi2/SAr2 payloads
during the CREATE_CHILD_SA exchange, while the AfRG designated as ESP
Sequence Number esp_sn in Table 1 is initialized upon the creation of
the Child SA and incremented for each subsequent ESP message.
The ability to derive the SoR for the IIPC from the agreed Traffic
Selectors is indicated by the variable iipc_profile.
+===================+========================+===========+=========+
| Variable | Possible Values | Reference | Stratum |
+===================+========================+===========+=========+
| iipc_profile | "iipc_diet-esp", | ThisRFC | N/A |
| | "iipc_uncompress" | | |
+-------------------+------------------------+-----------+---------+
| dscp_cda | "uncompress", "lower", | ThisRFC | IIPC |
| | "sa" | | |
+-------------------+------------------------+-----------+---------+
| ecn_cda | "uncompress", "lower" | ThisRFC | IIPC |
+-------------------+------------------------+-----------+---------+
| flow_label_cda | "uncompress", "lower", | ThisRFC | IIPC |
Migault, et al. Expires 30 July 2025 [Page 11]
Internet-Draft EHCP January 2025
| | "generated", "zero" | | |
+-------------------+------------------------+-----------+---------+
| ts_ip_version | "IPv4-only", | RFC7296 | IIPC |
| | "IPv6-only" | | |
+-------------------+------------------------+-----------+---------+
| ts_ip_src_start | IPv4 or IPv6 address | RFC7296 | IIPC |
+-------------------+------------------------+-----------+---------+
| ts_ip_src_end | IPv4 or IPv6 address | RFC7296 | IIPC |
+-------------------+------------------------+-----------+---------+
| ts_ip_dst_start | IPv4 or IPv6 address | RFC7296 | IIPC |
+-------------------+------------------------+-----------+---------+
| ts_ip_dst_end | IPv4 or IPv6 address | RFC7296 | IIPC |
+-------------------+------------------------+-----------+---------+
| ts_proto | TCP, UDP, UDP-Lite, | RFC7296 | IIPC |
| | SCTP, ANY, ... | | |
+-------------------+------------------------+-----------+---------+
| ts_port_src_start | Port number | RFC7296 | IIPC |
+-------------------+------------------------+-----------+---------+
| ts_port_src_end | Port number | RFC7296 | IIPC |
+-------------------+------------------------+-----------+---------+
| ts_port_dst_start | Port number | RFC7296 | IIPC |
+-------------------+------------------------+-----------+---------+
| ts_port_dst_end | Port number | RFC7296 | IIPC |
+-------------------+------------------------+-----------+---------+
| dscp_list | list of DSCP numbers | RFCYYYY | IIPC |
+-------------------+------------------------+-----------+---------+
| alignment | "8 bit", "16 bit", "32 | ThisRFC | CTEC |
| | bit", "64 bit" | | |
+-------------------+------------------------+-----------+---------+
| ipsec_mode | "Tunnel", "Transport" | RFC4301 | CTEC |
+-------------------+------------------------+-----------+---------+
| tunnel_ip | IPv4 or IPv6 address | RFC4301 | CTEC |
+-------------------+------------------------+-----------+---------+
| esp_encr | ESP Encryption | RFC4301 | CTEC |
| | Algorithm | | |
+-------------------+------------------------+-----------+---------+
| esp_spi | ESP SPI | RFC4301 | EEC |
+-------------------+------------------------+-----------+---------+
| esp_spi_lsb | 0-32 | ThisRFC | EEC |
+-------------------+------------------------+-----------+---------+
| esp_sn | ESP Sequence Number | RFC4301 | EEC |
+-------------------+------------------------+-----------+---------+
| esp_sn_lsb | 0-32 | ThisRFC | EEC |
+-------------------+------------------------+-----------+---------+
Table 1: Set of Variables to establish Diet-ESP SCHC sessions in
Diet-ESP
Migault, et al. Expires 30 July 2025 [Page 12]
Internet-Draft EHCP January 2025
Any variable starting with "ts_" is associated with the Traffic
Selectors (TSi/TSr) of the SA. The notation is introduced by this
specification but the definitions of the variables are in [RFC4301]
and [RFC7296].
The Traffic Selectors may result in a quite complex expression, and
this specification restricts that complexity. This specification
restricts the resulting TSi/TSr to a single type of IP address (IPv4
or IPv6), a single protocol (e.g., UDP, TCP, or ANY), a single port
range for source and destination. This specification presumes that
the Traffic Selectors can be articulated as a result of
CREATE_CHILD_SA with only one Traffic Selector [RFC7296],
Section 3.13.1 in both TSi and TSr payloads (as described in
[RFC7296], Section 3.13). The TS Type MUST be either
TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE.
Let the resulting Trafic Selectors TSi/TSr be expressed via the
Traffic Selector structure defined in [RFC7296], Section 3.13.1. We
designate the local TS the TS - either TSi or TSr - sent by the local
peer. Conversely we designate as remote TS the TS - either TSi or
TSr - sent by the remote peer.
The details of each parameter are the following:
iipc_profile: designates the behavior of the IIPC layer. When set
to "iipc_uncompress" IIPC is not performed. This specification
describes IIPC that corresponds to the "iipc_diet-esp" profile.
flow_label_cda: indicates the Flow Label CDA, that is how the Flow
Label field of the inner IPv6 packet or the Identification field
of the inner IPv4 packet is compressed / decompressed - See
Section 4.3.1 for more information. In a nutshell, "uncompress"
indicates that Flow Label (resp. Identification) are not
compressed. "lower" indicates the value is read from the outer IP
header - eventually with some adaptations when inner IP packet and
outer IP packets have different versions. "generated" indicates
that the field is generated by the receiving party. In that case,
the decompressed value may take a different value compared to its
original value. "zero" indicates the field is set to zero.
dscp_cda: indicates the DSCP CDA, that is how the DSCP values of the
inner IP packet are compressed / decompressed - See Section 4.3.1
for more information. In a nutshell, "uncompress" indicates that
DSCP are not compressed. "lower" indicates the value is read from
the outer IP header - eventually with some adaptations when inner
IP packet and outer IP packets have different versions. "sa"
indicates, compression is performed according to the DSCP values
agreed by the SA (dscp_list).
Migault, et al. Expires 30 July 2025 [Page 13]
Internet-Draft EHCP January 2025
ecn_cda: indicates ECN CDA, that is how the ECN values of the inner
IP packet are compressed / decompressed - See Section 4.3.1 for
more information. In a nutshell, "uncompress" indicates that DSCP
are not compressed. "lower" indicates the value is read from the
outer IP header - eventually with some adaptations when inner IP
packet and outer IP packets have different versions.
ts_ip_version: designates the TS IP version. Its value is set to
"IPv4-only" when only IPv4 IP addresses are considered and to
"IPv6-only" 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. If TS Type of the resulting TSi/TSr
is set to TS_IPV4_ADDR_RANGE, ts_ip_version takes the value
"IPv4-only". Respectively, if TS Type is set to
TS_IPV6_ADDR_RANGE, ts_ip_version is set to "IPv6-only".
ts_ip_src_start: designates the TS IP Source Start, that is the
starting value range of source IP addresses of the inner packet
and has the same meaning as the Starting Address field of the
local TS.
ts_ip_src_end: designates TS IP Source End that is 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 local TS.
ts_ip_dst_start: designates the TS IP Destination Start, that is the
starting value range of destination IP addresses of the inner
packet and has the same meaning as the Starting Address field of
the remote TS.
ts_ip_dst_end: designates the TS IP Destination End, that is the
high end value range of destination IP addresses of the inner
packet and has the same meaning as the Ending Address field of the
remote TS.
ts_proto: designates the TS Protocol, that is the Protocol ID of the
resulting TSi/TSr. This profile considers the specific protocol
values "TCP", "UDP", "UDP-Lite", "SCTP" and "ANY". The
representation of "ANY" is given in [RFC4301], Section 4.4.4.2.
ts_port_src_start: designates the TS Port Source Start, that is the
the starting value of the source port range of the inner packet
and has the same meaning as the Start Port field of the local TS.
ts_port_src_end: designates the TS Port Source End, that is the high
end value range of the source port range of the inner packet and
has the same meaning as the End Port field of the local TS.
Migault, et al. Expires 30 July 2025 [Page 14]
Internet-Draft EHCP January 2025
ts_port_dst_start: designates TS Port Destination Start, that is the
starting value of the destination port range of the inner packet
and has the same meaning as the Start Port field of the remote TS.
ts_port_dst_end: designates TS Port Destination End, that is the
high end value range of the destination port range of the inner
packet and has the same meaning as the End Port field of the
remote TS.
IP addresses and ports are defined as a range and compressed using
the Least Significant Bits (LSB). For a range defined by start and
end values, msb( start, end ) is defined as the function that returns
the Most Significant Bits (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.
dscp_list: designates the list of DSCP values associated to the
inner traffic - see for example [I-D.mglt-ipsecme-dscp-np]. These
are not Traffic Selectors, but the compression mandates that the
packets take one of these listed DSCP values.
alignment: designates the ESP alignment as defined by [RFC4303].
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 Tunnel 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_encr: designates the ESP Encryption Algorithm - also designated
as Transform 1 in [RFC7296], Section 3.3.2. The algorithm is
needed to determine whether the ESP Payload Data needs to be
aligned to some predefined block size and if the ESP Pad Length
and Padding fields can be compressed. For the purpose of
compression it is RECOMMENDED to use algorithms that already
compressed their IV [RFC8750].
esp_spi: designates the Security Parameter Index defined in
[RFC4301].
esp_spi_lsb: designates the LSB to be considered for the compressed
SPI. A value of 32 for esp_spi_lsb will leave the SPI unchanged.
esp_sn: designates the ESP Sequence Number (SN) field defined in
Migault, et al. Expires 30 July 2025 [Page 15]
Internet-Draft EHCP January 2025
[RFC4301].
esp_sn_lsb: designates the LSB to be considered for the compressed
SN. It works similarly to ESP SPI LSB (see esp_spi_lsb).
4.3.1. Compression/Decompression Actions in Diet-ESP
In addition to the Compression/Decompression Actions (CDAs) defined
in [RFC8724], Section 7.4, this specification uses the CDAs presented
in Table 2. These CDAs are either a refinement of the compute- * CDA
or the result of a combined CDA.
+========================+=============+======================+
| Action | Compression | Decompression |
+========================+=============+======================+
| lower | elided | Get from lower layer |
+------------------------+-------------+----------------------+
| generated (Flow Label) | elided | Compute flow label |
+------------------------+-------------+----------------------+
| checksum | elided | Compute checksum |
+------------------------+-------------+----------------------+
| ESP padding | elided | Compute padding |
+------------------------+-------------+----------------------+
| hop limit | elided | Get from lower layer |
+------------------------+-------------+----------------------+
| SCHC padding | send | Compute padding |
+------------------------+-------------+----------------------+
Table 2: EHCP ESP related parameter
lower: is only used in a Tunnel Mode and indicates that the fields
of the inner IP packet header are generated from the corresponding
fields of the Tunnel IP header fields. This CDA can be used for
the DSCP, ECN, and IPv6 Flow Label (resp. IPv4 identification)
fields.
generated: indicates that a brand new Flow Label/Identification
field is generated following [RFC6437], [RFC6864].
checksum: indicates that a checksum is computed accordingly.
Typically, the checksum CDA has a different implementation for
IPv4, UDP, TCP,...
ESP padding: indicates that the ESP padding bytes are generated
accordingly.
hop limit: indicates that the hop limit is derived from the outer
IPv6 header.
Migault, et al. Expires 30 July 2025 [Page 16]
Internet-Draft EHCP January 2025
SCHC padding: indicates that the SCHC padding bits are generated
accordingly.
5. SCHC Compression for IPsec in Tunnel mode
5.1. Inner IP Compression (IIPC)
When iipc_profile is set to "iipc_uncompress", the packet is
uncompressed. When iipc_profile is set to "iipc_diet-esp", IIPC
proceeds to the compression of the inner IP Packet composed of an IP
Header and an IP Payload. The compression of the inner IP Payload is
described in Section 5.1.1.
The IP Header is compressed when ipsec_mode is set to "Tunnel" and
left uncompressed otherwise. ts_ip_version determines how the IPv6
Header (resp. the IPv4 header) is compressed - see Section 5.1.2
(resp. Section 5.1.3).
5.1.1. Inner IP Payload Compression
The compression only affects UDP, UDP-Lite, TCP or SCTP packets and
the type of packet is determined by the IP header.
For UDP, UDP-Lite, TCP and SCTP packets, source ports, destination
ports, and checksums are compressed. For source port (resp.
destination port) only the least significant bits are sent. FL is
set to 16 bits, TV is set to msb( ts_port_src_start, ts_port_src_end
) ( resp. ts_port_dst_start, ts_port_dst_end ), MO is set to "MSB"
and CDA to "LSB". The checksum is elided, FL is set to 16 bits, 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.
For UDP or UDP-Lite the length field is elided. FL is set to 16, TV
is not set, MO is set to "ignore".
5.1.2. Inner IPv6 Header Compression
The version field is elided, FL is set to 3, TV is set to
ts_ipversion, MO is set to "equal" and CDA is set to "not-sent".
Traffic Class is composed of the 6 bit DSCP and 2 bit ECN. The
compression of DSCP and ECN are defined independently.
DSCP values are compressed according to the dscp_cda value:
Migault, et al. Expires 30 July 2025 [Page 17]
Internet-Draft EHCP January 2025
* If dscp_cda is set to "uncompress", the DSCP values are included
in the inner IP header. FL is set to 6 bits, TV is not set, MO is
set to "ignore", CDA is set to "sent-value".
* If dscp_cda is set to "lower", the DSCP field is elided and its
value is copied from the Tunnel IP header. FL is set to 6 bits,
TV is not set, MO is set to "ignore", CDA is set to "lower".
* If dscp_cda is set to "sa", DSCP is compressed according to the
DSCP values of the SA. If dscp_list contains a single element,
the DSCP is elided, FL is set to 6 bits, TV is set to
dscp_list[0], MO is set to "equal" and CDA is set to "not-sent".
If dscp_list contains more than one DSCP value, FL is set to 6
bits, TV is set to dscp_list, MO is set to "match-mapping" and the
CDA is set to "mapping-sent". For ECN, FL is set to 2 bits, TV is
not set, MO is set to ignore and CDA is set to "value-sent".
ECN values are compressed according to the ecn_cda value:
* If ecn_cda is set to "uncompress", the ECN field is included in
the inner IP header. FL is set to 2 bits, TV is not set, MO is
set to "ignore", CDA is set to "sent-value".
* If ecn_cda is set to "lower", the ECN value is elided and the ECN
value is copied in the outer IP header. FL is set to 2 bits, TV
is not set, MO is set to "ignore", CDA is set to "lower".
Flow label is compressed according to the flow_label_cda value:
* If flow_label_cda is set to "uncompress", the Flow label is
included in the IPv6 Header. FL is set to 20 bits, TV is not set,
MO is set to "ignore", and CDA is set to "sent-value".
* If flow_label_cda is set to "lower", the Flow Label is elided and
read from the outer IP Header (See Section 4.3.1). FL is set to
20 bits, TV is not set, MO is set to "ignore", and CDA is set to
"lower". If the outer IP header is an IPv4 header, only the 16
LSB of the Flow Label are inserted into the IPv4 Header. At the
decompression, the 4 MSB of the Flow Label are set to 0.
* If flow_label_cda is set to "generated", the Flow Label is elided
and the Flow Label is then re-generated at the decompression (See
Section 4.3.1). The resulting Flow Label differs from the initial
value. FL is set to 20, TV is not set, MO is set to "ignore" and
CDA is set to "generated".
Migault, et al. Expires 30 July 2025 [Page 18]
Internet-Draft EHCP January 2025
* If flow_label_cda is set to "zero", the Flow Label is elided and
set to 0 at decompression. A 0 value indicates no flow label is
present. Fl is set to 20 bits, TV is set to 0, MO is set to
"equal" and CDA is set to "not-sent".
Payload Length is elided and determined from the Tunnel IP Header
Payload Length as well as the decompressed Payload. FL is set to 16
bits, TV is not set, MO is set to "ignore", CDA is set to "lower".
Next Header is compressed according to ts_proto:
* If ts_proto is the single value 0, Next Header is not compressed.
FL is set to 8 bits, TV is not set, MO is set to "ignore", CDA is
set to "sent-value".
* If ts_proto is a single non zero value, Next Header is compressed.
FL is set to 8 bits, TV is set to ts_proto, MO is set to "equal"
and CDA is set to "not-sent".
The IPv6 Hop Limit is read from the Tunnel IP Header Hop Limit. FL
is set to 8 bits, TV is not set, MO is set to "ignore" and CDA is set
to "lower."
The source and destination IPv6 addresses are compressed using MSB.
In both cases, FL is set to 128, TV is respectively set to
msb(ts_ip_src_start, ts_ip_src_ed) or msb(ts_ip_dst_start,
ts_ip_dst_end), the MO is set to "MSB," and the CDA is set to "LSB."
5.1.3. Inner IPv4 Header Compression
The fields Version, DSCP, ECN, Source Address and Destination Address
are compressed as described for IPv6 in Section 5.1.2. The field
Total Length (16 bits) is compressed similarly to the IPv6 field
Payload Length. The field Identification (16 bits) is compressed
similarly to the IPv6 field Flow Label. If the tunnel IP Header is
an IPv6 Header, the Identification is placed as the LSB of the IPv6
Header and the 4 remaining MSB are set to 0. The field Time to Live
is compressed similarly to the IPv6 Hop Limit field. The Protocol
field is compressed similarly to the last IPv6 Next Header field.
The Internet Header Length (IHL) is uncompressed, FL is set to 4
bits, TV is not set, MO is set to ignore and CDA is set to "value-
sent".
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."
Migault, et al. Expires 30 July 2025 [Page 19]
Internet-Draft EHCP January 2025
5.2. ESP Payload Data Byte Alignment
SCHC operates on bits, and the compression performed by SCHC may
result in a bit payload that is not aligned to a byte (8 bits)
boundary. Protocols such as ESP expect payloads to be aligned to
byte boundaries (8-bit alignment). To ensure this, we apply a
padding by appending the SCHC_padding bits and the SCHC_padding_len.
SCHC_padding_len is encoded over 3 bits to encode the number of bits
that will compose the SCHC_padding field. As a result SCHC_padding
field has between 0 and 7 bits coded over the SCHC_padding_len. The
two fields are between 3 and 10 bits, so if the complementing bits
are less than or equal to 2 bits, the padding will result in adding
an extra byte.
When the iipc_profile is set to "iipc_uncompress" there is no ESP
Payload Data Byte alignment. When iipc_profile is set to "iipc_diet-
esp" ESP Payload Data Byte Alignment is performed over the Compressed
Inner IP packet. This ensures that in both transport and tunnel
mode, the Payload Data later encrypted by ESP result in an integer
number of bytes.
5.3. Clear Text ESP Compression (CTEC)
Once the Inner IP Packet has undergone compression as outlined in
Section 5.1, followed by the ESP Byte Alignment detailed in
Section 5.2, the resulting compressed inner packet comprises a
specific number of bytes. To construct the Clear Text ESP Packet, it
is necessary to ascertain the ESP Payload Data, the Next Header, the
Pad Length, and the Padding fields.
In transport mode, the IP header of the inner packet remains
uncompressed during the IIPC phase, and the ESP Payload Data is
derived from the inner packet. Conversely, in tunnel mode, the
Payload Data encompasses the entirety of the inner packet.
In transport mode, the Next Header field is obtained from either the
inner IP Header or the Security Association, as specified in
Section 5.1.3 or Section 5.1.2. In tunnel mode, the Next Header is
elided, as it is determined by ts_ip_version. FL is set to 8 bit, TV
is set to IPv4 or IPv6 depending on ts_ip_version, MO is set to
"equal" and CDA is set to "not-sent".
The ESP Pad Length and Padding fields are omitted only when ESP
alignment has been selected to "8bit" and esp_encr does not
necessitate a specific block size alignment, or if that block size is
one byte. This is represented by setting FL to (Pad Length + 1) * 8
bits, leaving TV unset, configuring MO to "ignore," and designating
CDA as padding. The ESP Padding and Pad Length may vary from their
Migault, et al. Expires 30 July 2025 [Page 20]
Internet-Draft EHCP January 2025
decompressed counterparts. However, since the IPsec process removes
the padding, these variations do not affect packet processing. When
esp_encr requires a specific block size, the ESP Pad Length and
Padding fields remain uncompressed.
5.4. 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".
SN is 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_sn_lsb)" and CDA is
set to "LSB".
6. SCHC Compression for IPsec in Transport mode
The transport mode mostly differs from the Tunnel mode in that the IP
header of the packet is not encrypted. As a result, the IP Payload
is compressed as described in Section 5.1.1. The IP header is not
compressed. The byte alignment of the Compressed Payload is
performed as described in Section 5.2. The Clear Text ESP
Compression is performed as described in Section 5.3 except for the
Next Header Field, which is compressed as described in Section 5.1.2.
7. IANA Considerations
We request the IANA to create a new registry for the IIPC Profile
| IIPC Profile value | Reference |
+--------------------+-----------+
| "iipc_uncompress" | ThisRFC |
| "iipc_diet-esp" | ThisRFC |
We request IANA to create the following registries for the "diet-esp"
IIPC Profile.
| Flow Label CDA Value | Reference |
+----------------------+-----------+
| "uncompress" | ThisRFC |
| "generated" | ThisRFC |
| "lower" | ThisRFC |
| "zero" | ThisRFC |
| DSCP CDA Value | Reference |
+----------------------+-----------+
| "uncompress" | ThisRFC |
| "lower" | ThisRFC |
| "sa" | ThisRFC |
Migault, et al. Expires 30 July 2025 [Page 21]
Internet-Draft EHCP January 2025
| ECN CDA Value | Reference |
+----------------------+-----------+
| "uncompress" | ThisRFC |
| "lower" | ThisRFC |
| Alignment | Reference |
+----------------------+-----------+
| "8 bit" | ThisRFC |
| "16 bit" | ThisRFC |
| "32 bit" | ThisRFC |
| "64 bit" | ThisRFC |
| IPsec mode Value | Reference |
+----------------------+-----------+
| "Tunnel" | ThisRFC |
| "Transport" | ThisRFC |
8. Security Considerations
The security considerations encompass those outlined in ESP [RFC4303]
as well as those pertaining to SCHC [RFC8724].
When employing ESP [RFC4303] in Tunnel Mode, the complete inner IP
packet is safeguarded against man-in-the-middle attacks through
cryptographic means, rendering it virtually impossible for an
attacker to alter any fields associated with either the inner IP
header or the inner IP payload. This level of protection is achieved
by configuring the Flow Label CDA Value to "uncompress," the DSCP CDA
Value to either "uncompress" or "sa," and the ECN CDA Value to
"uncompress."
Migault, et al. Expires 30 July 2025 [Page 22]
Internet-Draft EHCP January 2025
However, this protection is compromised if the Flow Label CAD Value,
DSCP CAD Value, or ECN CDA Values are set to "lower." In such cases,
the values from the inner packet for the respective fields will be
derived from the outer IP header, leaving these fields unprotected.
It is important to note that even the Authentication Header [RFC4302]
does not provide protection for these fields. When associated with a
CDA value of "lower," the level of protection is akin to that
provided in Transport mode. This vulnerability could be exploited by
an attacker within an untrusted domain, potentially disrupting load
balancing strategies that rely on the Flow Label [RFC6438][RFC6437].
More broadly, when the Flow Label CAD Value is set to "lower," the
relevant Flow Label Security Considerations from [RFC6437] apply.
Additionally, an attacker may manipulate the DSCP values to diminish
the priority of specific packets, resulting in packets from the same
flow having varying priorities, traversing different paths, and
introducing additional latency to applications, thereby facilitating
DDoS attacks. Consequently, these fields remain unprotected and are
susceptible to modification during transmission, which may also be
regarded as an acceptable risk.
When the Flow Label CDA Value is designated as "generated" or "zero,"
an attacker is unable to exploit the Flow Label field in any manner.
The inner packet received is anticipated to possess a Flow Label
distinct from that of the original encapsulated packet. However, the
Flow Label is assigned by the receiving gateway. When the value is
set to "zero," it is known, whereas when it is designated as
"generated," it must be produced in accordance with the
specifications outlined in [RFC6437].
The DSCP CDA Value is assigned as "sa" when DSCP values are linked to
Security Associations (SAs), but it should not be utilized when all
DSCP values are encompassed within a single SA. In such instances,
"uncompress" is recommended.
The encryption algorithm must adhere to the guidelines provided in
[RFC8221] to guarantee contemporary cryptographic protection.
Migault, et al. Expires 30 July 2025 [Page 23]
Internet-Draft EHCP January 2025
The least significant bits (LSB) of the ESP Security Parameter Index
(SPI) determine the number of bits allocated to the SPI. An
acceptable quantity of LSB must ensure that the peer possesses a
sufficient number of SPIs, which is contingent upon the
implementation of the SA lookup employed. If a peer relies solely on
the SPI fields for SA lookup, then the LSB must be sufficiently large
to satisfy the condition MAX_SPI <= 2**LSB. The SPI may assume
various LSB values; however, the operator must be cognizant that if
multiple LSB values are permissible for each type of SA lookup, then
multiple SA lookups and signature verifications may be required. It
is advisable for a peer to ascertain the LSB associated with an
incoming packet in a deterministic manner.
The ESP SN LSB must be established in a manner that allows the
receiving peer to clearly ascertain the sequence number of the IPsec
packet. If this requirement is not met, it will lead to an invalid
signature verification, resulting in the rejection of the packet.
Furthermore, the LSB should have the capacity to accommodate the
maximum number of packets that may be in transit simultaneously.
This approach will guarantee that the last packet received is
correctly linked to the corresponding sequence number.
9. Acknowledgements
We would like to thank Laurent Toutain for his guidance on SCHC.
Robert Moskowitz for inspiring the name "Diet-ESP" from Diet-HIP.
The authors would like to acknowledge the support from Mitacs through
the Mitacs Accelerate program.
10. References
10.1. Normative References
[I-D.ietf-ipsecme-ikev2-diet-esp-extension]
Migault, D., Guggemos, T., Schinazi, D., Atwood, J. W.,
Liu, D., Preda, S., Hatami, M., and S. Cespedes, "Internet
Key Exchange version 2 (IKEv2) extension for Header
Compression Profile (HCP)", Work in Progress, Internet-
Draft, draft-ietf-ipsecme-ikev2-diet-esp-extension-02, 21
November 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-ipsecme-ikev2-diet-esp-extension-02>.
[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>.
Migault, et al. Expires 30 July 2025 [Page 24]
Internet-Draft EHCP January 2025
[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>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>.
[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>.
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
Kivinen, "Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating Security
Payload (ESP) and Authentication Header (AH)", RFC 8221,
DOI 10.17487/RFC8221, October 2017,
<https://www.rfc-editor.org/info/rfc8221>.
[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>.
10.2. Informative References
Migault, et al. Expires 30 July 2025 [Page 25]
Internet-Draft EHCP January 2025
[I-D.ietf-schc-architecture]
Pelov, A., Thubert, P., and A. Minaburo, "Static Context
Header Compression (SCHC) Architecture", Work in Progress,
Internet-Draft, draft-ietf-schc-architecture-03, 11
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-schc-architecture-03>.
[I-D.mglt-ipsecme-dscp-np]
Migault, D., Halpern, J. M., Parkholm, U., and D. Liu,
"Differentiated Services Field Codepoints Internet Key
Exchange version 2 Notification", Work in Progress,
Internet-Draft, draft-mglt-ipsecme-dscp-np-01, 3 July
2024, <https://datatracker.ietf.org/doc/html/draft-mglt-
ipsecme-dscp-np-01>.
[OpenSCHC] "OpenSCHC a Python open-source implementation of SCHC
(Static Context Header Compression)", n.d.,
<https://github.com/openschc>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[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>.
[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. Appendix
This appendix provides the details of the SCHC rules defined for
Diet-ESP compression, alongside an explanation and an example
outcome.
Migault, et al. Expires 30 July 2025 [Page 26]
Internet-Draft EHCP January 2025
A.1. JSON Representation of SCHC Rules for Diet-ESP Header Compression
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. The rules include all the compression_levels,
including IIPC, CTEC, and EEC as defined in the Terminology section.
[
{
"RuleIDValue": 1,
"RuleIDLength": 8,
"Compression": [
{
"FID": "ESP.SPI",
"TV": 5,
"MO": "equal",
"CDA": "not-sent"
},
{
"FID": "ESP.SEQ",
"TV": 1,
"MO": "MSB",
"MO.VAL": 16,
"CDA": "LSB"
}
]
},
{
"RuleIDValue": 2,
"RuleIDLength": 8,
"Compression": [
{
"FID": "UDP.DEV_PORT",
"TV": 123,
"MO": "MSB",
"MO.VAL": 12,
"CDA": "LSB"
},
{
"FID": "UDP.APP_PORT",
"TV": 4567,
"MO": "MSB",
"MO.VAL": 12,
"CDA": "LSB"
},
Migault, et al. Expires 30 July 2025 [Page 27]
Internet-Draft EHCP January 2025
{
"FID": "UDP.LEN",
"TV": 0,
"MO": "ignore",
"CDA": "compute-length"
},
{
"FID": "UDP.CKSUM",
"TV": 0,
"MO": "ignore",
"CDA": "compute-checksum"
}
]
},
{
"RuleIDValue": 0,
"RuleIDLength": 0,
"schc_header": [
{
"FID": "SCHC.NXT",
"TV": [17, 50, 41],
"MO": "equal",
"CDA": "not-sent"
}
]
},
{
"RuleIDValue": 4,
"RuleIDLength": 8,
"Compression": [
{
"FID": "IPV6.DEV_PREFIX",
"TV": "ff02::5678",
"MO": "equal",
"CDA": "value-sent"
},
{
"FID": "IPV6.APP_PREFIX",
"TV": "2001:db8::1000",
"MO": "equal",
"CDA": "value-sent"
}
]
},
{
"RuleIDValue": 5,
"RuleIDLength": 8,
"Compression": [
Migault, et al. Expires 30 July 2025 [Page 28]
Internet-Draft EHCP January 2025
{
"FID": "ESP.NXT",
"TV": 41,
"MO": "equal",
"CDA": "not-sent"
}
]
}
]
A.2. Example Outcome
A.2.1. Input Packet
The following packet undergoes processing based on the SCHC Diet-ESP
profile:
* *IPv6 Header*:
- Source Address: 2001:db8::1000
- Destination Address: ff02::5678
- Other attributes include Payload Length: 18, Next Header: UDP,
and Hop Limit: 64.
* *UDP Header*:
- Source Port: 123
- Destination Port: 4567
- Length: 18
- Checksum: 0x6bc9
* *Payload*:
- 10 bytes sample Data: b'U\xe2(\x88\xbf\xf9\xd91\x08\xc5'
A.2.2. Compression Process
1. *UDP Header Compression*:
* Initial size: 8 bytes.
* Compressed using the UDP-specific rules from the Diet-ESP
profile.
Migault, et al. Expires 30 July 2025 [Page 29]
Internet-Draft EHCP January 2025
* Ports are encoded as LSB fields, reducing the size to 2 bytes.
2. *IPv6 Header Compression*:
* Initial size: 40 bytes.
* Source and destination addresses are compressed using value-
sent rules based on matching prefixes.
* Final compressed size: 17 bytes.
3. *ESP Header Compression*:
* Initial size: 12 bytes.
* SPI is not transmitted (not-sent CDA), and SEQ is compressed
using the LSB technique.
* Final compressed size: 2 bytes.
4. *ESP Clear Text Compression*:
* The ESP.NXT field (Next Header) is compressed using the match-
mapping CDA: Rule: The ESP.NXT value is matched to a single
value (41 for the IPv6 Next Header). CDA: mapping-sent is
used to send only the mapped index.
5. *Payload Handling*:
* The payload is not compressed. Further compression may be
possible with additional SCHC rules.
A.2.3. Decompression Process
The decompression reverses the steps:
1. *ESP Header Reconstruction*:
* SPI is restored using the fixed value from the rule (TV=5).
* SEQ is reconstructed from the LSB field.
2. *ESP Clear Text Reconstruction*:
* The ESP.NXT field is restored using the mapping-sent rule,
where the value 41 (Next Header for IPv6) is retrieved from
the mapping.
Migault, et al. Expires 30 July 2025 [Page 30]
Internet-Draft EHCP January 2025
3. *UDP Header Reconstruction*:
* Ports are restored using the compressed LSB values.
* Length and checksum fields are calculated using compute-length
and compute-checksum CDA.
4. *IPv6 Header Reconstruction*:
* Prefixes are restored using the value-sent fields in the rule.
5. *Payload Restoration*:
* The payload is directly restored, as it was not compressed.
A.2.4. Final Output Packet
After reconstruction, the packet is identical to the original input:
* *IPv6 Header*:
- Source Address: 2001:db8::1000
- Destination Address: ff02::5678
- Payload Length: 18
- Next Header: UDP
- Hop Limit: 64.
* *UDP Header*:
- Source Port: 123
- Destination Port: 4567
- Length: 18
- Checksum: 0x6bc9.
* *Payload*:
- Data: b'U\xe2(\x88\xbf\xf9\xd91\x08\xc5'.
This example demonstrates the efficiency and accuracy of the Diet-ESP
profile when applied to compress and decompress network packets.
Migault, et al. Expires 30 July 2025 [Page 31]
Internet-Draft EHCP January 2025
* *Efficiency*: The SCHC rules reduce packet overhead:
- The UDP header is compressed from 8 bytes to 2 bytes.
- The IPv6 header is reduced from 40 bytes to 17 bytes.
- The ESP header size is decreased from 12 bytes to 2 bytes.
- The ESP.NXT field is eliminated from transmission (1 byte
reduction).
These reductions are particularly beneficial in constrained
environments such as Low-Power Wide-Area Networks (LPWANs).
* *Accuracy*: The decompression process fully reconstructs the
original packet, ensuring no loss of information.
* *Applicability*: By leveraging these rules, the Diet-ESP profile
addresses the challenges of transmitting data efficiently in
constrained networks, optimizing bandwidth utilization while
retaining compatibility with standard protocols.
A.2.5. GitHub Repository: Diet-ESP SCHC Implementation
The source code for the implementation of the Diet-ESP profile,
including the compression and decompression logic using the SCHC
rules, is available on GitHub. Access the code at the following
link:
GitHub Repository: Diet-ESP SCHC Implementation
(https://github.com/mglt/pyesp/tree/master/examples/draft-diet-
esp.py)
This repository contains the rule definitions, examples, and source
code for implementing and testing the Diet-ESP profile. Refer to the
README file for setup instructions and usage guidelines.
Authors' Addresses
Daniel Migault
Ericsson
Email: daniel.migault@ericsson.com
Maryam Hatami
Concordia University
Email: maryam.hatami@mail.concordia.ca
Migault, et al. Expires 30 July 2025 [Page 32]
Internet-Draft EHCP January 2025
Sandra Céspedes
Concordia University
Email: sandra.cespedes@concordia.ca
J. William Atwood
Concordia University
Email: william.atwood@concordia.ca
Daiying Liu
Ericsson
Email: harold.liu@ericsson.com
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 30 July 2025 [Page 33]