IPsecme D. Migault Internet-Draft Ericsson Intended status: Standards Track T. Guggemos Expires: 7 May 2025 LMU D. Schinazi Google LLC W. Atwood Concordia University D. Liu S. Preda Ericsson M. Hatami S. Céspedes Concordia University 3 November 2024 Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) draft-ietf-ipsecme-ikev2-diet-esp-extension-01 Abstract This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rules Generation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. 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 7 May 2025. Migault, et al. Expires 7 May 2025 [Page 1] Internet-Draft EHC extension November 2024 Copyright Notice 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. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. HCP_SUPPORTED and HCP_UNSUPPORTED Notify Payloads . . . . . . 4 4. Attributes for Rules Generation . . . . . . . . . . . . . . . 5 5. Registrating a Header Compression Profile . . . . . . . . . . 6 6. Registration of Diet-ESP EHCP . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7.1. Registration of IKEv2 Notify Message Types . . . . . . . 8 7.2. Registry for Generic Attributes for Rules Generation . . 8 7.3. Registry for IKEv2 Header Compression Profile . . . . . . 9 7.4. Registry for Diet-ESP Attributes for Rules Generation . . 9 7.5. Registries for the Values of Diet-ESP Attributes for Rules Generation . . . . . . . . . . . . . . . . . . . . . . . 10 7.5.1. DSCP CDA Value Registry . . . . . . . . . . . . . . . 10 7.5.2. ECDN CDA Value Registry . . . . . . . . . . . . . . . 11 7.5.3. Flow Label CDA Value Registry . . . . . . . . . . . . 11 7.5.4. OS or Network Byte Alignment . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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. Migault, et al. Expires 7 May 2025 [Page 2] Internet-Draft EHC extension November 2024 2. Introduction The ESP Header Compression Profile (EHCP) [I-D.mglt-ipsecme-diet-esp] minimizes the overhead associated with ESP by compressing both the ESP 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 . # Protocol Overview As illustrated in Figure 1, an initiator intending to utilize the Header Compression Profile (HCP) informs its peer by sending a HCP_SUPPORTED Notify Payload during the IKE_AUTH and CREATE_CHILD_SA exchanges. The HCP_SUPPORTED includes a list of Proposal payloads, each comprising an EHCP Name along with a set of Attributes for Rules Generation (AfRG)[I-D.mglt-ipsecme-diet-esp]. Any AfRG for which the initiator has no limitations SHOULD be excluded. A given AfRG MAY be repeated with different values in order to provide a list of acceptable values. A range of possible AfRG value MAY be indicated as well. Proposals that contain an unknown HCP Name or any of the specified AfRG must be disregarded by the initiator. If none of the received Proposals are deemed acceptable, the responder may choose to disregard the HCP_SUPPORTED Notify Payload. Nevertheless, it is anticipated that the responder will provide an explanation for rejecting all HCP Proposals. Should the reason pertain to an AfRG with an unacceptable value, the responder should reply with an HCP_UNSUPPORTED Notify Payload. This Notify Payload should include one or more acceptable Proposal Payloads to guide the initiator. Conversely, if the receiver identifies a suitable Proposal, it will respond with a HCP_SUPPORTED 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 receiver MUST NOT provide more than one values. The Proposal MUST NOT contain any range of AfRG. Upon receipt of an HCP_UNSUPPORTED Notify Payload, the initiator has the option to restart the CREATE_CHILD_SA exchange. When the initiator receives the HCP_SUPPORTED Notify Payload, it will evaluate the Proposal to ensure it aligns with the initial proposal and adheres to its policies prior to executing the HCP. Migault, et al. Expires 7 May 2025 [Page 3] Internet-Draft EHC extension November 2024 Initiator Responder ------------------------------------------------------------------- HDR, SA, KEi, Ni --> <-- HDR, SA, KEr, Nr HDR, SK {IDi, AUTH, SA, TSi, TSr, N(HCP_SUPPORTED 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_SUPPORTED Proposal_ID=2, HCP Name="Diet-ESP" AfRG_a ... AfRG_j, AfRG_k, ... AfRG_u) Figure 1: The parameters for Diet-ESP have been established through the HCP_SUPPORTED Notify exchange. In this instance, the responder has opted for the second Proposal, which includes the specified Attributes for Rules Generation (AfRG). Any absent AfRG will default to their predetermined values. 3. HCP_SUPPORTED and HCP_UNSUPPORTED Notify Payloads Figure 2 describes the HCP_SUPPORTED and HCP_UNACCEPTABLE_PARAMETER Notify Payload. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID | SPI Size | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Notify Payload Migault, et al. Expires 7 May 2025 [Page 4] Internet-Draft EHC extension November 2024 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_SUPPORTED and TBA2 for HCP_UNSUPPORTED When sent by the Initiator, the HCP_SUPPORTED Notify Payload contains a list of Proposal payloads described in Figure 3. When sent by the responder the HCP_SUPPORTED 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Proposal Payload Proposal ID (1 octet): The number identifying the Proposal. EHCP Name (2 octets): The identifier of the EHCP Name. (see Section 7.3) Proposal Length (2 octets): The length in octet 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 4. 4. Attributes for Rules Generation Attributes for Rules Generation (AfRG) follow the same format as the Transform Attribute [RFC7296], Section 3.3.5 reminded for convenience below: Migault, et al. Expires 7 May 2025 [Page 5] Internet-Draft EHC extension November 2024 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Transform Attribute Payload There are two types of AfRG: 1) AfRG that are specific to a given HCP and 2) generic AfRG. This specification defines range_afrg_proposal as a Generic Attribute for Rules Generation to specify that a given AfRG can be selected within a range of value. * Designation: range_afrg_proposal * Has Associated Data: YES (AF=0) * Attribute Data: Let AfRG_min and AfRG_max the minimum and maximum values of the proposed range, expressed following the Transform Attribute Payload format. The corresponding Attribute Data is the concatenation of AfRG_min and AfRG_max. 5. Registrating a Header Compression Profile An HCP needs to register a HCP Name in Section 7.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 and the Default Value MUST be specified. 6. Registration of Diet-ESP EHCP This section defines the code points that are needed to agree the AfRG between two IKEv2 peers as described in Section 5. * HCP Name: "Diet-ESP" as specified in Section 7.3. * Specification : [I-D.mglt-ipsecme-diet-esp] The following Attributes for Rules Generation are defined: DSCP Compression/Decompression Action (CDA) * Designation: dscp_cda Migault, et al. Expires 7 May 2025 [Page 6] Internet-Draft EHC extension November 2024 * Has Associated Data: YES (AF=0) * Attribute Data: DSCP CDA takes discrete values coded over one byte as described in DSCP CDA Value Registry Section 7.5.1 * Default Value: the default value is set to "uncompress" ECN Compression/Decompression Action (CDA) * Designation: ecn_cda * Has Associated Data: YES (AF=0) * Attribute Data: ECN CDA takes discrete values coded over one byte as described in the ECN CDA Value Registry Section 7.5.2 * Default Value: the default value is set to "uncompress" Flow Label Compression/Decompression Action (CDA) * Designation: flow_label_cda * Has Associated Data: YES (AF=0) * Attribute Data: Flow Label CDA takes discrete values coded over one byte as described in the Flow Label CDA Value Registry Section 7.5.3 * Default Value: the default value is set to "uncompress" OS or Network Bit Alignment * Designation: alignment * Has Associated Data: YES (AF=0) * Attribute Data: Byte Alignment takes discrete values coded over one byte as described in the Bit Alignment Value Registry Section 7.5.4 * Default Value: the default value is set to "32 bit" which correspond to the standard IPv6 bit alignment Security Policy Index (SPI) Least Significant Bits (LSB) * Designation: esp_spi_lsb * Has Associated Data: YES (AF=0) Migault, et al. Expires 7 May 2025 [Page 7] Internet-Draft EHC extension November 2024 * Attribute Data: 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 ESP Sequence Number (SN) Least Significant Bits (LSB) * Designation: esp_sn_lsb * Has Associated Data: YES (AF=0) * Attribute Data: 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 ESP 7. IANA Considerations 7.1. Registration of IKEv2 Notify Message Types IANA has allocated two values in the "IKEv2 Notify Message Types - Status Types" registry: Value Notify Messages - Status Types ----------------------------------------- TBA1 HCP_SUPPORTED TBA2 HCP_UNSUPPORTED This specification requests the IANA to create an IKEv2 Header Compression registry (see Section 7.3), as well as the necessary registries for the ESP Header Compression Profile Diet-ESP, that is the Attribute for Rules Generations (see Section 7.4 as well as, when required, the complementary specific AfRG Values associated to each AfRG (see Section 7.5). All registries are "Specification Required". 7.2. Registry for Generic Attributes for Rules Generation Registry for Generic Attributes for Rules Generation. When Associated Data is set to YES, the AF bit of the corresponding Transform Attribute Payload is set to 0 and 1 otherwise. The AfRG Code Point mentioned here MUST NOT be reused by any Registries associated to any Profile and are shared bu all profiles. Migault, et al. Expires 7 May 2025 [Page 8] Internet-Draft EHC extension November 2024 +===========+=======+=============+================+===========+ | AfRG Code | Full | Designation | Has Associated | Reference | | Point | Name | | Data | | +===========+=======+=============+================+===========+ | 65535 | RANGE | range_afrg | YES | ThisRFC | | | AfRG | | | | +-----------+-------+-------------+----------------+-----------+ Table 1 7.3. Registry for IKEv2 Header Compression Profile +================+=============+===========+ | Value (1 Byte) | Designation | Reference | +================+=============+===========+ | 0 | Diet-ESP | ThisRFC | +----------------+-------------+-----------+ | 1-255 | unallocated | - | +----------------+-------------+-----------+ Table 2 7.4. Registry for Diet-ESP Attributes for Rules Generation Registry for Attributes for Rules Generation 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 and 1 otherwise. Migault, et al. Expires 7 May 2025 [Page 9] Internet-Draft EHC extension November 2024 +===========+=============+================+============+===========+ | AfRG | Full Name | Designation | Has | Reference | | Code | | | Associated | | | Point | | | Data | | +===========+=============+================+============+===========+ | 0 | DSCP CDA | dscp_cda | YES | ThisRFC | +-----------+-------------+----------------+------------+-----------+ | 1 | ECN CDA | ecn_cda | YES | ThisRFC | +-----------+-------------+----------------+------------+-----------+ | 2 | Flow Label | flow_label_cda | YES | ThisRFC | | | CDA | | | | +-----------+-------------+----------------+------------+-----------+ | 3 | Alignment | alignment | YES | ThisRFC | +-----------+-------------+----------------+------------+-----------+ | 4 | SPI LSB | esp_spi_lsb | YES | ThisRFC | +-----------+-------------+----------------+------------+-----------+ | 5 | SN LSB | esp_spi_sn | YES | ThisRFC | +-----------+-------------+----------------+------------+-----------+ | 6 - | unallocated | - | - | - | | 2^16-2 | | | | | +-----------+-------------+----------------+------------+-----------+ Table 3 7.5. Registries for the Values of Diet-ESP Attributes for Rules Generation 7.5.1. DSCP CDA Value Registry +=======+=============+===========+ | Value | Designation | Reference | +=======+=============+===========+ | 0 | uncompress | ThisRFC | +-------+-------------+-----------+ | 1 | lower | ThisRFC | +-------+-------------+-----------+ | 2 | sa | ThisRFC | +-------+-------------+-----------+ | 3-255 | unallocated | - | +-------+-------------+-----------+ Table 4 Migault, et al. Expires 7 May 2025 [Page 10] Internet-Draft EHC extension November 2024 7.5.2. ECDN CDA Value Registry +=======+=============+===========+ | Value | Designation | Reference | +=======+=============+===========+ | 0 | uncompress | ThisRFC | +-------+-------------+-----------+ | 1 | lower | ThisRFC | +-------+-------------+-----------+ | 2-255 | unallocated | - | +-------+-------------+-----------+ Table 5 7.5.3. Flow Label CDA Value Registry +=======+=============+===========+ | Value | Designation | Reference | +=======+=============+===========+ | 0 | uncompress | ThisRFC | +-------+-------------+-----------+ | 1 | lower | ThisRFC | +-------+-------------+-----------+ | 2 | generated | ThiesRFC | +-------+-------------+-----------+ | 3 | zero | ThisRFC | +-------+-------------+-----------+ | 4-255 | unallocated | - | +-------+-------------+-----------+ Table 6 7.5.4. OS or Network Byte Alignment +=======+=============+===========+ | Value | Designation | Reference | +=======+=============+===========+ | 0 | 8 bit | ThisRFC | +-------+-------------+-----------+ | 1 | 16 bit | ThisRFC | +-------+-------------+-----------+ | 2 | 32 bit | ThiesRFC | +-------+-------------+-----------+ | 3 | 64 bit | ThisRFC | +-------+-------------+-----------+ | 4-255 | unallocated | - | +-------+-------------+-----------+ Migault, et al. Expires 7 May 2025 [Page 11] Internet-Draft EHC extension November 2024 Table 7 8. Security Considerations The protocol defined in this document does not modify IKEv2. Proposals may expressed in various ways and may be expressed in a specific way so its treatment overload the receiver. The receiver needs to consider aborting the exchange when too much resources are required. 9. Normative References [I-D.mglt-ipsecme-diet-esp] Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, "ESP Header Compression Profile", Work in Progress, Internet-Draft, draft-mglt-ipsecme-diet-esp-12, 18 March 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Daniel Migault Ericsson Email: daniel.migault@ericsson.com Tobias Guggemos LMU Email: guggemos@nm.ifi.lmu.de David Schinazi Google LLC Migault, et al. Expires 7 May 2025 [Page 12] Internet-Draft EHC extension November 2024 Email: dschinazi.ietf@gmail.com J. William Atwood Concordia University Email: william.atwood@concordia.ca Daiying Liu Ericsson Email: harold.liu@ericsson.com Stere Preda Ericsson Email: stere.preda@ericsson.com Maryam Hatami Concordia University Email: maryam.hatami@mail.concordia.ca Sandra Céspedes Concordia University Email: sandra.cespedes@concordia.ca Migault, et al. Expires 7 May 2025 [Page 13]