---
title: ESP Header Compression Profile
abbrev: EHCP
docname: draft-ietf-ipsecme-diet-esp-01
ipr: trust200902
area: Security
wg: IPsecme
kw: Internet-Draft
cat: std
stream: IETF

pi:
toc: yes
sortrefs: yes
symrefs: yes

author:
-
ins: D. Migault
name: Daniel Migault
org: Ericsson
email: [e-mail]

-
ins: M. Hatami
name: Maryam Hatami
org: Concordia University
email: [e-mail]
-
ins: S. Céspedes
name: Sandra Cespedes
org: Concordia University
email: [e-mail]
-
ins: W. Atwood
name: J. William Atwood
org: Concordia University
email: [e-mail]
-
ins: T. Guggemos
name: Tobias Guggemos
org: LMU
email: [e-mail]
-
ins: C. Bormann
name: Carsten Bormann
org: Universitaet Bremen TZI
email: [e-mail]
-
ins: D. Schinazi
name: David Schinazi
org: Google LLC
email: [e-mail]

--- abstract

This document defines how to compress/decompress communications protected with IPsec/ESP using Static Context Header Compression and fragmentation (SCHC). SCHC uses static information from IPv6 headers to reduce redundancy and size of packets on the wire. This specification provides guidelines on the application of SCHC to compress/decompress at different levels of the ESP/IPv6 protected packets, leveraging the information already shared by the peers.

~~~
<Add inside the text that For every SCHC packet we compress the header>

-> (DONE)

~~~

--- middle

# Outline

abstract

Introduction

Terminology

SCHC Integration into the IPsec Stack

SCHC Parameters
- SCHC Context Initialization
- SCHC Rules
- RuleID
- SCHC MAX_PACKET_SIZE
- Fragmentation
- SCHC parameterization for ESP
- New SCHC CDA

Inner IP Compression (IIPC)
- Inner IPv4 Compression

Clear Text ESP Compression (CTEC)
- Inner Packet Payload Compression
- ESP Compression

Encrypted ESP Compression (EEC)

IANA Considerations

Security Considerations

Acknowledgements

Illustrative Example
- Single UDP Session IoT VPN
- Single TCP session for IoT VPN
- Traditoinal VPN
- IPv6 in IPv6
- JSON format Context

# Requirements notation

{::boilerplate bcp14}

# Introduction

The Encapsulating Security Payload (ESP) {{!RFC4303}} protocol can provide confidentiality, data origin authentication, integrity, anti-replay, and traffic flow confidentiality. The set of services ESP provides depends on the Security Association (SA) parameters negotiated between devices.

ESP has two modes: Tunnel and Transport. Tunnel mode is commonly used for VPNs, with the ESP header placed after the outer IP header and before the inner IP packet headers. In Transport mode, the ESP Payload Data consists of the IP Payload, with the ESP header placed after the inner IP packet header and any IP extensions headers.

This document defines the ESP Header Compression profile (EHCP) for compression/decompression (C/D) of IPsec/ESP {{!RFC4301}} / {{!RFC4303}} packets, represented by the structure shown in {{fig-esp}}, using Static Context Header Compression and fragmentation (SCHC) {{!RFC8724}}. Compression with SCHC is based on using a set of Rules, which constitutes the Context of SCHC C/D, to compress or decompress headers. The motivation is to avoid sending information that has already been shared by the peers, thus reducing the ESP packet size on the wire. To better understand ESP, the reader might be interested in reading Minimal ESP {{?RFC9333}}, a simplified version of ESP.

