]> Ericsson

daniel.migault@ericsson.com

Concordia University

maryam.hatami@mail.concordia.ca

Concordia University

sandra.cespedes@concordia.ca

Concordia University

william.atwood@concordia.ca

Ericsson

harold.liu@ericsson.com

LMU

guggemos@nm.ifi.lmu.de

Universitaet Bremen TZI

cabo@tzi.org

Google LLC

dschinazi.ietf@gmail.com

Security IPsecme Internet-Draft This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression uses Static Context Header Compression rules.

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 when, and only when, they appear in all capitals, as shown here.

Introduction The Encapsulating Security Payload (ESP) protocol is part of the IPsec 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 Data, the ESP Trailer, and the Integrity Check Value (ICV). ESP has two modes of operation: Transport and Tunnel. In Transport mode, the ESP Payload Data 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 Data 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 ESP Payload Data, 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 Data 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 . In , the Payload Data, ESP Padding, Pad Length, and Next Header compose the Cleartext ESP Packet (CTE) to be protected by encryption. The Authentication Coverage extends from SPI through Padding, while the Encryption Coverage applies to the Payload Data and optional Padding, Pad Length, and Next Header fields. While ESP is effective in securing traffic, compression 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 Diet-ESP, a protocol that includes compression/decompression (C/D) of the various structures processed by ESP. The C/D uses Static Context Header Compression and Fragmentation (SCHC) rules . The structure of a standard uncompressed ESP packet is shown in .

Top-Level Format of a standard ESP Packet. The ESP Data Payload, ESP Padding, Pad Length, and Next Header compose the Clear Text ESP Packet (CTE) to be protected by encryption.

The Three Compressors Described in this Specification The document outlines the three compressors utilized in Diet-ESP, which are detailed as follows:

1. Inner IP Compression (IIPC): The original packet to be protected by ESP, namely, the Inner IP packet (IIP), is split into a Header subject to compression and a Payload (see for more details). The process in the IIPC pertains to the compression and decompression of fields of the Header of the IIP. For outbound packets, after IIPC, ESP incorporates the resulting SCHC Packet and the (unaltered) Payload of the IIP into the ESP Data Payload of a Clear Text ESP packet (CTE) (refer to ). In the case of inbound packets, decompression occurs after the compressed Header is retrieved from the ESP Payload Data within the CTE.
2. Clear Text ESP Compression (CTEC): This process pertains to the compression and decompression of the segment of the ESP packet that is covered by encryption. This encompasses the ESP Data Payload and the ESP Trailer, which includes the Padding, Pad Length, and Next Header fields, as illustrated in . For the CTEC stage, only these three ESP Trailer fields are eligible for compression. For outbound packets, ESP subsequently encrypts the compressed CTE packet. For inbound packets, decompression takes place following the decryption process of the ESP.
3. Encrypted ESP Compression (EEC): This process pertains to the compression and decompression of the Encrypted ESP packet (EE), which consists of the ESP Header, the encrypted payload, and the Integrity Check Value (ICV). Since neither the encrypted payload nor the ICV can be compressed, only the ESP Header, specifically the SPI and SN fields, is subject to compression.

depicts the incorporation of Diet-ESP compressors within the IPsec framework.

SCHC Integration into the IPsec Stack. Packets are described for IPsec in tunnel mode. C(.) and DC(.) designate compression/decompression for the fields inside, and E{.} designates encryption. IIP refers to the Inner IP packet, EH refers to the ESP Header, and ET refers to the ESP Trailer. IIPC, CTEC and EEC respectively designate the Inner IP Compressor, the Clear Text ESP Compressor, and the Encrypted ESP Compressor.

