idnits 2.17.00 (12 Aug 2021) /tmp/idnits59196/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.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 (July 04, 2021) is 321 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 (~~), 1 warning (==), 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: January 5, 2022 M. Bharath 6 Mavenir 7 M. Chen 8 CMCC 9 July 04, 2021 11 IKEv2 Optional SA&TS Payloads in Child Exchange 12 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05 14 Abstract 16 This document describes a method for reducing the size of the 17 Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying 18 IKE SAs and Child SAs by removing or making optional of SA & TS 19 payloads. Reducing size of IKEv2 exchanges is desirable for low 20 power consumption battery powered devices. It also helps to avoid IP 21 fragmentation of IKEv2 messages. 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 January 5, 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Negotiation of Support for Optimizing Payloads at 62 Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4 63 3.2. Payload Optimization at Rekeying IKE SAs . . . . . . . . 4 64 3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 6 65 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 7 67 4.2. REKEY_OPTIMIZED Notification . . . . . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The Internet Key Exchange protocol version 2 (IKEv2) specified in 77 [RFC7296] is used in the IP Security (IPSec) architecture for the 78 purposes of Security Association (SA) parameters negotiation and 79 authenticated key exchange. The protocol uses UDP as the transport 80 for its messages, which size varies from less than one hundred bytes 81 to several kilobytes. 83 According to [RFC7296], the secret keys used by IKE/IPSec SAs should 84 be used only for a limited amount of time and to protect a limited 85 amount of data. When the lifetime of an SA expires or is about to 86 expire, the peers can rekey the SA to reestablish a new SA to take 87 the place of the old one. 89 For security gateways/ePDG in 4G networks and cRAN/Cloud in 5G 90 networks, they will support more than 100,000 IKE/IPSEC tunnels. So 91 on an average, for every second there may be hundreds or thousands of 92 IKE SAs and Child SAs that are rekeying. This takes huge amount of 93 bandwidth, packet fragmentation and more processing resources. For 94 these devices, these problems can be solved by introducing the 95 solution described in this document. 97 This is also useful in Internet of Things (IoT) devices which 98 utilizing lower power consumption technology. For these devices, 99 reducing the length of IKE/Child SA rekeying messages can save the 100 bandwidth consumption. At the same time, it can also save the 101 computing processes by less payload are included. 103 Most devices don't prefer to change cryptographic suites frequently. 104 By taking this advantage the SA and TS payloads can be made optional 105 at the time of rekeying IKE SAs and Child SAs. In such situation, 106 only a new SPI value is needed to create the new IKE SA and Child SA. 107 So a new Notify payload which contains the needed SPI value can be 108 sent instead of the SA and TS payloads. 110 In case of rekeying IKE SAs, the SA payloads can be optimized if 111 there is no change of cryptographic suites. In case of rekeying 112 Child SAs, the SA and TS payloads can be optimized if there is no 113 change of cryptographic suites and ACL configuration. 115 2. Conventions Used in This Document 117 2.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. Protocol Details 127 This section provides protocol details and contains the normative 128 parts. 130 Before using this new optimization, the IPSec implementation who 131 supports it has to know that the peer also supports it. Without the 132 support on both sides, the optimized rekeying messages sent by one 133 peer may be unrecognizable for the other peer. To prevent this 134 failure from happening, the first step is to negotiate the support of 135 this optimization between the two peers. There are two specific 136 rekeying SAs cases: rekeying IKE SAs and rekeying Child SAs. After 137 the negotiation, the initiator can optimize the rekeying message 138 payloads in both cases. In other words, once the negotiation of 139 support for optimizing payloads at rekeying IKE SAs and Child SAs is 140 complete, both IKE SAs and Child SAs rekeying are supported by the 141 two sides. The responder can react based on the received rekeying 142 message. 144 3.1. Negotiation of Support for Optimizing Payloads at Rekeying IKE SAs 145 and Child SAs 147 The initiator indicates its support for optimizing payloads at 148 rekeying IKE SAs and Child SAs by including a Notify payload of type 149 MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By 150 observing the MINIMAL_REKEY_SUPPORTED notification in the received 151 message, the responder can deduce the initiator's support of this 152 extension. If the responder also supports this extension, it 153 includes the MINIMAL_REKEY_SUPPORTED notification in the 154 corresponding response message. After receiving the response 155 message, the initiator can also know the support of this extension of 156 the responder side. 158 The IKE_AUTH message exchange in this case is shown below: 160 Initiator Responder 161 -------------------------------------------------------------------- 162 HDR, SK {IDi, [CERT,] [CERTREQ,] 163 [IDr,] AUTH, SAi2, TSi, TSr, 164 N(MINIMAL_REKEY_SUPPORTED)} --> 165 <-- HDR, SK {IDr, [CERT,] AUTH, 166 SAr2, TSi, TSr, 167 N(MINIMAL_REKEY_SUPPORTED)} 169 If the responder doesn't support this extension, it MUST ignore the 170 MINIMAL_REKEY_SUPPORTED notification sent by the initiator and MUST 171 NOT respond error to the initiator. With no MINIMAL_REKEY_SUPPORTED 172 notification in the response message, the initiator can deduce that 173 the responder doesn't support this extension. In this case, the IKE 174 SAs and Child SAs rekeyings happen as the usual way without the 175 optimizations defined in this document. 177 The IKE_AUTH message exchange in this case is shown below: 179 Initiator Responder 180 -------------------------------------------------------------------- 181 HDR, SK {IDi, [CERT,] [CERTREQ,] 182 [IDr,] AUTH, SAi2, TSi, TSr, 183 N(MINIMAL_REKEY_SUPPORTED)} --> 184 <-- HDR, SK {IDr, [CERT,] AUTH, 185 SAr2, TSi, TSr} 187 3.2. Payload Optimization at Rekeying IKE SAs 189 The payload optimization at rekeying IKE SAs MUST NOT be used unless 190 both peers have indicated their support of this extension by using 191 the negotiation method described in Section 3.1. 193 At the time of rekeying an IKE SA, when the initiator determines 194 there is no change on its cryptographic suites since this IKE SA was 195 created or last rekeyed, it MUST send the REKEY_OPTIMIZED 196 notification payload instead of the SA payloads in the rekeying 197 request message. In this REKEY_OPTIMIZED notification, it contains 198 the initiator's new Security Parameter Index (SPI) used for creating 199 the new IKE SA. 201 After receiving the initiator's rekeying request message with the 202 REKEY_OPTIMIZED notification and no SA payloads, the responder knows 203 that the initiator wants to optimize the rekeying payload. Then when 204 it determines that there is also no change in its cryptographic 205 suites, the responder MUST send the rekeying respond message to the 206 initiator with the REKEY_OPTIMIZED notification payload instead of 207 the SA payloads. In this REKEY_OPTIMIZED notification, it contains 208 the responder's new SPI used for creating the new IKE SA. 210 According to the initiator's new SPI and the responder's new SPI, the 211 initiator and the responder can rekey the IKE SA on both sides. 213 The CREATE_CHILD_SA message exchange in this case is shown below: 215 Initiator Responder 216 -------------------------------------------------------------------- 217 HDR, SK {N(REKEY_OPTIMIZED), 218 Ni, KEi} --> 219 <-- HDR, SK {N(REKEY_OPTIMIZED), 220 Nr, KEr} 222 The initiator sends a REKEY_OPTIMIZED notification payload, a Nonce 223 payload and a Diffie-Hellman value in the KEi payload. A new 224 initiator SPI is supplied in the SPI field of the REKEY_OPTIMIZED 225 notification payload. These messages also follow the original 226 Perfect Forwarding Secrecy (PFS) with the signature and encryption 227 algorithms used as last message. 229 The responder replies (using the same Message ID to respond) with a 230 REKEY_OPTIMIZED notification payload, a Nonce payload and a Diffie- 231 Hellman value in the KEr payload. A new responder SPI is supplied in 232 the SPI field of the REKEY_OPTIMIZED notification payload. 234 This REKEY_OPTIMIZED notification MUST be included in a 235 CREATE_CHILD_SA exchange message when there is no SA payloads 236 included. When the REKEY_OPTIMIZED notification payload is included, 237 the SA payload MUST NOT be included. 239 3.3. Payload Optimization at Rekeying Child SAs 241 The payload optimization at rekeying Child SAs MUST NOT be used 242 unless both peers have indicated their support of this extension by 243 using the negotiation method described in Section 3.1. 245 At the time of rekeying a Child SA, when the initiator determines 246 there is no change in its cryptographic suites and ACL configuration 247 since this Child SA was created or last rekeyed, it MUST send the 248 REKEY_OPTIMIZED notification payload instead of the SA and TS 249 payloads in the rekeying request message. In this REKEY_OPTIMIZED 250 notification, it contains the initiator's new Security Parameter 251 Index (SPI) used for creating the new Child SA. 253 After receiving the initiator's rekeying request message with the 254 REKEY_OPTIMIZED notification and no SA and TS payloads, the responder 255 knows that the initiator wants to optimize the rekeying payload. 256 Then when it determines that there is also no change in its 257 cryptographic suites and ACL configuration, the responder MUST send 258 the rekeying respond message to the initiator with the 259 REKEY_OPTIMIZED notification payload instead of the SA and TS 260 payloads. In this REKEY_OPTIMIZED notification, it contains the 261 responder's new SPI used for creating the new Child SA. 263 According to the old SPIs included in the REKEY_SA payloads and the 264 new SPIs included in the REKEY_OPTIMIZED payloads, the initiator and 265 the responder can rekey the Child SA on both sides. 267 The CREATE_CHILD_SA message exchange in this case is shown below: 269 Initiator Responder 270 -------------------------------------------------------------------- 271 HDR, SK {N(REKEY_SA), N(REKEY_OPTIMIZED), 272 Ni, [KEi,]} --> 273 <-- HDR, SK {N(REKEY_OPTIMIZED), 274 Nr, [KEr,]} 276 This REKEY_OPTIMIZED notification MUST be included in a 277 CREATE_CHILD_SA exchange message when there is no SA and TS payloads 278 included at the time of rekeying Child SAs. When the REKEY_OPTIMIZED 279 notification payload is included, the SA and TS payloads MUST NOT be 280 included. 282 4. Payload Formats 283 4.1. MINIMAL_REKEY_SUPPORTED Notification 285 The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and 286 responder to inform their ability of optimizing payloads at the time 287 of rekeying IKE SAs and Child SAs to the peers. It is formatted as 288 follows: 290 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Next Payload |C| RESERVED | Payload Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 o Protocol ID (1 octet) - MUST be 0. 300 o SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 302 o Notify Message Type (2 octets) - MUST be , the value assigned for the MINIMAL_REKEY_SUPPORTED 304 notification. 306 This notification contains no data. 308 4.2. REKEY_OPTIMIZED Notification 310 The REKEY_OPTIMIZED notification is used to replace the SA payloads 311 at the time of rekeying IKE SAs when there is no change of 312 cryptographic suites in initiator and responder, and to replace the 313 SA payloads and TS payloads at the time of rekeying Child SAs when 314 there is no change of cryptographic suites and ACL configuration in 315 initiator and responder. It is formatted as follows: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Next Payload |C| RESERVED | Payload Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 |Protocol ID | SPI Size (=8) | Notify Message Type | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Security Parameter Index (SPI) | 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 o Protocol ID (1 octet) - MUST be 1. 330 o SPI Size (1 octet) - MUST be 8 when used at the time of rekeying 331 IKE SAs and be 4 when used at the time of rekeying Child SAs. 333 o Notify Message Type (2 octets) - MUST be , the value assigned for the REKEY_OPTIMIZED notification. 336 o SPI (4 octets or 8 octets) - Security Parameter Index. The 337 initiator sends initiator SPI. The responder sends responder SPI. 339 5. IANA Considerations 341 This document defines two new Notify Message Types in the "IKEv2 342 Notify Message Types - Status Types" registry. IANA is requested to 343 assign codepoints in this registry. 345 NOTIFY messages: status types Value 346 ---------------------------------------------------------- 347 MINIMAL_REKEY_SUPPORTED TBD 348 REKEY_OPTIMIZED TBD 350 6. Security Considerations 352 When using the payload optimization defined in this document, the 353 rekeying of IKE SAs and Child SAs are using the same cryptographic 354 suites. If changes to the configurations are wanted, such as 355 supporting a new cryptographic algorithm, the rekeying won't apply 356 these changes. The initiator or responder should start a new IKE SA 357 or Child SA to apply the new changes. 359 7. Acknowledgments 361 Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony. 363 8. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 371 Kivinen, "Internet Key Exchange Protocol Version 2 372 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 373 2014, . 375 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 376 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 377 May 2017, . 379 Authors' Addresses 381 Sandeep Kampati 382 Huawei Technologies 383 Divyashree Techno Park, Whitefield 384 Bangalore, Karnataka 560066 385 India 387 Email: sandeepkampati@huawei.com 389 Wei Pan 390 Huawei Technologies 391 101 Software Avenue, Yuhuatai District 392 Nanjing, Jiangsu 393 China 395 Email: william.panwei@huawei.com 397 Meduri S S Bharath 398 Mavenir Systems Pvt Ltd 399 Manyata Tech Park 400 Bangalore, Karnataka 401 India 403 Email: bharath.meduri@mavenir.com 405 Meiling Chen 406 China Mobile 407 32 Xuanwumen West Street, West District 408 Beijing, Beijing 100053 409 China 411 Email: chenmeiling@chinamobile.com