idnits 2.17.1 draft-sajassi-bess-secure-evpn-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8365], [RFC7432]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1131 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) == Missing Reference: 'EVPN-PREFIX' is mentioned on line 272, but not defined == Missing Reference: 'RFC7365' is mentioned on line 296, but not defined == Missing Reference: 'IKEV2-IANA' is mentioned on line 382, but not defined == Missing Reference: 'RFC7296' is mentioned on line 1437, but not defined == Missing Reference: 'IKEv2-IANA' is mentioned on line 1184, but not defined == Missing Reference: 'TUNNEL-ENCAP' is mentioned on line 1326, but not defined == Missing Reference: 'RFC5114' is mentioned on line 1388, but not defined == Missing Reference: 'RFC4753' is mentioned on line 1393, but not defined ** Obsolete undefined reference: RFC 4753 (Obsoleted by RFC 5903) == Missing Reference: 'IKEV2IANA' is mentioned on line 1435, but not defined == Missing Reference: 'RFC6989' is mentioned on line 1496, but not defined == Missing Reference: 'REUSE' is mentioned on line 1496, but not defined == Missing Reference: 'I-D.ietf-ipsecme-qr-ikev2' is mentioned on line 1541, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'GENEVE' Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group A. Sajassi, Ed. 3 Internet-Draft A. Banerjee 4 Intended status: Standards Track S. Thoria 5 Expires: August 26, 2021 Cisco 6 D. Carrel 7 Graphiant 8 B. Weis 9 Independent 10 J. Drake 11 Juniper Networks 12 February 22, 2021 14 Secure EVPN 15 draft-sajassi-bess-secure-evpn-04 17 Abstract 19 The applications of EVPN-based solutions ([RFC7432] and [RFC8365]) 20 have become pervasive in Data Center, Service Provider, and 21 Enterprise segments. It is being used for fabric overlays and inter- 22 site connectivity in the Data Center market segment, for Layer-2, 23 Layer-3, and IRB VPN services in the Service Provider market segment, 24 and for fabric overlay and WAN connectivity in Enterprise networks. 25 For Data Center and Enterprise applications, there is a need to 26 provide inter-site and WAN connectivity over public Internet in a 27 secured manner with same level of privacy, integrity, and 28 authentication for tenant's traffic as IPsec tunneling using IKEv2. 29 This document presents a solution where BGP point-to-multipoint 30 signaling is leveraged for key and policy exchange among PE devices 31 to create private pair-wise IPsec Security Associations without IKEv2 32 point-to-point signaling or any other direct peer-to-peer session 33 establishment messages. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 26, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. Tenant's Layer-2 and Layer-3 data and control traffic . . 7 73 3.2. Tenant's Unicast and Multicast Data Protection . . . . . 7 74 3.3. P2MP Signaling for SA setup and Maintenance . . . . . . . 7 75 3.4. Granularity of Security Association Tunnels . . . . . . . 7 76 3.5. Support for Policy and DH-Group List . . . . . . . . . . 8 77 4. SA and Key Management . . . . . . . . . . . . . . . . . . . . 8 78 4.1. Generating Initial IPsec SAs . . . . . . . . . . . . . . 8 79 4.2. Rekey of IPsec SAs . . . . . . . . . . . . . . . . . . . 10 80 4.2.1. Single IPSec Device Rekey . . . . . . . . . . . . . . 11 81 4.2.2. Multiple IPSec Device Rekey . . . . . . . . . . . . . 13 82 5. IPsec Database Generation . . . . . . . . . . . . . . . . . . 16 83 5.1. The Security Policy Database (SPD) . . . . . . . . . . . 16 84 5.2. Security Association Database (SAD) . . . . . . . . . . . 16 85 5.2.1. Generating Keying Material for IPsec SAs . . . . . . 16 86 5.2.1.1. g^ir . . . . . . . . . . . . . . . . . . . . . . 16 87 5.2.1.2. Nonces . . . . . . . . . . . . . . . . . . . . . 17 88 5.2.1.3. SPIs . . . . . . . . . . . . . . . . . . . . . . 17 89 5.2.1.4. IPsec key generation . . . . . . . . . . . . . . 18 90 5.3. Peer Authorization Database (PAD) . . . . . . . . . . . . 19 91 6. Policy distributed through the BGP RR . . . . . . . . . . . . 19 92 6.1. IPsec policy negotiation . . . . . . . . . . . . . . . . 20 93 7. BGP Component . . . . . . . . . . . . . . . . . . . . . . . . 21 94 7.1. Zero Touch Bring-up (ZTB) . . . . . . . . . . . . . . . . 21 95 7.2. Configuration Management . . . . . . . . . . . . . . . . 21 96 7.3. Orchestration . . . . . . . . . . . . . . . . . . . . . . 22 97 7.4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 22 98 8. Solution Description . . . . . . . . . . . . . . . . . . . . 22 99 8.1. Inheritance of Security Policies . . . . . . . . . . . . 23 100 8.2. Distribution of Public Keys and Policies . . . . . . . . 24 101 8.2.1. Minimal DIM . . . . . . . . . . . . . . . . . . . . . 24 102 8.2.2. Multiple Policies . . . . . . . . . . . . . . . . . . 25 103 8.2.3. Multiple DH-groups . . . . . . . . . . . . . . . . . 25 104 8.2.4. Multiple or Single ESP SA policies . . . . . . . . . 25 105 8.3. Initial IPsec SAs Generation . . . . . . . . . . . . . . 25 106 8.4. Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . 26 107 8.5. IPsec Databases . . . . . . . . . . . . . . . . . . . . . 26 108 9. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 26 109 9.1. Standard ESP Encapsulation . . . . . . . . . . . . . . . 26 110 9.2. ESP Encapsulation within UDP packet . . . . . . . . . . . 27 111 10. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 28 112 10.1. The Base (Minimal Set) DIM Sub-TLV . . . . . . . . . . . 29 113 10.2. The Key Exchange Sub-TLV . . . . . . . . . . . . . . . . 29 114 10.3. ESP SA Proposals Sub-TLV . . . . . . . . . . . . . . . . 30 115 10.3.1. Transform Substructure . . . . . . . . . . . . . . . 30 116 11. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 31 117 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 118 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 119 14. Security Considerations . . . . . . . . . . . . . . . . . . . 32 120 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 121 15.1. Normative References . . . . . . . . . . . . . . . . . . 33 122 15.2. Informative References . . . . . . . . . . . . . . . . . 34 123 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 35 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 126 1. Introduction 128 The applications of EVPN-based solutions have become pervasive in 129 Data Center, Service Provider, and Enterprise segments. It is being 130 used for fabric overlays and inter-site connectivity in the Data 131 Center market segment, for Layer-2, Layer-3, and IRB VPN services in 132 the Service Provider market segment, and for fabric overlay and WAN 133 connectivity in the Enterprise networks. For Data Center and 134 Enterprise applications, there is a need to provide inter-site and 135 WAN connectivity over public Internet in a secured manner with the 136 same level of privacy, integrity, and authentication for tenant's 137 traffic as used in IPsec tunneling using IKEv2. This document 138 presents a solution where BGP point-to-multipoint signaling is 139 leveraged for key and policy exchange among PE devices to create 140 private pair-wise IPsec Security Associations without IKEv2 point-to- 141 point signaling or any other direct peer-to-peer session 142 establishment messages. This method is specially recommended for 143 large scale deployment where large meshes of IKEv2 sessions among PE 144 devices are not appropriate. 146 EVPN uses BGP as control-plane protocol for distribution of 147 information needed for discovery of PEs participating in a VPN, 148 discovery of PEs participating in a redundancy group, customer MAC 149 addresses and IP prefixes/addresses, aliasing information, tunnel 150 encapsulation types, multicast tunnel types, multicast group 151 memberships, and other information. The advantages of using BGP 152 control plane in EVPN are well understood including the following: 154 1. A full mesh of BGP sessions among PE devices can be avoided by 155 using Route Reflector (RR) where a PE only needs to setup a 156 single BGP session between itself and the RR as opposed to 157 setting up N BGP sessions to N other remote PEs; therefore, 158 reducing number of BGP sessions from O(N^2) to O(N) in the 159 network. Furthermore, RR hierarchy can be leveraged to scale the 160 number of BGP routes on the RR. 162 2. MP-BGP route filtering and constrained route distribution can be 163 leveraged to ensure that the control-plane traffic for a given 164 VPN is only distributed to the PEs participating in that VPN. 166 For setting up point-to-point security association (i.e., IPsec 167 tunnel) between a pair of EVPN PEs, it is important to leverage BGP 168 point-to-multipoint singling architecture using the RR along with its 169 route filtering and constrain mechanisms to achieve the performance 170 and the scale needed for large number of security associations (IPsec 171 tunnels) along with their frequent re-keying requirements. Using BGP 172 signaling along with the RR (instead of peer-to-peer protocol such as 173 IKEv2) reduces number of message exchanges needed for SAs 174 establishment and maintenance from O(N^2) to O(N) in the network. 176 Many key exchange methods (such as IKEv2) use a Diffie-Hellman (DH) 177 algorithm to derive keys. When combined with an authentication 178 method, the key exchange method allows two network devices to 179 generate private pair-wise keys with each other. This document 180 presents a key exchange method making use of the PE-to-RR trust 181 model, where an RR is used to distribute keying material and policy 182 between PE devices, also resulting in the PEs generating private 183 pair-wise keys with each other. DH public values are provided to 184 controllers from IPsec devices, where the controller relays the DH 185 public values to authorized peers of that IPsec device as defined by 186 a centralized policy. PE devices then create and install private 187 pair-wise IPsec session keys to be used to secure communications with 188 their peers. 190 Although IKEv2 is not used in this approach, the key management 191 interfaces between IKEv2 and IPsec defined in RFC 7296 are maintained 192 as much as possible. 194 1.1. Requirements Language 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in RFC 2119 [RFC2119] RFC 199 8174 [RFC8174] when, and only when, they appear in all capitals, as 200 shown here. 202 2. Terminology 204 o AC: Attachment Circuit. 206 o ARP: Address Resolution Protocol. 208 o BD: Broadcast Domain. As per RFC7432 [RFC7432], an EVI consists 209 of a single or multiple BDs. In case of VLAN-bundle and VLAN- 210 based service models (see RFC7432 [RFC7432]), a BD is equivalent 211 to an EVI. In case of VLAN-aware bundle service model, an EVI 212 contains multiple BDs. Also, in this document, BD and subnet are 213 equivalent terms. 215 o BD Route Target: refers to the Broadcast Domain assigned Route 216 Target RFC4364 [RFC4364]. In case of VLAN-aware bundle service 217 model, all the BD instances in the MAC-VRF share the same Route 218 Target. 220 o BT: Bridge Table. The instantiation of a BD in a MAC-VRF, as per 221 RFC7432 [RFC7432]. 223 o DGW: Data Center Gateway. 225 o Ethernet A-D route: Ethernet Auto-Discovery (A-D) route, as per 226 [RFC7432]. 228 o Ethernet NVO tunnel: refers to Network Virtualization Overlay 229 tunnels with Ethernet payload. Examples of this type of tunnels 230 are VXLAN or GENEVE [GENEVE]. 232 o EVI: EVPN Instance spanning the NVE/PE devices that are 233 participating on that EVPN, as per [RFC7432]. 235 o EVPN: Ethernet Virtual Private Networks, as per [RFC7432]. 237 o GRE: Generic Routing Encapsulation. 239 o GW IP: Gateway IP Address. 241 o IPL: IP Prefix Length. 243 o IP NVO tunnel: it refers to Network Virtualization Overlay tunnels 244 with IP payload (no MAC header in the payload). 246 o IP-VRF: A VPN Routing and Forwarding table for IP routes on an 247 NVE/PE. The IP routes could be populated by EVPN and IP-VPN 248 address families. An IP-VRF is also an instantiation of a layer 3 249 VPN in an NVE/PE. 251 o IRB: Integrated Routing and Bridging interface. It connects an 252 IP-VRF to a BD (or subnet). 254 o MAC-VRF: A Virtual Routing and Forwarding table for Media Access 255 Control (MAC) addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF 256 is also an instantiation of an EVI in an NVE/PE. 258 o ML: MAC address length. 260 o ND: Neighbor Discovery Protocol. 262 o NVE: Network Virtualization Edge. 264 o GENEVE: Generic Network Virtualization Encapsulation, [GENEVE]. 266 o NVO: Network Virtualization Overlays. 268 o RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as 269 defined in [RFC7432]. 271 o RT-5: EVPN route type 5, i.e., IP Prefix route. As defined in 272 Section 3 of [EVPN-PREFIX]. 274 o SBD: Supplementary Broadcast Domain. A BD that does not have any 275 ACs, only IRB interfaces, and it is used to provide connectivity 276 among all the IP-VRFs of the tenant. The SBD is only required in 277 IP-VRF- to-IP- VRF use-cases (see Section 4.4.). 279 o SN: Subnet. 281 o TS: Tenant System. 283 o VA: Virtual Appliance. 285 o VNI: Virtual Network Identifier. As in [RFC8365], the term is 286 used as a representation of a 24-bit NVO instance identifier, with 287 the understanding that VNI will refer to a VXLAN Network 288 Identifier in VXLAN, or Virtual Network Identifier in GENEVE, etc. 289 unless it is stated otherwise. 291 o VTEP: VXLAN Termination End Point, as in RFC 7348 [RFC7348]. 293 o VXLAN: Virtual Extensible LAN, as in RFC 7348 [RFC7348]. 295 This document also assumes familiarity with the terminology of 296 [RFC7432], [RFC8365], and [RFC7365]. 298 3. Requirements 300 The requirements for secured EVPN are captured in the following 301 subsections. 303 3.1. Tenant's Layer-2 and Layer-3 data and control traffic 305 Tenant's layer-2 and layer-3 data and control traffic must be 306 protected by IPsec cryptographic methods. This implies not only 307 tenant's data traffic must be protected by IPsec but also tenant's 308 control and routing information that are advertised in BGP must also 309 be protected by IPsec. This in turn implies that BGP session must be 310 protected by IPsec. 312 3.2. Tenant's Unicast and Multicast Data Protection 314 Tenant's layer-2 and layer-3 unicast traffic must be protected by 315 IPsec. In addition to that, tenant's layer-2 broadcast, unknown 316 unicast, and multicast traffic as well as tenant's layer-3 multicast 317 traffic must be protected by IPsec when ingress replication or 318 assisted replication are used. The use of BGP P2MP signaling for 319 setting up P2MP SAs in P2MP multicast tunnels is for future study. 321 3.3. P2MP Signaling for SA setup and Maintenance 323 BGP P2MP signaling must be used for IPsec SAs setup and maintenance. 324 This reduces the number of message exchanges from O(N^2) to O(N) 325 among the participating PE devices. 327 3.4. Granularity of Security Association Tunnels 329 The solution must support the setup and maintenance of IPsec SAs at 330 the following level of granularities: 332 o Per PE: A single IPsec tunnel between a pair of PEs to be used for 333 all tenants' traffic supported by the pair of PEs. 335 o Per tenant: A single IPsec tunnel per tenant per pair of PEs. For 336 example, if there are 1000 tenants supported on a pair of PEs, 337 then 1000 IPsec tunnels are required between that pair of PEs. 339 o Per subnet: A single IPsec tunnel per subnet (e.g., per VLAN/EVI) 340 of a tenant on a pair of PEs. 342 o Per L3 flow: A single IPsec tunnel per pair of IP addresses of a 343 tenant on a pair of PEs. 345 o Per L2 flow: A single IPsec tunnel per pair of MAC addresses of a 346 tenant on a pair of PEs. 348 o Per AC pair: A single IPsec tunnel per pair of Attachment Circuits 349 between a pair of PEs. 351 3.5. Support for Policy and DH-Group List 353 The solution must support a single policy and DH group for all SAs as 354 well as supporting multiple policies and DH groups among the SAs. 356 4. SA and Key Management 358 The BGP Route Reflector (RR) acts as a trusted third party, which 359 relays policy and keying material between PE devices. Communications 360 between the RR and the PEs MUST be authenticated, encrypted, and 361 integrity-protected. All algorithms are selected by the management 362 station associated with the RR. The combination of the RR and a set 363 of PE devices comprises of a cooperating group of devices that make 364 up a VPN, where each PE device is authorized to communicate with 365 other PE devices in the group. Policies can allow a PE device to 366 communicate with all other PE devices in the group, or may restrict 367 it to a subset of those devices. 369 DH public values from each PE are distributed to other authorized 370 peer PEs via the RR. Each PE device creates and maintains a DH pair, 371 which it uses to communicate with other members of the VPN. This 372 distribution of DH public values (and other related values) is 373 intended to be embedded into the BGP protocol as described later. In 374 particular, the RR provides a mechanism for secure key management. 375 However, it does not provide policy information or configuration as 376 that is assumed to be provided by the management station. 378 4.1. Generating Initial IPsec SAs 380 When an PE device (PE) begins operation, it generates a private/ 381 public DH pair, using an algorithm defined in the IKEv2 Diffie- 382 Hellman Group Transform IDs [IKEV2-IANA]. If the device does not 383 have any active peers it simply distributes its DH public value to 384 the BGP RR, along with a nonce to be used during SA creation. 385 Whenever a private/public DH pair is created, a new nonce MUST also 386 be created. Whenever DH public values are transmitted, they are 387 transmitted with the corresponding nonce. Whenever a DH private or 388 DH public value is used, it is used along with the corresponding 389 nonce. However, in the diagrams and descriptions below, the nonces 390 are often left out for the sake of clarity. 392 Upon receiving a peer's DH public value and nonce, the receiver 393 creates IPsec SAs (as described in Section 5.2). For each peer, a 394 pair of IPsec SAs are created by combining the PE device's own DH 395 private value with the DH public number received from the Controller. 397 +---+ +----------+ +---+ 398 | A | | BGP RR | | B | 399 +-+-+ +-----+----+ +-+-+ 400 +----------+ | | | 401 |Generate | | | | +----------+ 402 |DH pair a1| | | | |Generate | 403 +----------+ | a1-pub | | |DH pair b1| 404 +----------> | b1-pub | +----------+ 405 | | <----------+ 406 | | | 407 | | a1-pub | 408 | b1-pub +----------> | +-----------+ 409 +-----------+ | <----------+ | |Create SA: | 410 |Create SAs:| | | | | Tx(b1-a1)| 411 | Tx(a1-b1)| | | | | Rx(a1-b1)| 412 | Rx(b1-a1)| | | | +-----------+ 413 +-----------+ | | | 414 | | | 415 | IPsec ESP Tx(a1-b1) | 416 +-----------------------> | 417 | | | 418 | IPsec ESP Tx(b1-a1) | 419 | <-----------------------+ 420 | | | 421 + + + 423 Figure 1: Generation of Initial IPsec SAs between two peers 425 Figure 1 shows IPsec SA generation between a pair of PE devices. Two 426 PE devices (A and B shown in Figure 1) join the network. Each 427 creates it's own DH pair (labelled "a1" on A and "b1" on B), and 428 distributes the DH public value (labelled a1-pub and b1-pub) to the 429 BGP RR. The BGP RR forwards the DH public value to all authorized 430 peers, although for simplicity of exposition the figure only shows 431 the two IPsec devices. 433 When each device receives the peer's DH public value, a pair of IPsec 434 SAs are generated: one outbound and one inbound. As shown in the 435 figure, A generates an outbound SA labeled Tx(a1-b1), representing 436 that it has been generated using A's DH pair labeled a1 and B's DH 437 pair labeled b1. B generates the same IPsec SA as an inbound SA, 438 which is labeled Rx(a1-b1). Similarly, A generates an inbound IPsec 439 SA labelled Rx(b1-a1), which is the same IPsec SA on B which is 440 labelled Tx(b1-a1). 442 This process repeats on both A and B as they discover other PE 443 devices with which they are authorized to communicate. 445 4.2. Rekey of IPsec SAs 447 Any IPsec device may initiate a rekey at any time. Common reasons to 448 perform a rekey include a local time or volume based policy, or may 449 be the result of a cipher counter mode Initialization Vector (IV) 450 counter nearing its final value. The rekey process is performed 451 individually for each remote peer. If rekeying is performed with 452 multiple peers simultaneously, then the decision process and rules 453 described in this rekey are performed independently for each peer. 455 A decision process choosing an outbound IPsec SA is followed when 456 certain events occur, as described in the rules below. The same 457 decision process is followed regardless of whether the device is 458 performing a rekey or responding to a peer's rekey. The decision 459 process is: 461 1. Determine the outbound SAs with the remote peer's most recently 462 distributed DH public value. 464 2. Determine which of those outbound SAs are "live". A "live" 465 outbound SA is one built from a DH value from the local peer for 466 which it has observed inbound traffic using any SA based on the 467 same local DH pair. This proves that the remote peer is prepared 468 to receive traffic protected by that DH pair. 470 3. Choose the "live" outbound SA built from the local peer's most 471 recent DH public value. 473 A rekey operation follows these four basic rules. 475 Rule 1: When an IPsec device needs to perform a rekey with a remote 476 peer, it creates a new pair of IPsec SAs by combining the 477 new DH private value with the peer's DH public values. If 478 the remote peer is also in the midst of a rollover and its 479 DH public value has already been received, then this may 480 result in creating two sets of SAs: one pair with the remote 481 peer's old DH public value, and one pair with the remote 482 peer's new DH public value. 484 Rule 2: When an IPsec device receives a new remote peer's DH public 485 value from the controller it creates and installs a new pair 486 of IPsec SAs by combining the remote peer's new DH public 487 value with its own current local DH private values. If both 488 devices are in the midst of a rollover, this may result in 489 creating two sets of SAs with the remote peer's new DH 490 public value: one with the local old DH private value, and 491 one with the local new DH private value. The outbound SA 492 decision process is performed. 494 Rule 3: The first IPsec packet received by a rekeying IPsec device 495 on an inbound SA using its new DH pair causes it to perform 496 the outbound SA decision process. It may also shorten the 497 lifetime of IPsec SAs using its own old DH pair that are 498 shared with this peer, as they are no longer in use (other 499 than the inbound SA might receive packets in transit). 501 Rule 4: The first IPsec packet received from a remote rekeying IPsec 502 device using the remote peer's new DH pair allows the IPsec 503 device to shorten the lifetime of IPsec SAs shared with this 504 peer using unused remote DH pairs. 506 Two examples follow: a single IPsec device performing a rekey with 507 its peers, and two IPsec devices performing a simultaneous rekey. 508 The same rekey operations described above are exhibited in both 509 cases. 511 4.2.1. Single IPSec Device Rekey 513 When a single IPsec device begins a rekey, it first generates a new 514 DH pair and generates new IPsec SA pairs for each peer with which it 515 is communicating. It does this by combining the new DH private value 516 with each peer's existing DH public value. Only when the new IPsec 517 SAs have been installed and the device is prepared to receive on 518 those new SAs does it then distribute the new DH public value to the 519 Controller, which forwards the new DH public value to its authorized 520 peers. The rekeying IPsec device continues to transmit on the old 521 SAs for each peer until it observes that peer begin to transmit on 522 the new SAs. 524 +---+ +----------+ +---+ 525 | A | | BGP RR | | B | 526 +-+-+ +-----+----+ +-+-+ 527 +----------+ | | | 528 |Generate | | | | 529 |DH pair a2| | | | 530 +----------+ | | | 531 +--------------+ | | | 532 |Rule 1 | | | | 533 | Create SAs | | | | 534 | Tx(a2-b1) | | | | 535 | Rx(b1-a2) | | | | 536 | Use Tx(a1-b1)| | a2-pub | | 537 +--------------+ +----------> | | 538 | | | 539 | IPsec ESP Tx(a1-b1) | 540 +-----------------------> | 541 | IPsec ESP Tx(b1-a1) | 542 | <-----------------------+ 543 | | | 544 | | a2-pub | 545 | +----------> | +--------------+ 546 | | | |Rule 2 | 547 | | | | Create SAs | 548 | | | | Tx(b1-a2) | 549 | | | | Rx(a2-b1) | 550 | IPsec ESP Tx(b1-a2) | | Use Tx(b1-a2)| 551 +--------------+ | <-----------------------+ +--------------+ 552 |Rule 3 | | | | 553 | Use Tx(a2-b1)| | | | 554 | Shorten life | | | | 555 | Tx(a1-b1) | | IPsec ESP Tx(a2-b1) | 556 | Rx(b1-a1) | +----------------------> | +--------------+ 557 +--------------+ | | | |Rule 4 | 558 | | | | Shorten life | 559 | | | | Tx(b1-a1) | 560 | | | | Rx(a1-b1) | 561 | | | +--------------+ 562 + + + 564 Figure 2: Single IPSec Device Rekey between two peers 566 In Figure 3, device A is shown as performing a rekey, and it creates 567 a DH pair labelled "a2". The following steps are followed. 569 1. Rule 1 requires creating new IPsec SAs for each peer. In this 570 example, A creates a new outbound IPsec SA to communicate with B 571 labelled Tx(a2-b1), and a new inbound IPsec SA labelled 572 Rx(b1-a2). A continues to transmit on Tx(a1-b1) (generated as 573 shown in Figure 2). 575 2. A distributes the new public value (a2-pub) to the Controller who 576 forwards it to A's authorized peers, which includes B. During 577 this time, both A and B continue to use the initial IPsec SAs 578 setup between them using a1 and b1. 580 3. When B receives a2 from the controller, B follows Rule 2 by 581 creating Tx(b1-a2), Rx(a2-b1). B also follows the outbound SA 582 decision process, which causes it to change its outbound IPsec SA 583 to A to Tx(b1-a2). 585 4. When A receives a packet protected by Rx(b1-a2), it follows Rule 586 3 and performs the outbound SA decision process. This causes it 587 to change its outbound IPsec SA to Use Tx(a2-b1). It also 588 optionally shortens the lifetime of the old IPsec SAs shared with 589 this peer. 591 5. When B receives a packet protected by Tx(a2-b1), it follows Rule 592 4, in which it may shorten the lifetime of the old IPsec SAs 593 shared with this peer using DH pairs that are no longer in use. 595 At the end of the rekey, both A and B retain a single DH pair, and a 596 single set of IPsec SAs between them. 598 4.2.2. Multiple IPSec Device Rekey 600 When two or more IPsec device simultaneously begin a rekey, they each 601 follow the rekeying method described in the previous section. Every 602 rekeying IPsec device generates a new DH pair and generates new IPsec 603 SA pairs for each peer with which it is communicating by combining 604 their new DH private value with each peer's existing DH public value. 605 When this completes on a particular IPsec device, it distributes the 606 new DH public value to the Controller, which forwards it to its 607 authorized peers. Each continues to transmit on the existing SAs for 608 each peer until it observes that peer transmitting on the new SAs. 609 During a simultaneous rekey up to four pairs of IPsec SAs may be 610 temporarily created, but the four rules ensure that they converge on 611 a single new set of IPsec SAs. 613 +---+ +----------+ +---+ 614 | A | | BGP RR | | B | 615 +-+-+ +-----+----+ +-+-+ 616 +---------------------+ | | | +--------------+ 617 |Generate DH pair a2 | | | | |Gen DH pair b2| 618 +---------------------+ | | | +--------------+ 619 +---------------------+ | | | +--------------+ 620 |Rule 1 | | | | |Rule 1 | 621 | Create SAs | | | | | Create SAs | 622 | Tx(a2-b1),Rx(b1-a2)| | | | | Tx(b2-a1) | 623 | Use Tx(a1-b1) | | a2-pub | | | Rx(a1-b2) | 624 +---------------------+ +----------> | b2-pub | | Use Tx(b1-a1)| 625 | | <----------+ +--------------+ 626 | IPsec ESP Tx(a1-b1) | 627 +-----------------------> | 628 | IPsec ESP Tx(b1-a1) | 629 | <-----------------------+ 630 | | a2-pub | 631 | b2-pub +----------> | +--------------+ 632 +---------------------+ | <----------+ | |Rule 2 | 633 |Rule 2 | | | | | Create SAs | 634 | Create SAs | | | | | Tx(b1-a2) | 635 | Tx(a1-b2),Rx(b2-a1)| | | | | Rx(a2-b1) | 636 | Tx(a2-b2),Rx(b2-a2)| | | | | Tx(b2-a2) | 637 | Use Tx(a1-b2) | | | | | Rx(a2-b2) | 638 +---------------------+ | IPsec ESP Tx(b1-a2) | | Use Tx(b1-a2)| 639 | <-----------------------+ +--------------+ 640 | IPsec ESP Tx(a1-b2) | 641 +---------------------+ +-----------------------> | +--------------+ 642 |Rule 3 | | | | |Rule 3 | 643 | Use Tx(a2-b2) | | | | | Use Tx(b2-a2)| 644 | Shorten life | | | | | Shorten life | 645 | Tx(a1-b1),Rx(b1-a1)| | | | | Tx(b1-a1) | 646 | Tx(a1-b2),Rx(b2-a1)| | | | | Rx(a1-b1) | 647 +---------------------+ | IPsec ESP Tx(a2-b2) | | Tx(b1-a2) | 648 +----------------------> | | Rx(a2-b1) | 649 | IPsec ESP Tx(b2-a2) | +--------------+ 650 +---------------------+ <-----------------------+ +--------------+ 651 | Rule 4 | | | | |Rule 4 | 652 | Shorten life | | | | | Shorten life | 653 | Tx(a2-b1),Rx(b1-a2)| | | | | Tx(b1-a2) | 654 +---------------------+ | | | | Rx(a2-b1) | 655 + + + +--------------+ 657 Figure 3: Simultaneous IPsec Device Rekey between two peers 659 In Figure 4, device A and device B are both shown as performing a 660 rekey. Their initial state corresponds to the final state shown in 661 Figure 2 (i.e., they are communicating using a single pair of IPsec 662 SAs created from DH pairs "a1" and "b1". 664 1. A and B follow Rule 1, which includes creating new IPsec SAs for 665 each peer. In this example, A creates a new outbound IPsec SA to 666 communicate with B labelled Tx(a2-b1), and a new inbound IPsec SA 667 labelled Rx(b1-a2). B creates a new outbound IPsec SA to 668 communicate with B labelled Tx(a1-b2), and a new inbound IPsec SA 669 labelled Rx(b2-a1). A and B continue to transmit on IPsec SAs 670 previously created from DH pairs "a1" and "b1". 672 2. A distributes the new public value (a2-pub) to the Controller who 673 forwards it to A's authorized peers, which includes B. B also 674 distributes the new public value (b2-pub) to the Controller who 675 forwards it to B's authorized peers, which includes A. 677 3. When A and B receive each other's new peer DH public value from 678 the controller they follows Rule 2. But because now there are 679 four DH values that could be in used between A and B, they must 680 be prepared to use IPsec SAs using each permutation of DH values: 681 a1-b1, a1-b2, a2-b1, a2-b2. Prior to implementing Rule 2, each 682 has already created sets of IPsec SAs matching two of the 683 permutations, so just two more sets must be generated during Rule 684 2. 686 * One pair is created using the IPsec device's old DH pair with 687 the peer's new DH pair. This is necessary, because the peer 688 may transmit on this pair. 690 * One pair is created using the IPsec device's new DH pair with 691 the peer's new DH pair. This is the set of IPsec SAs that 692 will be used at the end of the rekey process. 694 Each peer begins transmitting on an IPsec SA that combines the 695 remote peer's new DH pair and its own old DH pair, which is the 696 most recent "live" SA on which it can transmit. I.e., A begins 697 transmitting on Tx(a1-b2) and B begins transmitting on Tx(b1-a2). 699 4. When A receives a packet protected by Rx(b1-a2), it understands 700 that the remote peer has received its new DH public value. A 701 also understands that because of Rule 2 that B must have created 702 IPsec SAs using a2-b2. This allows A to follow Rule 3 and change 703 its outbound IPsec SA to Use Tx(a2-b2). Similarly, when B 704 receives a packet protected by Rx(a1-b2), B recognizes that it 705 can also begin to transmit using Tx(b2-a2). Note that it also 706 possible that A will receive a packet protected by Rx(b2-a2) or B 707 will receive a packet protected by Rx(a2-b2), and then knows it 708 can transmit on an IPsec SA using both of the new DH pairs. 710 5. Also in Rule 3, Both A and B optionally shorten the lifetime of 711 older IPsec SAs shared with this peer derived from unused DH 712 pairs to be cleaned up. A shortens the lifetime of SAs based on 713 a1. B shortens the lifetime of SAs based on b1. 715 6. When A and B receive a packet protected by the remote peer's 716 latest DH pair, they shortens the lifetime of SAs based on the 717 remote peer's unused DH pair. 719 5. IPsec Database Generation 721 The PAD, SPD, and SAD all need to be setup as defined in the IPsec 722 Security Architecture [RFC4301]. 724 5.1. The Security Policy Database (SPD) 726 The SPD is implemented using methods outside the scope of this 727 document. The SPD describes the type of traffic that will be 728 protected between IPsec devices and the policy (e.g., ciphers) used 729 to create SAs. 731 5.2. Security Association Database (SAD) 733 The SAD is constructed from IPsec policy (e.g., ciphers) obtained 734 (depending on the controller protocol method) either from the 735 controller or distributed by a peer (see Section 6). 737 Keying Material is generated following the method defined in IKEv2, 738 and depends on SPIs, nonces, and the Diffie-Hellman shared secret. 740 The following sections describe how the necessary values are 741 determined. 743 5.2.1. Generating Keying Material for IPsec SAs 745 5.2.1.1. g^ir 747 A DH public value is distributed from the peer. 749 A DH shared secret (g^ir) is computed using the peer's public value, 750 and the device's private value. The DH group to be used must be 751 known by the device. Options include distribution by an SDN 752 controller, or distribution by the peer with the DH public value (see 753 Section 6). 755 5.2.1.2. Nonces 757 Nonces are distributed with a DH public value, and are used only with 758 that value. It is RECOMMENDED that nonces are generated as described 759 in Section 2.10 of [RFC7296]. 761 IKEv2 Key derivation specifies an initiator's nonce (Ni) and a 762 responder's nonce (Nr). While neither peer is truly initiating a 763 session), in order to fit the IKE key material models the roles must 764 be assigned. The initiator is chosen as the peer with the larger 765 nonce and the responder is the peer with the smaller. This does mean 766 that the roles can change for each rekey and for each SA within a 767 rekey. 769 5.2.1.3. SPIs 771 SPI values that are unique to each generation of keying material need 772 to be determined. While each peer could distribute its own inbound 773 SA value, the SPI value would be used by many peers. Although this 774 is not a problem for an SA lookup (lookup can include the source and 775 destination IP addresses), experience has shown that this is sub- 776 optimal for some hardware SA lookup algorithms. Instead, this 777 specification proposes generating values that are unpredictable and 778 indistinguishable from randomly-generated SPI values. 780 SPI values are generated using the IKEv2 prf+ function, where nonces 781 are used as the input to the prf. This produces a statistically 782 random SPI value that should be unique. However, with a 32 bit value 783 there is still a very small, but non-zero, chance of SPIs repeating 784 for a given pair of peers. To prevent this and ensure uniqueness in 785 the operational window, we also use the lower 2 bits from each peer's 786 rekey counter. 788 First the SPIs are taken from the prf+ function as 32 bit values and 789 assigned based on which peer is taking the role of initiator and 790 which is taking the role of responder. The p_SPI_i is taken by the 791 device providing Ni, where p_SPI_r is taken by the other device. 793 {p_SPI_i | p_SPI_r } = prf+(Ni | Nr, "SPI generation") 795 Next p_SPI_i and p_SPI_r are mapped from initiator and responder 796 roles to local and remote roles based on the choice of Ni and Nr in 797 5.2.1.2 and are renamed to p_SPI_local and p_SPI_remote. 799 Then, 2 2-bit Rotation Numbers (RN) are generated from the 2 least 800 significant bits (LSB) of the 2 rekey counter values (see Section 6). 801 These 4 bits replace the least significant bits of p_SPI_local and 802 p_SPI_remote with the local RN bits taking the least significant 803 position in p_SPI_local and the remote RN bits taking the least 804 significant position in p_SPI_remote. This shown in the following 805 two diagrams with RN_local shown as R_l and RN_remote shown as R_r. 807 (MSB) (LSB) 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | p_SPI_local bits from prf+ |R_r|R_l| 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 (MSB) (LSB) 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | p_SPI_remote bits from prf+ |R_l|R_r| 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 The reason for changing terminology from initiator/responder to 821 local/remote is because the roles of initiator/responder can change 822 in every rekey. The order of RN_local and RN_remote needs to remain 823 constant. If that order was based on initiator/responder, there's a 824 risk that if the initiator and responder roles changed and the two 825 peers re-keyed on different frequencies, they could end up with 826 identical RN values. 828 In some circumstances additional values may also need to be added to 829 the prf for peers to ensure that they have implemented the same 830 policy. Appendix A.3.1 includes a discussion of when this might be 831 needed. In these cases, only the prf+ inputs are modified and the 832 Rotation Numbers MUST still be added as above. 834 Because a device is not choosing its inbound SPI, its SA lookup 835 process needs to be aware that duplicates could occur across 836 different peers. In that case, the inbound SA Lookup SHOULD include 837 a source IP address in addition to the SPI value (see Section 4.1 of 838 [RFC4301]). 840 5.2.1.4. IPsec key generation 842 As described in previous sections, a DH public value and a nonce are 843 distributed by peers. These are used to generate IPsec keys 844 following the method defined in the IKEv2. SKEYSEED is generated 845 following Section 2.14 of [RFC7296]: 847 SKEYSEED = prf(Ni | Nr, g^ir) 849 KEYMAT can be similarly derived as defined by IKEv2 (Section 2.17 of 850 [RFC7296]), although only SK_d is required to be generated (shown in 851 Section 2.14 of [RFC7296]). 853 SK_d = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) 855 KEYMAT = prf+(SK_d, Ni | Nr) 857 However, with the simplification where only SK_d is generated, it can 858 be observed that the derivation of SK_d could be skipped entirely, 859 and an optimized derivation of KEYMAT could be as follows: 861 KEYMAT = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) 863 Note: A single specification for generating KEYMAT will be determined 864 in a future version of this document. 866 5.3. Peer Authorization Database (PAD) 868 The PAD identifies authorized peers. PAD entries are either 869 statically configured, or may be dynamically updated by the 870 controller. 872 The PAD omits authentication data for each peer, because it has 873 delegated authentication and authorization to the controller. 875 The controller protocol MUST be able to describe an identity that a 876 receiver can match against its local PAD database, to ensure that the 877 peer is an authorized peer. 879 6. Policy distributed through the BGP RR 881 An IPsec device distributes to a controller a DH public value and the 882 associated information and policy needed to create IPsec SAs in a 883 Device Information Message (DIM). The controller then distributes 884 the DIM to all authorized peers of that device. The following data 885 elements MUST be embedded in a DIM message: 887 o DH public number (used for key computation) 889 o Nonce (used for key computation and SPI generation) 891 o Peer identity (used to identify a peer in the PAD) 893 o An Indication whether this is the initial distributed policy 895 o A rekey counter, which increases for each unique DIM sent 896 In cases where a single fixed IPsec policy has been pre-distributed, 897 it is not necessary for the peer to send or receive that policy in a 898 DIM. However, in cases where an IPsec device needs to indicate the 899 policy it is willing to use, the following data elements SHOULD be 900 included in a DIM: 902 o An IPsec policy or policies 904 o A lifetime bounding the use of the DH public number. When this DH 905 public number is used to create an IPsec SA, the shortest lifetime 906 is used as an SA lifetime for the pair of generated IPsec SAs. 907 When the lifetime expires, the local version of the DIM and IPsec 908 SAs generated from it MUST be deleted. 910 Appendix A suggests different ways that this policy may be included 911 in a controller protocol. This document does not define a normative 912 protocol format, because the DIM very likely needs to be integrated 913 into an existing controller protocol rather than be an independent 914 key management protocol. However, the controller protocol MUST 915 provide a strong authentication between the device and the 916 controller, and integrity of the messages MUST be provided. 917 Confidentiality of the messages SHOULD also be provided. It is 918 important that the controller protocol be protected with algorithms 919 that are at least as strong as the algorithms used to protect the 920 IPsec packets. 922 6.1. IPsec policy negotiation 924 In many controller based networks, there is a single IPsec policy 925 used by all devices and there is no need to redistribute or select 926 policy details. However, in some circumstances, there may be a need 927 to have multiple policy options. This could happen when a controller 928 changes the policy and wants to smoothly migrate all devices to the 929 new policy. Or it could happen if a network supports devices with 930 different capabilities. In these cases, devices need to be able to 931 choose the correct policy to use for each other device, and must do 932 this without sending additional messages and without sending 933 individual messages to each peer. When a device supports multiple 934 policies, it MUST include those policies within the DIM. This is 935 done by sending multiple distinct policies, in order of preference, 936 where the first policy is the most preferred. The policy to use is 937 selected by taking the receiver's list of policies (i.e., the list 938 advertised by the device that generates Nr), starting with the first 939 policy, compare against the initiator's (device that generates Ni) 940 list, and choosing the first one found in common. The method 941 conforms to the IKEv2 Cryptographic Algorithm Negotiation described 942 in Section 2.7 of [RFC7296]. (However, see additional discussion 943 when IKEv2 payloads are used in Appendix A.3.1). 945 If there is no match, this indicates a controller configuration 946 error. These devices MUST NOT establish new SAs until a DIM is 947 received that does produce a match. 949 When a device supports more than one DH group, then a unique DH 950 public number MUST be specified for each in order of preference. The 951 selection of which DH group to use follows the same logic as Policy 952 selection, using the receiver's list order until a match is found in 953 the initiator's list. 955 7. BGP Component 957 The architecture that encompasses device-to-controller trust model, 958 has several components among which is the signaling component. 959 Secure EVPN Signaling, as defined in this document, is the BGP 960 signaling component of the overall Architecture. We will briefly 961 describe this Architecture here to further facilitate understanding 962 how Secure EVPN fits into the overall architecture. The Architecture 963 describes the components needed to create BGP based SD-WANs and how 964 these components work together. Our intention is to list these 965 components here along with their brief description and to describe 966 this Architecture in details in a separate document where to specify 967 the details for other parts of this architecture besides the BGP 968 signaling component which is described in this document. 970 The Architecture consists of four components. These components are 971 Zero Touch Bring-up, Configuration Management, Orchestration, and 972 Signaling. In addition to these components, secure communications 973 must be provided between the edge nodes and all servers/devices 974 providing the architecture components. 976 7.1. Zero Touch Bring-up (ZTB) 978 The first component is a zero touch capability that allows an edge 979 device to find and join its SD-WAN with little to no assistance other 980 than power and network connectivity. The goal is to use existing 981 work in this area. The requirements are that an edge device can 982 locate its ZTB server/component of its SD-WAN controller in a secure 983 manner and to proceed to receive its configuration. 985 7.2. Configuration Management 987 After an edge device joins its SD-WAN, it needs to be configured. 988 Configuration covers all device configuration, not just the 989 configuration related to Secure EVPN. The previous Zero Touch Bring- 990 up component will have directed the edge device, either directly or 991 indirectly, to its configuration server/component. One example of a 992 configuration server is the I2NSF Controller. After a device has 993 been configured, it can engage in the next two components. 994 Configuration may include updates over time and is not a one time 995 only component. 997 7.3. Orchestration 999 This component is optional. It allows for more dynamic updates of 1000 configuration and statistics information. Orchestration can be more 1001 dynamic than configuration. 1003 7.4. Signaling 1005 Signaling is the component described in this document. The 1006 functionality of a Route Reflector is well understood. Here we 1007 describe the signaling component of BGP SD-WAN Architecture and the 1008 BGP extension/signaling for IPsec key management and policy. 1010 8. Solution Description 1012 This solution uses BGP P2MP signaling where an originating PE only 1013 send a message to the Route Reflector (RR) and then the RR reflects 1014 that message to the interested recipient PEs. The framework for such 1015 signaling is described in section 4 and it is referred to as device- 1016 to-controller trust model. This trust model is significantly 1017 different than the traditional peer-to-peer trust model where a P2P 1018 signaling protocol such as IKEv2 [RFC7296] is used in which the PE 1019 devices directly authenticate each other and agree upon security 1020 policy and keying material to protect communications between 1021 themselves. The device-to-controller trust model leverages P2MP 1022 signaling via the controller (e.g., the RR) to achieve much better 1023 scale and performance for establishment and maintenance of large 1024 number of pair-wise Security Associations (SAs) among the PEs. 1026 This device-to-controller trust model first secures the control 1027 channel between each device and the controller using peer-to-peer 1028 protocol such as IKEv2 [RFC7296] to establish P2P SAs between each PE 1029 and the RR. It then uses this secured control channel for P2MP 1030 signaling in establishment of P2P SAs between each pair of PE 1031 devices. 1033 Each PE advertises to other PEs via the RR the information needed in 1034 establishment of pair-wise SAs between itself an every other remote 1035 PEs. These pieces of information are sent as Sub-TLVs of IPSec 1036 tunnel type in BGP Tunnel Encapsulation attribute. These Sub-TLVs 1037 are detailed in section 10 and are based on the DIM message 1038 components in section 5 and the IKEv2 specification [RFC7296]. The 1039 IPsec tunnel TLVs along with its Sub-TLVs are sent along with the BGP 1040 route (NLRI) for a given level of granularity. 1042 If only a single SA is required per pair of PE devices to multiplex 1043 user traffic for all tenants, then IPsec tunnel TLV is advertised 1044 along with IPv4 or IPv6 NLRI representing loopback address of the 1045 originating PE. It should be noted that this is not a VPN route but 1046 rather an IPv4 or IPv6 route. 1048 If a SA is required per tenant between a pair of PE devices, then 1049 IPsec tunnel TLV can be advertised along with EVPN IMET route 1050 representing the tenant or can be advertised along with a new EVPN 1051 route representing the tenant. 1053 If a SA is required per tenant's subnet (e.g., per VLAN) between a 1054 pair of PE devices, then IPsec tunnel TLV is advertised along with 1055 EVPN IMET route. 1057 If a SA is required between a pair of tenant's devices represented by 1058 a pair of IP addresses, then IPsec tunnel TLV is advertised along 1059 with EVPN IP Prefix Advertisement Route or EVPN MAC/IP Advertisement 1060 route. 1062 If a SA is required between a pair of tenant's devices represented by 1063 a pair of MAC addresses, then IPsec tunnel TLV is advertised along 1064 with EVPN MAC/IP Advertisement route. 1066 If a SA is required between a pair of Attachment Circuits (ACs) on 1067 two PE devices (where an AC can be represented by {VLAN, port}), then 1068 IPsec tunnel TLV is advertised along with EVPN Ethernet AD route. 1070 8.1. Inheritance of Security Policies 1072 Operationally, it is easy to configure a security association between 1073 a pair of PEs using BGP signaling. This is the default security 1074 association that is used for traffic that flows between peers. 1075 However, in the event more finer granularity of security association 1076 is desired on the traffic flows, it is possible to set up SAs between 1077 a pair of tenants, a pair of subnets within a tenant, a pair of IPs 1078 between a subnet, and a pair of MACs between a subnet using the 1079 appropriate EVPN routes as described above. In the event, there are 1080 no security TLVs associated with an EVPN route, there is a strict 1081 order in the manner security associations are inherited for such a 1082 route. This results in an EVPN route inheriting the security 1083 associations of the parent in a hierarchical fashion. For example, 1084 traffic between an IP pair is protected using security TLVs announced 1085 along with the EVPN IP Prefix Advertisement Route or EVPN MAC/IP 1086 Advertisement route as a first choice. If such TLVs are missing with 1087 the associated route, then one checks to see if the subnets the IPs 1088 are associated with has security TLVs with the EVPN IMET route. If 1089 they are present, those associations are used in securing the 1090 traffic. In the absence of them, the peer security associations are 1091 used. The order in which security associations are inherited are 1092 from the granular to the coarser, namely, IP/MAC associated TLVs with 1093 the EVPN route being the first preference, and the subnet, the 1094 tenant, and the peer associations preferred in that fashion. 1096 It should be noted that when a security association is made it is 1097 possible for it to be re-used by a large number of traffic flows. 1098 For example, a tenant security association may be associated with a 1099 number of child subnet routes. Clearly it is mandatory to keep a 1100 tenant security association alive, if there are one or more subnet 1101 routes that want to use that association. Logically, the security 1102 associations between a pair of entities creates a single secure 1103 tunnel. It is thus possible to classify the incoming traffic in the 1104 most granular sense {IP/MAC, subnet, tenant, peer} to a particular 1105 secure tunnel that falls within its route hierarchy. The policy that 1106 is applied to such traffic is independent from its use of an existing 1107 or a new secure tunnel. It is clear that since any number of 1108 classified traffic flows can use a security association, such a 1109 security association will not be torn down, if at least there is one 1110 policy using such a secure tunnel. 1112 8.2. Distribution of Public Keys and Policies 1114 One of the requirements for this solution is to support a single DH 1115 group and a single policy for all SAs as well as to support multiple 1116 DH groups and policies among the SAs. The following subsections 1117 describe what pieces of information (what Sub-TLVs) are needed to be 1118 exchanged to support a single DH group and a single policy versus 1119 multiple DH groups and multiple policies. 1121 8.2.1. Minimal DIM 1123 For SA establishment, at the minimum, a PE needs to advertise to 1124 other PEs, its DIM values as specified in section 5. These include: 1126 ID Tunnel ID 1127 N Nonce 1128 RC Rekey Counter 1129 I Indication of initial policy distribution 1130 KE DH public value. 1132 When this minimal set of DIM values is sent, then it is assumed that 1133 all peer PEs share the same policy for which DH group to use, as well 1134 as which IPSec SA policy to employ. Section 5.1 defines the Minimal 1135 DIM sub-TLV as part of IPsec tunnel TLV in BGP Tunnel Encapsulation 1136 Attribute. 1138 8.2.2. Multiple Policies 1140 There can be scenarios for which there is a need to have multiple 1141 policy options. This can happen when there is a need for policy 1142 change and smooth migration among all PE devices to the new policy is 1143 required. It can also happen if different PE devices have different 1144 capabilities within the network. In these scenarios, PE devices need 1145 to be able to choose the correct policy to use for each other. This 1146 multi-policy scheme is described in section 6. In order to support 1147 this multi-policy feature, a PE device MUST distribute a policy list. 1148 This list consists of multiple distinct policies in order of 1149 preference, where the first policy is the most preferred one. The 1150 receiving PE selects the policy by taking the received list (starting 1151 with the first policy) and comparing that against its own list and 1152 choosing the first one found in common. If there is no match, this 1153 indicates a configuration error and the PEs MUST NOT establish new 1154 SAs until a message is received that does produce a match. 1156 8.2.3. Multiple DH-groups 1158 It can be the case that not all peers use the same DH group. When 1159 multiple DH groups are supported, the peer may include multiple KE 1160 Sub-TLVs. The order of the KE Sub-TLVs determines the preference. 1161 The preference and selection methods are specified in section 6. 1163 8.2.4. Multiple or Single ESP SA policies 1165 In order to specify an ESP SA Policy, a DIM may include one or more 1166 SA Sub-TLVs. When all peers are configured by a controller with the 1167 same ESP SA policy, they MAY leave the SA out of the DIM. This 1168 minimizes messaging when group configuration is static and known. 1169 However, it may also be desirable to include the SA. If a single SA 1170 is included, the peer is indicating what ESP SA policy it uses, but 1171 is not willing to negotiate. If multiple SA Sub-TLVs are included, 1172 the peer is indicating that it is willing to negotiate. The order of 1173 the SA Sub-TLVs determines the preference. The preference and 1174 selection methods are specified in section 6. 1176 8.3. Initial IPsec SAs Generation 1178 The procedure for generation of initial IPsec SAs is described in 1179 section 4. This section gives a summary of it in context of BGP 1180 signaling. When a PE device first comes up and wants to setup an 1181 IPsec SA between itself and each of the interested remote PEs, it 1182 generates a DH pair along for each [what word here? "tennant"?] using 1183 an algorithm defined in the IKEv2 Diffie-Hellman Group Transform IDs 1184 [IKEv2-IANA]. The originating PE distributes the DH public value 1185 along with the other values in the DIM (using IPsec Tunnel TLV in 1186 Tunnel Encapsulation Attribute) to other remote PEs via the RR. Each 1187 receiving PE uses this DH public number and the corresponding nonce 1188 in creation of IPsec SA pair to the originating PE - i.e., an 1189 outbound SA and an inbound SA. The detail procedures are described 1190 in Section 4.1. 1192 8.4. Re-Keying 1194 A PE can initiate re-keying at any time due to local time or volume 1195 based policy or due to the result of cipher counter nearing its final 1196 value. The rekey process is performed individually for each remote 1197 PE. If rekeying is performed with multiple PEs simultaneously, then 1198 the decision process and rules described in this rekey are performed 1199 independently for each PE. Section 4.2 describes this rekeying 1200 process in details and gives examples for a single IPsec device 1201 (e.g., a single PE) rekey versus multiple PE devices rekey 1202 simultaneously. 1204 8.5. IPsec Databases 1206 The Peer Authorization Database (PAD), the Security Policy Database 1207 (SPD), and the Security Association Database (SAD) all need to be 1208 setup as defined in the IPsec Security Architecture RFC 4301 1209 [RFC4301]. Section 5 of this document gives a summary description of 1210 how these databases are setup where key is exchanged via P2MP 1211 signaling through the RR and the policy can be either signaled via 1212 the RR (in case of multiple policies) or configured by the management 1213 station (in case of single policy). 1215 9. Encapsulation 1217 Vast majority of Encapsulation for Network Virtualization Overlay 1218 (NVO) networks in deployment are based on UDP/IP with UDP destination 1219 port ID indicating the type of NVO encapsulation (e.g., VxLAN, GPE, 1220 GENEVE, GUE) and UDP source port ID representing flow entropy for 1221 load-balancing of the traffic within the fabric based on n-tuple that 1222 includes UDP header. When encrypting NVO encapsulated packets using 1223 IP Encapsulating Security Payload (ESP), the following two options 1224 can be used: a) adding a UDP header before ESP header (e.g., UDP 1225 header in clear) and b) no UDP header before ESP header (e.g., 1226 standard ESP encapsulation). The following subsection describe these 1227 encapsulation in further details. 1229 9.1. Standard ESP Encapsulation 1231 When standard IP Encapsulating Security Payload (ESP) is used 1232 (without outer UDP header) for encryption of NVO packets, it is used 1233 in transport mode as depicted below. When such encapsulation is 1234 used, for BGP signaling, the Tunnel Type of Tunnel Encapsulation TLV 1235 is set to ESP-Transport and the Tunnel Type of Encapsulation Extended 1236 Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE, 1237 etc.). This implies that the customer packets are first encapsulated 1238 using NVO encapsulation type and then it is further encapsulated and 1239 encrypted using ESP-Transport mode. 1241 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | MAC Header | | MAC Header | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Eth Type = IPv4/IPv6 | | Eth Type = IPv4/IPv6 | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | IP Header | | IP Header | 1247 | Protocol = UDP | | Protocol = UDP | 1248 +-----------------------+ +-----------------------+ 1249 | UDP Header | | UDP Header | 1250 | Dest Port = VxLAN | | Dest Port = 4500(ESP) | 1251 +-----------------------+ +-----------------------+ 1252 | VxLAN Header | | ESP Header | 1253 +-----------------------+ +-----------------------+ 1254 | Inner MAC Header | | UDP Header | 1255 +-----------------------+ | Dest Port = VxLAN | 1256 | Inner Eth Payload | +-----------------------+ 1257 +-----------------------+ | VxLAN Header | 1258 | CRC | +-----------------------+ 1259 +-----------------------+ | Inner MAC Header | 1260 +-----------------------+ 1261 | Inner Eth Payload | 1262 +-----------------------+ 1263 | ESP Trailer (NP=UDP) | 1264 +-----------------------+ 1265 | CRC | 1266 +-----------------------+ 1268 Figure 4 1270 9.2. ESP Encapsulation within UDP packet 1272 In scenarios where NAT traversal is required (RFC 3948 [RFC3948]) or 1273 where load balancing using UDP header is required, then ESP 1274 encapsulation within UDP packet as depicted in the following figure 1275 is used. The ESP for NVO applications is in transport mode. The 1276 outer UDP header (before the ESP header) has its source port set to 1277 flow entropy and its destination port set to 4500 (indicating ESP 1278 header follows). A non-zero SPI value in ESP header implies that 1279 this is a data packet (i.e., it is not an IKE packet). The Next 1280 Protocol field in the ESP trailer indicates what follows the ESP 1281 header, is a UDP header. This inner UDP header has a destination 1282 port ID that identifies NVO encapsulation type (e.g., VxLAN). 1283 Optimization of this packet format where only a single UDP header is 1284 used (only the outer UDP header) is for future study. 1286 When such encapsulation is used, for BGP signaling, the Tunnel Type 1287 of Tunnel Encapsulation TLV is set to ESP-in-UDP-Transport and the 1288 Tunnel Type of Encapsulation Extended Community is set to NVO 1289 encapsulation type (e.g., VxLAN, GENEVE, GPE, etc.). This implies 1290 that the customer packets are first encapsulated using NVO 1291 encapsulation type and then it is further encapsulated and encrypted 1292 using ESP-in-UDP with Transport mode. 1294 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | MAC Header | | MAC Header | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Eth Type = IPv4/IPv6 | | Eth Type = IPv4/IPv6 | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | IP Header | | IP Header | 1300 | Protocol = UDP | | Protocol = UDP | 1301 +-----------------------+ +-----------------------+ 1302 | UDP Header | | UDP Header | 1303 | Dest Port = VxLAN | | Dest Port = 4500(ESP) | 1304 +-----------------------+ +-----------------------+ 1305 | VxLAN Header | | ESP Header | 1306 +-----------------------+ +-----------------------+ 1307 | Inner MAC Header | | UDP Header | 1308 +-----------------------+ | Dest Port = VxLAN | 1309 | Inner Eth Payload | +-----------------------+ 1310 +-----------------------+ | VxLAN Header | 1311 | CRC | +-----------------------+ 1312 +-----------------------+ | Inner MAC Header | 1313 +-----------------------+ 1314 | Inner Eth Payload | 1315 +-----------------------+ 1316 | ESP Trailer (NP=UDP) | 1317 +-----------------------+ 1318 | CRC | 1319 +-----------------------+ 1321 Figure 5 1323 10. BGP Encoding 1325 This document defines two new Tunnel Types along with its associated 1326 sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP]. 1327 These tunnel types correspond to ESP-Transport and ESP-in-UDP- 1328 Transport as described in section 4. The following sub-TLVs apply to 1329 both tunnel types unless stated otherwise. 1331 10.1. The Base (Minimal Set) DIM Sub-TLV 1333 The Base DIM is described in 3.2.1. One and only one Base DIM may be 1334 sent in the IPSec Tunnel TLV. 1336 0 1 2 3 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | ID Length | Nonce Length |I| Flags | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Rekey | 1342 | Counter | 1343 +---------------------------------------------------------------+ 1344 | | 1345 ~ Originator ID + (Tenant ID) + (Subnet ID) + (Tenant Address) ~ 1346 | | 1347 +---------------------------------------------------------------+ 1348 | | 1349 ~ Nonce Data ~ 1350 | | 1351 +---------------------------------------------------------------+ 1353 Figure 6 1355 ID Length (16 bits) is the length of the Originator ID + (Tenant ID) 1356 + (Subnet ID) + (Tenant Address) in bytes. Nonce Length (8 bits) is 1357 the length of the Nonce Data in bytes I (1 bit) is the initial 1358 contact flag Flags (7 bits) are reserved and MUST be set to zero on 1359 transmit and ignored on receipt. The Rekey Counter is a 64 bit rekey 1360 counter The Originator ID + (Tenant ID) + (Subnet ID) + (Tenant 1361 Address) is the tunnel identifier and uniquely identifies the tunnel. 1362 Depending on the granularity of the tunnel, the fields in () may not 1363 be used - i.e., for a tunnel at the PE level of granularity, only 1364 Originator ID is required. The Nonce Data is the nonce. Its length 1365 is a multiple of 32 bits. Nonce lengths should be chosen to meet 1366 minimum requirements described in IKEv2 [RFC7296]. 1368 10.2. The Key Exchange Sub-TLV 1370 The KE Sub-TLV is described in 3.2.1 and 3.2.2.1. A KE is always 1371 required. One or more KE Sub-TLVs may be included in the IPSec 1372 Tunnel TLV. 1374 0 1 2 3 1375 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 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Diffie-Hellman Group Num | Reserved | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | | 1380 ~ Key Exchange Data ~ 1381 | | 1382 +---------------------------------------------------------------+ 1384 Figure 7 1386 Diffie-Hellman Group Num 916 bits) identifies the Diffie-Hellman 1387 group in the Key Exchange Data was computed. Diffie-Hellman group 1388 numbers are discussed in IKEv2 [RFC7296] Appendix B and [RFC5114]. 1390 The Key Exchange payload is constructed by copying one's Diffie- 1391 Hellman public value into the "Key Exchange Data" portion of the 1392 payload. The length of the Diffie-Hellman public value is described 1393 for MOPD groups in [RFC7296] and for ECP groups in [RFC4753]. 1395 10.3. ESP SA Proposals Sub-TLV 1397 The SA Sub-TLV is described in 3.2.2.2. Zero or more SA Sub-TLVs may 1398 be included in the IPSec Tunnel TLV. 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 ||Num Transforms| Reserved | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | | 1406 ~ Transforms ~ 1407 | | 1408 +---------------------------------------------------------------+ 1410 Figure 8 1412 Num Transforms is the number of transforms included. Reserved is not 1413 used and MUST be set to zero on transmit and MUST be ignored on 1414 receipt. 1416 10.3.1. Transform Substructure 1417 0 1 2 3 1418 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 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Transform Attr Length |Transform Type | Reserved. | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Transform ID | Reserved | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | | 1425 ~ Transform Attributes ~ 1426 | | 1427 +---------------------------------------------------------------+ 1429 Figure 9 1431 The Transform Attr Length is the length of the Transform Attributes 1432 field. The Transform Type is from Section 3.3.2 of [RFC7296] and 1433 [IKEV2IANA]. Only the values ENCR, INTEG, and ESN are allowed. The 1434 Transform ID specifies the transform identification value from 1435 [IKEV2IANA]. Reserved is unused and MUST be zero on transmit and 1436 MUST be ignored on receipt. The Transform Attributes are taken 1437 directly from 3.3.5 of [RFC7296]. 1439 11. Applicability 1441 Although P2MP BGP signaling for establishment and maintenance of SAs 1442 among PE devices is described in this document in context of EVPN, 1443 there is no reason why it cannot be extended to other VPN 1444 technologies such as IP-VPN RFC 4364 [RFC4364], VPLS RFC 4761 1445 [RFC4761] and RFC 4762 [RFC4762], and MVPN RFC 6513 [RFC6513] and RFC 1446 6514 [RFC6514] with ingress replication. The reason EVPN has been 1447 chosen is because of its pervasiveness in DC, SP, and Enterprise 1448 applications and because of its ability to support SA establishment 1449 at different granularity levels such as: per PE, Per tenant, per 1450 subnet, per Ethernet Segment, per IP address, and per MAC. For other 1451 VPN technology types, a much smaller granularity levels can be 1452 supported. For example for VPLS, only the granularity of per PE and 1453 per subnet can be supported. For per-PE granularity level, the 1454 mechanism is the same among all the VPN technologies as IPsec tunnel 1455 type (and its associated TLV and sub-TLVs) are sent along with the 1456 PE's loopback IPv4 (or IPv6) address. For VPLS, if per-subnet (per 1457 bridge domain) granularity level needs to be supported, then the 1458 IPsec tunnel type and TLV are sent along with VPLS AD route. 1460 The following table lists what level of granularity can be supported 1461 by a given VPN technology and with what BGP route. 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Functionality | EVPN | IP-VPN | MVPN | VPLS | 1465 +---------------+-------------+-------------+-----------+---------+ 1466 | per PE |IPv4/v6 route|IPv4/v6 route|IPv4/v6 rte|IPv4/v6 | 1467 +---------------+-------------+-------------+-----------+---------+ 1468 | per tenant |IMET (or new)|lpbk (or new)| I-PMSI | N/A | 1469 +---------------+-------------+-------------+-----------+---------+ 1470 | per subnet | IMET | N/A | N/A | VPLS AD | 1471 +---------------+-------------+-------------+-----------+---------+ 1472 | per IP |EVPN RT2/RT5 | VPN IP rt | *,G or S,G| N/A | 1473 +---------------+-------------+-------------+-----------+---------+ 1474 | per MAC | EVPN RT2 | N/A | N/A | N/A | 1475 +---------------+-------------+-------------+-----------+---------+ 1477 Figure 10 1479 12. Acknowledgements 1481 TBD. 1483 13. IANA Considerations 1485 A new transitive extended community Type of 0x06 and Sub-Type of TBD 1486 for EVPN Attachment Circuit Extended Community needs to be allocated 1487 by IANA. 1489 14. Security Considerations 1491 This document proposes that a device re-use an ephemeral Diffie- 1492 Hellman exponential with multiple peers. There are some known 1493 potential vulnerabilities to this approach, which can be mitigated by 1494 the device first validating a peer's public value to be a safe public 1495 value before combining its own private value with it. The tests 1496 which MUST be performed are described in [RFC6989]. See [REUSE] for 1497 additional security considerations when reusing ephemeral Diffie- 1498 Hellman keys. 1500 A controller acts as a "trusted third party", which asserts that a 1501 particular Diffie-Hellman public value is associated with a 1502 particular entity. A device receiving the public key is not required 1503 to validate the assertion. 1505 A subverted controller can act as a "man-in-the-middle" between a 1506 pair of devices. The easiest attack would be for the attacker to 1507 adjust the routing for the desired traffic through a compromised 1508 gateway and directly observe the cleartext. It is also possible that 1509 a subverted controller could provide a device with a Diffie-Hellman 1510 public value that actually belongs to a compromised gateway rather 1511 than the intended gateway, but doing so does not seem to be 1512 necessary. Nonetheless, the attack of a subverted controller can be 1513 mitigated by having a device sign its Diffie-Hellman public value 1514 (e.g, as a CMS Signed data object), where the receiver validates the 1515 digital signature on the object. However, this adds significant 1516 processing cost to a rekey and does not fit the controller-based 1517 network architecture model. 1519 A subverted IPsec device whose DH pair has been compromised would be 1520 vulnerable to all of its IPsec traffic using that DH pair being 1521 compromised. Assuming the use of strong DH algorithms (including 1522 quantum resistant algorithms as they become available), the 1523 compromise would most likely be due to the device itself being 1524 compromised. Such a compromised device is also vulnerable to a 1525 direct plaintext compromise. 1527 PFS is achieved between rekey periods, as DH pairs are required to be 1528 generated independently. However, because a device uses the same 1529 long-term key to generate session key with multiple peers, there is 1530 no PFS between sessions within the same rekey period. To reduce key 1531 exposure outside of a rekey period, when a connection is closed each 1532 endpoint MUST forget not only the keys used by the connection but 1533 also any information that could be used to recompute those keys. 1534 However, the DH private key value and the nonce distributed with it 1535 may be forgotten only once the last IPsec SA that uses the private 1536 key value is removed from the SAD and there is no chance that a new 1537 IPsec SA could be setup that requires the private key value. 1539 If quantum resistance is considered to be an issue, the controller 1540 can distribute a PSK, which could be used to create the SK_d in the 1541 manner shown in [I-D.ietf-ipsecme-qr-ikev2]. 1543 15. References 1545 15.1. Normative References 1547 [GENEVE] Gross, J., et al., "Geneve: Generic Network Virtualization 1548 Encapsulation", 2018, 1549 . 1551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1552 Requirement Levels", BCP 14, RFC 2119, 1553 DOI 10.17487/RFC2119, March 1997, 1554 . 1556 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1557 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1558 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1559 . 1561 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1562 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1563 December 2005, . 1565 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1566 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1567 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1568 2015, . 1570 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1571 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1572 May 2017, . 1574 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 1575 Uttaro, J., and W. Henderickx, "A Network Virtualization 1576 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 1577 DOI 10.17487/RFC8365, March 2018, 1578 . 1580 15.2. Informative References 1582 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1583 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1584 2006, . 1586 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1587 LAN Service (VPLS) Using BGP for Auto-Discovery and 1588 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1589 . 1591 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1592 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1593 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1594 . 1596 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1597 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1598 2012, . 1600 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1601 Encodings and Procedures for Multicast in MPLS/BGP IP 1602 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1603 . 1605 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1606 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1607 eXtensible Local Area Network (VXLAN): A Framework for 1608 Overlaying Virtualized Layer 2 Networks over Layer 3 1609 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1610 . 1612 Appendix A. Additional Stuff 1614 TBD. 1616 Authors' Addresses 1618 Ali Sajassi (editor) 1619 Cisco 1620 170 W Tasman Drive 1621 San Jose, CA 1622 USA 1624 Email: sajassi@cisco.com 1626 Ayan Banerjee 1627 Cisco 1628 170 W Tasman Drive 1629 San Jose, CA 1630 USA 1632 Email: ayabaner@cisco.com 1634 Sameer Thoria 1635 Cisco 1636 170 W Tasman Drive 1637 San Jose, CA 1638 USA 1640 Email: sthoria@cisco.com 1642 David Carrel 1643 Graphiant 1644 CA 1645 USA 1647 Email: carrel@graphiant.com 1648 Brian Weis 1649 Independent 1650 CA 1651 USA 1653 Email: bew.stds@gmail.com 1655 John Drake 1656 Juniper Networks 1657 CA 1658 USA 1660 Email: jdrake@juniper.net