IPsec requires that both endpoints agree on a shared context known as the Security Association (SA). This SA is established via IKEv2 and encompasses all Attributes for Rule Derivation (AfRD) (refer to ) essential for formulating the Rules for each compressor defined in , specifically the Inner IP packet Compressor (IIPC), the Clear Text ESP Compressor (CTEC), and the Encrypted ESP Compressor (EEC). When an Inner IP packet (IIP) is received, IPsec identifies the SA linked to that packet. Upon the ESP determining the IIPC Rule from the AfRD contained within the SA, the IIPC pre-processes the the IIP and separates it into Header and Payload. Only the Header is sent for compression. The compressed Header is composed of RuleID, Compressed Residue, and an optional Padding field. The original Payload of the IIP is then appended after the compressed Header, resulting in an IIPC packet with format |C(Header)|Payload| where C(.) indicates compression. Subsequently, ESP constructs the Clear Text ESP packet (CTE). The CTEC Rule, which is derived from the AfRD of the SA, allows for the compression of the CTE, resulting in a CTEC packet with format |C(Header)|Payload|C(ET)| where ET represents the ESP Trailer. Then, ESP encrypts the ESP Data Payload, computes the Integrity Check Value (ICV), and forms the Encrypted ESP packet (EE) formatted as |EH|E{C(Header)|Payload|C(ET)}|ICV|, where EH represents the ESP Header and E{.} indicates encryption. The EEC Rule that has been derived from the AfRD of the SA, is then utilized to compress the EE, resulting in an EEC packet with format |C(EH)|E{C(Header)|Payload|C(ET)}|ICV|. The resulting compressed ESP packet is integrated into an IP packet and transmitted as outbound traffic. For inbound traffic, the endpoint extracts the Security Parameter Index (SPI) from the compressed EE, along with any other selectors from the packet, to conduct a lookup for the SA. As outlined in , since the SPI is derived from a potentially compressed ESP Header, there may be instances where the endpoint must explore multiple options, potentially leading to several lookups or, in the worst-case scenario, multiple signature verifications (see for a more detailed discussion). Once the SA is retrieved, the ESP accesses the AfRD to ascertain the EEC Rule and proceeds to decompress the EE. The ESP verifies the signature prior to decryption. Following this, the decompressor applies the CTEC Rule derived from the AfRD of the SA, allowing for the subsequent decompression. Finally, ESP extracts the Data Payload from the CTE packet, retrieves the IIPC Rule and decompresses the Header. Note that implementations MAY differ from the architectural description but it is assumed that the output will be the same.

The Scope of SCHC in this Specification SCHC offers a mechanism for header compression as well as an optional fragmentation feature. SCHC facilitates the compression and decompression of headers by utilizing a common context that may encompass multiple Rules. Each Rule is designed to correspond with specific values or ranges of values within the header fields. When a Rule is successfully matched, the corresponding header fields are substituted with the Rule ID and the Compression Residue. The Compression Residue for the packet header is the concatenation of the non-empty residues for each field of the header. The Compression Residue is directly followed by the packet payload and an optional padding to ensure byte alignment. This document utilizes SCHC as a practical means to illustrate the capability to compress and decompress a structured payload. It is important to note that any elements of SCHC that pertain to aspects other than compression or decompression, such as fragmentation, fall outside the purview of this document. The reference to SCHC herein is solely for descriptive purposes related to compression and decompression, and it is not anticipated that the general SCHC framework will be integrated into the ESP implementation. The structured payloads addressed in this specification pertain to internal structures managed by ESP for the processing of an IP packet. Consequently, the compression and decompression processes outlined in this document represent supplementary steps for the ESP stack in handling the ESP packet.

Diet-ESP Rules and Context In IPsec, the process of encryption or decryption between IPsec peers necessitates a common context known as a Security Association (SA). More broadly, the SA encompasses all essential parameters required by the ESP to handle both inbound and outbound packets. SAs are unidirectional. Furthermore, IPsec can link both outbound and inbound IP packets to the SA through Traffic Selectors (TS) or Security Parameter Index (SPI). This capability allows IPsec to uniquely associate outbound and inbound packets with a specific context (SA), which contains all pertinent information for IPsec processing. This document adopts a comparable methodology for compression and decompression, ensuring that the SA includes all necessary parameters to create the Rules applicable for compressing or decompressing each structured payload. The Rule associated with each structured payload is generated based on specific parameters referred to in this document as Attributes for Rule Derivation (AfRD) (see for a more detailed description). These AfRDs are negotiated through IKEv2 , and in such cases, they are likely already included in the SA. Any additional missing AfRDs are negotiated via .

Terminology

ESP Header Compression:

A method to reduce the size of ESP headers and trailer using predefined compression rules and contexts to improve efficiency.

ESP Trailer:

A set of fields added at the end of the ESP payload, including Padding, Pad Length, and Next Header, used to ensure alignment and indicate the next protocol.

Inner IP C/D (IIPC):

Process that compresses/decompresses the inner IP packet headers.

Clear Text ESP C/D (CTEC):

Process that compresses/decompresses all fields that will later be encrypted by ESP, which include the ESP Data Payload and ESP Trailer.

Encrypted ESP C/D (EEC):

Process that compresses/decompresses ESP fields not encrypted by ESP.

Security Parameter Index (SPI):

As defined in .

Sequence Number (SN):

As defined in .

Static Context Header Compression (SCHC):

A framework for header compression designed for LPWANs, as defined in .

Static Context Header Compression Rules (SCHC Rules):

As defined in

RuleID:

A unique identifier for each Rule part of the Diet-ESP context.

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.

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 , , and eventually .

Diet-ESP Integration into the IPsec Stack

SCHC Parameters for Diet-ESP The SCHC Packet is always in the form:

