idnits 2.17.1 draft-nir-i2nsf-ipsec-dc-prof-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 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 (July 22, 2019) is 1737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Y. Nir 3 Internet-Draft DellEMC 4 Intended status: Informational July 22, 2019 5 Expires: January 23, 2020 7 A Data Center Profile for Software Defined Networking (SDN)-based IPsec 8 draft-nir-i2nsf-ipsec-dc-prof-00 10 Abstract 12 This document presents two profiles for configuring IPsec within a 13 data center using an SDN controller and the YANG model described in 14 the sdn-ipsec draft. 16 Two profiles are described to allow both the IKE and IKE-less cases 17 because some data centers may be required to use a standardized 18 method of key exchange rather than SDN. 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 January 23, 2020. 37 Copyright Notice 39 Copyright (c) 2019 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 1. Introduction 54 [sdn-ipsec] describes a YANG model that allows a software defined 55 networking (SDN) controller to configure the use of IP security 56 (IPsec - [RFC4301]) and optionally the Internet Key Exchange protocol 57 (IKEv2 - [RFC7296]) to secure IP traffic between the hosts that it 58 controls. 60 The SDN-IPsec document allows for configuration of most of the 61 options available in IPsec. However, not every one of those options 62 are appropriate for all use cases. 64 The use case that is covered here is the need to encrypt traffic 65 between hosts within a data center. As explained in Section 2, data 66 centers cannot be considered a secure environment where internal 67 communications are safe behind the firewall. One way to protect the 68 internal traffic is to configure TLS pair-wise between the hosts, but 69 [sdn-ipsec] provides a more convenient, automated solution. 71 This document presents two profiles that are appropriate for 72 encrypting traffic among the hosts in a data center, one with and one 73 without the use of IKE. 75 1.1. Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in BCP 14 [RFC2119] 80 [RFC8174] when, and only when, they appear in all capitals, as shown 81 here. 83 "Security Controller" or "SC" is an SDN controller used to configure 84 security policy. For the purposes of this document, we limit the use 85 of this term to an SDN controller that distributes IPsec policy. 87 "Data center hosts" is the term we use for any machine in the data 88 center that communicates using Internet Protocol (IP) with other 89 machines, both within and outside the data center. 91 "Network Security Functions" or NSF is the term used for a host in 92 the data plane that implements a security function. For the purposes 93 of this document we will call a host that has an IPsec stack and the 94 software necessary to be configured by an SC an "IPsec NSF". 96 "Control Domain" will be used here to mean the set of all IPsec NSFs 97 controlled by a particular security controller. The controller can 98 set up security associations within the control domain, but any 99 associations from within the domain to hosts or gateways outside of 100 the domain have to be configured on the remote host as well. The 101 controller can, however, configure the local side of things, as 102 mentioned in Section 3.4. 104 2. Assumptions About The Evnironment 106 A modern data center usually has many systems from several different 107 vendors containing data with varying levels of sensitivity. In the 108 past people often assumed that the data center was protected from 109 traffic interception by physical security. It was assumed that 110 traffic within the data center or within the corporate network could 111 safely be sent in the clear. This perception no longer holds if it 112 ever did. (TODO: citation needed). 114 The servers in today's data center are connected both to corporate 115 systems outside the data center as well as to public clouds and the 116 Internet. Even if physical security is maintained, the threat of a 117 compromised server intercepting internal traffic is very real. In 118 practice, even the physical security cannot be consistently 119 maintained, as technicians from multiple vendors are often allowed 120 physical access to the data center and supervision of those 121 technicians is often lax. 123 Additionally, certain industries or types of data are regulated to 124 require encryption of all data in transit. Medical information, 125 personal information, and financial information are examples of data 126 that often requires protection both at rest and in transit. For 127 these reasons it is often necessary to encrypt traffic within the 128 data center, between the data center and corporate networks, and 129 between the data center and public clouds. 131 IPsec is a good option for encrypting traffic between servers. It 132 provides the required confidentiality and message authentication, and 133 it is included in every common operating system as well as third 134 party vendor products It can be imposed by server administrators 135 without any changes to or configuration of the applications running 136 on the servers. 138 The problem with using IPsec has been that its configuration is 139 difficult. The data structures described in [RFC4301] require that 140 data center hosts should all be configured with Peer Authentication 141 Database (PAD) and Security Policy Database (SPD) entries for each 142 peer host, plus either pair-wise shared secrets or public-key based 143 credentials. There has never been a scalable way to perform this 144 mass configuration until [sdn-ipsec], which allows an SDN controller 145 (renamed to Security Controller) to configure all of the necessary 146 information so that any two data center hosts can communicate using 147 IPsec. 149 The following assumptions are made: 151 o That an SC as described in [sdn-ipsec] is present in the data 152 center. 154 o That the data center hosts are also IPsec NSFs, that they 155 implement the NSF role of an [sdn-ipsec] implementation, and that 156 they can all be configured by the above-mentioned SC. 158 o That the IPsec NSFs are relatively new, so that they include 159 implementations of current cryptographic algorithms. 161 o That the connection between the SC and the IPsec NSFs is secure. 162 Specifically, that it is safe to transmit keys and secret 163 credentials over that connection. 165 o That the SC can produce enough good random bits to periodically 166 produce pair-wise keys for as many IPsec NSFs as it can control. 168 o That both the IKE and IKE-less cases from [sdn-ipsec] are 169 technically viable. In other words, the software on the IPsec 170 NSFs can accommodate both. 172 If the last point does not hold, and the NSFs can only accommodate 173 IPsec (but not IKE), then only the IKE-less option is viable. At 174 this point in time, I am not aware of any such NSFs. 176 2.1. Block and Bypass Traffic 178 Not all nodes in a data center are supposed to communicate with one 179 another at all, and some traffic does not need to be encrypted. In 180 other words, a mesh is not the most appropriate topology for IPsec on 181 the network. The controller can enforce this lack of communication 182 with policy that blocks all communications that are not needed with 183 the action "block" and allow some unprotected traffic with the action 184 "bypass". 186 This means that with N IPsec NSFs, there will be far less than N^2 187 security associations. A mesh is still a valid configuration, but 188 it's not usually the most appropriate. Using "block" actions to 189 prevent unwanted communications is as much a part of enforcing a 190 security policy in the data center as encrypting legitimate traffic. 192 The particulars of what traffic should be allowed in the clear, what 193 should be protected, and what should be blocked are, of course, 194 unique to each organization and this document cannot make any rules 195 about that. Most often, the last or "cleanup" rule in the policy 196 should be a universal "block" rule. 198 3. Profiles For Data Center Hosts 200 This section presents two profiles for using IPsec in the data 201 center: one that includes IKE, and one that does not. The choice 202 between these two is entirely up to the regulatory regime. The IKE- 203 less profile is simpler and requires less components. It is 204 preferable unless the regulatory regime demands the use of an 205 Authenticated Key Exchange (AKE) method such as IKEv2. 207 3.1. IKE Profile 209 With an IKE profile, all pairs of hosts that are supposed to 210 communicate securely with one another SHALL be issued shared secrets. 211 The shared secrets MUST be generated independently of one another by 212 the controller using a true random number generator (TRNG) or a 213 secure pseudo-random number generator (PRNG) for each pair of hosts. 215 Only IKEv2 will be used. 217 The identities configured for the PAD can either be meaningful names 218 from the configuration of the controller, or they can be generated 219 sequentially by the controller. In either case the ID type SHALL be 220 Key ID (See section 4.4.3.1 of [RFC4301]) 222 The algorithms used within IKEv2 SHALL be selected from among those 223 marked MUST, SHOULD, and SHOULD+ in [RFC8247] without the "(IoT)" 224 label, or a newer RFC that will obsolete RFC 8247 (TODO: why is this 225 not a BCP?) 227 The lifetime for an IKE SA SHALL be 24 hours. The lifetime for an 228 ESP SA SHALL be 8 hours. 230 For both IKE and IPsec, the controller MUST specify exactly one set 231 of algorithms for each pair of nodes. The controller SHOULD specify 232 one set of algorithms for all the associations in the system, unless 233 one of the following applies: 235 1. The preferred algorithm is not supported by all nodes, so those 236 that do not support it have to use another algorithm. 238 2. Different algorithms have different performance on different 239 NSFs. For example, AES-GCM is faster than ChaCha20-Poly1305 on 240 Intel platforms, while ChaCha20-Poly1305 is faster on ARM 241 platforms. It can be advantageous to use one or the other 242 depending on the types of systems communicating. 244 The rest of the properties are similar to those in the IKE-less 245 profile (Section 3.2) 247 3.2. IKE-Less Profile 249 All security associations MUST have selectors (see section 4.4.1.1 of 250 [RFC4301]) that have a single local address and a single remote 251 address with no value for protocols or ports. TBD: exception for 252 multi-homed hosts? 254 All security associations are provided proactively. The controller 255 does not wait for a request from the NSF for an SA. 257 The controller SHOULD refresh the SAs every hour, and MAY do this 258 more often if the volume of traffic exceeds the limits of the 259 algorithms used. 261 3.3. Propertied Common to Both Profile 263 All SPD entries MUST have selectors that have a single local address 264 and a single remote address with no value for protocols or ports. 265 This, in the IKE case will lead to SAs as described in the first 266 paragraph of Section 3.2, so this requirement does not need to be 267 repeated. TBD: exception for multi-homed hosts? 269 All algorithms used in IPsec MUST be those marked MUST, SHOULD, and 270 SHOULD+ in [RFC8221], or a newer RFC that will obsolete RFC 8221 271 (TODO: why is this not a BCP?) 273 All SAD entries MUST be regular ESP [RFC4303]. AH [RFC4302] and WESP 274 [RFC5840] are not supported in this profile. 276 All SAs SHOULD use tunnel-mode. They MAY use transport mode only if 277 all NSFs support this. 279 3.4. Communications Outside the Domain 281 Associations between NSFs in the domain and NSFs that are not in the 282 domain are outside the scope of this document. The security 283 controller may configure the NSFs in the domain with the IKE case, 284 but success of the communications depends on the other NSF being 285 configured in a compatible way. 287 Because of this dependency, the advice in this document do not apply: 288 It is fine to support multiple algorithms, it is fine to support 289 subnets and/or specific protocols and ports, and it is also OK to use 290 other ID types and certificates. That configuration can co-exist in 291 the NSFs with the configuration specified in this profile, but is out 292 of scope here. 294 4. Rationale for the Properties in the Profile 296 The sub-sections below explain the rationale for the content of 297 Section 3. 299 4.1. Why IKE-less is preferrable 301 IKEv2 [RFC7296] is a protocol for authenticating peers and generating 302 traffic encryption keys. It allows peers that have a good random 303 number generator to be configured either once or rarely, and still be 304 able to communicate securely over the Internet. 306 IKEv2 thus addresses two issues that are not at all problematic for 307 IPsec NSFs that are configured by an SC. The SC can configure the 308 NSF as often as necessary, and already has the identities established 309 through its own secure channel with those NSFs. 311 For this reason, setting up the traffic keys directly by the SC where 312 it exists and controls all the relevant hosts is not an inferior 313 solution. It should be preferred for its simplicity, its lower 314 latency, and because it avoids relying on the random number generator 315 within the NSF. 317 4.2. Shared Secrets vs PKI 319 We chose to use shared secrets in Section 3.1 because they are 320 simpler than PKI and require less infrastructure. PKI has an 321 advantage when configuring the hosts pair-wise is difficult. 322 However, using a security controller means that changing the 323 configuration or generating pair-wise secrets for even a large number 324 of hosts is attainable. With this change of assumption, it no longer 325 makes sense to use PKI with its expiration times, revocation checks 326 and hierarchical signature verification. 328 4.3. Why just one algorithm in IKE 330 IKEv2 allows peers to each support multiple algorithms, and the 331 protocols selects one that is supported by both. This is a good 332 feature for interoperability between peers that are configured 333 separately. When configuring the peers with SDN IPsec, both peers 334 are configured by the same controller, so there is no reason for them 335 to offer any algorithm except the one preferred by the controller. 337 4.4. Why not MUST- 339 In both Section 3.1 and Section 3.3 we required the use of algorithms 340 marked as MUST, SHOULD, or SHOULD+. We excluded those marked as 341 MUST-, even though these seem to be at a higher level of preference 342 than those marked SHOULD or SHOULD+. 344 The reason for this is that despite what [RFC8221] says, algorithms 345 tend to be deprecated quickly and may fall from MUST- to MAY or even 346 MUST NOT. The only algorithm marked as MUST- in those drafts in 347 HMAC-SHA1, and it would have been at the MAY or lower level had it 348 not been for the fact that it is the most widely deployed algorithm, 349 and disabling it may lead to interoperability problems. 351 In a new deployment such as this, there is no reason to keep using 352 such an outdated algorithm that is very likely on its way out. 354 4.5. Proactive vs Reactive Model 356 The profile in Section 3.2 is proactive. SAs are installed in the 357 NSFs along with the policy, and are maintained as long as the policy 358 remains. We never wait for the NSF to request an SA. There are two 359 reasons for this: 361 1. Creating the SAs proactively eliminates any latency in processing 362 a packet at the NSF. 364 2. The cost of an unused SA is very low in the NSF - usually on the 365 order of a few hundreds of bytes. The cost at the controller of 366 managing these SAs is also low. If SAs are generated every 8 367 hours and there are 1000 IPsec NSFs in a mesh, that's still just 368 a million tunnels and only 35 needing to be rekeyed per second. 370 5. IANA Considerations 372 There are no requests for IANA in this document. 374 6. Security Considerations 376 The entire document is about security. The considerations in 377 [sdn-ipsec] apply. Additionally, Section 4 contains explanation of 378 the thinking behind the security decisions in this document. 380 The environment where this profile is expected to be used is 381 described in the Introduction (Section 1), and is an internal network 382 of a data center rather than the open Internet. Despite this, no 383 assumptions are made about the network between IPsec NSFs being in 384 any way safer than the open Internet: the connection between 385 controller and NSF is required to be secure, and traffic keys are set 386 up in a secure way: either over the controller-NSF secure connection, 387 or using IKEv2. 389 The communication channel between the security controller and the NSF 390 is required to be secure because it carries traffic keys, 391 credentials, or both. 393 A risk that is not addressed in this document is that of an attacker 394 blocking or delaying messages from the controller to the NSFs so as 395 to prevent the timely setup of security associations. Such an attack 396 can lead to denial of service if the IPsec NSFs are configured to 397 fail closed, or to sending traffic in the clear if they are 398 configured to fail open, which may be valid if it is expected that 399 only some of the traffic in the data center is to be encrypted. This 400 risk has to be mitigated by normal data center operations which 401 should ensure that nodes in the data center, in this case the 402 controller and the NSF, are not blocked. 404 7. ToDo 406 Need to add a reference to https://csrc.nist.gov/publications/detail/ 407 sp/800-77/rev-1/draft 409 8. References 411 8.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 419 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 420 May 2017, . 422 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 423 Kivinen, "Cryptographic Algorithm Implementation 424 Requirements and Usage Guidance for Encapsulating Security 425 Payload (ESP) and Authentication Header (AH)", RFC 8221, 426 DOI 10.17487/RFC8221, October 2017, 427 . 429 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 430 "Algorithm Implementation Requirements and Usage Guidance 431 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 432 RFC 8247, DOI 10.17487/RFC8247, September 2017, 433 . 435 [sdn-ipsec] 436 Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, 437 "Software-Defined Networking (SDN)-based IPsec Flow 438 Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 439 (work in progress), March 2019. 441 8.2. Informative References 443 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 444 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 445 December 2005, . 447 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 448 DOI 10.17487/RFC4302, December 2005, 449 . 451 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 452 RFC 4303, DOI 10.17487/RFC4303, December 2005, 453 . 455 [RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped 456 Encapsulating Security Payload (ESP) for Traffic 457 Visibility", RFC 5840, DOI 10.17487/RFC5840, April 2010, 458 . 460 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 461 Kivinen, "Internet Key Exchange Protocol Version 2 462 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 463 2014, . 465 Author's Address 467 Yoav Nir 468 DellEMC 469 9 Andrei Sakharov St 470 Haifa 3190500 471 Israel 473 Email: ynir.ietf@gmail.com