idnits 2.17.00 (12 Aug 2021) /tmp/idnits57613/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.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 (April 20, 2021) is 396 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: October 22, 2021 M. Bharath 6 Mavenir 7 M. Chen 8 CMCC 9 April 20, 2021 11 IKEv2 Optional SA&TS Payloads in Child Exchange 12 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04 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 October 22, 2021. 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 Optional Payload at 62 Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4 63 3.2. Payload Optimization at Rekeying IKE SAs . . . . . . . . 5 64 3.2.1. Rekeying IKE SAs When No Change of Initiator and 65 Responder's Cryptographic Suites . . . . . . . . . . 5 66 3.2.2. Rekeying IKE SAs When Responder's Cryptographic 67 Suites Changed . . . . . . . . . . . . . . . . . . . 6 68 3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 7 69 3.3.1. Rekeying Child SAs When No Change of Initiator and 70 Responder's Cryptographic Suites and ACL 71 Configuration . . . . . . . . . . . . . . . . . . . . 7 72 3.3.2. Rekeying Child SAs When Responder's Cryptographic 73 Suites or ACL Configuration Changed . . . . . . . . . 8 74 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 9 76 4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 10 77 4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 10 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 7.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The Internet Key Exchange protocol version 2 (IKEv2) specified in 88 [RFC7296] is used in the IP Security (IPsec) architecture for the 89 purposes of Security Association (SA) parameters negotiation and 90 authenticated key exchange. The protocol uses UDP as the transport 91 for its messages, which size varies from less than one hundred bytes 92 to several kilobytes. 94 According to [RFC7296], the secret keys used by IKE/IPSec SAs should 95 be used only for a limited amount of time and to protect a limited 96 amount of data. When the lifetime of an SA expires or is about to 97 expire, the peers can rekey the SA to reestablish a new SA to take 98 the place of the old one. 100 For security gateways/ePDG in 4G networks and cRAN/Cloud in 5G 101 networks, they will support more than 100,000 IKE/IPSEC tunnels. So 102 on an average, for every second there may be hundreds or thousands of 103 IKE SAs and Child SAs that are rekeying. This takes huge amount of 104 bandwidth, packet fragmentation and more processing resources. For 105 these devices, these problems can be solved by introducing the 106 solution described in this document. 108 This is also useful in Internet of Things (IoT) devices which 109 utilizing lower power consumption technology. The appendix A of 110 [I-D.mglt-6lo-diet-esp-requirements] gives some estimate data. For 111 these devices, reducing the length of IKE/Child SA rekeying messages 112 can save the bandwidth consumption. At the same time, it can also 113 save the computing processes by less payload are included. 115 Most devices don't prefer to change cryptographic suites frequently. 116 By taking this advantage the SA and TS payloads can be made optional 117 at the time of rekeying IKE SAs and Child SAs. In such situation, 118 only a new SPI value is needed to create the new IKE SA and Child SA. 119 So a new Notify payload which contains the needed SPI value can be 120 sent instead of the SA and TS payloads. 122 In case of rekeying IKE SAs, the SA payloads can be optimized if 123 there is no change of cryptographic suites. In case of rekeying 124 Child SAs, the SA and TS payloads can be optimized if there is no 125 change of cryptographic suites and ACL configuration. 127 2. Conventions Used in This Document 129 2.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 3. Protocol Details 139 This section provides protocol details and contains the normative 140 parts. 142 Before using this new optimization, the IPSec implementation who 143 supports it has to know that the peer also supports it. Without the 144 support on both sides, the optimized rekeying messages sent by one 145 peer may be unrecognizable for the other peer. To prevent this 146 failure from happening, the first step is to negotiate the support of 147 this optimization between the two peers. There are two specific 148 rekeying SAs cases: rekeying IKE SAs and rekeying Child SAs. After 149 the negotiation, the initiator can optimize the rekeying message 150 payloads in both cases. In other words, once the negotiation of 151 support for optimizing payloads at rekeying IKE SAs and Child SAs is 152 complete, both IKE SAs and Child SAs rekeying are supported by the 153 two sides. The responder can react based on the received rekeying 154 message. 156 3.1. Negotiation of Support for Optimizing Optional Payload at Rekeying 157 IKE SAs and Child SAs 159 The initiator indicates its support for optimizing optional payloads 160 at rekeying IKE SAs and Child SAs by including a Notify payload of 161 type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By 162 observing the MINIMAL_REKEY_SUPPORTED notification in the received 163 message, the responder can deduce the initiator's support of this 164 extension. If the responder also supports this extension, it 165 includes the MINIMAL_REKEY_SUPPORTED notification in the 166 corresponding response message. After receiving the response 167 message, the initiator can also know the support of this extension of 168 the responder side. 170 The IKE_AUTH message exchange in this case is shown below: 172 Initiator Responder 173 -------------------------------------------------------------------- 174 HDR, SK {IDi, [CERT,] [CERTREQ,] 175 [IDr,] AUTH, SAi2, TSi, TSr, 176 N(MINIMAL_REKEY_SUPPORTED)} --> 177 <-- HDR, SK {IDr, [CERT,] AUTH, 178 SAr2, TSi, TSr, 179 N(MINIMAL_REKEY_SUPPORTED)} 181 If the responder doesn't support this extension, it MUST ignore the 182 MINIMAL_REKEY_SUPPORTED notification sent by the initiator and MUST 183 NOT respond error to the initiator. With no MINIMAL_REKEY_SUPPORTED 184 notification in the response message, the initiator can deduce that 185 the responder doesn't support this extension. In this case, the IKE 186 SAs and Child SAs rekeyings happen as the usual way without the 187 optimizations defined in this document. 189 The IKE_AUTH message exchange in this case is shown below: 191 Initiator Responder 192 -------------------------------------------------------------------- 193 HDR, SK {IDi, [CERT,] [CERTREQ,] 194 [IDr,] AUTH, SAi2, TSi, TSr, 195 N(MINIMAL_REKEY_SUPPORTED)} --> 196 <-- HDR, SK {IDr, [CERT,] AUTH, 197 SAr2, TSi, TSr} 199 3.2. Payload Optimization at Rekeying IKE SAs 201 The payload optimization at rekeying IKE SAs MUST NOT be used unless 202 both peers have indicated their support of this extension by using 203 the negotiation method described in Section 3.1. If the initiator 204 decides to optimize the payloads at the time of rekeying IKE SAs, 205 then it includes the SA_UNCHANGED notification in its CREATE_CHILD_SA 206 exchange message. If the initiator decides not to do the 207 optimization, then it just sends the rekeying request message as the 208 original way, the rekeying is conducted as [RFC7296] defined. If the 209 initiator and responder decides to do the optimization, then the IKE 210 SA rekeying uses PFS by default. 212 3.2.1. Rekeying IKE SAs When No Change of Initiator and Responder's 213 Cryptographic Suites 215 At the time of rekeying an IKE SA, when the initiator determines 216 there is no change on its cryptographic suites since this IKE SA was 217 created or last rekeyed, it MAY send the SA_UNCHANGED notification 218 payload instead of the SA payloads in the rekeying request message. 219 In this SA_UNCHANGED notification, it contains the initiator's new 220 Security Parameter Index (SPI) used for creating the new IKE SA. 222 After receiving the initiator's rekeying request message with the 223 SA_UNCHANGED notification and no SA payloads, the responder knows 224 that the initiator wants to optimize the rekeying payload. Then when 225 it determines that there is also no change in its cryptographic 226 suites, the responder MAY send the rekeying respond message to the 227 initiator with the SA_UNCHANGED notification payload instead of the 228 SA payloads. In this SA_UNCHANGED notification, it contains the 229 responder's new SPI used for creating the new IKE SA. 231 According to the initiator's new SPI and the responder's new SPI, the 232 initiator and the responder can rekey the IKE SA on both sides. 234 The CREATE_CHILD_SA message exchange in this case is shown below: 236 Initiator Responder 237 -------------------------------------------------------------------- 238 HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> 239 <-- HDR, SK {N(SA_UNCHANGED), Nr, KEr} 241 The initiator sends a SA_UNCHANGED notification payload, a Nonce 242 payload and a Diffie-Hellman value in the KEi payload. A new 243 initiator SPI is supplied in the SPI field of the SA_UNCHANGED 244 notification payload. These messages also follow the original PFS 245 with the signature and encryption algorithms used as last message. 247 The responder replies (using the same Message ID to respond) with a 248 SA_UNCHANGED notification payload, a Nonce payload and a Diffie- 249 Hellman value in the KEr payload. A new responder SPI is supplied in 250 the SPI field of the SA_UNCHANGED notification payload. 252 This SA_UNCHANGED notification MUST be included in a CREATE_CHILD_SA 253 exchange message when there is no SA payloads included. When the 254 SA_UNCHANGED notification payload is included, the SA payload MUST 255 NOT be included. 257 3.2.2. Rekeying IKE SAs When Responder's Cryptographic Suites Changed 259 At the time of or before rekeying IKE SAs, the responder's 260 cryptographic suites may be changed while there is no change of 261 initiator's cryptographic suites. New cryptographic suites may be 262 added to the responder, or some outdated cryptographic suites may be 263 deleted from the responder. In this situation, the initiator MAY 264 send the SA_UNCHANGED notification payload instead of the SA payloads 265 in the CREATE_CHILD_SA request message at the time of rekeying IKE 266 SAs. 268 If the responder decides to continue using the previously negotiated 269 cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED 270 notification payload in the CREATE_CHILD_SA response message, then 271 the rekeying is conducted like the way described in Section 3.2.1. 273 If the responder decides to re-negotiate the cryptographic suite, it 274 MUST send NO_PROPOSAL_CHOSEN notification payload in the 275 CREATE_CHILD_SA response message. After receiving this error 276 notification, the initiator MUST retry the CREATE_CHILD_SA exchange 277 with the SA payloads. Then the rekeying is conducted in the original 278 way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in 279 this case is shown below: 281 Initiator Responder 282 -------------------------------------------------------------------- 283 HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> 284 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), 285 Nr, KEr} 286 HDR, SK {SA, Ni, KEi} --> 287 <-- HDR, SK {SA, Ni, KEi} 289 Besides, if the responder only supports the Child SA rekeying 290 optimization and doesn't support the IKE SA rekeying optimization, it 291 can also follow the way described above, i.e., it MUST send 292 NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA 293 response message when receiving the SA_UNCHANGED notification at the 294 time of rekeying IKE SAs. 296 3.3. Payload Optimization at Rekeying Child SAs 298 The payload optimization at rekeying Child SAs MUST NOT be used 299 unless both peers have indicated their support of this extension by 300 using the negotiation method described in Section 3.1. If the 301 initiator decides to optimize the payloads at the time of rekeying 302 Child SAs, then it includes the SA_TS_UNCHANGED notification in its 303 CREATE_CHILD_SA exchange message. If the initiator decides not to do 304 the optimization, then it just sends the rekeying request message as 305 the original way, the rekeying is conducted as [RFC7296] defined. 307 This SA_TS_UNCHANGED notification MUST be included in a 308 CREATE_CHILD_SA exchange message when there is no SA and TS payloads 309 included. The new Child SA is created with the SPI value in the 310 SA_TS_UNCHANGED notification. 312 3.3.1. Rekeying Child SAs When No Change of Initiator and Responder's 313 Cryptographic Suites and ACL Configuration 315 At the time of rekeying Child SAs, the initiator MAY send the 316 SA_TS_UNCHANGED notification payload instead of the SA and TS 317 payloads when there is no change in its cryptographic suites and ACL 318 configuration since last negotiation. After receiving the 319 initiator's request message with the SA_TS_UNCHANGED notification, 320 the responder MAY respond to the initiator with the SA_TS_UNCHANGED 321 notification payload instead of the SA and TS payloads if there is 322 also no change in its cryptographic suites and ACL configuration 323 since last negotiation. 325 At the time of rekeying a Child SA, when the initiator determines 326 there is no change in its cryptographic suites and ACL configuration 327 since this Child SA was created or last rekeyed, it MAY send the 328 SA_TS_UNCHANGED notification payload instead of the SA and TS 329 payloads in the rekeying request message. In this SA_TS_UNCHANGED 330 notification, it contains the initiator's new Security Parameter 331 Index (SPI) used for creating the new Child SA. 333 After receiving the initiator's rekeying request message with the 334 SA_TS_UNCHANGED notification and no SA and TS payloads, the responder 335 knows that the initiator wants to optimize the rekeying payload. 336 Then when it determines that there is also no change in its 337 cryptographic suites and ACL configuration, the responder MAY send 338 the rekeying respond message to the initiator with the 339 SA_TS_UNCHANGED notification payload instead of the SA and TS 340 payloads. In this SA_TS_UNCHANGED notification, it contains the 341 responder's new SPI used for creating the new Child SA. 343 According to the initiator's new SPI and the responder's new SPI, the 344 initiator and the responder can rekey the Child SA on both sides. 346 The CREATE_CHILD_SA message exchange in this case is shown below: 348 Initiator Responder 349 -------------------------------------------------------------------- 350 HDR, SK {N(REKEY_SA), N(SA_TS_UNCHANGED), 351 Ni, [KEi,]} --> 352 <-- HDR, SK {N(SA_TS_UNCHANGED), 353 Nr, [KEr,]} 355 This SA_TS_UNCHANGED notification MUST be included in a 356 CREATE_CHILD_SA exchange message when there is no SA and TS payloads 357 included at the time of rekeying Child SAs. When the SA_TS_UNCHANGED 358 notification payload is included, the SA and TS payloads MUST NOT be 359 included. 361 3.3.2. Rekeying Child SAs When Responder's Cryptographic Suites or ACL 362 Configuration Changed 364 At the time of or before rekeying Child SAs, the responder's 365 cryptographic suites or ACL configuration may be changed while there 366 is no change of initiator's cryptographic suites and ACL 367 configuration. In this situation, the initiator MAY send the 368 SA_TS_UNCHANGED notification payload instead of the SA and TS 369 payloads in the CREATE_CHILD_SA request message at the time of 370 rekeying Child SAs. 372 If the responder decides to continue using the previously negotiated 373 cryptographic suite and Traffic Selectors to rekey the Child SA, it 374 MAY send the SA_TS_UNCHANGED notification payload in the 375 CREATE_CHILD_SA response message, then the rekeying is conducted like 376 Section 3.3.1. 378 If the responder decides to re-negotiate the cryptographic suite or 379 Traffic Selectors, it MUST send NO_PROPOSAL_CHOSEN notification 380 payload in the CREATE_CHILD_SA response message. After receiving 381 this error notification, the initiator MUST retry the CREATE_CHILD_SA 382 exchange with the SA and TS payloads. Then the rekeying is conducted 383 in the original way defined in [RFC7296]. The CREATE_CHILD_SA 384 message exchange in this case is shown below: 386 Initiator Responder 387 -------------------------------------------------------------------- 388 HDR, SK {N(SA_TS_UNCHANGED), Ni, KEi} --> 389 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), 390 Nr, KEr} 391 HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] 392 TSi, TSr} --> 393 <-- HDR, SK {SA, Nr, [KEr,] 394 TSi, TSr} 396 Besides, if the responder only supports the IKE SA rekeying 397 optimization and doesn't support the Child SA rekeying optimization, 398 it can also follow the way described above, i.e., it MUST send 399 NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA 400 response message when receiving the SA_TS_UNCHANGED notification at 401 the time of rekeying Child SAs. 403 4. Payload Formats 405 4.1. MINIMAL_REKEY_SUPPORTED Notification 407 The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and 408 responder to inform their ability of optimizing optional payload at 409 the time of rekeying IKE SAs and Child SAs to the peers. It is 410 formatted as follows: 412 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Next Payload |C| RESERVED | Payload Length | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 o Protocol ID (1 octet) - MUST be 0. 422 o SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 424 o Notify Message Type (2 octets) - MUST be , the value assigned for the MINIMAL_REKEY_SUPPORTED 426 notification. 428 This notification contains no data. 430 4.2. SA_UNCHANGED Notification 432 The SA_UNCHANGED notification is used to replace the SA payloads at 433 the time of rekeying IKE SAs when there is no change of cryptographic 434 suites in initiator or responder. It is formatted as follows: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Next Payload |C| RESERVED | Payload Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |Protocol ID | SPI Size (=8) | Notify Message Type | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Security Parameter Index (SPI) | 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 o Protocol ID (1 octet) - MUST be 1. 449 o SPI Size (1 octet) - MUST be 8. 451 o Notify Message Type (2 octets) - MUST be , the value assigned for the SA_UNCHANGED notification. 454 o SPI (8 octets) - Security Parameter Index. The initiator sends 455 initiator SPI. The responder sends responder SPI. 457 4.3. SA_TS_UNCHANGED Notification 459 The SA_TS_UNCHANGED notification is used to replace the SA payloads 460 and TS payloads at the time of rekeying Child SAs when there is no 461 change of cryptographic suites and ACL configuration in initiator or 462 responder. The SPI of the new Child SA is included in this payload, 463 and the SPI of the old Child SA is in the REKEY_SA notification 464 payload. The SA_TS_UNCHANGED notification is formatted as follows: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Next Payload |C| RESERVED | Payload Length | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 |Protocol ID | SPI Size (=4) | Notify Message Type | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Security Parameter Index (SPI) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 o Protocol ID (1 octet) - MUST be either (2) to indicate AH or (3) 477 to indicate ESP. 479 o SPI Size (1 octet) - MUST be 4. 481 o Notify Message Type (2 octets) - MUST be , the value assigned for the SA_TS_UNCHANGED notification. 484 o SPI (4 octets) - Security Parameter Index. The initiator sends 485 initiator SPI. The responder sends responder SPI. 487 5. IANA Considerations 489 This document defines two new Notify Message Types in the "IKEv2 490 Notify Message Types - Status Types" registry. IANA is requested to 491 assign codepoints in this registry. 493 NOTIFY messages: status types Value 494 ---------------------------------------------------------- 495 MINIMAL_REKEY_SUPPORTED TBD 496 SA_UNCHANGED TBD 497 SA_TS_UNCHANGED TBD 499 6. Security Considerations 501 TBD 503 7. References 505 7.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 513 Kivinen, "Internet Key Exchange Protocol Version 2 514 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 515 2014, . 517 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 518 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 519 May 2017, . 521 7.2. Informative References 523 [I-D.mglt-6lo-diet-esp-requirements] 524 Migault, D., Guggemos, T., and C. Bormann, "Requirements 525 for Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt- 526 6lo-diet-esp-requirements-02 (work in progress), July 527 2016. 529 Authors' Addresses 531 Sandeep Kampati 532 Huawei Technologies 533 Divyashree Techno Park, Whitefield 534 Bangalore, Karnataka 560066 535 India 537 Email: sandeepkampati@huawei.com 539 Wei Pan 540 Huawei Technologies 541 101 Software Avenue, Yuhuatai District 542 Nanjing, Jiangsu 543 China 545 Email: william.panwei@huawei.com 547 Meduri S S Bharath 548 Mavenir Systems Pvt Ltd 549 Manyata Tech Park 550 Bangalore, Karnataka 551 India 553 Email: bharath.meduri@mavenir.com 554 Meiling Chen 555 China Mobile 556 32 Xuanwumen West Street, West District 557 Beijing, Beijing 100053 559 Email: chenmeiling@chinamobile.com