SCHC Packet

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. Furthermore, indicates that the way the RuleID is sent is left open to the profile specification. The RuleID in Diet-ESP is expressed as 1 byte but it can be elided as there is a unique Rule determined for the compressors. The 1 byte may be used in future implementations to support multiple flows over the same SA. SCHC padding in SCHC serves the purpose of aligning data to a designated boundary, which is typically byte-aligned or aligned to 8 bits. This document presumes that this field is not utilized in CET and EEC. This document outlines a simpler form of padding for byte-alignment, as detailed in section . Such alignment is essential to ensure that encryption is applied to data that is byte-aligned. The rationale for employing a padding method other than SCHC Padding is to accommodate the length of the compressed ESP Payload Data. Another variable required for the C/D in Diet-ESP is the Maximum Packet Size (MAX_PACKET_SIZE) 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.

Attributes for Rules Derivation The list of attributes for Rules Derivation (AfRD) is shown in . These attributes are used to express the various compressions that operate at the IIPC, CTEC, and EEC. As outlined in , this specification does not detail the process by which the AfRD are established between peers. Instead, such negotiations are addressed in . However, the AfRD can be classified into two distinct categories. The first category encompasses AfRD that are negotiated through a specific IKEv2 extension tailored for the negotiation of AfRD linked to a particular profile, the Diet-ESP profile in this context. The AfRD referenced in 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 AfRD that are negotiated through IKEv2 exchanges or extensions that are not specifically designed for compression purposes. This category includes AfRD associated with TS, as identified in , 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 AfRD are derived from the Traffic Selectors established through TSi/TSr payloads during the IKEv2 CREATE_CHILD_SA exchange, as described in . The AfRD IPsec Mode designated as ipsec_mode in is determined by the presence or absence of the USE_TRANSPORT_MODE Notify Payload during the CREATE_CHILD_SA exchange, as detailed in . The AfRD Tunnel IP designated as tunnel_ip in is obtained from the IP address of the IKE messages exchanged during the CREATE_CHILD_SA process, as noted in . The AfRDs designated as ESP Encryption Algorithm esp_encr and ESP Security Parameter Index (SPI) esp_spi in are established through the SAi2/SAr2 payloads during the CREATE_CHILD_SA exchange, while the AfRD designated as ESP Sequence Number esp_sn in is initialized upon the creation of the Child SA and incremented for each subsequent ESP message. The DSCP values identified as dscp_list in are established through the DSCP Notify Payload . The ability to derive the IIP Compressor Rules for the internal IP packet from the agreed Traffic Selectors is indicated by the variable iipc_profile. Attributes for Rule Derivation (AfRD) to generate IIPC, CTEC and EEC Rules in Diet-ESP

Variable	Possible Values	Reference	Compressor
iipc_profile	"iipc_diet-esp", "iipc_not_compressed"	ThisRFC	N/A
dscp_cda	"not_compressed", "lower", "sa"	ThisRFC	IIPC
ecn_cda	"not_compressed", "lower"	ThisRFC	IIPC
flow_label_cda	"not_compressed", "lower", "generated", "zero"	ThisRFC	IIPC
ts_ip_version	"IPv4-only", "IPv6-only"	RFC7296	IIPC
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, SCTP, ANY, ...	RFC7296	IIPC
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 bit", "64 bit"	ThisRFC	CTEC
esp_trailer	"Mandatory", "Optional"	ThisRFC	CTEC
ipsec_mode	"Tunnel", "Transport"	RFC4301	CTEC
tunnel_ip	IPv4 or IPv6 address	RFC4301	CTEC
esp_encr	ESP Encryption Algorithm	RFC4301	CTEC
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

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 and . 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 in both TSi and TSr payloads (as described in ). The TS Type MUST be either TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. Let the resulting Traffic Selectors TSi/TSr be expressed via the Traffic Selector structure defined in . 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_not_compressed" 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 for more information. In a nutshell, "not_compressed" indicates that Flow Label (resp. Identification) is not compressed and the field is sent as-is using value-sent. "lower" ( using compute-* ) 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. This field is computed from the outer IP header using compute-* ( MO: ignore, CDA: compute-* )."generated" indicates the value is re-generated at the decompressor side ( CDA: compute-* ). In that case, the decompressed value may take a different value compared to its original value. "zero" indicates the field is removed by matching against a target value of 0 (MO: equal, CDA: not-sent). See for further details on the applied CDA logic.

dscp_cda:

indicates the DSCP CDA, that is how the DSCP values of the inner IP packet are compressed / decompressed - See for more information. In a nutshell, "not_compressed" 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 ( compute-* ). "sa" indicates that compression is performed according to the pre-negotioated list of DSCP values (dscp_list) agreed by the SA, using SCHC's MO and index (CDA). See for rule examples.

