idnits 2.17.1 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-03.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 (March 07, 2021) is 1144 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 M. Bharath 4 Intended status: Standards Track W. Pan 5 Expires: September 8, 2021 Huawei 6 March 07, 2021 8 IKEv2 Optional SA&TS Payloads in Child Exchange 9 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-03 11 Abstract 13 This document describes a method for reducing the size of the 14 Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying 15 IKE SAs and Child SAs by removing or making optional of SA & TS 16 payloads. Reducing size of IKEv2 exchanges is desirable for low 17 power consumption battery powered devices. It also helps to avoid IP 18 fragmentation of IKEv2 messages. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 8, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Negotiation of Support for Optimizing Optional Payload at 59 Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4 60 3.2. Payload Optimization at Rekeying IKE SAs . . . . . . . . 5 61 3.2.1. Rekeying IKE SAs When No Change of Initiator and 62 Responder's Cryptographic Suites . . . . . . . . . . 5 63 3.2.2. Rekeying IKE SAs When Responder's Cryptographic 64 Suites Changed . . . . . . . . . . . . . . . . . . . 6 65 3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 7 66 3.3.1. Rekeying Child SAs When No Change of Initiator and 67 Responder's Cryptographic Suites and ACL 68 Configuration . . . . . . . . . . . . . . . . . . . . 7 69 3.3.2. Rekeying Child SAs When Responder's Cryptographic 70 Suites or ACL Configuration Changed . . . . . . . . . 8 71 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 9 73 4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 10 74 4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 10 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 7.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The Internet Key Exchange protocol version 2 (IKEv2) specified in 85 [RFC7296] is used in the IP Security (IPsec) architecture for the 86 purposes of Security Association (SA) parameters negotiation and 87 authenticated key exchange. The protocol uses UDP as the transport 88 for its messages, which size varies from less than one hundred bytes 89 to several kilobytes. 91 According to [RFC7296], the secret keys used by IKE/IPSec SAs should 92 be used only for a limited amount of time and to protect a limited 93 amount of data. When the lifetime of an SA expires or is about to 94 expire, the peers can rekey the SA to reestablish a new SA to take 95 the place of the old one. 97 For security gateways/ePDG in 4G networks and cRAN/Cloud in 5G 98 networks, they will support more than 100,000 IKE/IPSEC tunnels. So 99 on an average, for every second there may be hundreds or thousands of 100 IKE SAs and Child SAs that are rekeying. This takes huge amount of 101 bandwidth, packet fragmentation and more processing resources. For 102 these devices, these problems can be solved by introducing the 103 solution described in this document. 105 This is also useful in Internet of Things (IoT) devices which 106 utilizing lower power consumption technology. The appendix A of 107 [I-D.mglt-6lo-diet-esp-requirements] gives some estimate data. For 108 these devices, reducing the length of IKE/Child SA rekeying messages 109 can save the bandwidth consumption. At the same time, it can also 110 save the computing processes by less payload are included. 112 Most devices don't prefer to change cryptographic suites frequently. 113 By taking this advantage the SA and TS payloads can be made optional 114 at the time of rekeying IKE SAs and Child SAs. In such situation, 115 only a new SPI value is needed to create the new IKE SA and Child SA. 116 So a new Notify payload which contains the needed SPI value can be 117 sent instead of the SA and TS payloads. 119 In case of rekeying IKE SAs, the SA payloads can be optimized if 120 there is no change of cryptographic suites. In case of rekeying 121 Child SAs, the SA and TS payloads can be optimized if there is no 122 change of cryptographic suites and ACL configuration. 124 2. Conventions Used in This Document 126 2.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. Protocol Details 136 This section provides protocol details and contains the normative 137 parts. 139 Before using this new optimization, the IPSec implementation who 140 supports it has to know that the peer also supports it. Without the 141 support on both sides, the optimized rekeying messages sent by one 142 peer may be unrecognizable for the other peer. To stop this failure 143 from happening, the first step is to negotiate the support of this 144 optimization between the two peers. There are two specific rekeying 145 SAs cases: rekeying IKE SAs and rekeying Child SAs. After the 146 negotiation, it's up to the initiator to decide at which case to 147 optimize the rekeying messages. The initiator can optimize the 148 rekeying message payloads in both cases, or just in one case. The 149 responder can react based on the received rekeying message. 151 3.1. Negotiation of Support for Optimizing Optional Payload at Rekeying 152 IKE SAs and Child SAs 154 The initiator indicates its support for optimizing optional payloads 155 at rekeying IKE SAs and Child SAs by including a Notify payload of 156 type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By 157 observing the MINIMAL_REKEY_SUPPORTED notification in the received 158 message, the responder can deduce the initiator's support of this 159 extension. If the responder also supports this extension, it 160 includes the MINIMAL_REKEY_SUPPORTED notification in the 161 corresponding response message. After receiving the response 162 message, the initiator can also know the support of this extension of 163 the responder side. 165 The IKE_AUTH message exchange in this case is shown below: 167 Initiator Responder 168 -------------------------------------------------------------------- 169 HDR, SK {IDi, [CERT,] [CERTREQ,] 170 [IDr,] AUTH, SAi2, TSi, TSr, 171 N(MINIMAL_REKEY_SUPPORTED)} --> 172 <-- HDR, SK {IDr, [CERT,] AUTH, 173 SAr2, TSi, TSr, 174 N(MINIMAL_REKEY_SUPPORTED)} 176 If the responder doesn't support this extension, it MUST ignore the 177 MINIMAL_REKEY_SUPPORTED notification sent by the initiator and MUST 178 NOT respond error to the initiator. With no MINIMAL_REKEY_SUPPORTED 179 notification in the response message, the initiator can deduce that 180 the responder doesn't support this extension. In this case, the IKE 181 SAs and Child SAs rekeyings happen as the usual way without the 182 optimizations defined in this document. 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(MINIMAL_REKEY_SUPPORTED)} --> 191 <-- HDR, SK {IDr, [CERT,] AUTH, 192 SAr2, TSi, TSr} 194 3.2. Payload Optimization at Rekeying IKE SAs 196 The payload optimization at rekeying IKE SAs MUST NOT be used unless 197 both peers have indicated their support of this extension by using 198 the negotiation method described in Section 3.1. If the initiator 199 decides to optimize the payloads at the time of rekeying IKE SAs, 200 then it includes the SA_UNCHANGED notification in its CREATE_CHILD_SA 201 exchange message. If the initiator decides not to do the 202 optimization, then it just sends the rekeying request message as the 203 original way, the rekeying is conducted as [RFC7296] defined. 205 3.2.1. Rekeying IKE SAs When No Change of Initiator and Responder's 206 Cryptographic Suites 208 At the time of rekeying an IKE SA, when the initiator determines 209 there is no change on its cryptographic suites since this IKE SA was 210 created or last rekeyed, it MAY send the SA_UNCHANGED notification 211 payload instead of the SA payloads in the rekeying request message. 212 In this SA_UNCHANGED notification, it contains the initiator's new 213 Security Parameter Index (SPI) used for creating the new IKE SA. 215 After receiving the initiator's rekeying request message with the 216 SA_UNCHANGED notification and no SA payloads, the responder knows 217 that the initiator wants to optimize the rekeying payload. Then when 218 it determines that there is also no change in its cryptographic 219 suites, the responder MAY send the rekeying respond message to the 220 initiator with the SA_UNCHANGED notification payload instead of the 221 SA payloads. In this SA_UNCHANGED notification, it contains the 222 responder's new SPI used for creating the new IKE SA. 224 According to the initiator's new SPI and the responder's new SPI, the 225 initiator and the responder can rekey the IKE SA on both sides. 227 The CREATE_CHILD_SA message exchange in this case is shown below: 229 Initiator Responder 230 -------------------------------------------------------------------- 231 HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> 232 <-- HDR, SK {N(SA_UNCHANGED), Nr, KEr} 234 The initiator sends a SA_UNCHANGED notification payload, a Nonce 235 payload and a Diffie-Hellman value in the KEi payload. A new 236 initiator SPI is supplied in the SPI field of the SA_UNCHANGED 237 notification payload. 239 The responder replies (using the same Message ID to respond) with a 240 SA_UNCHANGED notification payload, a Nonce payload and a Diffie- 241 Hellman value in the KEr payload. A new responder SPI is supplied in 242 the SPI field of the SA_UNCHANGED notification payload. 244 This SA_UNCHANGED notification MUST be included in a CREATE_CHILD_SA 245 exchange message when there is no SA payloads included. When the 246 SA_UNCHANGED notification payload is included, the SA payload MUST 247 NOT be included. 249 3.2.2. Rekeying IKE SAs When Responder's Cryptographic Suites Changed 251 At the time of or before rekeying IKE SAs, the responder's 252 cryptographic suites may be changed while there is no change of 253 initiator's cryptographic suites. New cryptographic suites may be 254 added to the responder, or some outdated cryptographic suites may be 255 deleted from the responder. In this situation, the initiator MAY 256 send the SA_UNCHANGED notification payload instead of the SA payloads 257 in the CREATE_CHILD_SA request message at the time of rekeying IKE 258 SAs. 260 If the responder decides to continue using the previously negotiated 261 cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED 262 notification payload in the CREATE_CHILD_SA response message, then 263 the rekeying is conducted like the way described in Section 3.2.1. 265 If the responder decides to re-negotiate the cryptographic suite, it 266 MUST send NO_PROPOSAL_CHOSEN notification payload in the 267 CREATE_CHILD_SA response message. After receiving this error 268 notification, the initiator MUST retry the CREATE_CHILD_SA exchange 269 with the SA payloads. Then the rekeying is conducted in the original 270 way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in 271 this case is shown below: 273 Initiator Responder 274 -------------------------------------------------------------------- 275 HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> 276 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), 277 Nr, KEr} 278 HDR, SK {SA, Ni, KEi} --> 279 <-- HDR, SK {SA, Ni, KEi} 281 Besides, if the responder only supports the Child SA rekeying 282 optimization and doesn't support the IKE SA rekeying optimization, it 283 can also follow the way described above, i.e., it MUST send 284 NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA 285 response message when receiving the SA_UNCHANGED notification at the 286 time of rekeying IKE SAs. 288 3.3. Payload Optimization at Rekeying Child SAs 290 The payload optimization at rekeying Child SAs MUST NOT be used 291 unless both peers have indicated their support of this extension by 292 using the negotiation method described in Section 3.1. If the 293 initiator decides to optimize the payloads at the time of rekeying 294 Child SAs, then it includes the SA_TS_UNCHANGED notification in its 295 CREATE_CHILD_SA exchange message. If the initiator decides not to do 296 the optimization, then it just sends the rekeying request message as 297 the original way, the rekeying is conducted as [RFC7296] defined. 299 This SA_TS_UNCHANGED notification MUST be included in a 300 CREATE_CHILD_SA exchange message when there is no SA and TS payloads 301 included. The new Child SA is created with the SPI value in the 302 SA_TS_UNCHANGED notification. 304 3.3.1. Rekeying Child SAs When No Change of Initiator and Responder's 305 Cryptographic Suites and ACL Configuration 307 At the time of rekeying Child SAs, the initiator MAY send the 308 SA_TS_UNCHANGED notification payload instead of the SA and TS 309 payloads when there is no change in its cryptographic suites and ACL 310 configuration since last negotiation. After receiving the 311 initiator's request message with the SA_TS_UNCHANGED notification, 312 the responder MAY respond to the initiator with the SA_TS_UNCHANGED 313 notification payload instead of the SA and TS payloads if there is 314 also no change in its cryptographic suites and ACL configuration 315 since last negotiation. 317 At the time of rekeying a Child SA, when the initiator determines 318 there is no change in its cryptographic suites and ACL configuration 319 since this Child SA was created or last rekeyed, it MAY send the 320 SA_TS_UNCHANGED notification payload instead of the SA and TS 321 payloads in the rekeying request message. In this SA_TS_UNCHANGED 322 notification, it contains the initiator's new Security Parameter 323 Index (SPI) used for creating the new Child SA. 325 After receiving the initiator's rekeying request message with the 326 SA_TS_UNCHANGED notification and no SA and TS payloads, the responder 327 knows that the initiator wants to optimize the rekeying payload. 328 Then when it determines that there is also no change in its 329 cryptographic suites and ACL configuration, the responder MAY send 330 the rekeying respond message to the initiator with the 331 SA_TS_UNCHANGED notification payload instead of the SA and TS 332 payloads. In this SA_TS_UNCHANGED notification, it contains the 333 responder's new SPI used for creating the new Child SA. 335 According to the initiator's new SPI and the responder's new SPI, the 336 initiator and the responder can rekey the Child SA on both sides. 338 The CREATE_CHILD_SA message exchange in this case is shown below: 340 Initiator Responder 341 -------------------------------------------------------------------- 342 HDR, SK {N(REKEY_SA), N(SA_TS_UNCHANGED), 343 Ni, [KEi,]} --> 344 <-- HDR, SK {N(SA_TS_UNCHANGED), 345 Nr, [KEr,]} 347 This SA_TS_UNCHANGED notification MUST be included in a 348 CREATE_CHILD_SA exchange message when there is no SA and TS payloads 349 included at the time of rekeying Child SAs. When the SA_TS_UNCHANGED 350 notification payload is included, the SA and TS payloads MUST NOT be 351 included. 353 3.3.2. Rekeying Child SAs When Responder's Cryptographic Suites or ACL 354 Configuration Changed 356 At the time of or before rekeying Child SAs, the responder's 357 cryptographic suites or ACL configuration may be changed while there 358 is no change of initiator's cryptographic suites and ACL 359 configuration. In this situation, the initiator MAY send the 360 SA_TS_UNCHANGED notification payload instead of the SA and TS 361 payloads in the CREATE_CHILD_SA request message at the time of 362 rekeying Child SAs. 364 If the responder decides to continue using the previously negotiated 365 cryptographic suite and Traffic Selectors to rekey the Child SA, it 366 MAY send the SA_TS_UNCHANGED notification payload in the 367 CREATE_CHILD_SA response message, then the rekeying is conducted like 368 Section 3.3.1. 370 If the responder decides to re-negotiate the cryptographic suite or 371 Traffic Selectors, it MUST send NO_PROPOSAL_CHOSEN notification 372 payload in the CREATE_CHILD_SA response message. After receiving 373 this error notification, the initiator MUST retry the CREATE_CHILD_SA 374 exchange with the SA and TS payloads. Then the rekeying is conducted 375 in the original way defined in [RFC7296]. The CREATE_CHILD_SA 376 message exchange in this case is shown below: 378 Initiator Responder 379 -------------------------------------------------------------------- 380 HDR, SK {N(SA_TS_UNCHANGED), Ni, KEi} --> 381 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), 382 Nr, KEr} 383 HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] 384 TSi, TSr} --> 385 <-- HDR, SK {SA, Nr, [KEr,] 386 TSi, TSr} 388 Besides, if the responder only supports the IKE SA rekeying 389 optimization and doesn't support the Child SA rekeying optimization, 390 it can also follow the way described above, i.e., it MUST send 391 NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA 392 response message when receiving the SA_TS_UNCHANGED notification at 393 the time of rekeying Child SAs. 395 4. Payload Formats 397 4.1. MINIMAL_REKEY_SUPPORTED Notification 399 The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and 400 responder to inform their ability of optimizing optional payload at 401 the time of rekeying IKE SAs and Child SAs to the peers. It is 402 formatted as follows: 404 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Next Payload |C| RESERVED | Payload Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 o Protocol ID (1 octet) - MUST be 0. 414 o SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 416 o Notify Message Type (2 octets) - MUST be , the value assigned for the MINIMAL_REKEY_SUPPORTED 418 notification. 420 This notification contains no data. 422 4.2. SA_UNCHANGED Notification 424 The SA_UNCHANGED notification is used to replace the SA payloads at 425 the time of rekeying IKE SAs when there is no change of cryptographic 426 suites in initiator or responder. It is formatted as follows: 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Next Payload |C| RESERVED | Payload Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 |Protocol ID | SPI Size (=8) | Notify Message Type | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Security Parameter Index (SPI) | 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 o Protocol ID (1 octet) - MUST be 1. 441 o SPI Size (1 octet) - MUST be 8. 443 o Notify Message Type (2 octets) - MUST be , the value assigned for the SA_UNCHANGED notification. 446 o SPI (8 octets) - Security Parameter Index. The initiator sends 447 initiator SPI. The responder sends responder SPI. 449 4.3. SA_TS_UNCHANGED Notification 451 The SA_TS_UNCHANGED notification is used to replace the SA payloads 452 and TS payloads at the time of rekeying Child SAs when there is no 453 change of cryptographic suites and ACL configuration in initiator or 454 responder. It is formatted as follows: 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Next Payload |C| RESERVED | Payload Length | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 |Protocol ID | SPI Size (=4) | Notify Message Type | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Security Parameter Index (SPI) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 o Protocol ID (1 octet) - MUST be either (2) to indicate AH or (3) 467 to indicate ESP. 469 o SPI Size (1 octet) - MUST be 4. 471 o Notify Message Type (2 octets) - MUST be , the value assigned for the SA_TS_UNCHANGED notification. 474 o SPI (4 octets) - Security Parameter Index. The initiator sends 475 initiator SPI. The responder sends responder SPI. 477 5. IANA Considerations 479 This document defines two new Notify Message Types in the "IKEv2 480 Notify Message Types - Status Types" registry. IANA is requested to 481 assign codepoints in this registry. 483 NOTIFY messages: status types Value 484 ---------------------------------------------------------- 485 MINIMAL_REKEY_SUPPORTED TBD 486 SA_UNCHANGED TBD 487 SA_TS_UNCHANGED TBD 489 6. Security Considerations 491 TBD 493 7. References 495 7.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 503 Kivinen, "Internet Key Exchange Protocol Version 2 504 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 505 2014, . 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 509 May 2017, . 511 7.2. Informative References 513 [I-D.mglt-6lo-diet-esp-requirements] 514 Migault, D., Guggemos, T., and C. Bormann, "Requirements 515 for Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt- 516 6lo-diet-esp-requirements-02 (work in progress), July 517 2016. 519 Authors' Addresses 521 Sandeep Kampati 522 Huawei Technologies 523 Divyashree Techno Park, Whitefield 524 Bangalore, Karnataka 560066 525 India 527 Email: sandeepkampati@huawei.com 529 Meduri S S Bharath 530 Huawei Technologies 531 Divyashree Techno Park, Whitefield 532 Bangalore, Karnataka 560066 533 India 535 Email: MeduriS.Bharath@huawei.com 537 Wei Pan 538 Huawei Technologies 539 101 Software Avenue, Yuhuatai District 540 Nanjing, Jiangsu 541 China 543 Email: william.panwei@huawei.com