idnits 2.17.1 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.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 (Feb 18, 2019) is 1894 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 S. Kampati 3 Internet-Draft Huawei 4 Intended status: Standards Track Feb 18, 2019 5 Expires: Aug 22, 2019 7 IKEv2 Optional SA&TS Payloads in Child Exchange 8 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00 10 Abstract 12 This document describes a method for reduce the size of the Internet 13 Key Exchange version 2 (IKEv2) exchanges at time of IKE rekey and 14 Child SA Rekey by removing or making optional of SA & TS payloads. 15 Reducing size of IKEv2 exchange is desirable for low power 16 consumption battery powered devices. It also helps to avoid IP 17 fragmentation of IKEv2 messages. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on Aug 22, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2 Rekeying IKE SAs with the CREATE_CHILD_SA . . . . . . . . . 4 59 3.2.1 Exchange with out SA payload . . . . . . . . . . . . . 4 60 3.2.2 Exchange with optional SA payload . . . . . . . . . . 5 61 3.2.3 Exchange when there is change in responder . . . . . . 6 62 3.3 Exchange without SA and TS payload . . . . . . . . . . . . . 7 63 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 4.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The Internet Key Exchange protocol version 2 (IKEv2) specified in 73 [RFC7296] is used in the IP Security (IPsec) architecture for the 74 purposes of Security Association (SA) parameters negotiation and 75 authenticated key exchange. The protocol uses UDP as the transport 76 for its messages, which size varies from less than one hundred bytes 77 to several kBytes. 79 In 4G network security gateways/ePDG and in 5G networks cRAN/Cloud 80 will support more than one 100000 IKE/IPSEC tunnels. So on an 81 average, for every second we encounter many rekeys. This takes huge 82 amount of bandwidth, packet fragmentation and more processing. This 83 can be solved by introducing this solution. 85 This is useful in Internet of Things (IoT) devices which utilizing 86 lower power consumption technology. The appendix A of [IPSEC-IOT- 87 REQS] gives some estimate data. 89 Most of devices they don't preferred to change suits frequently. 90 Taking this advantage we can make SA and TS as optional payloads at 91 time of IKE SA rekey and IPSEC SA rekey. 93 In ESP transport mode if when protocol ID and port numbers are any to 94 any than no need to send TS payloads. 96 In case of Rekeying IKE SAs with the CREATE_CHILD_SA Exchange Minimum 97 size of (single set of cryptographic suite)SA payload 52 bytes, we 98 can replace these payloads with Notify payload N(NEW_SPI) to get SPI 99 which of Size is 16 bytes. So we are have reduced 36 bytes. 101 In case of Rekeying Child SAs with the CREATE_CHILD_SA Exchange 102 Minimum size of SA payload 40 bytes, each TS size 24 bytes (2*24 = 48 103 bytes). total Size 88 bytes. we can replace these payloads with 104 Notify payload N(NEW_SPI) to get SPI which of Size is 12 bytes, So 105 total reduced size is 76 bytes. 107 2. Conventions Used in This Document 109 2.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. Protocol Details 119 This section provides protocol details and contains the normative 120 parts. 122 3.1 Negotiation 124 The initiator indicates its support for IKE optional payloads at 125 rekey and willingness to use it by including a Notification payload 126 of type IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in the IKE_SA_INIT 127 request message. If the responder also supports this extension and 128 is willing to use it, it includes this notification in the response 129 message. 131 Initiator Responder 132 ----------------------------------------------------------------- 133 HDR(A,0), SAi1, KEi, Ni, --> 134 N(IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED) 136 <-- HDR, SAr1, KEr, Nr, [CERTREQ,] 137 N(IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED) 139 The Notify payload is formatted as follows: 141 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Next Payload |C| RESERVED | Payload Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 o Protocol ID (1 octet) - MUST be zero. 151 o SPI Size (1 octet) - MUST be zero, meaning no Security Parameter 152 Index (SPI) is present. 154 o Notify Message Type (2 octets) - MUST be , the value assigned for the 156 IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED notification. 158 3.2 Rekeying IKE SAs with the CREATE_CHILD_SA 160 IKE REKEY optional SA payloads support MUST NOT be used unless both 161 peers have indicated their support for it. The NEW_SPI notification 162 MUST be included in a CREATE_CHILD_SA exchange when there is no SA 163 payload, The New IKE SA is created with the SPI values in the NEW_SPI 164 Notify payload. 166 3.2.1 Exchange with out SA payload 168 At time of IKE rekey initiator sends NEW_SPI notification payload 169 instead SA payload when there is no change in initial negotiated 170 cryptographic suite. Responder sends NEW_SPI notification payload 171 instead SA payload when there is no change in initial negotiated 172 cryptographic suite. 174 An IKEv2 message exchange with this modification is shown below: 176 Initiator Responder 177 ---------------------------------------------------------------- 178 HDR, SK {N(NEW_SPI), Ni} --> 180 Initiator sends NEW_SPI notification payload, Nonce payload and a 181 Diffie-Hellman value in the KEi payload. 183 A new initiator SPI is supplied in the SPI field of the NEW_SPI 184 notification payload. 186 The CREATE_CHILD_SA response for creating a new Child SA is: 188 <-- HDR, SK {N(NEW_SPI), Nr} 190 The responder replies (using the same Message ID to respond) with the 191 NEW_SPI notification payload, Nonce payload and a Diffie-Hellman 192 value in the KEr payload 194 A new responder SPI is supplied in the SPI field of the SA payload. 196 NEW_SPI notification payload is included, MUST NOT include NEW_SPI 197 notification payload. 199 The Notify payload is formatted as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Next Payload |C| RESERVED | Payload Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |Protocol ID(=1)| SPI Size (=8) | Notify Message Type | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 ~ Security Parameter Index (SPI) ~ 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 o Protocol ID (1 octet) - MUST be 1. 215 o SPI Size (1 octet) - this field MUST be 8. 217 o Notify Message Type (2 octets) - MUST be , the value assigned for the NEW_SPI notification. 220 o SPI - IKE SPI (4 octets), initiator will send initiator IKE 221 SPI. Responder will send responder IKE SPI 223 3.2.2 Exchange with optional SA payload 224 Initiator side new cryptographic suites are added after initial SA 225 creation, So at time of CREATE_CHILD_SA initiator sends SA payload 226 when multiple cryptographic suite, but responder selected previous 227 suits at time of CREATE_CHILD_SA Exchange, so responder MAY send 228 NEW_SPI notification payload instead of SA payload. so initiator need 229 to use old IKE SA negotiated cryptographic suits to new IKE SA. 231 Initiator Responder 232 -------------------------------------------------------------------- 233 HDR, SK {SA, Ni, KEi} --> 235 <-- HDR, SK {N(NEW_SPI), Nr} 237 3.2.3 Exchange when there is change in responder 239 At time of IKE rekey initiator sends NEW_SPI notification payload 240 instead SA payload when there is no change in initial negotiated 241 cryptographic suite. Responder side there is change in cryptographic 242 suite so responder send NO_PROPOSAL_CHOSEN notification payload to 243 initiator. 245 Initiator need to send new rekey request with SA payload. 247 Initiator Responder 248 -------------------------------------------------------------------- 249 HDR, SK {N(NEW_SPI), Ni, KEi} --> 251 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), Nr, KEr} 253 HDR, SK {SA, Ni, KEi} --> 255 <-- HDR, SK {SA, Ni, KEi} 257 3.3 Exchange without SA and TS payload 259 Child SA REKEY optional SA and TS paylaods, support MUST NOT be used 260 unless both peers have indicated their support for it. 262 The NEW_SPI notification MUST be included in a CREATE_CHILD_SA 263 exchange when there is no SA payload, The New Child SA is created 264 with the SPI values in the NEW_SPI Notify payload. 266 An Rekeying Child SAs with the CREATE_CHILD_SA Exchange exchange with 267 this modification is shown below: 269 Initiator Responder 270 ------------------------------------------------------------------ 272 HDR, SK {N(NEW_SPI), Ni, [KEi,]} --> 274 <-- HDR, SK {N(NEW_SPI), Nr, [KEr,]} 276 The Notify payload is formatted as follows: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Next Payload |C| RESERVED | Payload Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |Protocol ID | SPI Size (=4) | Notify Message Type | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 286 ~ Security Parameter Index (SPI) ~ 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 o Protocol ID (1 octet) - this field MUST contain either (2) to 291 indicate AH or (3) to indicate ESP. 293 o SPI Size (1 octet) - MUST be 4. 295 o Notify Message Type (2 octets) - MUST be , the value assigned for the NEW_SPI notification. 298 o SPI (variable length) - AH/ESP SPI (4 octets), initiator will 299 send initiator SPI. Responder will send responder SPI 301 4 Security Considerations 302 TBD 304 5 IANA Considerations 305 This document defines two new Notify Message Types in the "Notify 306 Message Types - Status Types" registry. IANA is requested to assign 307 codepoints in this registry. 309 NOTIFY messages: status types Value 310 ---------------------------------------------------------- 311 NEW_SPI TBD 312 IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED TBD 314 4. References 316 4.1. Normative References 318 [RFC2119] 319 Bradner, S., "Key words for use in RFCs to Indicate Requirement 320 Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, 321 . 323 [RFC7296] 324 Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.Kivinen, 325 "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 326 7296, DOI 10.17487/RFC7296, October 2014, . 329 [RFC8174] 330 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 331 Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 332 . 334 4.2. Informative References 336 [IPSEC-IOT-REQS] 337 Migault, D., Guggemos, T., and C. Bormann, "Requirements for 338 Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt-6lo-diet- 339 esp-requirements-02 (work in progress), July 2016. 341 Authors' Addresses 343 Sandeep Kampati 344 Huawei Technologies 345 Divyashree Techno Park, Whitefield 346 Bangalore, Karnataka 560066 347 India 349 Email: sandeepkampati@huawei.com