ecn_cda:

indicates ECN CDA, that is how the ECN values of the inner IP packet are compressed / decompressed - See for more information. In a nutshell, "not_compressed" indicates that DSCP are not compressed. "lower" indicates the value is read from the outer IP header using compute-* (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 .

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.

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.

In Diet-ESP compression, fields such as IP addresses and port numbers are split into a stable prefix and a variable suffix. The stable part is captured in the rule as the Target Value (TV), expressed with prefix_bits(start, end). The Matching Operator MO = MSB(x) verifies that the most significant x bits of the Field Value (FV) match this prefix. When the match succeeds, the Compression/Decompression Action CDA = LSB transmits only the remaining low-order bits (FL - x), where FL is the full field length in bits. Formally, the operation of MO = MSB(x) is defined as: (FV & (((1 << x) - 1) << (FL - x))) == (TV & (((1 << x) - 1) << (FL - x))) where FL is the total field length in bits. The parameter x is computed as: x = FL - prefix_bits_length

dscp_list:

designates the list of DSCP values associated to the inner traffic - see for example . 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 .

esp_trailer:

When configured to "Mandatory," it signifies that the implementation requires the ESP Trailer to include a Next Header and a Pad Len field, as outlined in . This requirement primarily aims to ensure compatibility with current hardware implementations of ESP, as detailed in . Conversely, if set to "Optional," it indicates that the implementation is capable of supporting the compression of the ESP Trailer.

ipsec_mode:

designates the IPsec Mode defined in . 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 . 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 . 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 .

esp_spi:

designates the Security Parameter Index defined in .

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 .

esp_sn_lsb:

designates the LSB to be considered for the compressed SN. It works similarly to ESP SPI LSB (see esp_spi_lsb).

Examples of Diet-ESP SCHC Rule Tables The tables in this section provide examples of SCHC compression rules for Diet-ESP in IPsec. The Compression/Decompression Actions (CDAs), derived from the AfRD discussed in Section , specify how various IPv6, UDP/TCP, and ESP header fields are compressed and decompressed, , , and collectively represent an example configuration for Diet-ESP compression, where each compressor stage applies its own dedicated rule as per Section 7.2. In , the field flow_label_cda is set to lower, which results in MO = ignore and CDA = compute-*, indicating the value is derived from the outer header. The dscp_cda is set to *not_compressed*, corresponding to MO = ignore and CDA = value-sent, meaning the DSCP field is transmitted in full. IPv6 address and port fields are compressed using the MSB/LSB strategy, where the MO = MSB(x) checks whether the most significant x bits of the Field Value (FV) equal the rule's Target Value (TV), and transmits only the variable suffix (FL - x bits). The ESP-related fields, including padding and alignment, are compressed using a separate rule in , while the ESP SPI and Sequence Number are compressed independently using the rule in . Each rule includes only the fields visible and relevant to its corresponding compression stage.

Diet-ESP with Inner IP and UDP/TCP Header Compression

Inner IP Compression (IIPC) Rule This rule defines the compression behavior for the IIPC, which operates before ESP encapsulation and encryption. The example handles all fields from the inner IPv6 and transport layer headers (e.g., UDP, TCP, SCTP) that are visible at this stage. Version, Next Header, and Payload Length are elided or derived based on known values or outer headers. Traffic Class fields (DSCP and ECN) are partially elided or transmitted depending on their CDA. Flow Label is computed from the outer header (flow_label_cda = lower). Source/Destination Addresses and Ports are compressed using MSB/LSB strategy based on Traffic Selectors. Checksum and UDP Length are elided and computed at the decompressor. IIPC Rule: Compression of Inner IP and Transport Headers

Field	FL	FP	DI	TV	MO	CDA	Sent [bits]
Version	3	1	Bi	ts_ipversion	equal	not-sent	0
DSCP	6	1	Dw	-	ignore	value-sent	6
ECN	2	1	Dw	-	ignore	value-sent	2
Flow Label	20	1	Dw	-	ignore	compute-*	0
Payload Length	16	1	Bi	-	ignore	compute-*	0
Next Header	8	1	Bi	ts_proto	equal	not-sent	0
Hop Limit	8	1	Dw	-	ignore	compute-*	0
Source Address	128	1	Bi	prefix_bits (ts_ip_src_start, ts_ip_src_end)	MSB(x)	LSB	FL-x
Destination Address	128	1	Bi	prefix_bits (ts_ip_dst_start, ts_ip_dst_end)	MSB(x)	LSB	FL-x
Source Port (UDP/TCP)	16	1	Bi	prefix_bits (ts_port_src_start, ts_port_src_end)	MSB(x)	LSB	FL-x
Destination Port (UDP/TCP)	16	1	Bi	prefix_bits (ts_port_dst_start, ts_ip_src_end)	MSB(x)	LSB	FL-x
Checksum	16	1	Bi	-	ignore	compute-*	0
UDP Length	16	1	Bi	-	ignore	compute-*	0

Clear Text ESP Compression (CTEC) Rule This rule is used by the CTEC compressor, which processes ESP-specific fields just before encryption. These fields primarily deal with formatting and alignment. ESP Padding is used to ensure that the ESP payload aligns to the encryption algorithm's block size or protocol requirements. It is not sent and is instead calculated (CDA = compute-*). Byte Alignment ensures that the SCHC packet respects the alignment required by ESP and IPv6 extension header parsing (e.g., 64-bit alignment). These fields are handled separately because they are relevant only at the Clear Text ESP Packet construction stage and are not part of the inner packet or ESP Header fields. CTEC Rule: ESP Trailer and Alignment Compression

Field	FL	FP	DI	TV	MO	CDA	Sent [bits]
ESP Padding	-	-	-	-	ignore	compute-*	0
Byte Alignment	8	1	Bi	-	ignore	compute-*	0

Encrypted ESP Compression (EEC) Rule This rule focuses on compressing the ESP Header fields that are still visible post-encryption. These fields are typically stable over a session and can be compressed without compromising lookup reliability or replay protection. SPI (Security Parameter Index) and Sequence Number (SN) are compressed using the Least Significant Bits (LSB) approach. MSB(8) signifies that only 8 bits of variation need to be sent (leaving 24 fixed bits). EEC Rule: ESP SPI and Sequence Number Compression

Field	FL	FP	DI	TV	MO	CDA	Sent [bits]
SPI	32	1	Dw	-	MSB(x)	LSB	FL - x
SN	32	1	Dw	-	MSB(x)	LSB	FL - x

SA-Based DSCP Compression with Zeroed Flow Label , , and illustrate rule examples where the DSCP field is compressed using a pre-negotiated Security Association (SA) list. Here, dscp_cda = sa results in MO = match-mapping and CDA = index, meaning the field value is matched from a list and only the index is sent. The ECN field is computed from the outer header (ecn_cda = lower), so it is not sent. The Flow Label is removed from transmission by setting a target value of 0 (flow_label_cda = zero), which results in MO = equal and CDA = not-sent. Example of Diet-ESP IIPC Rule table where the DSCP field is compressed using a pre-negotiated Security Association (SA) list

Field	MO	CDA	Sent [bits]
DSCP	match-mapping	index	3
ECN	ignore	compute-*	0
Flow Label	equal (TV=0)	not-sent	0

Example of Diet-ESP EEC Rule table where the DSCP field is compressed using a pre-negotiated Security Association (SA) list

Field	MO	CDA	Sent [bits]
ESP Padding	ignore	compute-*	0
Byte Alignment	ignore	compute-*	0

Example of Diet-ESP EEC Rule table where the DSCP field is compressed using a pre-negotiated Security Association (SA) list

Field	MO	CDA	Sent [bits]
SPI	MSB(x)	LSB	FL - x
SN	MSB(x)	LSB	FL - x

Full Header Transmission Without Compression , , and show a configuration disabling all compression mechanisms. Every field is transmitted in full using MO = ignore and CDA = value-sent, which is the result of setting each cda attribute to not_compressed in the AfRD. Example of Diet-ESP IIPC Rule table with all compression mechanisms disabled

Field	MO	CDA	Sent [bits]
DSCP	ignore	value-sent	6
ECN	ignore	value-sent	2
Flow Label	ignore	value-sent	20
Payload Length	ignore	value-sent	16
Hop Limit	ignore	value-sent	8

Example of Diet-ESP IIPC Rule table with all compression mechanisms disabled

Field	MO	CDA	Sent [bits]
ESP Padding	ignore	compute-*	0
Byte Alignment	ignore	compute-*	0

Example of Diet-ESP EEC Rule table with all compression mechanisms disabled

Field	MO	CDA	Sent [bits]
SPI	ignore	value-sent	32
SN	ignore	value-sent	32

Mixed Compression Strategy to demonstrate a mixed strategy. The Flow Label is generated at the decompressor side and not transmitted, after following the attribute flow_label_cda = generated, which results in MO = ignore and CDA = compute-*. The ECN field is derived from the outer header, while the DSCP field is transmitted as-is (dscp_cda = not_compressed). Example of Diet-ESP IIPC Rule table with a mixed strategy

Field	MO	CDA	Sent [bits]
DSCP	ignore	value-sent	6
ECN	ignore	compute-*	0
Flow Label	ignore	compute-*	0

Example of Diet-ESP IIPC Rule table with a mixed strategy

Field	MO	CDA	Sent [bits]
ESP Padding	ignore	compute-*	0
Byte Alignment	ignore	compute-*	0

Example of Diet-ESP EEC Rule table with a mixed strategy

Field	MO	CDA	Sent [bits]
SPI	MSB(x)	LSB	x
SN	MSB(x)	LSB	x

Diet-ESP for IPsec in Tunnel Mode

Inner IP Compression (IIPC) When the iipc_profile attribute is set to "iipc_not_compressed", the inner IP Packet (IIP) is not compressed. When iipc_profile is set to "iipc_diet-esp", IIPC proceeds with the compression. The Header fields subject to compression depend on the encapsulation mode. When ipsec_mode is set to "tunnel", all Header fields of the IIP structure are subject to compression. ts_ip_version determines how the IPv6 header (resp. the IPv4 header) is compressed - see (resp. ). Conversely, when ipsec_mode is set to "transport", the compression applies only to Header fields other than the IPv4 or IPv6 header fields. This means that the IPv4 and IPv6 headers remain uncompressed, while other Header fields within the IIP structure are subject to compression. Note that the SCHC packet illustrated in appends the padding at the end of the SCHC Packet. This approach presents notable challenges, including handling a Payload that lacks byte alignment. Furthermore, the absence of a specified Payload length would necessitate the inclusion of the padding length within the padding itself, which would require a particular padding construction akin to that utilized by the ESP Padding, thereby posing difficulties for hardware implementations. To address these issues, IIPC uses a pre-processing phase where the IIP is divided into two segments: the Header and the Payload and only the Header is considered as the candidate structure for SCHC compression. The division between Header and Payload can only occur because all the Header fields are of a fixed size. By construction, the compression process applies the defined rule to the Header, resulting in a SCHC Packet (refer to ) that features a Rule ID, a Compression Residue, a Padding field, and an empty SCHC Payload field.

CTEC packet construction |<-0..7 bits-> | +-----+---+--------...----------+------------+ | | Rule ID | Compression Residue | Padding | | +-----+---+--------...----------+------------+ | | | v | SCHC Packet | | Post-processing | +-----------------------------------+ | v +-------+------+------+--------+------+-----+ ESP Payload | SCHC Packet | Payload | +-------+------+------+--------+------+-----+ ESP Trailer | ESP Padding | Pad Length | Next Header| +-------+------+------+--------+------+-----+ ]]>

