idnits 2.17.1 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-08.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When rekeying, a full set of negotiation parameters are exchanged. However, most of these parameters will be the same as before, and some of these parameters MUST not change. -- The document date (10 February 2022) is 805 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) No issues found here. 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 Working Group S. Kampati 3 Internet-Draft W. Pan 4 Intended status: Standards Track Huawei 5 Expires: 14 August 2022 P. Wouters 6 Aiven 7 M. Bharath 8 Mavenir 9 M. Chen 10 CMCC 11 M. Richardson, Ed. 12 Sandelman Software Works 13 10 February 2022 15 IKEv2 Optional SA&TS Payloads in Child Exchange 16 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-08 18 Abstract 20 This document describes a method for reducing the size of the 21 Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges 22 used for rekeying of the IKE or Child SA by replacing the SA and TS 23 payloads with a Notify Message payload. Reducing size and complexity 24 of IKEv2 exchanges is especially useful for low power consumption 25 battery powered devices. 27 About This Document 29 This note is to be removed before publishing as an RFC. 31 Status information for this document may be found at 32 https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts- 33 payloads-opt/. 35 Discussion of this document takes place on the ipsec Working Group 36 mailing list (mailto:ipsec@ietf.org), which is archived at 37 https://mailarchive.ietf.org/arch/browse/ipsec/. 39 Source for this draft and an issue tracker can be found at 40 https://github.com/mcr/ipsecme-ikev2-sa-ts-payloads.git. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 14 August 2022. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 77 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 78 3. Negotiation of Support for OPTIMIZED REKEY . . . . . . . . . 4 79 4. Optimized Rekey of the IKE SA . . . . . . . . . . . . . . . . 5 80 5. Optimized Rekey of Child SAs . . . . . . . . . . . . . . . . 5 81 6. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6 82 6.1. OPTIMIZED_REKEY_SUPPORTED Notify . . . . . . . . . . . . 6 83 6.2. OPTIMIZED_REKEY Notify . . . . . . . . . . . . . . . . . 7 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 85 8. Operational Considerations . . . . . . . . . . . . . . . . . 8 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 88 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 91 1. Introduction 93 The Internet Key Exchange protocol version 2 (IKEv2) [RFC7296] is 94 used to negotiate Security Association (SA) parameters for the IKE SA 95 and the Child SAs. Cryptographic key material for these SAs have a 96 limited lifetime before it needs to be refreshed, a process referred 97 to as "rekeying". IKEv2 uses the CREATE_CHILD_SA exchange to rekey 98 either the IKE SA or the Child SAs. 100 When rekeying, a full set of negotiation parameters are exchanged. 101 However, most of these parameters will be the same as before, and 102 some of these parameters MUST not change. 104 For example, the Traffic Selector (TS) negotiated for the new Child 105 SA MUST cover the Traffic Selectors negotiated for the old Child SA. 106 And in practically all cases, a new Child SA does not need to cover a 107 wider set of Traffic. In the rare case where this would be needed, 108 either a standard rekey could be used or a new Child SA could be 109 negotiated followed by a deletion of the replaced Child SA. 111 Similarly, IKEv2 states that the cryptographic parameters negotiated 112 for rekeying SHOULD NOT be different. This means that the security 113 properties of the IKE or Child SA in practise do not change during a 114 typical rekey. 116 This document specifies a method to omit these parameters and replace 117 them with a single Notify Message declaring that all these parameters 118 are identical to the originally negotiated parameters. 120 Large scale IKEv2 gateways such as Evolved Packet Data Gateway (ePDG) 121 in 4G networks or Centralized Radio Access Network (cRAN/Cloud) 122 gateways in 5G networks typically support more than 100,000 IKE/IPsec 123 connections. At any point in time, there will be hundreds or 124 thousands of IKE SAs and Child SAs that are being rekeyed. This 125 takes a large amount of bandwidth and CPU power and any protocol 126 simplification or bandwidth reducing would result in a significant 127 resource saving. 129 For Internet of Things (IoT) devices which utilize low power 130 consumption technology, reducing the size of the CREATE_CHILD_SA 131 exchange for rekeying reduces its power consumption, as sending bytes 132 over the air is usually the most power consuming operation of such a 133 device. Reducing the CPU operations required to verify the rekey 134 exchanges parameters will also save power and extend the lifetime for 135 these devices. 137 When using identical parameters for the IKE SA or Child SA rekey, the 138 SA and TS payloads can be omitted thanks to the optimization defined 139 in this document. For an IKE SA rekey, instead of the (large) SA 140 payload, only a Key Exchange (KE) payload and a new Notify Type 141 payload with the new SPI are required. For a Child SA payload, 142 instead of the SA or TS payloads, only an optional nonce payload 143 (when using PFS) and a new Notify Type payload with the new SPI are 144 needed. This makes the rekey exchange packets much smaller and the 145 peers do not need to verify that the SA or TS parameters are 146 compatible with the old SA parameters. 148 2. Conventions Used in This Document 150 2.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 3. Negotiation of Support for OPTIMIZED REKEY 160 To indicate support for the optimized rekey negotiation, the 161 initiator includes the OPTIMIZED_REKEY_SUPPORTED notify payload in 162 the IKE_AUTH exchange request. During this initial key request, the 163 entire SA and TA payloads are included as normal. A responder that 164 supports the optimized rekey exchange includes the 165 OPTIMIZED_REKEY_SUPPORTED notify payload in its response. Note that 166 the notify indicates support for optimized rekey for both IKE and 167 Child SAs. 169 A responder that does not support the optimized rekey exchange 170 processes the SA and TA payloads as normal, and does not include the 171 new Notify. As per regular IKEv2 processing, a responder that does 172 not recognize this new Notify, MUST ignore the notify. Responders 173 may have been administratively configured with the optimization 174 turned off for local reasons. The absense of the Notify indicates to 175 the initiator that the optimization is not available, and normal, 176 full rekey should be done. 178 When a peer wishes to rekey an IKE SA or Child SA, it MAY use the 179 optimized rekey method during the CREATE_CHILD_SA exchange. If both 180 peers have exchanged OPTIMIZED_REKEY_SUPPORTED notifies, peers SHOULD 181 use the optimized rekey method for rekeys. Non-optimized, regular 182 rekey requests MUST always be accepted. 184 The IKE_AUTH message exchange in this case is shown below: 186 Initiator Responder 187 -------------------------------------------------------------------- 188 HDR, SK {IDi, [CERT,] [CERTREQ,] 189 [IDr,] AUTH, SAi2, TSi, TSr, 190 N(OPTIMIZED_REKEY_SUPPORTED)} --> 191 <-- HDR, SK {IDr, [CERT,] AUTH, 192 SAr2, TSi, TSr, 193 N(OPTIMIZED_REKEY_SUPPORTED)} 195 4. Optimized Rekey of the IKE SA 197 The initiator of an optimized rekey request sends a CREATE_CHILD_SA 198 payload with the OPTIMIZED_REKEY notify payload containing the new 199 Security Parameter Index (SPI) for the new IKE SA. It omits the SA 200 payload. 202 The responder of an optimized rekey request replies with an included 203 OPTIMIZED_REKEY notify with its new IKE SPI and also omits the SA 204 payload. 206 Both parties send their nonce and KE payloads just as they would do 207 for a regular IKE SA rekey. 209 Using the old SPI from the IKE header and the two new SPIs 210 respectively from the initiator and responder's OPTIMIZED_REKEY 211 payloads, both parties can perform the IKE SA rekey operation. 213 The CREATE_CHILD_SA message exchange in this case is shown below: 215 Initiator Responder 216 -------------------------------------------------------------------- 217 HDR, SK {N(OPTIMIZED_REKEY,newSPIi), 218 Ni, KEi} --> 219 <-- HDR, SK {N(OPTIMIZED_REKEY,newSPIr), 220 Nr, KEr} 222 5. Optimized Rekey of Child SAs 224 The initiator of an optimized rekey request sends a CREATE_CHILD_SA 225 payload with the OPTIMIZED_REKEY notify payload containing the new 226 Security Parameter Index (SPI) for the new Child SA. It omits the SA 227 and TS payloads. If the current Child SA was negotiated with Perfect 228 Forward Secrecy (PFS), a KEi payload MUST be included as well. If no 229 PFS was negotiated for the current Child SA, a KEi payload MUST NOT 230 be included. 232 The responder of an optimized rekey request performs the same 233 process. It includes the OPTIMIZED_REKEY notify with its new IKE SPI 234 and omits the SA and TS payloads. Depending on the PFS negotiation 235 of the current Child SA, the responder includes a KEr payload. 237 Both parties send their nonce payloads just as they would do for a 238 regular Child SA rekey. 240 Using the old SPI from the REKEY_SA payload and the two new SPIs 241 respectively from the initiator and responder's OPTIMIZED_REKEY 242 payloads, both parties can perform the Child SA rekey operation. 244 The CREATE_CHILD_SA message exchange in this case is shown below: 246 Initiator Responder 247 -------------------------------------------------------------------- 248 HDR, SK {N(REKEY_SA,oldSPI), N(OPTIMIZED_REKEY,newSPIi), 249 Ni, [KEi,]} --> 250 <-- HDR, SK {N(OPTIMIZED_REKEY,newSPIr), 251 Nr, [KEr,]} 253 6. Payload Formats 255 6.1. OPTIMIZED_REKEY_SUPPORTED Notify 257 The OPTIMIZED_REKEY_SUPPORTED Notify Message type notification is 258 used by the initiator and responder to indicate their support for the 259 optimized rekey negotiation. 261 1 2 3 262 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 263 +---------------+-+-------------+-------------------------------+ 264 | Next Payload |C| RESERVED | Payload Length | 265 +---------------+-+-------------+-------------------------------+ 266 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 267 +---------------+---------------+-------------------------------+ 269 * Protocol ID (1 octet) - MUST be 0. 271 * SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 273 * Notify Message Type (2 octets) - MUST be set to the value TBD1. 275 This Notify Message type contains no data. 277 The Critical bit MUST be 0. A non-zero value MUST be ignored. 279 6.2. OPTIMIZED_REKEY Notify 281 The OPTIMIZED_REKEY Notify Message type is used to perform an 282 optimized IKE SA or Child SA rekey. 284 0 1 2 3 285 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 286 +---------------+-+-------------+-------------------------------+ 287 | Next Payload |C| RESERVED | Payload Length | 288 +---------------+-+-------------+-------------------------------+ 289 |Protocol ID | SPI Size (=8) | Notify Message Type | 290 +---------------+---------------+-------------------------------+ 291 | Security Parameter Index (SPI) | 292 | | 293 +---------------------------------------------------------------+ 295 * Protocol ID (1 octet) - For an IKE SA rekey, this field MUST 296 contain (1). For Child SAs, this field MUST contain either (2) to 297 indicate AH or (3) to indicate ESP. 299 * SPI Size (1 octet) - MUST be 8 when rekeying an IKE SA. MUST be 4 300 when rekeying a Child SA. 302 * Notify Message Type (2 octets) - MUST be set to the value TBD2. 304 * SPI (4 octets or 8 octets) - Security Parameter Index. The new 305 SPI. 307 The Critical bit MUST be 1. A value of 0 MUST be ignored. 309 7. IANA Considerations 311 This document defines two new Notify Message Types in the "IKEv2 312 Notify Message Types - Status Types" registry. IANA is requested to 313 assign codepoints in this registry. 315 NOTIFY messages: status types Value 316 ---------------------------------------------------------- 317 OPTIMIZED_REKEY_SUPPORTED TBD1 318 OPTIMIZED_REKEY TBD2 320 8. Operational Considerations 322 Some implementations allow sending rekey messages with a different 323 set of Traffic Selectors or cryptographic parameters in response to a 324 configuration update. IKEv2 states this SHOULD NOT be done. Whether 325 or not optimized rekeying is used, a configuration change that 326 changes the Traffic Selectors or cryptographic parameters MUST NOT 327 use the optimized rekey method. It SHOULD also not use a regular 328 rekey method but instead start an entire new IKE and Child SA 329 negotiation with the new parameters. 331 9. Security Considerations 333 The optimized rekey removes sending unnecessary new parameters that 334 originally would have to be validated against the original 335 parameters. In that sense, this optimization enhances the security 336 of the rekey process by reducing the complexity and code required. 338 10. Acknowledgments 340 Special thanks to Valery Smyslov and Antony Antony. 342 11. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, 346 DOI 10.17487/RFC2119, March 1997, 347 . 349 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 350 Kivinen, "Internet Key Exchange Protocol Version 2 351 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 352 2014, . 354 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 355 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 356 May 2017, . 358 Authors' Addresses 360 Sandeep Kampati 361 Huawei Technologies 362 Divyashree Techno Park, Whitefield 363 Bangalore 560066 364 Karnataka 365 India 367 Email: sandeepkampati@huawei.com 368 Wei Pan 369 Huawei Technologies 370 101 Software Avenue, Yuhuatai District 371 Nanjing 372 Jiangsu, 373 China 375 Email: william.panwei@huawei.com 377 Paul Wouters 378 Aiven 380 Email: paul.wouters@aiven.io 382 Meduri S S Bharath 383 Mavenir Systems Pvt Ltd 384 Manyata Tech Park 385 Bangalore 386 Karnataka 387 India 389 Email: bharath.meduri@mavenir.com 391 Meiling Chen 392 China Mobile 393 32 Xuanwumen West Street, West District 394 Beijing 395 100053 396 China 398 Email: chenmeiling@chinamobile.com 400 Michael Richardson (editor) 401 Sandelman Software Works 403 Email: mcr+ietf@sandelman.ca