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

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

Introduction The ESP Header Compression Profile (EHCP) minimizes the overhead associated with ESP by compressing both the ESP header and additional fields within the secured packet. EHCP utilizes Attributes for Rule Derivation (AfRD) that are specified for each Security Association (SA). Certain AfRD have already been established during the SA negotiation process through IKEv2. This extension facilitates the agreement on the remaining AfRD through IKEv2.

Protocol Overview As illustrated in , 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 AfRD . Any AfRD for which the initiator wishes to specify no limitations SHOULD be excluded, i.e., an AfRD is only sent if the sending peer wants the receiving peer to select a subset of the available values. A given AfRD MAY be repeated with different values in order to provide a list of acceptable values. A range of possible AfRD values MAY be indicated as well. If a Proposal contains an unknown HCP Name, or any AfRD 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 AfRD 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 AfRD was not explicitly stated, the responder will provide the AfRD unless it defaults to a standard value. Each AfRD MUST NOT be mentioned more than one time. When multiple values are provided for a specific AfRD (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 AfRD. 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.

<-- HDR, SA, KEr, Nr HDR, SK {IDi, AUTH, SA, TSi, TSr, N(HCP_PROPOSAL Proposal_ID=1, HCP Name="Diet-ESP" AfRD_a ... AfRD_i ... Proposal_ID=2, HCP Name="Diet-ESP" AfRD_a ... AfRD_j) <-- HDR, SK {IDr, AUTH, SA, TSi, TSr, N(HCP_PROPOSAL Proposal_ID=2, HCP Name="Diet-ESP" AfRD_a ... AfRD_j, AfRD_k, ... AfRD_u) ]]>

HCP_PROPOSAL Notify Payload describes the HCP_PROPOSAL Notify Payload.

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

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 . When sent by the responder the HCP_PROPOSAL Notify Payload contains a single Payload described in .

Proposal ID (1 octet):: The number identifying the Proposal.
EHCP Name (1 octet):: The identifier of the EHCP Name (see ).
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 and detailed further as described in .

Attributes for Rule Derivation Attributes for Rule Derivation (AfRD) follow the same format as the Transform Attribute copied for convenience in .

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 AfRDs, and 2) AfRDs that are tailored to a particular HCP and possess a distinct value.

Generic Attributes This specification defines range_afrd_proposal as a Generic Attribute for Rule Derivation to specify that a given AfRD can be selected within a range of values. Designation: range_afrd_proposal Attribute Format: 0 Attribute Data: Let AfRD_min and AfRD_max be the minimum and maximum values of the proposed range, expressed following the Transform Attribute Payload format. The corresponding Attribute Data is the concatenation of AfRD_min and AfRD_max. To avoid ambiguity, it is explicitly required that both AfRD_min and AfRD_max refer to the same type of parameter and that they are processed as attributes with values defining the minimum and maximum of the range. This ensures consistent interpretation during negotiation and compression. The figure below illustrates a Proposal for a compressed SPI between 6 and 8 bit long. SPI are compressed by sending LSB, so in our case AfRD_min is an esp_spi_lsb AfRD set to 6 and AfRD_max is a esp_spi_lsb set to 8. The esp_spi_lsb AfRD is detailed in the Diet-ESP EHCP and is a 2 byte length Attribute. The resulting range proposal is expressed via the combination of the range_afrd_proposal and AfRD_min and AfRD_max.

Registering a Header Compression Profile An HCP needs to register an HCP Name taken from in , the specification that describes the operations of the EHCP, as well as the different AfRD. For each AfRD, the corresponding Attribute Type, the AF value, the Attribute Data or Attribute Value and the Default Value MUST be specified.

AfRD for the Diet-ESP HCP This section defines the code points that are needed to agree on the AfRD between two IKEv2 peers as described in . HCP Name: "Diet-ESP" as specified in , . Specification : The following Attributes for Rule Derivation are defined: DSCP Action Designation: dscp_action Attribute Format: 1 Attribute Value: DSCP Action takes discrete values coded over one byte as described in DSCP Action Value Registry ( in ) Default Value: the default value is set to "not_compressed" ECN Action Designation: ecn_action Attribute Format: 1 Attribute Value: ECN ACTION takes discrete values coded over one byte as described in the ECN ACTION Value Registry ( in ) Default Value: the default value is set to "not_compressed" Flow Label Action Designation: flow_label_action Attribute Format: 1 Attribute Value: Flow Label ACTION takes discrete values coded over one byte as described in the Flow Label ACTION Value Registry ( in ) Default Value: the default value is set to "not_compressed" 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 ( in ) 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. ESP Trailer Designation: esp_trailer Attribute Format: 1 Attribute Value: ESP Trailer takes discrete values coded over one byte as described in the Bit Alignment Value Registry ( in ) Default Value: the default value is set to "Optional", which enables the ESP Trailer to be compressed. 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.