Ultimately, a post-processing phase merges the SCHC Packet with the Payload. Note that the resulting SCHC packet is byte-aligned.

Compression of the Inner IP payload This section describes the compression of the inner IP payload. The compression described herein only affects UDP, UDP-Lite, TCP or SCTP segments. The type of segment is specified in the IP header. For UDP, UDP-Lite, TCP and SCTP segments, 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 prefix_bits( 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".

Compression of the Inner IPv6 header 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:

• If dscp_cda is set to "not_compressed", 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 "not_compressed", 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 "not_compressed", 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 (using compute-*(See )). 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 (using compute-*) at the decompression (See ). 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".
• 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 prefix_bits(ts_ip_src_start, ts_ip_src_ed) or prefix_bits(ts_ip_dst_start, ts_ip_dst_end), the MO is set to "MSB," and the CDA is set to "LSB."

Compression of the Inner IPv4 header The fields Version, DSCP, ECN, Source Address and Destination Address are compressed as described for IPv6 in . 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 not compressed, 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."

Clear Text ESP Compression (CTEC) Once the Inner IP Packet has undergone compression as outlined in , the resulting compressed 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 ESP Pad Length, and the ESP Padding fields. (Refer to , after post-processing.) When esp_trailer is set to "Mandatory", the Next Header and the ESP Pad Length fields are present. Such requirement is usually expected to remain compatible with hardware implementations of ESP. The ESP Pad Length value is determined to meet the required alignment. When alignment is set to "8bit", Pad Length is set to 0 and the Padding field is empty. Conversely, when esp_trailer is set to "Optional", the Next Header, Pad Length, and Padding are generated as follows: In transport mode, the IP header of the inner packet remains not compressed during the IIPC phase, and the ESP Payload Data is derived from the inner packet. Conversely, in tunnel mode, the ESP Payload Data encompasses the entirety of the packet generated by the IIPC. In transport mode, the Next Header field is obtained from either the inner IP header or the Security Association, as specified in or . 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 ESP 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 ESP Pad Length may vary from their 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 ESP Padding fields remain not compressed.

Encrypted ESP Compression (EEC) Once the Clear Text Packet has undergone compression as outlined in , the resulting CTEC is encrypted. The header fields once the encrypted ESP packet is formed are the SPI and SN. To facilitate the processes of compression and decompression, this specification requires that the compressed ESP Header is byte-aligned. This requirement is satisfied by ensuring that the sum of esp_spi_lsb and esp_sn_lsb MUST be a multiple of 8. 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 its 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".

Diet-ESP 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 . The IP header is not compressed. The byte alignment of the Compressed Payload is performed as described in . The Clear Text ESP Compression is performed as described in except for the Next Header Field, which is compressed as described in .

IANA Considerations We request the IANA to create a new registry for the IIPC Profile We request IANA to create the following registries for the "diet-esp" IIPC Profile.

Security Considerations The security considerations encompass those outlined in ESP as well as those pertaining to SCHC . When employing ESP 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 "not_compressed", the DSCP CDA Value to either "not_compressed" or "sa", and the ECN CDA Value to "not_compressed". However, this protection is compromised if the Flow Label CDA Value, DSCP CDA 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 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 . More broadly, when the Flow Label CDA Value is set to "lower," the relevant Flow Label Security Considerations from 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 . 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, "not_compressed" is recommended. The encryption algorithm must adhere to the guidelines provided in to guarantee contemporary cryptographic protection. The least significant bits (LSB) of the ESP Security Parameter Index (SPI) determine the number of bits allocated to the SPI. An acceptable value for 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 number of LSB to consider must be sufficiently large to include the number of SPIs. A peer may compress its SPIs differently, in which case a incoming packet may have its SPI compressed to X bits while another packet may have its SPI compressed to Y bits. 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. The ESP extension for IPv6 (and similarly for IPv4) requires a 64-bit (or 32-bit) alignment. Choosing alternative alignment values may result in a packet that fails to comply with this alignment requirement, potentially leading to rejection. The necessity for such alignment in IPv6 extensions arises from the fact that the length field in an IPv6 header extension is defined in terms of 64-bit words, making proper alignment essential for accurate packet parsing. Parsing of ESP does not present complications, as it is compatible with IPv6; the ESP extension is processed exclusively by the terminal IPsec peers and not by intermediary nodes. Furthermore, the ESP extension lacks a dedicated length field. Instead, its length is determined by the IPv6 header Length field, which is measured in bytes, along with the starting position of the ESP header extension. Consequently, it remains entirely feasible to parse an ESP extension that is not aligned to 64 bits. The same principle is applicable to IPv4.

Acknowledgements We extend our gratitude to Laurent Toutain, Ana Carolina Minaburo, Pascal Thubert, and Alexandre Pelov for their guidance on SCHC and their valuable insights concerning the implementation of OpenSCHC . Additionally, we express our appreciation to Robert Moskowitz for his inspiration in coining the term "Diet-ESP," derived from Diet-HIP, as well as to Samita Chakrabart, Tero Kivinen, Michael Richardson, and Valery Smyslov for their enduring support. The authors also wish to acknowledge the assistance provided by Mitacs through the Mitacs Accelerate program.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. Ericsson Concordia University Ericsson Ericsson Concordia University Concordia University LMU Google LLC This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rule Generation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. Ericsson Ericsson Ericsson Ericsson Ericsson This document outlines the DSCP Notification Payload, which, during a CREATE_CHILD_SA Exchange, explicitly indicates the DSCP code points that will be encapsulated in the newly established tunnel. This document updates RFC 4301. Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this. This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK] This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. Informative References n.d. This document describes the minimal properties that an IP Encapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard ESP as defined in RFC 4303. Such a minimal version of ESP is not intended to become a replacement of ESP in RFC 4303. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of ESP. In addition, this document provides some considerations for implementing minimal ESP in a constrained environment, such as limiting the number of flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation. This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description. Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs. IMT Atlantique Consultant This document defines the SCHC architecture. This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK] The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]

