idnits 2.17.1 draft-mglt-ipsecme-ikev2-diet-esp-extension-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 May 2022) is 714 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-mglt-ipsecme-diet-esp-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ipsecme D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Guggemos 5 Expires: 14 November 2022 LMU Munich 6 D. Schinazi 7 Apple Inc. 8 13 May 2022 10 Internet Key Exchange version 2 (IKEv2) extension for the ESP Header 11 Compression (EHC) Strategy 12 draft-mglt-ipsecme-ikev2-diet-esp-extension-02 14 Abstract 16 ESP Header Compression (EHC) reduces the ESP overhead by compressing 17 ESP fields. Compression results from a coordination of various EHC 18 Rules designed as EHC Strategies. An EHC Strategy may require to be 19 configured with some configuration parameters. 21 When a Security Association (SA) is enabling EHC, the two peers need 22 to agree which EHC Strategy is applied as well as its associated 23 configuration parameters. 25 This document describes an extension of IKEv2 that enables two peers 26 to agree on a specific EHC Strategy as well as its associated 27 configuration parameters. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 14 November 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 66 5. Notify Payload . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. EHC_STRATEGY_SUPPORTED Notify Payload . . . . . . . . . . 6 68 5.2. EHC_STRATEGY_UNACCEPTABLE_PARAMETER Notify Payload . . . 7 69 6. EHC Strategy Configuration Parameters . . . . . . . . . . . . 7 70 7. EHC Strategy Configuration Parameter Attributes . . . . . . . 8 71 7.1. Range Attribute . . . . . . . . . . . . . . . . . . . . . 10 72 7.2. Value Attribute . . . . . . . . . . . . . . . . . . . . . 10 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Requirements notation 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Terminology 86 This section defines terms and acronyms used in this document. 88 - EHC Strategy : EHC Strategy is a generic term defined in 89 [I-D.mglt-ipsecme-diet-esp] that defines the way EHC Rules are 90 coordinated. 92 - Designated EHC Strategy: the specific EHC Strategy agreed between 93 the two peers. [I-D.mglt-ipsecme-diet-esp] defines Diet-ESP as 94 an EHC Strategy and other may be defined in the future. This 95 document only considers Diet-ESP but provides negotiation 96 mechanisms so future EHC Strategies may also be negotiated. 97 New EHC Strategies will require to register the necessary 98 associated EHC Strategy Configuration Parameters. This will 99 typically include a specific designation as well as specific 100 configuration parameters. The parameters are designated as EHC 101 Strategy Configuration Parameter (Parameter) 103 - EHC Strategy Configuration Parameter (Parameter): describes the 104 configuration parameters associated to a specific EHC Strategy. 105 The Parameters includes the EHC Strategy as well as 106 configuration parameters. 108 - EHC Strategy Configuration Parameter Attributes (Attribute): desig 109 nates the necessary attributes associated to each Parameter 110 exchanged in order to agree on the EHC Strategy Configuration 111 Parameter. This document considers two type of attributes: the 112 Range Attribute that indicates a range for a given Parameter, 113 and the Value Attribute that indicates a fixed value associated 114 to a Parameter. 116 - Range Attribute: the payload that indicates a supported range of 117 values on an specific EHC Strategy Configuration Parameter. In 118 this document, all Parameters are associated a specific Range 119 Attribute. 121 - Value Attribute: the payload that indicates a value of an specific 122 EHC Strategy Configuration Parameter. In this document, all 123 Parameters are associated a specific Value Payload. 125 3. Introduction 127 ESP Header Compression (EHC) [I-D.mglt-ipsecme-diet-esp] reduces the 128 ESP overhead by compressing ESP fields. Compression results from a 129 coordination of various EHC Rules performed by the EHC Strategy. The 130 EHC Strategy may require to be configured with some configuration 131 parameters designated as EHC Strategy Configuration Parameter (or 132 simply Parameter). 134 When a Security Association (SA) is enabling EHC the two peers needs 135 to agree which EHC Strategy strategy is applied as well as its 136 associated configuration parameters. 138 This document describes an extension of IKEv2 that enables two peers 139 to agree on a specific EHC Strategy as well as its associated 140 Parameters. 142 4. Protocol Overview 144 ESP Header Compression requires IKEv2 to negotiate the IPsec mode and 145 the used EHC strategy and its corresponding parameters. 147 EHC Strategies are configured on a per-SA basis and need to be agreed 148 between the two peers. An EHC Strategy is agreed when peers have 149 agreed on the EHC Strategy as well as its associated Parameters. 151 For example, [I-D.mglt-ipsecme-diet-esp] defines an EHC Strategy 152 called as Diet-ESP which requires the following Parameters to be set: 153 udplite_coverage, tcp_lsb, tcp_options, tcp_urgent, esp_sn_lsb, 154 esp_spi_lsb, esp_align. 156 The negotiation of the EHC Strategy as well as its Parameters is 157 performed via the EHC_STRATEGY_SUPPORTED Notify Payload exchange. 159 When the initiator is willing to negotiate an EHC Strategy for a 160 given SA, it sends a single EHC_STRATEGY_SUPPORTED Notify Payload in 161 its IKE_AUTH and CREATE_CHILD_SA exchange. This Notify Payload 162 indicates the support to negotiate EHC Strategies. In addition, the 163 Notify Payload MAY indicates with a Range Attribute, the supported 164 values for each Parameter, including the Designated EHC Strategy. If 165 the initiator does not have any restriction regarding a specific 166 Parameter, there is no need to provide an Range Value associated to 167 that Parameter. 169 Currently, the only defined EHC Strategy is Diet-ESP, and the 170 EHC_STRATEGY_SUPPORTED Notify Payload indicates the support for Diet- 171 ESP unless Diet-ESP is explicitly excluded by the Range Attribute. 172 In the future, when other EHC Strategies will be defined, the support 173 of that new Designated EHC Strategy will need to be explicitly 174 announced with its associated Range Attribute. Other Parameters MAY 175 also have their own associated Range Attribute. Note that if 176 multiple EHC Strategies that share a given Parameter, the Range 177 Attribute is applied for all designated EHC Strategies. In other 178 words, it is not possible to have a given Parameter associated with 179 different values depending on the EHC Strategy. 181 Upon receiving the IKE_AUTH and CREATE_CHILD_SA with a 182 EHC_STRATEGY_SUPPORTED Notify Payload, a receiver that does not 183 support this extension or that is not willing to activate EHC ignores 184 the Notify Payload and the negotiation continues as a standard ESP 185 negotiation. If the responder supports EHC Strategy negotiation and 186 chooses to apply a supported EHC Strategy to the negotiated SA, it 187 reads all Range Attributes and selects a Designated EHC Strategy as 188 well as specific values for each Parameter associated to the 189 Designated EHC Strategy. The responder enables EHC for the 190 negotiated SA and responds with an EHC_STRATEGY_SUPPORTED Notify 191 Payload which indicates the selected Parameters' values using Value 192 Attributes. The responder MAY send a Value Attribute that 193 corresponds to all selected Parameters. On the other hand, the 194 responder MAY also send only the Value Attribute of Parameters whose 195 value differs from the default value. In fact each EHC Strategy 196 defines default values for each Parameters. 198 In some cases, the supported values provided by the initiator may not 199 match those of the responder, and so EHC cannot be activated. The 200 responder may want to indicate the supported range provided by the 201 initiator were not acceptable by responding with a 202 EHC_STRATEGY_UNACCEPTABLE_PARAMETER. The initiator MAY carry Range 203 Attributes in order to indicates what it supports. 205 Upon receiving a EHC_STRATEGY_SUPPORTED Notify Payload back, the 206 initiator reads the Value Attributes and checks the Parameters match 207 the supported range. The initiator may configure the EHC Strategy 208 with the provided parameters or abort the negotiation with a Delete 209 Payload as specified in section 3.11 of [RFC7296]. 211 Upon receiving a EHC_STRATEGY_UNACCEPTABLE_PARAMETER Notify Payload, 212 the initiator may use the regular ESP or delete the SA. When the SA 213 is deleted, the initiator is expected to restart a negotiation 214 providing contraints that respect those of the responder. 216 Initiator Responder 217 ------------------------------------------------------------------- 218 HDR, SA, KEi, Ni --> 219 <-- HDR, SA, KEr, Nr 220 HDR, SK {IDi, AUTH, 221 SA, TSi, TSr, 222 N(EHC_STRATEGY_SUPPORTED) 223 <-- HDR, SK {IDr, AUTH, 224 SA, TSi, TSr, 225 N(EHC_STRATEGY_SUPPORTED) 227 Figure 1: Protocol Overview 229 5. Notify Payload 231 Figure 2 illustrates the Notify Payload packet format as described in 232 section 3.10 of [RFC7296], used for EHC_STRATEGY_SUPPORTED and 233 EHC_STRATEGY_UNACCEPTABLE_PARAMETER Notify Payloads. 235 The EHC_STRATEGY_SUPPORTED and EHC_STRATEGY_UNACCEPTABLE_PARAMETER 236 Notify Payloads are used during the IKE_AUTH and CREATE_CHILD_SA. 237 The sender is expected to send only a single payload. When multiple 238 payloads are received, the receiver MAY consider the first one and 239 MUST ignore the remaining ones. 241 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Next Payload |C| RESERVED | Payload Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Protocol ID | SPI Size | Notify Message Type | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 2: Notify Payload 251 The fields Next Payload, Critical Bit, RESERVED, and Payload Length 252 are defined in [RFC7296]. Specific fields defined in this document 253 are: 255 - Protocol ID (1 octet): set to zero. 257 - SPI Size (1 octet): set to zero. 259 - Notify Message Type (2 octets): Specifies the type of notification 260 message. It is set to: 262 for the EHC_STRATEGY_SUPPORTED 264 for EHC_STRATEGY_UNACCEPTABLE_PARAMETER 266 5.1. EHC_STRATEGY_SUPPORTED Notify Payload 268 The EHC_STRATEGY_SUPPORTED Notify Payload indicates the supported EHC 269 Strategies. 271 When sent by the initiator, it MAY contain Range Attributes (see 272 Section 7.1). A responder not understanding a Range Attribute MUST 273 ignore it. This is intended to ease the negotiation of new EHC 274 Strategies with new Parameters. It is its responsibility to 275 understand the Parameters associated to the negotiated EHC Strategy. 277 When sent by the responder, it MAY contain Value Attributes (see 278 Section 7.2). An initiator not understanding a Value Payload MUST 279 NOT create the SA and SHOULD send a Delete Payload to the responder 280 as described in section 3.11 of [RFC7296]. 282 5.2. EHC_STRATEGY_UNACCEPTABLE_PARAMETER Notify Payload 284 The EHC_STRATEGY_UNACCEPTABLE_PARAMETER Notify Payload indicates the 285 responder supports of EHC Strategy negotiation but was not able to 286 configure it due to the constraints provided by the initiator. The 287 responder MAY insert Range Attributes (see Section 7.1) to inform the 288 initiator of its supported ranges. 290 The responder has configured the SA without enabling the EHC. Upon 291 receiving the Notify Payload, the initiator MAY accept the SA without 292 EHC. It MAY also Delete the SA as described in section 3.11 of 293 [RFC7296] and renegotiate the SA, considering the responder's 294 supported ranges. 296 6. EHC Strategy Configuration Parameters 298 This document only considers Diet-ESP, which requires the following 299 Parameters to be agreed by the two peers: esp_align, esp_spi_lsb, 300 esp_sn_lsb, tcp_urgent, tcp_options, tcp_lsb, udplite_coverage. In 301 addition, in order to enable future EHC Strategies, the following 302 parameter has been introduce to designate the agreed EHC Strategy: 303 ehc_strategy. Figure 3 lists these Parameters with description and 304 associated values. 306 In addition, each of these parameter is associated to a default 307 value. The default value is considered unless other values are 308 specified by the responder. The associated default value is 309 specified in Figure 3. 311 Parameter Value Description Default 312 --------------------------------------------------------------- 313 ehc_strategy 0 Diet-ESP * 314 1-127 Unassigned 315 128-255 Private Used 316 esp_align 0 8 bit alignment * 317 1 16 bit alignment 318 2 32 bit alignment 319 3-255 Unassigned 320 esp_spi_lsb 0 0 bit length SPI * 321 1 8 bit length SPI 322 2 16 bit length SPI 323 3 24 bit length SPI 324 4 32 bit length SPI 325 5-255 Unassigned 326 esp_sn_lsb 0 0 bit length SN * 327 1 8 bit length SN 328 2 16 bit length SN 329 3 24 bit length SN 330 4 32 bit length SN 331 5-255 Unassigned 332 tcp_urgent 0 Urgent pointer field compressed 333 1 Urgent pointer field uncompressed * 334 2-255 Unassigned 335 tcp_options 0 TCP option field compressed 336 1 TCP option field uncompressed * 337 2-255 Unassigned 338 tcp_lsb 0 0 bit length SN 339 1 8 bit length SN 340 2 16 bit length SN 341 3 24 bit length SN 342 4 32 bit length SN 343 5-255 Unassigned 344 udplite_coverage 0 Coverage is UDP Length 345 8-65535 Coverage 8 (the UDP-Lite Header) 346 1-7 Unassigned 348 Figure 3: Parameter Values 350 7. EHC Strategy Configuration Parameter Attributes 352 For each of these Parameters, the initiator or responder may indicate 353 acceptable values of these Parameters. Such constraints are 354 expressed with the Range Attributes. Each Parameters has its 355 corresponding payload which carries the minimum and maximum 356 acceptable values associated to the parameters (see Section 7.1). 358 Similarly, for each of these Parameters, the responder needs to be 359 able to provide the selected value associated to the Parameter. Each 360 of these Parameters' value can be expressed by via the Value 361 Attribute. Each parameter has a corresponding payload which carries 362 the associated value (see Section 7.2). 364 The Range Attribute and Value Attribute use the format of the 365 Transform Attribute of section 3.3.5 of [RFC7296] represented in 366 Figure 4. The fields are described in [RFC7296]. 368 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |A| Attribute Type | AF=0 Attribute Length | 372 |F| | AF=1 Attribute Value | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | AF=0 Attribute Data | 375 | AF=1 Not Transmitted | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 4: Parameter Attributes 380 The document considers only the TLV format so AF = 0 with the 381 Parameter Types defined in Figure 5 and acceptable and default 382 Parameter's Values are defined in Figure 3. 384 Attribute Type Value Associated Parameter 385 ---------------------------------------------------------------- 386 EHC Designated Strategy Range 0 ehc_strategy 387 ESP Alignment Range 1 esp_align 388 ESP LSB SPI Range 2 esp_spi_lsb 389 ESP LSB SN Range 3 esp_sn_lsb 390 TCP Urgent Range 4 tcp_urgent 391 TCP Options Range 5 tcp_options 392 TCP LSB Range 6 tcp_lsb 393 UDP-Lite Coverage Range 7 udplite_coverage 394 Unassigned 8-63 395 EHC Designated Strategy Value 64 ehc_strategy 396 ESP Alignment Value 65 esp_align 397 ESP LSB SPI Value 66 esp_spi_lsb 398 ESP LSB SN Value 67 esp_sn_lsb 399 TCP Urgent Value 68 tcp_urgent 400 TCP Options Value 69 tcp_options 401 TCP LSB Value 70 tcp_lsb 402 UDP-Lite Coverage Value 71 udplite_coverage 403 Unassigned 72-99 404 Private Use 100-127 405 Figure 5: Attribute Type 407 7.1. Range Attribute 409 The Parameter's value of ehc_strategy, esp_align, esp_spi_lsb, 410 esp_sn_lsb, tcp_urgent, tcp_options, tcp_lsb and udplite_coverage is 411 coded on 1 byte, so the Attribute Data of the Range Attribute is 2 412 byte long and the Attribute Length is set to 4. The first byte 413 indicates the minimal acceptable value, while the second byte 414 indicates the maximal value. 416 Similarly, udplight_coverage is coded on 2 bytes, so the Attribute 417 Data of the Range Attribute is 4 byte long, and Attribute Length is 418 set to 6. 420 7.2. Value Attribute 422 The Parameters ehc_strategy, esp_align, esp_spi_lsb, esp_sn_lsb, 423 tcp_urgent, tcp_options and tcp_lsb the Attribute Data is codes on 1 424 byte, and Attribute Length is set to 3. 426 Similarly, udplight_coverage is coded on 2 bytes, so the Attribute 427 Data of the Value Attribute is 2 byte long and the Attribute Length 428 is set to 4. 430 8. IANA Considerations 432 IANA is requested to allocate two values in the IKEv2 Notify Message 433 Types - Status Types registry: 435 IKEv2 Notify Message Types - Status Types 436 ----------------------------------------- 437 EHC_STRATEGY_SUPPORTED TBA1 438 EHC_STRATEGY_UNACCEPTABLE_PARAMETER TBA2 439 Attribute Type Value 440 -------------------------------------------- 441 EHC Designated Strategy Range 0 442 ESP Alignment Range 1 443 ESP LSB SPI Range 2 444 ESP LSB SN Range 3 445 TCP Urgent Range 4 446 TCP Options Range 5 447 TCP LSB Range 6 448 UDP-Lite Coverage Range 7 449 Unassigned 8-42 450 Private Use 43-63 451 EHC Designated Strategy Value 64 452 ESP Alignment Value 65 453 ESP LSB SPI Value 66 454 ESP LSB SN Value 67 455 TCP Urgent Value 68 456 TCP Options Value 69 457 TCP LSB Value 70 458 UDP-Lite Coverage Value 71 459 Unassigned 72-116 460 Private Use 117-127 462 Figure 6: Attribute Type 464 9. Security Considerations 466 10. Normative References 468 [I-D.mglt-ipsecme-diet-esp] 469 Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, 470 "ESP Header Compression and Diet-ESP", Work in Progress, 471 Internet-Draft, draft-mglt-ipsecme-diet-esp-08, 13 May 472 2022, . 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 481 Kivinen, "Internet Key Exchange Protocol Version 2 482 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 483 2014, . 485 Authors' Addresses 486 Daniel Migault 487 Ericsson 488 8275 Trans Canada Route 489 Saint-Laurent, QC H4S 490 Canada 491 Email: daniel.migault@ericsson.com 493 Tobias Guggemos 494 LMU Munich 495 Oettingenstr. 67 496 80538 Munich 497 Germany 498 Email: guggemos@nm.ifi.lmu.de 499 URI: www.nm.ifi.lmu.de/~guggemos 501 David Schinazi 502 Apple Inc. 503 One Apple Park Way 504 Cupertino, California 95014 505 United States of America 506 Email: dschinazi@apple.com