idnits 2.17.00 (12 Aug 2021) /tmp/idnits58551/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-06.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 (12 July 2021) is 313 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) == Missing Reference: 'TBD1' is mentioned on line 238, but not defined == Missing Reference: 'TBD2' is mentioned on line 263, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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: 13 January 2022 M. Bharath 6 Mavenir 7 M. Chen 8 CMCC 9 12 July 2021 11 IKEv2 Optional SA&TS Payloads in Child Exchange 12 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-06 14 Abstract 16 This document describes a method for reducing the size of the 17 Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges 18 used for rekeying of the IKE or Child SA by replacing the SA and TS 19 payloads with a Notify Message payload. Reducing size and complexity 20 of IKEv2 exchanges is especially useful for low power consumption 21 battery powered devices. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 13 January 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 3. Negotiation of Support for OPTIMIZED REKEY . . . . . . . . . 3 60 4. Optimized Rekey of the IKE SA . . . . . . . . . . . . . . . . 4 61 5. Optimized Rekey of Child SAs . . . . . . . . . . . . . . . . 5 62 6. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. OPTIMIZED_REKEY_SUPPORTED Notify . . . . . . . . . . . . 5 64 6.2. OPTIMIZED_REKEY Notify . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 8. Operational Considerations . . . . . . . . . . . . . . . . . 7 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 11. Normative References . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The Internet Key Exchange protocol version 2 (IKEv2) [RFC7296] is 75 used to negotiate Security Association (SA) parameters for the IKE SA 76 and the Child SAs. Cryptographic key material for these SAs have a 77 limited lifetime before it needs to be refreshed, a process referred 78 to as "rekeying". IKEv2 uses the CREATE_CHILD_SA exchange to rekey 79 either the IKE SA or the Child SAs. 81 When rekeying, a full set of previously negotiated parameters are 82 exchanged. However, most of these parameters will be the same, and 83 some of these parameters MUST be the same. 85 For example, the Traffic Selector (TS) negotiated for the new Child 86 SA MUST cover the Traffic Selectors negotiated for the old Child SA. 87 And in practically all cases, a new Child SA would not need to cover 88 more Traffic Selectors. In the rare case where this would be needed, 89 a new Child SA could be negotiated instead of the current Child SA 90 being rekeyed. Similarly, IKEv2 states that the cryptographic 91 parameters negotiated for rekeying SHOULD NOT be different. This 92 means that the security properties of the IKE or Child SA in practise 93 do not change during a typical rekey. 95 This document specifies a method to omit these parameters and replace 96 them with a single Notify Message declaring that all these parameters 97 are identical to the originally negotiated parameters. 99 For security gateways/ePDG in 4G networks or cRAN/Cloud gateways in 100 5G networks, gateways typically support more than 100,000 IKE/IPSec 101 tunnels. At any point in time, there will be hundreds or thousands 102 of IKE SAs and Child SAs that are being rekeyed. This takes a large 103 amount of bandwidth and CPU power and any protocol simplification or 104 bandwidth reducing would result in an significant resource saving. 106 For Internet of Things (IoT) devices which utilize low power 107 consumption technology, reducing the size of rekey exchange reduces 108 its power consumption, as sending bytes over the air is usually the 109 most power consuming operation of such a device. Reducing the CPU 110 operations required to verify the rekey exchanges parameters will 111 also save power and extend the lifetime for these devices. 113 When using identical parameters during the IKE or Child SA rekey, the 114 SA and TS payloads can be omitted. For an IKE SA rekey, instead of 115 the (large) SA payload, only a Key Exchange (KE) payload and a new 116 Notify Type payload with the new SPI is required. For a Child SA 117 payload, instead of the SA or TS payloads, only an optional Nonce 118 payload (when using PFS) and a new Notify Type payload with the new 119 SPI is needed. This makes the rekey exchange packets much smaller 120 and the peers do not need to verify that the SA or TS parameters are 121 compatible with the old SA. 123 2. Conventions Used in This Document 125 2.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Negotiation of Support for OPTIMIZED REKEY 135 To indicate support for the optimized rekey negotiation, the 136 initiator includes the OPTIMIZED_REKEY_SUPPORTED Notify payload in 137 the IKE_AUTH exchange request. A responder that supports the 138 optimized rekey exchange includes the OPTIMIZED_REKEY_SUPPORTED 139 Notify payload in its response. Note that the notify indicates 140 support for optimized rekey for both IKE and Child SAs. 142 When a peer wishes to rekey an IKE SA or Child SA, it MAY use the 143 optimized rekey method during the CREATE_CHILD_SA exchange. A 144 responder MUST accept that the initiator uses a regular or optimized 145 rekey. 147 The IKE_AUTH message exchange in this case is shown below: 149 Initiator Responder 150 -------------------------------------------------------------------- 151 HDR, SK {IDi, [CERT,] [CERTREQ,] 152 [IDr,] AUTH, SAi2, TSi, TSr, 153 N(OPTIMIZED_REKEY_SUPPORTED)} --> 154 <-- HDR, SK {IDr, [CERT,] AUTH, 155 SAr2, TSi, TSr, 156 N(OPTIMIZED_REKEY_SUPPORTED)} 158 If the responder does not support this extension, as per regular 159 IKEv2 processing, it MUST ignore the unknown Notify payload. The 160 initiator will notice the lack of the OPTIMIZED_REKEY_SUPPORTED 161 Notify in the reply and thus know it cannot use the optimized rekey 162 method. 164 4. Optimized Rekey of the IKE SA 166 The initiator of an optimized rekey request sends a CREATE_CHILD_SA 167 payload with the OPTIMIZED_REKEY notify payload containing the new 168 Security Parameter Index (SPI) for the new IKE SA. It omits the SA 169 payload. 171 The responder of an optimized rekey request performs the same 172 process. It includes the OPTIMIZED_REKEY notify with its new IKE SPI 173 and omits the SA payload. 175 Both parties send Nonce and KE payloads just as they would do for a 176 regular IKE SA rekey. 178 The CREATE_CHILD_SA message exchange in this case is shown below: 180 Initiator Responder 181 -------------------------------------------------------------------- 182 HDR, SK {N(OPTIMIZED_REKEY), 183 Ni, KEi} --> 184 <-- HDR, SK {N(OPTIMIZED_REKEY), 185 Nr, KEr} 187 5. Optimized Rekey of Child SAs 189 The initiator of an optimized rekey request sends a CREATE_CHILD_SA 190 payload with the OPTIMIZED_REKEY notify payload containing the new 191 Security Parameter Index (SPI) for the new Child SA. It omits the SA 192 and TS payloads. If the current Child SA was negotiated with Perfect 193 Forward Secrecy (PFS), a KEi payload MUST be included as well. If no 194 PFS was negotiated for the current Child SA, a KEi payload MUST NOT 195 be included. 197 The responder of an optimized rekey request performs the same 198 process. It includes the OPTIMIZED_REKEY notify with its new IKE SPI 199 and omits the SA and TS payloads. Depending on the PFS negotiation 200 of the current Child SA, the responder includes a KEr payload. 202 Both parties send Nonce payloads just as they would do for a regular 203 Child SA rekey. 205 Using the received old SPI from the REKEY_SA payload and the new SPI 206 received from the OPTIMIZED_REKEY payload, both parties can perform 207 the Child SA rekey operation. 209 The CREATE_CHILD_SA message exchange in this case is shown below: 211 Initiator Responder 212 -------------------------------------------------------------------- 213 HDR, SK {N(REKEY_SA), N(OPTIMIZED_REKEY), 214 Ni, [KEi,]} --> 215 <-- HDR, SK {N(OPTIMIZED_REKEY), 216 Nr, [KEr,]} 218 6. Payload Formats 220 6.1. OPTIMIZED_REKEY_SUPPORTED Notify 222 The OPTIMIZED_REKEY_SUPPORTED Notify Message type notification is 223 used by the initiator and responder to indicate their support for the 224 optimized rekey negotiation. 226 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Next Payload |C| RESERVED | Payload Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 * Protocol ID (1 octet) - MUST be 0. 236 * SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 238 * Notify Message Type (2 octets) - MUST be set to the value [TBD1]. 240 This Notify Message type contains no data. 242 6.2. OPTIMIZED_REKEY Notify 244 The OPTIMIZED_REKEY Notify Message type is used to perform an 245 optimized IKE SA or Child SA rekey. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Next Payload |C| RESERVED | Payload Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 |Protocol ID | SPI Size (=8) | Notify Message Type | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Security Parameter Index (SPI) | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 * Protocol ID (1 octet) - MUST be 1. 260 * SPI Size (1 octet) - MUST be 8 when rekeying an IKE SA. MUST be 4 261 when rekeying a Child SA. 263 * Notify Message Type (2 octets) - MUST be set to the value [TBD2]. 265 * SPI (4 octets or 8 octets) - Security Parameter Index. The peer's 266 new SPI. 268 7. IANA Considerations 270 This document defines two new Notify Message Types in the "IKEv2 271 Notify Message Types - Status Types" registry. IANA is requested to 272 assign codepoints in this registry. 274 NOTIFY messages: status types Value 275 ---------------------------------------------------------- 276 OPTIMIZED_REKEY_SUPPORTED TBD1 277 OPTIMIZED_REKEY TBD2 279 8. Operational Considerations 281 Some implementations allow sending rekey messages with a different 282 set of Traffic Selectors or cryptographic parameters in response to a 283 configuration update. IKEv2 states this SHOULD NOT be done. Whether 284 or not optimized rekeying is used, a configuration change that 285 changes the Traffic Selectors or cryptographic parameters MUST NOT 286 use the optimized rekey method. It SHOULD also not use a regular 287 rekey method but instead start an entire new IKE and Child SA 288 negotiation with the new parameters. 290 9. Security Considerations 292 The optimized rekey removes sending unnecessary new parameters that 293 originally would have to be validated against the original 294 parameters. In that sense, this optimization enhances the security 295 of the rekey process. 297 10. Acknowledgments 299 Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony. 301 11. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 309 Kivinen, "Internet Key Exchange Protocol Version 2 310 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 311 2014, . 313 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 314 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 315 May 2017, . 317 Authors' Addresses 319 Sandeep Kampati 320 Huawei Technologies 321 Divyashree Techno Park, Whitefield 322 Bangalore 560066 323 Karnataka 324 India 326 Email: sandeepkampati@huawei.com 327 Wei Pan 328 Huawei Technologies 329 101 Software Avenue, Yuhuatai District 330 Nanjing 331 Jiangsu, 332 China 334 Email: william.panwei@huawei.com 336 Meduri S S Bharath 337 Mavenir Systems Pvt Ltd 338 Manyata Tech Park 339 Bangalore 340 Karnataka 341 India 343 Email: bharath.meduri@mavenir.com 345 Meiling Chen 346 China Mobile 347 32 Xuanwumen West Street, West District 348 Beijing 349 Beijing, 100053 350 China 352 Email: chenmeiling@chinamobile.com