Examples of Diet-ESP This appendix provides the details of the SCHC rules defined for Diet-ESP compression, alongside an explanation and illustrative examples for both Tunnel and Transport modes.

Tunnel Mode This section provides a structured example of how Diet-ESP operates in Tunnel Mode. The example includes Attributes for Rule Derivation (AfRD), SCHC rules, the Inner IP packet (IIP), the compression process, and the decompression process.

Json Representation in Tunnel Mode In Tunnel Mode, the full inner IP packet is compressed before ESP encapsulation, with each compression stage applying its own dedicated SCHC rule. The "iipc_diet-esp" profile activates the IIPC rule to compress the inner IPv6 and transport headers. The CTEC rule compresses ESP trailer-related fields such as padding and alignment. The EEC rule handles compression of the ESP SPI and Sequence Number, which are part of the outer ESP header and visible post-encryption. The separation into three rules ensures modularity and clarity: IIPC Rule: compresses source/destination IP addresses using MSB/LSB, compresses ports using LSB, and elides predictable fields like Next Header and Length. CTEC Rule: elides padding and enforces alignment constraints. EEC Rule: compresses ESP SPI and Sequence Number using LSB with an MSB match.

Attributes for Rule Derivation (AfRD) The SCHC rules for Tunnel Mode are derived from the following AfRD:

• IPsec Mode: Tunnel
• Traffic Selector IP Version: IPv6-only
• Traffic Selector Source Address: 2001:db8::1234
• Traffic Selector Destination Address: 2001:db8::5678
• DSCP CDA: Lower
• ECN CDA: Lower
• ESP SPI Compression: LSB
• ESP SN Compression: LSB

Inner IP Packet (IIP) The original packet (IIP), before compression consists of:

• IPv6 Source Address: 2001:db8::1234
• IPv6 Destination Address: 2001:db8::5678
• UDP Source Port: 5001
• UDP Destination Port: 4500
• UDP Length: 16 bytes
• Payload Data

Diet-ESP Compression The rules for the IIPC, CTEC, and EEC layers are defined as IIPC to compress IPv6 headers and UDP headers, CTEC to compress ESP Trailer fields, and EEC to compress ESP SPI and Sequence Number. Each compressor applies the rule selected by the SA as follows:

1. IIPC: UDP Header Compression
   • UDP ports are compressed using the LSB technique.
   • UDP Length is removed (computed at decompression).
   • UDP Checksum is omitted.
2. IIPC: IPv6 Header Compression
   • Source and Destination Addresses are compressed using MSB.
   • Next Header field is omitted.
3. CTEC: ESP Trailer Compression
   • Pad Length and Padding are omitted.
   • Next Header is omitted.