~~~
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) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~
{: #fig-esp artwork-align="center" title="Top-Level Format of an ESP Packet"}

This profile defines three levels of compression:

~~~
<mglt>
s/RFC 8724/{{!RFC8724}} to have the reference in the "reference" section

We always only mention "compression" but there is also a "decompression". I think only mentioning "compression" is fine... but I just want to double check.
</mglt>
~~~

- Inner IP Compression (IIPC): This level happens directly on the inner IP packet. In the case of a UDP packet with ports determined by the SA, fields such as UDP ports and checksums are typically compressed. If no compression of the inner packet is possible, the resulting SCHC packet contains the uncompressed IP packet, as per {{!RFC8724, Section 7.2}}.
- Clear Text ESP Compression (CTEC): This level compresses fields of the ESP payload right before being encrypted.
- Encrypted ESP Compression (EEC): This level compresses ESP fields that remain after encryption, that is, the ESP header.

~~~
<mglt>
The bullets mentions "This", so I suspect that the compressors have been fogotten. I think it might be clearer to name the compressor/ decompressor straight ahead.

The first compressor we mention needs to be described in a more generic term as it is not always a UDP packet. We can leave UDP as an example. I think it is important to include that compressor and not consider it outside IPsec as the **Full** inner packet is taken as an input to select the specific SA. If compression happens BEFORE, we are likely unable to find the SA that matches the packet.
In other words to perform the compression you need the corresponding SA, and to determine the corresponding SA, you need the inner packet.
sa = sadb_lookup( inner_packet )
1_level_compressed_packet = schc( sa, inner_packet )
I am calling this layer Inner IP Compression as I have not found it mentioned in the terminology section, but we can name it differently.

Maybe I would propose something around the lines:

- Inner IP Compression (IIPC): This level happens directly on the inner IP packet. In the case of an UDP packet with ports determined by the SA, fields such as UDP ports and checksums are typically compressed.
- Clear Text ESP Compression (CTEC): This level compresses fields of the ESP payload right before being encrypted.
- Encrypted ESP Compression (EEC): This level compresses ESP fields that remain after encryption, that is the ESP header.

</mglt>
~~~

The descriptions of the three levels of compression provided in this document are general purpose descriptions based on SCHC. It is possible that SCHC contexts from different levels can be merged under certain conditions. Typically, IIPC and CTEC happen under the same SA and some implementations may chose to merge these two levels.

~~~
<mglt>
I think that what we want to say is that the description we provide does not mandate the implementation to follow what we describe, but simply to ensure that it results in the same outputs.
We also want to say that specific application layer might be performed in the future. Since we mention that this document only focus on L3/L4 probably the lines "Furtherm,ore, while .... " might be moved after the next paragraph.

I would propose the following lines:

The description with the three level of compression provided in this document is a general purpose description based on SCHC. It is likely in some context some level of compression can be merge. Typically IIP and CTEC happens under the same SA and some implementation may chose to merge these levels. In addition, while SCHC is used for the description, implementation may chose to not rely on the generic SCHC framework and instead have specific routings that results in the same outputs as the standardized SCHC compression framework.

</mglt>
~~~

<!-- (Clear Text ESP Compression and Encrypted ESP Compression). -->

This document provides the ESP Header Compression profile (EHCP) architecture with the integration of SCHC into various levels of the IPsec stack. For each compressor/decompressor level, it defines the ESP fields to be considered in the rules of its corresponding SCHC context. In addition, it defines how the SCHC contexts are initialized from the SA and provides the corresponding SCHC rules (RuleID, SCHC MAX_PACKET_SIZE, new SCHC Compression/Decompression Actions (CDA), and fragmentation). The appendix provides illustrative examples of applications of EHC using an implementation in openschc.

~~~
<mglt>
I am not sure we introduced compression/decompression process. I am wondering if we should not stick to compresor/decompressor.
</mglt>
~~~

~~~
<mglt>
I think "It will also detail" could be "For each compressor/decompressor,". I think that ESP headerS means the various intermediary steps we introduce, but this is bnnot a very common terminology used, so it is probably better not to introduce it now. I would also just keep SCHC rather than expanding it, mostly because it makes it more readable and that we do not want to insist on Fragmentation.

If I understand it correctly I would propose the following lines:

For each compressor, we define the new (ESP) fields to be considered by the different SCHC comppressor/decompressors, how the SCHC context is initialized from the SA, and the corresponding SCHC rules ( RuleID, SCHC MAX_PACKET_SIZE, new SCHC Compression/Decompression Actions (CDA), and fragmentation )
</mglt>
~~~

~~~
<mglt>
We probably only need to mention that the appendix contains some illustrative examples implemented with openschc.

</mglt>
~~~

# Terminology

ESP Header Compression Profile (EHCP): A method to reduce the size of ESP headers using predefined compression rules and contexts to improve efficiency.

Inner IP C/D (IIPC): Expressed via the SCHC framework, IIPC compresses/decompresses the inner IP packet headers.

Clear Text ESP C/D (CTEC): Expressed via the SCHC framework, CTEC compresses/decompresses all fields that will later be encrypted by ESP.

Encrypted ESP C/D (EEC): Expressed via the SCHC framework, EEC compresses/decompresses ESP fields that will not be encrypted by ESP.

Security Parameters Index (SPI): As defined in {{!RFC4301, Section 4.1}}.

Sequence Number (SN): As defined in {{!RFC4303, Section 2.2}}.

Static Context Header Compression (SCHC): A framework for header compression designed for LPWANs, as defined in {{!RFC8724}}.

Static Context Header Compression Rules (SCHC Rules): As defined in {{!RFC8724}}, Section 5.

RuleID: A unique identifier for each SCHC rule, as defined in {{!RFC8724}}, Section 5.1.

SCHC Context: The set of parameters and rules shared between communicating entities, as defined in {{!RFC8724}}, Section 5.3.

It is assumed that the reader is familiar with other SCHC terminology defined in {{!RFC8376}} and {{!RFC8724}}.

~~~
<mglt>
We are probably missing Inner IP Compression / decompression.
The way reference work in markdown are {{!RFC4303}} for normative references and {{?RFC4343}} for non normative reference. For now just use normative references by default. I think that {{!RFC4303, Section 2.8}} works as well.

-> (DONE)

</mglt>
~~~

# SCHC Integration into the IPsec Stack

The main principle of the ESP Header Compression Profile (EHCP) is to avoid sending information that has already been shared by the peers. Different profiles and technologies, such as those defined by {{!RFC4301}} and {{!RFC4303}}, ensure that ESP can be tailored to various network requirements and security policies. However, ESP is not optimized for bandwidth efficiency because it has been designed as a general-purpose protocol. EHCP aims to address this by leveraging a profile, expressed via the SCHC framework, to optimize the ESP header sizes for better efficiency in constrained environments.

Profiles for compression are derived from parameters associated with the Security Association (SA) and agreed upon via IKEv2 {{!RFC7296}}, as well as specific compression parameters defined in IKEv2 {{!I-D.mglt-ipsecme-ikev2-diet-esp-extension}}. As depicted in {{fig-arch}}, this document defines three levels of compression, as previously described: IIPC, CTEC, and EEC. The terminology of "levels" is used consistently throughout the document for clarity.

The {{fig-arch}} illustrates the integration of SCHC into the IPsec stack, detailing the different levels and components involved in the compression and decompression processes. The diagram is divided into two entities, each representing an endpoint of a communication link.

~~~
removed as redundant:

- Inner IP Compression (IIPC): This level happens directly on the inner IP packet. In the case of a UDP packet with ports determined by the SA, fields such as UDP ports and checksums are typically compressed. If no compression of the inner packet is possible, the resulting SCHC packet contains the uncompressed IP packet, as per {{!RFC8724, Section 7.2}}.
- Clear Text ESP Compression (CTEC): This level compresses fields of the ESP payload right before being encrypted.
- Encrypted ESP Compression (EEC): This level compresses ESP fields that remain after encryption, that is, the ESP header.
~~~
~~~
<mglt>
We need to have the same Terminology as in the introduction. Since I am reading "Pre-IPsec" I think I understand where the confusion is and I believe "inner IP compression" is probably clearer.

-> (DONE)

We can repeat text for now, in intro and in that section, but usually we should avoid repeating and then wonder why we need to repeat. Maybe it is fine also.

->(DONE)

</mglt>
~~~

Note that potentially, the inner IP packet could be compressed within the Clear Text ESP, but this would vary depending on whether IPsec is used in Transport mode or Tunnel mode. Thus, it is simpler to perform this compression before IPsec. Furthermore, while the scope of this compression profile currently does not extend beyond the transport layer (i.e., UDP), there will eventually be a need to compress the application layer as well.

~~~
<mglt>
We need to align with the Intro.

-> (DONE)

</mglt>
~~~

The decompression of the inbound packet follows a reverse process. First, the Encrypted ESP C/D (EEC) decompresses the encrypted ESP header fields. After the ESP packet is decrypted, the Clear Text ESP C/D (CTEC) decompresses the Clear Text fields of the ESP packet.

Note that implementations MAY differ from the architectural description but it is assumed the outputs will be the same.

~~~
<mglt>
s/two phases/3 phases/
I think we can remove the first sentence "SCHC integration....", but it is also fine keeping it. I think it is better to call both entities as End points as there is not necessary a distinction between the peers.
In the diagram, it is important to clarify PIC happens withing ESP.
The diagram is using the term "phase", we used "level" in the intro. We should probably pick one and keep that one through the document. I like 'level' but I do not have a strong opinion.

-> (DONE)

</mglt>
~~~

~~~
+--------------------------------+
| ESP Header Compression Context |
| - Security Association |
| - Additional Parameters |
+--------------------------------+
|
Endpoint | Endpoint
|
+----------------+ | +----------------+
| Inner IP packet| | | Inner IP packet|
+----------------+ | +----------------+
| SCHC |+----------------IIPC level---------------------+| SCHC |
+----------------+ | +----------------+
| ESP | | | ESP |
| (encapsulation)| | | (unwrapping) |
+----------------+ v +----------------+
| SCHC |+----------------CTEC level---------------------+| SCHC |
+----------------+ EHC, C {IP, UDP, ESPT} +----------------+
| ESP | | | ESP |
| (encryption) | | | (decryption) |
+----------------+ v +----------------+
| SCHC | +-----------------EEC level--------------------+| SCHC |
+----------------+ C {IP, EH, IP, UDP} +----------------+
| IPv6 + ESP | | IPv6 + ESP |
+----------------+ +----------------+
| L2 | | L2 |
+----------------+ +----------------+
| |
+-------------------------communication----------------------------+
L2, RID, C {IP, EH, IP, UDP}

~~~
{: #fig-arch artwork-align="center" title="SCHC Integration into the IPsec Stack"}

~~~
<mglt>
PIC should be in ESP. I do not think we should mention extra application compression. Typically:
1) Either we agree that we compress at the application level. In that case IPsec will be set for SCHC packets (not UDP).
2) We agree to compress the UDP application within IPSec and in taht case IPsec is configured with UDP packets.

-> (DONE)

</mglt>
~~~
In the figure:
- Packet Integrity Check (PIC) happens within ESP.
- C is for Compressed headers for the fields inside.
- L2, RID, C {IP, EH, IP, UDP} shows the complete compressed packet with Layer 2, Rule ID, and compressed headers for IP, ESP Header, IP, and UDP.

# SCHC parameters

If ESP incorporates SCHC, it is essential that these scenarios use the SCHC header compression {{!RFC8724}} capability to optimize data transmission.

In order to work properly, the different levels of C/D need to be configured similarly with the same SCHC Context Initialization. This involves defining variables such as SCHC MAX_PACKET_SIZE or Fragmentation that are invariants in our case, as well as SCHC Rules that are expected to be set on a per SA basis.

~~~
<mglt>
The sentence above is a bit unclear to me. I think that one of the reason is that it looks SCHC is optional... In the introduction we said that we use SCHC, so there is no doubts now ;-).

I think what we are willing to say is that:

In order to work properly, the different levels of compressors need to be configured similarly with the same SCHC Context Initialization. This involves the definition of variables such as SCHC MAX_PACKET_SIZE or Fragmentaion that ar invariants in our case as well as SCHC Rules that are expected to be set on a per SA basis. This section defines the EHC Context, that is the necessary variables derived from the SA to derive the SCHC Rules in {{tab-ehc-ctx-esp}}, as well as new compression actions that are needed to express the SCHC Rules in section {{sec-cda}}.

I have not mentioned Rule ID. The question I have is whether we need to agree on specific id or not as I had the impression that it is compressed anyway. If that the case, we do not need to have a given rule id shared between the peers. But that might worth being explicitly mentioned somewhere.

The title might be changed to "SCHC parameters" The current one might be a bot too long.

->(DONE)

</mglt>
~~~

The EHCP Context provides the necessary information to generate the SCHC Rules.
Most pieces of information are already available from the negotiated SA {{!RFC4301}}.
Other pieces of information need to be specifically configured or agreed via other mechanisms, such as {{?I-D.mglt-ipsecme-ikev2-diet-esp-extension}}.

The reference column in {{tab-ehc-ctx-esp}} indicates how the information is defined. The C/D column specifies in which of the compression levels the parameter is being used.

Note that additional Compression might be performed especially on the inner IP packet - for example, including the TCP layer.
However, this profiles limits the scope of the compression to the inner IP header, and possibly UDP headers. We believe this is a reasonable scope for ESP to address both IoT UDP packets as well as large VPN traffic.
If further compression is needed, this should be achieved by sending an IP packet with a SCHC payload, where the expected compression is achieved outside ESP.

## SCHC Context Initialization
SCHC Context Initialization involves setting up the initial parameters and values that will be used for compressing and decompressing ESP headers. This includes defining the static context, which contains all the rules and parameters necessary for the SCHC operations. The context is shared between the sender and receiver to ensure consistent compression and decompression processes. Initialization ensures that both ends have a common understanding of the fields, their possible values, and how to handle them during communication.

## SCHC Rules
SCHC Rules are predefined sets of instructions that specify how to compress and decompress the header fields of an ESP packet. Each rule is designed to handle specific patterns and variations in the header fields, allowing for efficient compression by eliminating redundancy and leveraging the static context. Rules are identified by RuleIDs and are crucial for mapping the fields correctly during the compression and decompression processes.

~~~
<SCHC Rule IDs and Actions are required --for later-- in a SCHC way mention that the rule id can be defined by the other party>
-> (DONE)
~~~

## Rule ID
The RuleID is a unique identifier for each SCHC rule, included in packets to ensure the receiver applies the correct decompression rule, maintaining consistency in packet processing. Note that the Rule ID does not need to be explicitly agreed upon and can be defined independently by each party.

## SCHC MAX_PACKET_SIZE
This field defines the largest size of a compressed ESP packet that can be handled. It ensures packets fit within network limits, optimizing transmission and avoiding unnecessary fragmentation. Note that the SCHC MAX_PACKET_SIZE varies based on the packet because it is not specific to any particular lower-layer (LL) technology. This flexibility allows SCHC to be adapted to various network environments and constraints.

## Fragmentation
The resulting IP/ESP packet size is variable. In some networks, the packet will require fragmentation before transmission over the wire. Fragmentation is out of the scope of this document since it is dependant on the layer 2 technology.

## SCHC parameterization for ESP

The following attributes are considered in the EHCP Context.
Implementations may consider different expressions of the parameters but their behavior is expected to remain compatible with this specification.

SCHC Context parameterization:

~~~
+===================+==========================+===========+=======+
| EHC Context | Possible Values | Reference | C / D |
+===================+==========================+===========+=======+
| alignment | "8 bit", "32 bit" | ThisRFC | CTEC |
| ipsec_mode | "Tunnel", "Transport" | RFC4301 | CTEC |
| tunnel_ip | IPv4, IPv6 address | RFC4301 | CTEC |
| esp_spi | ESP SPI | RFC4301 | EEC |
| esp_spi_lsb | 0, 1, 2, 3, 4* | ThisRFC | EEC |
| esp_sn | ESP Sequence Number | RFC4301 | EEC |
| esp_sn_lsb | 0, 1, 2, 3, 4* | ThisRFC | EEC |
| esp_encr | ESP Encryption Algorithm | RFC4301 | CTEC |
| ts_flow_label | True, False | ThisRFC | CTEC |
| ts_ip_version | 4, 6 | ThisRFC | CTEC |
| ts_ip_src_start | IP4 or IPv6 address | ThisRFC | CTEC |
| ts_ip_src_end | IP4 or IPv6 address | ThisRFC | CTEC |
| ts_ip_dst_start | IPv4 or IPv6 address | ThisRFC | CTEC |
| ts_ip_dst_end | IPv4 or IPv6 address | ThisRFC | CTEC |
| ts_proto_list | TCP, UDP, ..., 0 | ThisRFC | CTEC |
| ts_port_src_start | Port number | ThisRFC | CTEC |
| ts_port_src_end | Port number | ThisRFC | CTEC |
| ts_port_dst_start | Port number | ThisRFC | CTEC |
| ts_port_dst_end | Port number | ThisRFC | CTEC |
| ts_dsp_list | DSCP number | RFCYYYY | CTEC |
+-------------------+--------------------------+-----------+-------+
~~~
{: #tab-ehc-ctx-esp artwork-align="center" title="EHCP related parameters"}

alignment:
: indicates the byte alignement supported by the OS for the ESP extension. By default, the alignement is 32 bit for IPv6, but some systems may also support an 8 bit alignement. Note that when a block cipher such as AES-CCM is used, an 8 bit alignment is overwritten by the block size.

ipsec_mode:
: designates the IPsec mode defined in {{!RFC4301}}. In this document, the possible values are "tunnel" for the Tunnel mode and "transport" for the Transport mode.

tunnel_ip:
: designates the IP address of the tunnel defined in {{!RFC4301}}.
This field is only applicable when the Tunnel mode is used.
That IP address can be an IPv4 or IPv6 address.

esp_spi:
: designates the Security Policy Index defined in {{!RFC4301}}.

esp_spi_lsb:
: designates the LSB to be considered for the compressed SPI. This parameter is defined by this specification and can take the following values 0, 1, 2, 4 respectively meaning that the compressed SPI will consist of the esp_spi_lsb LSB bytes of the original SPI.
A value esp_spi_lsb will leave the SPI unchanged.

esp_sn:
: designates the Sequence Number (SN) field defined in {{!RFC4301}}.

esp_sn_lsb:
: designates the LSB to be considered for the compressed SN and is defined by this specification. It works similarly to esp_spi_lsb.

esp_encr:
: designates the encryption algorithm used. For the purpose of compression it is RECOMMENDED to use {{!RFC8750}}.

ts_ *:
: Any parameter starting with "ts_". These parameters are associated with the Traffic Selectors of the SA and are introduced by this specification.
This specification limits the expression of the Traffic Selector to be of the form (IP source range, IP destination range, Port source range, Port destination range, Protocol ID list, DSCP list).
This limits the original flexibility of the expression of TS, but we believe that it provides sufficient flexibility. Following shows detail information of these parameters.

ts_flow_label:
: indicates the Flow Label field of the inner IPv6 packet or the Identification field of the inner IPv4 packet is copied from the outer IP address.

ts_ip_version:
: designates the IP version of the Traffic Selectors and its value is set to 4 when only IPv4 IP addresses are considered and to 6 when only IPv6 addresses are considered.
Practically, when IKEv2 is used, it means that the agreed TSi or TSr results only in a mutually exclusive combination of TS_IPv4_ADDR_RANGE or TS_IPV6_ADDR_RANGE payloads.
When the traffic selectors result in a combination of IPv4 and IPv6 addresses, ts_ip_version is undefined.

ts_ip_src_start:
: designates the starting value range of source IP addresses of the inner packet and has the same meaning as the Starting Address field of the Traffic Selector payload defined in {{!RFC7296, Section 3.13}}.
Note however that in this specification, ts_ip_src_start applies for all agreed Traffic Selector payloads.
When the IP addresses cannot be expressed as a range, that can be exactly expressed as [ ts_ip_src_start, ts_ip_src_end ], ts_ip_src_start is undefined.

ts_ip_src_end:
: designates the high end value range of source IP addresses of the inner packet and has the same meaning as the Ending Address field of the Traffic Selector payload defined in {{!RFC7296, Section 3.13}}.
Similarly to ts_ip_src_end, when the IP addresses cannot be expressed as a range, ts_ip_src_end is undefined.

ts_port_src_start:
: designates the starting value of the port range of the inner packet and has the same meaning as the Start Port field of the Traffic Selector payload defined in {{!RFC7296, Section 3.13}}.

ts_port_src_end:
: designates the starting value of the port range of the inner packet and has the same meaning as the End Port field of the Traffic Selector payload defined in {{!RFC7296, Section 3.13}}.

ts_proto_list:
: designates the list of Protocol ID field, whose meaning is defined in {{!RFC7296, Section 3.13}}.

ts_dscp_list:
: designates the list of DSCP values used by the Traffic Selector and has the same meaning as the List of DSCP Values defined in {{!I-D.mglt-ipsecme-ts-dscp}}.

IP addresses and ports are defined as a range and compressed using the LSB.
For a range defined by start and end values, msb( start, end ) is defined as the function that returns the MSB that remains unchanged while the value evolves between start and end.
Similarly, lsb( start, end ) is defined as the function that returns the LSB that changes while the value evolves between start and end.
Finally, len( x ) is defined as the function that returns the number of bits of the bit array x.

Protocol IDs and DSP are defined as lists of non consecutive values.
A target value is defined when the list contains a single element.

~~~
<mglt>
Do we use that notation ? If not we should remove it.

-> (Done)

One question we will need to question IPsec is whether ranges are sufficient, or if we need to consider multiple ranges.

-> (Not sure about the answer that if more ranges are required. but if needed, more RuleIDs with more context
can be defined. or as stated in the newest versions of SCHC profiles,
one Rule for a set of contexts can be defined.)

</mglt>

~~~

## New SCHC CDA

In addition to the Compression / Decompression Actions defined in {{!RFC8724, Section 7.4}}, this specification uses the CDA as presented in {{tab-cda}}.
These CDA are either a refinement of the compute- * CDA or the result of combined CDA.

~~~
+=================+=====================+=============================+
| Action | Compression | Decompression |
+=================+=====================+=============================+
| lower | elided | Get from lower layer |
| checksum | elided | Compute checksum |
| padding | elided | Compute padding |
+-----------------+---------------------+-----------------------------+
~~~
{: #tab-cda artwork-align="center" title="EHCP ESP related parameter"}

More specifically, when the list contains 0 or a single element, that value can be decompressed without ambiguity and as such an index does not need to be sent.
When more than one value is present in the list, the index needs to be sent.

~~~
<mglt>
I am wondering if these cda needs to be defined ? It looks to me as legacy text and we should expect changes on this.
Typically, we need to check lower works fine and is acceptable.

-> (Done)

</mglt>
~~~

# Inner IP Compression (IIPC)

When ts_ip_src/dst range is defined and ts_ipversion is set to "IPv6," IPv6 addresses of the inner IP packet are compressed. This inner packet compression always occurs.
FL is set to 128, TV to msb(ip_src) or msb(ip_dst), the MO is set to "MSB," and the CDA is set to "LSB."

The IPv6 Hop Limit is compressed/decompressed.
FL is set to 8 bits, TV is omitted, MO is set to "ignore," and CDA is set to "lower."

The last Next Header with a transport protocol value is compressed/decompressed.
FL is set to 8 bits. If ts_proto_list contains the value 0, TV is not set, MO is set to "ignore," and CDA is set to "value-sent."
If "proto_id" does not contain 0 and the list contains one or fewer values, TV is set to that value, MO is set to "equal," and CDA is set to "not-sent."
In any other case, TV is set to the proto_list, MO is set to "match-mapping," and CDA is set to "mapping-sent."

The IPv6 Total Length is compressed/decompressed.
FL is set to 16 bits, TV is not set, MO is set to "ignore," and CDA is set to "lower."

Traffic Class is compressed/decompressed similarly to the DSP and ECN fields.
FL is set to 8 bits. When the DSP and ECN are defined by the SA via {{!I-D.mglt-ipsecme-ts-dscp}} and ts_dsp_list contains a single element, TV is set to that element, MO is set to "equal," and CDA is set to "not-sent."
When the DSP and ECN are defined by the SA via {{!I-D.mglt-ipsecme-ts-dscp}} and ts_dsp_list contains more than one element, TV is set to the list, MO is set to "match-mapping," and CDA is set to "mapping-sent."
When the DSP and ECN are not defined by the SA, MO is set to "ignore," and the CDA is set to "lower."

When ts_ip_version can be inferred from the ts, the IP version is elided.
FL is set to 4 bits, TV is set to ts_ip_version, MO is set to "equal," and CDA to "not-sent."

When the inner IP address has the same version as the outer_ip and ts_traffic_flow is defined and set to True, the Identification field of the IPv4 inner packet or the Traffic Flow field of the IPv6 packet is elided and read from the outer IP address field.
For IPv6, FL is set to 20 bits, TV is ignored, MO is set to "ignore," and CDA is set to "lower."

When the inner IP is IPv6 and the outer IP is IPv4 and ts_traffic_flow is set to True, the LSB 16 bits of the inner Traffic Flow fields are set to the outer Identification field and the remaining 4 MSB bits are set to 0.
Such compression is not lossless and needs to be considered cautiously.
Note that the Flow Label of the inner packet arriving at the destination may have another value than the initial Flow Label. However, the Flow Label value set at the source ends up with the same value at the destination, with, of course, a lower entropy.

## Inner IPv4 Compression {#sec-inner-ip4}
The compression/decompression of IPv4 fields are similar to IPv6, with some differences. IPv4 addresses are compressed/decompressed similarly to IPv6 addresses except that FL is set to 32.

The IPv4 Header checksum is elided.
FL is set to 16, TV is omitted, MO is set to "ignore," and CDA is set to "checksum."

The IPv4 TTL field is derived from the IPv4 TTL field of the outer IPv4 address or the IPv6 Hop Limit.
FL is set to 8 bits, TV is omitted, MO is set to "ignore," and CDA is set to "lower."

The IPv4 Total Length is elided.
FL is set to 16 bits, TV is not set, MO is set to "ignore," and CDA is set to "lower."

# Clear Text ESP Compression (CTEC)

~~~
<mglt>
I think we should start with Inner IP compression, then CTE,

-> (Done)

</mglt>
~~~

The Clear Text ESP Compression is performed on the ESP fields not yet encrypted, that is the ESP Payload Data, the ESP padding field, the Pad Length field as well as the Next Header field, which indicates the type of the inner packet.

When ipsec_mode is set to "Transport", the Clear Text ESP packet that corresponds to an IPv4 packet will have the Payload Data set to the IPv4 Payload and the Next Header set to the Protocol ID - that is typically UDP, TCP or SCHC when the payload results from an SCHC compression.
The Clear Text ESP packet that corresponds to an IPv6 packet will have the Payload Data set may include some IPv6 extensions that precede the IP payload. In that case, the Next Header will have the value that corresponds to that first IPv6 extension being encrypted.

When ipsec_mode is set to "Tunnel", the Clear Text ESP packet has the Payload Data set to the IP packet with the Next Header field indicating whether this is an IPv4, an IPv6 or an SCHC packet.

SA are unidirectional and the Direction Indicator (DI) reflects that direction and is set to Up for outbound SA and Down for inbound SA.
Fields that are not compressed have no Target Value (TV), their Matching Operator (MO) is set to ignore and Compression/Decompression Actions (CDA) to "value-sent".
Unless specified the Field Position (FP) is set to 1.

Note that for both the IP payload and the IP header, some fields are Compressed / Decompressed independently of the value of Traffic Selectors EHC Context, while some other fields require the Traffic Selectors to be expressed under a specific format.

## Inner Packet Payload Compression {#sec-payload}

An SCHC payload is not compressed.

If the inner IP payload is an UDP or TCP packet the checksum is elided.
For both TCP or UDP, FL is set to 16 bit, TV is not set, MO is set to "ignore" and CDA is set to "checksum".
This may result in decompressing a zero-checksum UDP packet with a valid checksum, but this has no impact as a valid checksum is universally accepted.

If the inner packet is an UDP or UDP-Lite the length field is elided.
FL is set to 16, TV is not set, MO is set to "ignore" and CDA is set to "lower" as the length field of the decompressed UDP packet is expressed in bytes and is derived from the length of the compressed UDP packet by adding the 16 bit UDP Checksum, the 16 bit UDP Length field as well as the respective length of the respective source MSB port and destination MSB ports.

~~~
UDP.Length = ( len( compressed UDP) + 16 + 16 + len( lsb( port_src ) ) \
+ len( lsb( port_src ) ) ) / 8
~~~

Note that for each SA, LSB and MSB are of fixed length.
When the port has a single value this is equivalent to TV containing the port value, MO is set to "equal" and CDA set to not_sent.

## ESP Compression

When ipsec_mode is set to "Tunnel" and ts_ip_version can be determined, the Next Header Field is elided.
FL is set to 8 bits, TV is set to IPv4 or IPv6 depending on the ts_ip_version, MO is set to "equal" and CDA is set to "not-sent".

If the esp_encr does not require a specific block size, Padding and Pad Length are elided.
FL is defined by the type that is to (Pad Length + 1 ) * 8 bits, TV is unset, MO is set to "ignore" and CDA is set to padding.

Encryption may require require the clear text to respect a given size block.
In addition, IP networking may also require a special alignment which is 32 bits by default for IPv6 Extensions, but may also be overwritten by the EHC Context.
The Padding is defined by pad_value and pad_size appended to the clear text payload - similarly to what ESP does with Padding and Pad Len.
An 8 bit alignment is interpreted by SCHC as a Word of 8 bits, and a 32 bit alignment is interpreted as a Word of 32 bits.
The padding size pad_size is defined by the alignment and set to 3 bits for an 8 bit alignment (23) and 5 bits for 32 bit alignment (2**5).
If pad designates the number of bits to be padded, the pad value is set to pad_value = ( pad + len( pad_size ) % Word.
This results in an additional pad_value + pad_size bits.

# Encrypted ESP Compression (EEC)

SPI is compressed to its LSB.
FL is set to 32 bits, TV is not set, MO is set to "MSB( 4 - esp_spi_lsb)" and CDA is set to "LSB".

If the esp_encr considers implicit IV {{!RFC8750}}, Sequence Numbers are not compressed. Otherwise, SN are compressed to their LSB similarly to the SPI.
FL is set to 32 bits, TV is not set, MO is set to "MSB( 4 - esp_spi_lsb)" and CDA is set to "LSB".

Note that the use of implicit IV always result in a better compression as a 64 bit IV to be sent while compression of the SN alone results at best in a reduction of 32 bits.

The IPv6 Next Header field or the IPv4 Protocol that contains the "ESP" value is changed to "SCHC".

# IANA Considerations

There are no IANA parameters to be registered.

# Security Considerations

There is no specific considerations associated with the profile other than the security considerations of ESP {{!RFC4303}} and those of SCHC {{!RFC8724}}.

# Acknowledgements

We would like to thank Laurent Toutain for its guidance on SCHC. Robert Moskowitz for

--- back

# Illustrative Example

## Single UDP Session IoT VPN {#sec-iot-udp}

This section considers a IoT IPv6 probe hosting a UDP application.
The probe is dedicated to a single application and establishes a single UDP session with a server, and sets a VPN to connect its secure domain - like a home gateway.
The home gateway will be responsible to decompress the compress packet and provides interoperability with standard application server.

The EHC Context is defined as mentioned below:

* alignment is set to 8 bits
* ipsec_mode is set to "Tunnel"
* tunnel_ip_srct is set to the IPv6_m, the IPv6 address of the mote.
* tunnel_ip_dst is set to IPv6_gw, the IPv6 of the security gateway.
* esp_spi is agreed by the IKEv2.
* esp_spi_lsb is set to 0 as IPv6_m provides sufficient context to associate the right SA.
* esp_sn results from the standard IPsec, and not impacted.
* esp_sn_lsb is set to 2 even though we are considering AES-CCM_8_IIV {{!RFC8750}} which uses the ESP Sequence Number to generated the IV.
This results in a 8 bytes reduction compared to the AES-CCM_8 {{?RFC4309}}.
* esp_encr is configured with AES-CCM_8_IIV {{!RFC8750}}. This cipher suite does not require a block size and so no padding is required and does not support SN compression.
* ts_flow_label As the inner traffic and the encrypted traffic are very correlated, it makes sense to re-use the flow label and ts_flow_label is set to True.
* ts_ip_version is set to IPv6.
* ts_ip_src_start is set to IPv6_m. In this example, the SA is associated to messages sent by the mote to the application server (IPv6_server)
* ts_ip_src_end is set to IPv6_m
* ts_ip_dst_end the IPv6 address of the application server (IPv6_server).
* ts_ip_dst_end IPv6_server
* ts_proto_list [ UDP ], in the case of a very constraint mote, only UDP messages are considered.
* ts_port_src_start port_m. The mote and the application server are using dedicated ports.
* ts_port_src_end port_m. The mote and the application server are using dedicated ports. The use of a specific single port enables their elision.
* ts_port_dst_end port_server
* ts_port_dst_end port_server
* ts_dsp_list [ 0 ] the default standard value, we MAY assume that value has been negotiated via IKEv2 or that it as been set as the default value left to the lower layers.

{{fig-std-udp-tunnel}} illustrates an UDP packet being protected by ESP in the tunnel mode using AES-CCM_8_IIV.
This packet is compressed as depicted in {{fig-comp-udp-tunnel}}.
EHC reduces the packet size by 53 bytes.

~~~
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
U| source port | dest port |d t
D+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| length | checksum || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
-| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |v v
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~
{: #fig-std-udp-tunnel artwork-align="center" title="Standard ESP packet for IoT UDP in Tunnel mode more with AES-CCM_8_IIV" }

~~~
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| Sequence Number | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | aut
| | hen
~ APPLICATION DATA ~ tic
| (encrypted) | ate
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | V
+-+-+-+-+-+-+-+-+ |--
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
~~~
{: #fig-comp-udp-tunnel artwork-align="center" title="EHC ESP packet for IoT UDP in Tunnel mode more with AES-CCM_8_IIV" }

## Single TCP session IoT VPN

This section is very similar to {{sec-iot-udp}} except that a TCP session is used instead.

The compression on the TCP payload is very limited, and in a case where the TCP end point is the same as the ESP end point additionnal compression could be performed.
Additional fields such as TCP options, urgent pointers, the SN and ACK Number could be compressed by a specific profile agreed at the TCP level as opposed to the ESP level.

The ESP encapsulated TCP packet described in {{fig-std-tcp-tunnel}} is compressed by EHCP using th esam eEHCP context as in {{sec-iot-udp}} and EHCP reduces that packet by 55 bytes, as depicted in {{fig-comp-udp-tunnel}}.

~~~
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
T| source port | dest port |d t
C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| Sequence Number (SN) || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| ACK Sequence Number || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
|Off. | Rserv | Flags | Window Size || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| Checksum | Urgent Pointer || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |V V
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~
{: #fig-std-tcp-tunnel artwork-align="center" title="Standard ESP packet for IoT TCP in Tunnel mode more with AES-CCM_8_IIV" }

~~~
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Sequence Number (SN) (ESP) | Sequence Number ~ ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
~ (SN) (TCP) | ACK ~^ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| a
~ Sequence Number |Off. | Rserv | Flags || u
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e t
| Window Size | Urgent Pointer |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c |
| Urgent Pointer | |r |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |y |
| ~p |
~ APPLICATION DATA |t |
| || |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| | |v v
+-+-+-+-+-+-+-+-+ |---
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
~~~
{: #fig-comp-tcp-tunnel artwork-align="center" title="EHC ESP packet for IoT TCP in Tunnel mode more with AES-CCM_8_IIV" }

## Traditional VPN

This section illustrates the case of an company VPN that allows web browsing.
The VPN is typically set by a remote host that forwards all its traffic to the
security gateway.
In this case, the SA does not specify the protocol (TCP and UDP packet can be sent), nor the ports.
Regarding ports it could be possible to restrict the user to only use high range ports (0 - 2 ** 10) - especially if the VPN is only supporting web browsing - but we did not consider this in this example.
The destination IP address is also expect to take any value, while the IPv6 source in the case of a road warrior scenarios us expected to take a single value.
We consider the VPN client is using an IPv4 or an IPv6 address.
Regarding ESP, we considered the VPN client is using AES-GCM_16, though AES-GCM_IIV would be the RECOMMENDED transform.
The VPN client is also expected to have a reasonably low throughput which enables the SN to be coded over 16 bits as opposed to 32 bits.
Similarly, the number of connection is expected to remain sufficiently low so that a 16 bit SPI remains sufficient.

The EHC Context is defined as mentioned below:

* alignment is set to 8 bits
* ipsec_mode is set to "Tunnel"
* tunnel_ip_src is set to the IPv6_user, the IPv6 address of the mote.
* tunnel_ip_dst is set to IPv6_gw, the IPv6 of the security gateway.
* esp_spi: is agreed by the IKEv2.
* esp_spi_lsb: is set to 2 bytes.
* esp_sn: results from the standard IPsec, and not impacted.
* esp_sn_lsb: is set to 16 bits. Note that such compression is possible since AES-GCM_16 is used instead of AES-GCM_16_IIV.
While this results in better performances for EHC, it is not an optimal choice as IIV transforms results always in better comprehensions.
* esp_encr: is configured with AES-GCM_16 {{!RFC8750}}.
* ts_flow_label: is set to True, note as the outer IP address is IPv6, the compression is lossless.
* ts_ip_version: is set not set as the VPN user can use either an IPv4 or an IPv6 address.
* ts_ip_src_start: is set to IPv6_user or IPv4_user. Note that the version can be inferred by the Next Header, and the version can deterministically determine the IP in use.
* ts_ip_src_end: is set to IPv6_user or IPv4_user
* ts_ip_dst_end: IP destination is set to take any value, so the range is unspecified and the start/ end addresses are undefined.
* ts_ip_dst_end: undefined.
* ts_proto_list: undefined
* ts_port_src_start: undefined.
* ts_port_src_end: undefined.
* ts_port_dst_end: undefined
* ts_port_dst_end: undefined
* ts_dsp_list: [ 0 ] the default standard value, we MAY assume that value has been negotiated via IKEv2 or that it as been set as the default value left to the lower layers.

## IPv6 in IPv6

{{fig-std-vpn-tunnel-66}} represents the original ESP TCP packet with IPv6 inner IP addresses and {{fig-comp-vpn-tunnel-66}} represents the corresponding packet compressed with EHC.

The compression with Diet-ESP results in a reduction of 32 bytes.

~~~
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| IV | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
T| source port | dest port |d t
C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| Sequence Number (SN) || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| ACK Sequence Number || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
|Off. | Rserv | Flags | Window Size || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| Checksum | Urgent Pointer || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
-| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |V V
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| |
| Integrity Check Value-ICV (variable) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~
{: #fig-std-vpn-tunnel-66 artwork-align="center" title="Standard ESP packet for VPN traffic mode with AES-GCM_16" }

~~~
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| SPI | SN | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| IV | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
| Next Header | |^ |
+-+-+-+-+-+-+-+-+ || |
| || |
| inner destination IP || |
| || |a
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u
| | source port | destination ~|e|t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h
~ port | TCP Sequence Number (SN) ~|c|e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|r|n
~ (continue) | ACK Sequence Number (SN) ~|y|t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|p|i
~ (continue) |Off. | Rserv | Flags | Window ~|t|c
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|a
~ Size | Urgent Pointer | ~|d|t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |e
| || |d
~ APPLICATION DATA ~| |
| || |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || |
| | Next Header | Integrity ~v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---
| |
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~
{: #fig-comp-vpn-tunnel-66 artwork-align="center" title="Compressed IPv6 in IPv6 ESP packet for VPN traffic mode with AES-GCM_16" }

# JSON format Context

The JSON file defines a set of rules within the SCHC_Context that are used for compressing and decompressing ESP headers. Each rule has a RuleID, a Description, and a set of Fields. Each field specifies how a particular part of the packet should be handled during compression or decompression. Note that the RuleID can be set by the user in any numeric order.

Rule 1: Inner Packet Compression
Rule 1 is responsible for compressing the IP source and destination addresses of the inner packet. The IP Source field is compressed using the MSB technique, where only the most significant bits that change are sent (MO: "MSB", CDA: "LSB"). This reduces the amount of data transmitted by leveraging the static context of the IP addresses. Similarly, the IP Destination field is compressed using the same MSB technique, ensuring efficient compression of the IP addresses (MO: "MSB", CDA: "LSB"). By focusing on the most significant bits, this rule minimizes the data needed to represent the IP addresses.

Rule 2: Inner Packet Decompression
Rule 2 decompresses the IP source and destination addresses of the inner packet. The IP Source field, which was compressed using the MSB technique, is decompressed by reconstructing the full address from the received least significant bits (MO: "MSB", CDA: "LSB"). The same process applies to the IP Destination field, where the original address is reconstructed from the compressed data (MO: "MSB", CDA: "LSB"). This rule ensures that the IP addresses in the inner packet are accurately restored to their original form, maintaining the integrity of the packet structure.

Rule 3: Clear Text ESP Compression
Rule 3 compresses the fields of the ESP packet before encryption. The Payload Data field, which is variable in length, is not sent during compression (CDA: "not-sent"). This means that the data payload itself is excluded from the compressed packet and will be handled separately. The Padding field, also variable in length, is computed during decompression to meet alignment requirements (CDA: "padding"). The Pad Length field is an 8-bit field indicating the length of the padding, and it is sent as-is (CDA: "value-sent"). The Next Header field, which indicates the type of the next protocol header, is also an 8-bit field sent without modification (CDA: "value-sent").

Rule 4: Encrypted ESP Compression
Rule 4 focuses on compressing fields of the ESP packet after encryption. The SPI (Security Parameters Index) is a 32-bit field that is compressed using the Most Significant Bits (MSB) technique based on the number of least significant bytes to be considered (MO: "MSB(4 - esp_spi_lsb)", CDA: "LSB"). Similarly, the Sequence Number, another 32-bit field, is compressed using the MSB technique, reducing its size by only sending the least significant bits as defined in the context (MO: "MSB(4 - esp_sn_lsb)", CDA: "LSB"). This rule ensures that only the necessary parts of these large fields are transmitted, reducing the overall packet size.

Rule 5: Clear Text ESP Decompression
Rule 5 handles the decompression of the clear text fields of the ESP packet after decryption. The Payload Data field, which is variable in length and was not sent during compression, is restored in its original form (CDA: "not-sent"). The Padding field, also variable, is recalculated to ensure correct alignment as per the network requirements (CDA: "padding"). The Pad Length field, an 8-bit indicator of padding length, is received as-is (CDA: "value-sent"). Similarly, the Next Header field, which specifies the next protocol header, is decompressed directly from the received value (CDA: "value-sent"). This rule ensures that the original structure of the ESP packet is accurately reconstructed.
~~~
removed as it is basic and can be found in SCHC RFC8724:

## Detailed Field Explanation
Each field in the rules has the following properties:

- FieldID: The identifier of the field.
- FL: Field length, which can be fixed (e.g., 8, 32 bits) or variable.
- FP: Field position in the packet.
- DI: Direction indicator (Up for outbound, Down for inbound).
- TV: Target value, used for matching during compression/decompression.
- MO: Matching operator, which specifies how to match the field (ignore, MSB, etc.).
- CDA: Compression/Decompression action, which defines what to do with the field (e.g., not-sent, padding, value-sent, LSB).
~~~

Alignment: Ensures that the length of the compressed data plus padding aligns correctly according to network requirements.
Padding and Pad Length: Handled dynamically based on alignment and the length of the payload data.

For Rule 1, ignoring PadLen and Padding is an optimal choice when possible, but it is not always feasible as IPv6 typically requires ESP to have a 32-bit alignment. The alignment is determined by the network's requirements. We have:

len(Payload Data) + len(Padding) + len(Pad Length) + len(Next Header) = 0 mod ALIGN

- `len(Next Header) = 1` or `0` if compressed. It can be compressed if the type of inner packet is known. For example, in Tunnel mode, the IP range determines if it is an IPv6 or IPv4 packet. In Transport mode, the upper layer protocol type (TCP or UDP) determines this.
- Payload Data has been compressed by IIPC.
- `len(Padding) = Pad Length`

If alignment is set to 8 bits:

len(Padding) = Pad Length = 0
len(Pad Length) = 0

Otherwise:
- If Compressed Payload Data has a fixed size:

len(Pad Length) = 0
len(Padding) = Pad Length = ALIGN - len(Payload Data) - len(Next Header) mod ALIGN

- Otherwise:

len(Pad Length) = 1
len(Padding) = Pad Length = ALIGN - len(Payload Data) - 1 - len(Next Header) mod ALIGN

Overall, this means that the SCHC_Context is dynamically generated from the EHCP Context. Additionally, a rule is required to compress the inner packet. IP source and IP destination should be compressed using LSB.

~~~
{
"SCHC_Context": {
"Rules": [
{
"RuleID": 1,
"Description": "Inner Packet Compression",
"Fields": [
{
"FieldID": "IP Source",
"FL": "variable",
"FP": 1,
"DI": "Up",
"TV": "msb(ip_src)",
"MO": "MSB",
"CDA": "LSB"
},
{
"FieldID": "IP Destination",
"FL": "variable",
"FP": 2,
"DI": "Up",
"TV": "msb(ip_dst)",
"MO": "MSB",
"CDA": "LSB"
}
]
},
{
"RuleID": 2,
"Description": "Inner Packet Decompression",
"Fields": [
{
"FieldID": "IP Source",
"FL": "variable",
"FP": 1,
"DI": "Down",
"TV": "msb(ip_src)",
"MO": "MSB",
"CDA": "LSB"
},
{
"FieldID": "IP Destination",
"FL": "variable",
"FP": 2,
"DI": "Down",
"TV": "msb(ip_dst)",
"MO": "MSB",
"CDA": "LSB"
}
]
},
{
"RuleID": 3,
"Description": "Clear Text ESP Compression",
"Fields": [
{
"FieldID": "Payload Data",
"FL": "variable",
"FP": 1,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "not-sent"
},
{
"FieldID": "Padding",
"FL": "variable",
"FP": 2,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "padding"
},
{
"FieldID": "Pad Length",
"FL": 8,
"FP": 3,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
},
{
"FieldID": "Next Header",
"FL": 8,
"FP": 4,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
}
]
},
{
"RuleID": 4,
"Description": "Encrypted ESP Compression",
"Fields": [
{
"FieldID": "SPI",
"FL": 32,
"FP": 1,
"DI": "Up",
"TV": null,
"MO": "MSB(4 - esp_spi_lsb)",
"CDA": "LSB"
},
{
"FieldID": "Sequence Number",
"FL": 32,
"FP": 2,
"DI": "Up",
"TV": null,
"MO": "MSB(4 - esp_sn_lsb)",
"CDA": "LSB"
}
]
},
{
"RuleID": 5,
"Description": "Clear Text ESP Decompression",
"Fields": [
{
"FieldID": "Payload Data",
"FL": "variable",
"FP": 1,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "not-sent"
},
{
"FieldID": "Padding",
"FL": "variable",
"FP": 2,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "padding"
},
{
"FieldID": "Pad Length",
"FL": 8,
"FP": 3,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
},
{
"FieldID": "Next Header",
"FL": 8,
"FP": 4,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
}
]
}
]
}
}

~~~