idnits 2.17.1 draft-mglt-ipsecme-multiple-child-sa-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 17, 2019) is 1615 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ipsecme D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Klassert 5 Expires: May 20, 2020 Secunet 6 November 17, 2019 8 Negotiation of multiple Child Security Association with the Internet Key 9 Exchange Protocol Version 2 (IKEv2) 10 draft-mglt-ipsecme-multiple-child-sa-00 12 Abstract 14 IPsec packet processing with one Security Association (SA) per core 15 is more efficient than having a SA shared by the multiple cores. 17 This document optimizes the negotiation of multiple unidirectional 18 SAs in order to minimize the impact SAs being shared by multiple 19 cores. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 20, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Payload Description . . . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Consideration . . . . . . . . . . . . . . . . . . . 6 62 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Requirements Notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 69 "OPTIONAL" in this document are to be interpreted as described BCP 14 70 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 71 as shown here. 73 2. Introduction 75 IPsec processing (on Linux) is more efficient with SA attached to a 76 given core as opposed to a SA shared by multiple cores. Suppose an 77 initiator and a responder respectively with n and p cores establish 78 an IPsec protected communication defined by Traffic Selectors (TSi, 79 TSr). IPsec processing performance may be increased if the initiator 80 (resp. the responder) processes IPsec packets via n (resp. p) 81 distinct unidirectional SAs rather than having a SA shared by the n 82 (resp p) cores. 84 Optimally the number of SAs is expected to be equal to the number of 85 cores which can be different for each peer. When peers have a 86 different number of cores, the number of SA is expected to be equal 87 to the highest number of cores to minimize context switching and the 88 minimum number of cores to optimize memory space. In fact, having 89 fewer SAs than the number of cores may result in switching the SA 90 context to unused cores. On the other hand, having a greater number 91 of SAs results in a core sharing multiple SAs for the same purpose, 92 which does not improve performances at the cost of an additional SA 93 stored in the kernel. 95 Currently Child SA are agreed with IKEv2 [RFC7296] CREATE_CHILD_SA 96 exchange. Additional Child SAs (in our case n or p) would require n 97 or p CREATE_CHILD_SA exchanges that add multiple round trips carrying 98 similar payloads (TSi, TSr, SA) which is not necessary. 100 This document describes the MULTIPLE_CHILD_SA Notify Payload used in 101 a CREATE_CHILD_SA to indicate the support of Multiple SA Extension as 102 well as to agree on the additional number negotiated SA. 104 3. Protocol Exchange 106 The support for Multiple Child SA extension as well as the number of 107 additional Child SAs is performed during the CREATE_CHILD_SA exchange 108 via the MULTIPLE_CHILD_SA Notify Payload. 110 The initiator indicates in a single MULTIPLE_CHILD_SA notification, 111 the requested additional number of SA (nChildSAi), the maximum number 112 of Child SA (maxChildSA) a responder is able to request, and a Nonce 113 (SPIi_Nonce), that is used to generate the SPIi associated to the 114 SPIi of the Child SAs. The initiator MUST chose the Nonce value such 115 as SPIi associated to maxChildSA remains available. The associated 116 SPIi values are generated as follows: 118 {SPIi_1, ..., SPIi_maxChildSA} = prf+(SPIi_Nonce) 120 initiator responder 121 ------------------------------------------------------------------ 122 HDR, SK {IDi, [CERT,] [CERTREQ,] 123 [IDr,] AUTH, SAi2, TSi, TSr, 124 N(MULTIPLE_CHILD_SA(nChildSAi, maxChildSA, SPIi_Nonce))} --> 126 Upon receiving a request for the CREATE_CHILD_SA exchange, the 127 responder builds the CREATE_CHILD_SA Response. The MULTIPLE_CHILD_SA 128 Notify Payload is processed only when the CREATE_CHILD_SA can be 129 successfully completed and that the responder supports the Multiple 130 Child SA extension. Otherwise the MULTIPLE_CHILD_SA Notify Payload 131 is ignored. Only the first encountered MULTIPLE_CHILD_SA 132 notification is considered, others are ignored. 134 Upon receiving the MULTIPLE_CHILD_SA Notify Payload, a responder 135 indicates the accepted number of additional SA (nChildSA) it is 136 willing to generate. nChildSAr MUST be equal or greater to nChildSAi 137 and lower or equal to maxChildSA. In addition, the responder 138 provides a Nonce (SPIr_Nonce) that will be used to generate the 139 nChildSAs. maxChildSA is left unchanged. The responder MUST chose 140 Nonce such that the nChildSA SPIs are available. The SPIs are 141 generated as follows: 143 {SPIr_1, ..., SPIr_nChildSA} = prf+(SPIi_Nonce) 145 <-- HDR, SK {IDr, [CERT,] AUTH, 146 SAr2, TSi, TSr, 147 N(MULTIPLE_CHILD_SA(nChildSA, maxChildSA, SPIr_Nonce))} 149 Initiator and responder generate material for ChildSA and nChildSA 150 additional Child SAs, e.g KEYMAT, SPIi, SPIr, TSi, TSr. Note that 151 material derived for the Child SA is performed as defined in 152 [RFC7296] 154 KEYMAT for the Child SA as well as the nChildSAa are generated as 155 follows, with Ni, Nr provided in the IKE_AUTH exchange. Note that 156 the generation of KEYMAT remains compatible with [RFC7296] section 157 2.17 for the Child SA. 159 +-------------------------------------------------------------+-----+ 160 | {KEYMAT_ChildSA, KEYMAT_1..., KEYMAT_maxChildSA } = | Nr) | 161 | prf+(SK_d, Ni | | 162 +-------------------------------------------------------------+-----+ 163 +-------------------------------------------------------------+-----+ 165 SPIs (SPIi_1, SPIi_nChildSA) and (SPIr_1, SPI_nChildSA) associated to 166 the nChildSA are generated as follows. The SPIs of the Child SA are 167 SPIi, SPIr provided in the SA2 payload exchanged. 169 {SPIi_1, ..., SPIi_nChildSA} = prf+(SPIi_Nonce) {SPIr_1, ..., 170 SPIr_nChildSA} = prf+(SPIr_Nonce) 172 TSi, TSr have the same value for the Child SA and nChildSA additional 173 Child SAs. 175 4. Error Handling 177 There may be conditions when the responder for some reason is unable 178 or unwilling to create additional Child SAs. This inability may be 179 temporary or permanent. 181 Temporary inability occurs when the responder doesn't have enough 182 resources at the moment to generate Child SAs. In this case, the 183 responder SHOULD reject the request to clone the IKE SA with the 184 TEMPORARY_FAILURE notification. 186 <-- HDR, SK {N(TEMPORARY_FAILURE)} 188 After receiving this notification, the initiator MAY retry its 189 request after waiting some period of time. See Section 2.25 of 190 [RFC7296] for details. 192 In some cases, the responder may have restrictions on the number of 193 coexisting SAs with one peer. These restrictions may be either 194 implicit (some devices may have enough resources to handle only a few 195 SAs) or explicit (provided by some configuration parameter). If the 196 initiator wants more SAs than the responder is able or is configured 197 to handle, the responder SHOULD reject the request with the 198 NO_ADDITIONAL_SAS notification as defined in [RFC7296]. 200 <-- HDR, SK {N(NO_ADDITIONAL_SAS)} 202 This condition is considered permanent and the initiator SHOULD NOT 203 retry creating Child SAs until some of the existing SAs with the 204 responder are deleted. This condition is considered permanent and 205 the initiator SHOULD NOT retry cloning an IKE SA until some of the 206 existing SAs with the responder are deleted. 208 5. Payload Description 210 Figure 1 illustrates the Notify Payload packet format as described in 211 Section 3.10 of [RFC7296] used for both the MULTIPLE_CHILD_SA 212 notifications. 214 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Next Payload |C| RESERVED | Payload Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Protocol ID | SPI Size | Notify Message Type | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | nChildSA | maxChildSA | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | SPI_Nonce | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: Notify Payload 227 The fields Next Payload, Critical Bit, RESERVED, and Payload Length 228 are defined in [RFC7296]. Specific fields defined in this document 229 are: 231 o Protocol ID (1 octet): Set to zero. 233 o Security Parameter Index (SPI) Size (1 octet): Set to zero. 235 o Notify Message Type (2 octets): Specifies the type of notification 236 message. It is set to TBD1 for the MULTIPLE_CHILD_SA 237 notification. 239 o nChildSA (2 octets): number of set of SAs. The value set by the 240 initiator is nChildSAi and the one set by the responder is 241 nChildSAr. 243 o maxChildSA (2 octets): Maximum number of acceptable set of SAs. 244 This value is set by the initiator and set to zero by the 245 responder. 247 NOTES: -- IKE_SA SKEYSEED = prf(Ni | Nr, g^ir) 249 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+ 250 (SKEYSEED, Ni | Nr | SPIi | SPIr) -- SAs KEYMAT = prf+(SK_d, Ni | Nr) 252 6. IANA Considerations 254 IANA has allocated two values in the "IKEv2 Notify Message Types - 255 Status Types" registry: 257 Value Notify Messages - Status Types 258 ----------------------------------------- 259 TBD1 MULTIPLE_CHILD_SA 261 7. Security Consideration 263 The protocol defined in this document does not modify IKEv2. 264 Security considerations. Generating multiple SA is equivalent as the 265 CREATE_CHILD_SA exchange described in [RFC7296]. 267 8. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 275 Kivinen, "Internet Key Exchange Protocol Version 2 276 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 277 2014, . 279 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 280 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 281 May 2017, . 283 Authors' Addresses 285 Daniel Migault 286 Ericsson 287 8275 Trans Canada Route 288 Saint Laurent, QC 4S 0B6 289 Canada 291 EMail: daniel.migault@ericsson.com 293 Steffen Klassert 294 Secunet 296 EMail: steffen.klassert@secunet.com