4. EEC: ESP Header Compression
   • SPI and SN are compressed using LSB.
   • Compressed Packet Output

The final compressed packet consists of an EEC packet with a compressed ESP header, a compressed IIP Header, and the payload.

Diet-ESP Decompression The decompression process reverses these steps:

1. EEC: ESP Header Decompression
   • SPI and SN are reconstructed using the LSB values.
2. CTEC: ESP Trailer Decompression (Optional)
3. IIPC: IPv6 Header Decompression
   • ESP Next Header and Padding fields are restored.
   • IPv6 Source and Destination Addresses are restored.
4. IIPC: UDP Header Decompression
   • UDP ports are restored using the decompressed LSB values.
   • UDP Length and Checksum are recalculated.

Transport Mode This section follows the same structure as Tunnel Mode but applies to Transport Mode, where the IP header remains not compressed.

Json Representation in Transport Mode In Transport Mode, the inner IP header is not compressed, and only the UDP header fields (within the inner payload) and the ESP headers are subject to compression. Following the correct SCHC rule structure, the compression logic is split across three rules: The IIPC rule compresses UDP Source and Destination Ports using LSB and elides the Length and Checksum fields using compute-* and checksum CDAs. The CTEC rule compresses ESP trailer fields such as Padding and Next Header, and ensures byte alignment. The EEC rule compresses the ESP SPI and Sequence Number using the LSB approach. Since the inner IP header is retained in Transport Mode, the IP Source and Destination Addresses are not compressed but instead transmitted in full.

Attributes for Rule Derivation (AfRD) The SCHC rules for Transport Mode are derived from the following AfRD:

• IPsec Mode: Transport
• Traffic Selector IP Version: IPv6-only
• Traffic Selector Source Address: 2001:db8::1001
• Traffic Selector Destination Address: 2001:db8::2002
• DSCP CDA: Lower
• ECN CDA: Lower
• ESP SPI Compression: LSB
• ESP SN Compression: LSB

Inner IP Packet (IIP) The original packet before compression consists of:

• IPv6 Source Address: 2001:db8::1001
• IPv6 Destination Address: 2001:db8::2002
• UDP Source Port: 1234
• UDP Destination Port: 5678
• UDP Length: 18 bytes
• ESP Payload Data

Diet-ESP Compression

1. IIPC: UDP Header Compression
   • UDP ports are compressed using the LSB technique.
   • UDP Length is removed (computed at decompression).
   • UDP Checksum is omitted.
2. CTEC: ESP Trailer Compression
   • Pad Length and Padding are omitted.
   • Next Header is omitted.
3. EEC: ESP Header Compression
   • SPI and SN are compressed using LSB.
4. Compressed Packet Output

The final compressed packet consists of the compressed ESP header, IIPC compressed data, and payload.

Diet-ESP Decompression The decompression process mirrors the compression steps, restoring SPI, SN, UDP headers, ESP Next Header, and Padding fields.

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 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.