IANA Considerations

Registration of IKEv2 Notify Message Types IANA has allocated one value in the "IKEv2 Notify Message Types - Status Types" registry:

This specification requests the IANA to create a Header Compression Profile registry (see ), as well as the necessary registries for the ESP Header Compression Profile Diet-ESP, that is the Attributes for Rule Derivation (see ) as well as, when required, the complementary specific AfRD Values associated with each AfRD (see ). Note that the term "Header Compression Profile" reflects the purpose of the registry, which is to define profiles for ESP header compression using the Diet-ESP methodology. While the registry is managed and utilized exclusively by IKEv2 for negotiating compression parameters, its scope is limited to ESP header compression and does not extend to IKEv2 itself. All registries are "Specification Required".

Registry for Generic Attributes for Rule Derivation Registry for Generic Attributes for Rule Derivation. When Associated Data is set to YES, the AF bit of the corresponding Transform Attribute Payload is set to 0; otherwise it is set to 1. The AfRD Code Point mentioned here MUST NOT be reused by any Registries associated with any Profile and is shared by all profiles. AfRD Code Point Full Name Designation Attribute Format Reference 65535 RANGE AfRD range_afrd_proposal 0 ThisRFC Each entry in the range is represented by two attributes (AfRD_min and AfRD_max), both following the 2-byte Attribute Type format specified in . This ensures clarity and compatibility in all implementations.

Registry for IKEv2 Header Compression Profile Value (1 Byte) Designation Reference 0 Diet-ESP ThisRFC 1-255 unallocated -

Registry for Diet-ESP Attributes for Rule Derivation Registry for Attributes for Rule Derivation for the ESP Header Compression Profile Diet-ESP. When Associated Data is set to YES, the AF bit of the corresponding Transform Attribute Payload is set to 0; otherwise it is set to 1. The Diet-ESP Attributes for Rule Derivation registry specifies six AfRD parameters explicitly defined for Diet-ESP that are not part of the standard IKEv2 negotiation process. These attributes are required for implementing the Diet-ESP Header Compression Profile. The remaining attributes referenced in , , and related drafts (e.g., DSCP values) are already defined and negotiated during the creation of the CHILD SA. AfRD Code Point Full Name Designation Attribute Format Reference 0 DSCP Action dscp_action 1 ThisRFC 1 ECN Action ecn_action 1 ThisRFC 2 Flow Label Action flow_label_action 1 ThisRFC 3 Alignment alignment 1 ThisRFC 4 SPI LSB esp_spi_lsb 1 ThisRFC 5 SN LSB esp_sn_lsb 1 ThisRFC 6 - 2^16-2 unallocated - - -

Registries for the Values of Diet-ESP Attributes for Rule Derivation

DSCP Action Value Registry Value Designation Reference 0 not_compressed ThisRFC 1 lower ThisRFC 2 sa ThisRFC 3-255 unallocated -

ECN Action Value Registry Value Designation Reference 0 not_compressed ThisRFC 1 lower ThisRFC 2-255 unallocated -

Flow Label Action Value Registry Value Designation Reference 0 not_compressed ThisRFC 1 lower ThisRFC 2 generated ThisRFC 3 zero ThisRFC 4-255 unallocated -

ESP Byte Alignment Value Designation Reference 0 8 bit ThisRFC 1 16 bit ThisRFC 2 32 bit ThisRFC 3 64 bit ThisRFC 4-255 unallocated -

ESP Trailer Value Designation Reference 0 Mandatory ThisRFC 1 Optional ThisRFC 2-255 unallocated -

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.

Acknowledgements The authors extend their gratitude to Samita Chakrabart, Tero Kivinen, Michael Richardson and Valery Smyslov for their long time support. The authors would like to acknowledge the support from Mitacs through the Mitacs Accelerate program.