Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 30 July 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. Introduction

The ESP Header Compression Profile (EHCP) [I-D.ietf-ipsecme-diet-esp] minimizes the overhead associated with ESP by compressing both the ESP header and additional fields within the secured packet. EHCP utilizes Attributes for Rules Generation (AfRG) that are specified for each Security Association (SA). Certain AfRG have already been established during the SA negotiation process through IKEv2. This extension facilitates the agreement on the remaining AfRG through IKEv2.¶

3. Protocol Overview

As illustrated in Figure 1, an initiator intending to utilize the Header Compression Profile (HCP) informs its peer by sending a HCP_PROPOSAL Notify Payload during the IKE_AUTH and CREATE_CHILD_SA exchanges. The HCP_PROPOSAL includes a list of Proposals, each comprising an EHCP Name along with a set of Attributes for Rules Generation (AfRG)[I-D.ietf-ipsecme-diet-esp]. Any AfRG for which the initiator wishes to specify no limitations SHOULD be excluded, i.e., an AfRG is only sent if the sending peer wants the receiving peer to select a subset of the available values. A given AfRG MAY be repeated with different values in order to provide a list of acceptable values. A range of possible AfRG values MAY be indicated as well.¶

If a Proposal contains an unknown HCP Name, or any AfRG in a Proposal is unknown, then the entire Proposal must be discarded by the responder. If none of the received Proposals are deemed acceptable, the responder MAY choose to discard the HCP_PROPOSAL Notify Payload. Nevertheless, it is anticipated that the responder will provide an explanation for rejecting all HCP Proposals. If the reason pertains to an AfRG with an unacceptable value, the responder SHOULD reply with a NO_PROPOSAL_CHOSEN Notify Payload.¶

Conversely, if the receiver identifies a suitable Proposal, it will respond with an HCP_PROPOSAL Notify Payload that includes the chosen Proposal. In cases where the AfRG was not explicitly stated, the responder will provide the AfRG unless it defaults to a standard value. Each AfRG MUST NOT be mentioned more than one time. When multiple values are provided for a specific AfRG (either multiple values being provided or via a range of acceptable values), the responder MUST NOT provide more than one value. The Proposal MUST NOT contain any range of AfRG.¶

Upon receipt of an NO_PROPOSAL_CHOSEN Notify Payload, the initiator has the option to restart the CREATE_CHILD_SA exchange.¶

When the initiator receives the HCP_PROPOSAL_CHOSEN Notify Payload, it will evaluate the Proposal to ensure that it aligns with the initial proposal and adheres to its policies prior to executing the HCP.¶

Initiator                         Responder
-------------------------------------------------------------------
HDR, SA, KEi, Ni -->
                           <-- HDR, SA, KEr, Nr
HDR, SK {IDi, AUTH,
     SA, TSi, TSr,
     N(HCP_PROPOSAL
         Proposal_ID=1, HCP Name="Diet-ESP"
           AfRG_a
           ...
           AfRG_i
         ...
         Proposal_ID=2, HCP Name="Diet-ESP"
           AfRG_a
           ...
           AfRG_j)
                           <-- HDR, SK {IDr, AUTH,
                                    SA, TSi, TSr,
                                    N(HCP_PROPOSAL
                                      Proposal_ID=2, HCP Name="Diet-ESP"
                                        AfRG_a
                                        ...
                                        AfRG_j,
                                        AfRG_k,
                                        ...
                                        AfRG_u)

4. HCP_PROPOSAL Notify Payload

Figure 2 describes the HCP_PROPOSAL Notify Payload.¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol ID  |   SPI Size    |      Notify Message Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields Next Payload, Critical Bit, RESERVED, and Payload Length are defined in section 3.10 of [RFC7296].¶

Protocol ID (1 octet):

set to zero.¶

SPI Size (1 octet):

set to zero.¶

Notify Message Type (2 octets):

Specifies the type of notification message. It is set to TBA1 for HCP_PROPOSAL_CHOSEN.¶

When sent by the Initiator, the HCP_PROPOSAL Notify Payload contains a list of Proposals described in Figure 3. When sent by the responder the HCP_PROPOSAL Notify Payload contains a single Payload described in Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Proposal ID  |   HCP Name   |      Proposal Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                          Proposal Data                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposal ID (1 octet):

The number identifying the Proposal.¶

EHCP Name (1 octet):

The identifier of the EHCP Name. (see Table 2)¶

Proposal Length (2 octets):

The length in octets of the Proposal Data¶

Proposal Data:

A Proposal contains a set of parameters that are represented via Transform Attribute format [RFC7296], Section 3.3.5 and detailed further as described in Section 5.¶

5. Attributes for Rules Generation

Attributes for Rules Generation (AfRG) follow the same format as the Transform Attribute [RFC7296], Section 3.3.5 copied for convenience in Figure 4.¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|       Attribute Type        |    AF=0  Attribute Length     |
|F|                             |    AF=1  Attribute Value      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   AF=0  Attribute Data                        |
|                   AF=1  Not Transmitted                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

There exist two categories of attributes: 1) generic attributes, which are applicable across all HCPs and serve to enhance the representation of a combination of AfRGs, and 2) AfRGs that are tailored to a particular HCP and possess a distinct value.¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|       afrg_range_proposal    | Attribute Length = 4 octets  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|           esp_spi_lsb        | Attribute Value = 6          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|           esp_spi_lsb        | Attribute Value = 8          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Registering a Header Compression Profile

