| Internet-Draft | EHCP | July 2024 |
| Migault, et al. | Expires 9 January 2025 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 9 January 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Encapsulating Security Payload (ESP) [RFC4303] protocol can provide confidentiality, data origin authentication, integrity, anti-replay, and traffic flow confidentiality. The set of services ESP provides depends on the Security Association (SA) parameters negotiated between devices.¶
ESP has two modes: Tunnel and Transport. Tunnel mode is commonly used for VPNs, with the ESP header placed after the outer IP header and before the inner IP packet headers. In Transport mode, the ESP Payload Data consists of the IP Payload, with the ESP header placed after the inner IP packet header and any IP extensions headers.¶
This document defines the ESP Header Compression profile (EHCP) for compression/decompression (C/D) of IPsec/ESP [RFC4301] / [RFC4303] packets, represented by the structure shown in Figure 1, using Static Context Header Compression and fragmentation (SCHC) [RFC8724]. Compression with SCHC is based on using a set of Rules, which constitutes the Context of SCHC C/D, to compress or decompress headers. The motivation is to avoid sending information that has already been shared by the peers, thus reducing the ESP packet size on the wire. To better understand ESP, the reader might be interested in reading Minimal ESP [RFC9333], a simplified version of ESP.¶
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) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document provides the ESP Header Compression profile (EHCP) architecture with the integration of SCHC into various levels of the IPsec stack. The three levels of compression are defined below:¶
Inner IP Compression (IIPC): This level happens directly on the inner IP packet. For example, in the case of a UDP packet with ports determined by the SA, fields such as UDP ports and checksums are typically compressed. If no compression of the inner packet is possible, the resulting SCHC packet contains the uncompressed IP packet, as per [RFC8724], Section 7.2.¶
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.¶
Note that the descriptions of the three levels of compression provided in this document meet the general purpose of ESP. It is possible that in some specific deployments, SCHC contexts from different levels can be merged. Typically, a specific implementation may merge IIPC and CTEC.¶
For each compressor/decompressor level, it defines the ESP fields to be considered in the rules of its corresponding SCHC context. In addition, it defines how the SCHC contexts are initialized from the 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.¶
A method to reduce the size of ESP headers using predefined compression rules and contexts to improve efficiency.¶
Expressed via the SCHC framework, IIPC compresses/decompresses the inner IP packet headers.¶
Expressed via the SCHC framework, CTEC compresses/decompresses all fields that will later be encrypted by ESP.¶
Expressed via the SCHC framework, EEC compresses/decompresses ESP fields that will not be encrypted by ESP.¶
As defined in [RFC4301], Section 4.1.¶
As defined in [RFC4303], Section 2.2.¶
A framework for header compression designed for LPWANs, as defined in [RFC8724].¶
A unique identifier for each SCHC rule, as defined in [RFC8724], Section 5.1.¶
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].¶
The main principle of the ESP Header Compression Profile (EHCP) is to avoid sending information that has already been shared by the peers. Different profiles and technologies, such as those defined by [RFC4301] and [RFC4303], ensure that ESP can be tailored to various network requirements and security policies. However, ESP is not optimized for bandwidth efficiency because it has been designed as a general-purpose protocol. EHCP aims to address this by leveraging a profile, expressed via the SCHC framework, to optimize the ESP header sizes for better efficiency in constrained environments.¶
Profiles for compression are derived from parameters associated with the Security Association (SA) and agreed upon via IKEv2 [RFC7296], as well as specific compression parameters defined in IKEv2 [I-D.mglt-ipsecme-ikev2-diet-esp-extension]. As depicted in Figure 2, this document defines three levels of compression, as previously described: IIPC, CTEC, and EEC. The terminology of "levels" is used consistently throughout the document for clarity.¶
The Figure 2 illustrates the integration of SCHC into the IPsec stack, detailing the different levels and components involved in the compression and decompression processes. The diagram is divided into two entities, each representing an endpoint of a communication link.¶
While the scope of this compression profile currently does not extend beyond the transport layer (i.e., UDP), there will eventually be a need to compress the application layer as well.¶
The decompression of the inbound packet follows a reverse process. First, the Encrypted ESP C/D (EEC) decompresses the encrypted ESP header fields. After the ESP packet is decrypted, the Clear Text ESP C/D (CTEC) decompresses the Clear Text fields of the ESP packet.¶
Note that implementations MAY differ from the architectural description but it is assumed the outputs will be the same.¶
+--------------------------------+
| ESP Header Compression Context |
| - Security Association |
| - Additional Parameters |
+--------------------------------+
|
Endpoint | Endpoint
|
+----------------+ | +----------------+
| Inner IP packet| | | Inner IP packet|
+----------------+ | +----------------+
| SCHC |+---------IIPC level--------------+| SCHC |
+----------------+ C {IIP} +----------------+
| ESP | | | ESP |
| (encapsulation)| | | (unwrapping) |
+----------------+ v +----------------+
| SCHC |+---------CTEC level--------------+| SCHC |
+----------------+ EH, C {C {IIP}, ET} +----------------+
| ESP | | | ESP |
| (encryption) | | | (decryption) |
+----------------+ v +----------------+
| SCHC |+-----------EEC level-------------+| SCHC |
+----------------+ IP, C {EH, C {C {IIP}, ET}} +----------------+
| IPv6 + ESP | | IPv6 + ESP |
+----------------+ +----------------+
| L2 | | L2 |
+----------------+ +----------------+
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.¶
The EHCP Context provides the necessary information to generate the SCHC Rules. Most pieces of information are already available from the negotiated SA [RFC4301]. Other pieces of information need to be specifically configured or agreed via other mechanisms, such as [I-D.mglt-ipsecme-ikev2-diet-esp-extension].¶
The reference column in Figure 3 indicates how the information is defined. The C/D column specifies in which of the compression levels the parameter is being used.¶
Note that additional Compression might be performed especially on the inner IP packet - for example, including the TCP layer. However, this profiles limits the scope of the compression to the inner IP header, and possibly UDP headers. We believe this is a reasonable scope for ESP to address both IoT UDP packets as well as large VPN traffic. If further compression is needed, this should be achieved by sending an IP packet with a SCHC payload, where the expected compression is achieved outside ESP.¶
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 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.¶
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.¶
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.¶
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.¶
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 | +-------------------+--------------------------+-----------+-------+
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.¶
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.¶
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.¶
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 of 4 for esp_spi_lsb will leave the SPI unchanged.¶
designates the Sequence Number (SN) field defined in [RFC4301].¶
designates the LSB to be considered for the compressed SN and is defined by this specification. It works similarly to esp_spi_lsb.¶
designates the encryption algorithm used. For the purpose of compression it is RECOMMENDED to use [RFC8750].¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
designates the list of Protocol ID field, whose meaning is defined in [RFC7296], Section 3.13.¶
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.¶
In addition to the Compression / Decompression Actions defined in [RFC8724], Section 7.4, this specification uses the CDA as presented in Figure 4. These CDA are either a refinement of the compute- * CDA or the result of combined CDA.¶
+=================+=====================+=============================+ | Action | Compression | Decompression | +=================+=====================+=============================+ | lower | elided | Get from lower layer | | checksum | elided | Compute checksum | | padding | elided | Compute padding | +-----------------+---------------------+-----------------------------+
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.¶
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.¶
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."¶
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.¶
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.¶
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.¶
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".¶
There are no IANA parameters to be registered.¶
There is no specific considerations associated with the profile other than the security considerations of ESP [RFC4303] and those of SCHC [RFC8724].¶
We would like to thank Laurent Toutain for its guidance on SCHC. Robert Moskowitz for inspiring the name "Diet-ESP" from Diet-HIP.¶
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.¶
Figure 5 illustrates an UDP packet being protected by ESP in the tunnel mode using AES-CCM_8_IIV.
This packet is compressed as depicted in Figure 6.
EHC reduces the packet size by 53 bytes.¶
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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+
This section is very similar to Appendix A.1 except that a TCP session is used instead.¶
The compression on the TCP payload is very limited, and in a case where the TCP end point is the same as the ESP end point additionnal compression could be performed. Additional fields such as TCP options, urgent pointers, the SN and ACK Number could be compressed by a specific profile agreed at the TCP level as opposed to the ESP level.¶
The ESP encapsulated TCP packet described in Figure 7 is compressed by EHCP using th esam eEHCP context as in Appendix A.1 and EHCP reduces that packet by 55 bytes, as depicted in Figure 6.¶
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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+
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.¶
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.¶
Figure 9 represents the original ESP TCP packet with IPv6 inner IP addresses and Figure 10 represents the corresponding packet compressed with EHC.¶
The compression with Diet-ESP results in a reduction of 32 bytes.¶
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) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The JSON file defines a set of rules within the SCHC_Context that are used for compressing and decompressing ESP headers. Each rule has a RuleID, a Description, and a set of Fields. Each field specifies how a particular part of the packet should be handled during compression or decompression. Note that the RuleID can be set by the user in any numeric order.¶
Rule 1: Clear Text ESP Compression Rule 1 compresses the fields of the ESP packet before encryption. The Payload Data field, which is variable in length, is not sent during compression (CDA: "not-sent"). This means that the data payload itself is excluded from the compressed packet and will be handled separately. The Padding field, also variable in length, is computed during decompression to meet alignment requirements (CDA: "padding"). The Pad Length field is an 8-bit field indicating the length of the padding, and it is sent as-is (CDA: "value-sent"). The Next Header field, which indicates the type of the next protocol header, is also an 8-bit field sent without modification (CDA: "value-sent").¶
Rule 2: Encrypted ESP Compression Rule 2 focuses on compressing fields of the ESP packet after encryption. The SPI (Security Parameters Index) is a 32-bit field that is compressed using the Most Significant Bits (MSB) technique based on the number of least significant bytes to be considered (MO: "MSB(4 - esp_spi_lsb)", CDA: "LSB"). Similarly, the Sequence Number, another 32-bit field, is compressed using the MSB technique, reducing its size by only sending the least significant bits as defined in the context (MO: "MSB(4 - esp_sn_lsb)", CDA: "LSB"). This rule ensures that only the necessary parts of these large fields are transmitted, reducing the overall packet size.¶
Rule 3: Clear Text ESP Decompression Rule 3 handles the decompression of the clear text fields of the ESP packet after decryption. The Payload Data field, which is variable in length and was not sent during compression, is restored in its original form (CDA: "not-sent"). The Padding field, also variable, is recalculated to ensure correct alignment as per the network requirements (CDA: "padding"). The Pad Length field, an 8-bit indicator of padding length, is received as-is (CDA: "value-sent"). Similarly, the Next Header field, which specifies the next protocol header, is decompressed directly from the received value (CDA: "value-sent"). This rule ensures that the original structure of the ESP packet is accurately reconstructed.¶
Rule 4: Inner Packet Compression Rule 4 is responsible for compressing the IP source and destination addresses of the inner packet. The IP Source field is compressed using the MSB technique, where only the most significant bits that change are sent (MO: "MSB", CDA: "LSB"). This reduces the amount of data transmitted by leveraging the static context of the IP addresses. Similarly, the IP Destination field is compressed using the same MSB technique, ensuring efficient compression of the IP addresses (MO: "MSB", CDA: "LSB"). By focusing on the most significant bits, this rule minimizes the data needed to represent the IP addresses.¶
Rule 5: Inner Packet Decompression Rule 5 decompresses the IP source and destination addresses of the inner packet. The IP Source field, which was compressed using the MSB technique, is decompressed by reconstructing the full address from the received least significant bits (MO: "MSB", CDA: "LSB"). The same process applies to the IP Destination field, where the original address is reconstructed from the compressed data (MO: "MSB", CDA: "LSB"). This rule ensures that the IP addresses in the inner packet are accurately restored to their original form, maintaining the integrity of the packet structure.¶
removed as it is basic and can be found in SCHC RFC8724: ## Detailed Field Explanation Each field in the rules has the following properties: - FieldID: The identifier of the field. - FL: Field length, which can be fixed (e.g., 8, 32 bits) or variable. - FP: Field position in the packet. - DI: Direction indicator (Up for outbound, Down for inbound). - TV: Target value, used for matching during compression/decompression. - MO: Matching operator, which specifies how to match the field (ignore, MSB, etc.). - CDA: Compression/Decompression action, which defines what to do with the field (e.g., not-sent, padding, value-sent, LSB).¶
Alignment: Ensures that the length of the compressed data plus padding aligns correctly according to network requirements. Padding and Pad Length: Handled dynamically based on alignment and the length of the payload data.¶
For Rule 1, ignoring PadLen and Padding is an optimal choice when possible, but it is not always feasible as IPv6 typically requires ESP to have a 32-bit alignment. The alignment is determined by the network's requirements. We have:¶
len(Payload Data) + len(Padding) + len(Pad Length) + len(Next Header) = 0 mod ALIGN¶
len(Next Header) = 1 or 0 if compressed. It can be compressed if the type of inner packet is known. For example, in Tunnel mode, the IP range determines if it is an IPv6 or IPv4 packet. In Transport mode, the upper layer protocol type (TCP or UDP) determines this.¶
Payload Data has been compressed by IIPC.¶
len(Padding) = Pad Length¶
If alignment is set to 8 bits:¶
len(Padding) = Pad Length = 0 len(Pad Length) = 0¶
Otherwise: - If Compressed Payload Data has a fixed size:¶
len(Pad Length) = 0 len(Padding) = Pad Length = ALIGN - len(Payload Data) - len(Next Header) mod ALIGN¶
Otherwise:¶
len(Pad Length) = 1 len(Padding) = Pad Length = ALIGN - len(Payload Data) - 1 - len(Next Header) mod ALIGN¶
Overall, this means that the SCHC_Context is dynamically generated from the EHCP Context. Additionally, a rule is required to compress the inner packet. IP source and IP destination should be compressed using LSB.¶
{
"SCHC_Context": {
"Rules": [
{
"RuleID": 1,
"Description": "Clear Text ESP Compression",
"Fields": [
{
"FieldID": "Payload Data",
"FL": "variable",
"FP": 1,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "not-sent"
},
{
"FieldID": "Padding",
"FL": "variable",
"FP": 2,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "padding"
},
{
"FieldID": "Pad Length",
"FL": 8,
"FP": 3,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
},
{
"FieldID": "Next Header",
"FL": 8,
"FP": 4,
"DI": "Up",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
}
]
},
{
"RuleID": 2,
"Description": "Encrypted ESP Compression",
"Fields": [
{
"FieldID": "SPI",
"FL": 32,
"FP": 1,
"DI": "Up",
"TV": null,
"MO": "MSB(4 - esp_spi_lsb)",
"CDA": "LSB"
},
{
"FieldID": "Sequence Number",
"FL": 32,
"FP": 2,
"DI": "Up",
"TV": null,
"MO": "MSB(4 - esp_sn_lsb)",
"CDA": "LSB"
}
]
},
{
"RuleID": 3,
"Description": "Clear Text ESP Decompression",
"Fields": [
{
"FieldID": "Payload Data",
"FL": "variable",
"FP": 1,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "not-sent"
},
{
"FieldID": "Padding",
"FL": "variable",
"FP": 2,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "padding"
},
{
"FieldID": "Pad Length",
"FL": 8,
"FP": 3,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
},
{
"FieldID": "Next Header",
"FL": 8,
"FP": 4,
"DI": "Down",
"TV": null,
"MO": "ignore",
"CDA": "value-sent"
}
]
},
{
"RuleID": 4,
"Description": "Inner Packet Compression",
"Fields": [
{
"FieldID": "IP Source",
"FL": "variable",
"FP": 1,
"DI": "Up",
"TV": "msb(ip_src)",
"MO": "MSB",
"CDA": "LSB"
},
{
"FieldID": "IP Destination",
"FL": "variable",
"FP": 2,
"DI": "Up",
"TV": "msb(ip_dst)",
"MO": "MSB",
"CDA": "LSB"
}
]
},
{
"RuleID": 5,
"Description": "Inner Packet Decompression",
"Fields": [
{
"FieldID": "IP Source",
"FL": "variable",
"FP": 1,
"DI": "Down",
"TV": "msb(ip_src)",
"MO": "MSB",
"CDA": "LSB"
},
{
"FieldID": "IP Destination",
"FL": "variable",
"FP": 2,
"DI": "Down",
"TV": "msb(ip_dst)",
"MO": "MSB",
"CDA": "LSB"
}
]
}
]
}
}
¶