An HCP needs to register an HCP Name taken from Table 2 in Section 8.3, the specification that describes the operations of the EHCP, as well as the different AfRG. For each AfRG, the corresponding Attribute Type, the AF value, the Attribute Data or Attribute Value and the Default Value MUST be specified.¶

7. AfRG for the Diet-ESP HCP

This section defines the code points that are needed to agree on the AfRG between two IKEv2 peers as described in Section 6.¶

• HCP Name: "Diet-ESP" as specified in Table 2, Section 8.3.¶

• Specification : [I-D.ietf-ipsecme-diet-esp]¶

The following Attributes for Rules Generation are defined:¶

DSCP Compression/Decompression Action (CDA)¶

• Designation: dscp_cda¶

• Attribute Format: 1¶

• Attribute Value: DSCP CDA takes discrete values coded over one byte as described in DSCP CDA Value Registry (Table 4 in Section 8.5.1)¶

• Default Value: the default value is set to "uncompress"¶

ECN Compression/Decompression Action (CDA)¶

• Designation: ecn_cda¶

• Attribute Format: 1¶

• Attribute Value: ECN CDA takes discrete values coded over one byte as described in the ECN CDA Value Registry (Table 5 in Section 8.5.2)¶

• Default Value: the default value is set to "uncompress"¶

Flow Label Compression/Decompression Action (CDA)¶

• Designation: flow_label_cda¶

• Attribute Format: 1¶

• Attribute Value: Flow Label CDA takes discrete values coded over one byte as described in the Flow Label CDA Value Registry (Table 6 in Section 8.5.3)¶

• Default Value: the default value is set to "uncompress"¶

ESP Byte Alignment¶

• Designation: alignment¶

• Attribute Format: 1¶

• Attribute Value: Byte Alignment takes discrete values coded over one byte as described in the Bit Alignment Value Registry (Table 7 in Section 8.5.4)¶

• Default Value: the default value is set to "64 bit", which corresponds to the standard IPv6 bit alignment. The default value of 64 bit in this specification refers to the bit alignment used for Diet-ESP compression operations and does not override or contradict the alignment requirements of RFC 4303. Instead, the alignment specified here ensures compatibility with the SCHC compression framework, which is designed to operate efficiently in constrained networks.¶

Security Parameter Index (SPI) Least Significant Bits (LSB)¶

• Designation: esp_spi_lsb¶

• Attribute Format: 1¶

• Attribute Value: SPI LSB designates the number of bits that are provided to infer the SPI. This number is between 0 and 32.¶

• Default Value: the default value is 32, which is the size of the standard SPI in the standard ESP¶

Sequence Number (SN) Least Significant Bits (LSB)¶

• Designation: esp_sn_lsb¶

• Attribute Format: 1¶

• Attribute Value: SN LSB designates the number of bits that are provided to infer the SPI. This number is between 0 and 32.¶

• Default Value: the default value is 32, which is the size of the standard SN in the standard ESP¶

8. IANA Considerations

  Value    Notify Messages - Status Types
-----------------------------------------
  TBA1    HCP_PROPOSAL

9. Security Considerations

The protocol defined in this document does not modify IKEv2.¶

Proposals may be expressed in various ways and a proposal may be expressed in a specific way so that its treatment overloads the receiver. The receiver needs to consider aborting the exchange when too much resource is required.¶

10. Normative References

[I-D.ietf-ipsecme-diet-esp]

Migault, D., Hatami, M., Céspedes, S., Atwood, J. W., Liu, D., Guggemos, T., Bormann, C., and D. Schinazi, "ESP Header Compression Profile", Work in Progress, Internet-Draft, draft-ietf-ipsecme-diet-esp-04, 26 January 2025, <https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-ipsecme-diet-esp/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4301]

Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC7296]

Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses