idnits 2.17.1 draft-dunbar-idr-sdwan-edge-discovery-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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 17 characters in excess of 72. == There are 23 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 7, 2021) is 1145 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SDWAN-BGP-USAGE' is mentioned on line 233, but not defined == Missing Reference: 'Tunnel-encap' is mentioned on line 304, but not defined == Missing Reference: 'SDN-IPsec' is mentioned on line 349, but not defined == Missing Reference: 'RFC4760' is mentioned on line 497, but not defined == Missing Reference: 'SECURE-VPN' is mentioned on line 836, but not defined == Unused Reference: 'RFC2119' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 1016, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: 'CONTROLLER-IKE' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'LISP-GEOLOC' is defined on line 1027, but no explicit reference was found in the text == Unused Reference: 'SDN-IPSEC' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 1039, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-Problem' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 1059, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-geo-09 == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 == Outdated reference: A later version (-06) exists of draft-sajassi-bess-secure-evpn-02 == Outdated reference: A later version (-01) exists of draft-rosen-bess-secure-l3vpn-00 == Outdated reference: A later version (-07) exists of draft-dm-net2cloud-problem-statement-02 == Outdated reference: A later version (-04) exists of draft-dm-net2cloud-gap-analysis-02 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-10 Summary: 1 error (**), 0 flaws (~~), 27 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft Futurewei 3 Intended status: Standard S. Hares 4 Expires: September 5, 2021 Hickory Hill Consulting 5 R. Raszuk 6 Bloomberg LP 7 K. Majumdar 8 CommScope 9 March 7, 2021 11 BGP UPDATE for SDWAN Edge Discovery 12 draft-dunbar-idr-sdwan-edge-discovery-04 14 Abstract 16 The document describes the encoding of BGP UPDATE messages for the 17 SDWAN edge node discovery. 19 In the context of this document, BGP Route Reflectors (RR) is the 20 component of the SDWAN Controller that receives the BGP UPDATE from 21 SDWAN edges and in turns propagates the information to the intended 22 peers that are authorized to communicate via the SDWAN overlay 23 network. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on Dec 5, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction...................................................3 65 2. Conventions used in this document..............................3 66 3. Framework of SDWAN Edge Discovery..............................4 67 3.1. The Objectives of SDWAN Edge Discovery....................4 68 3.2. Comparing with Pure IPsec VPN.............................5 69 3.3. Client Route UPDATE and Hybrid Underlay Tunnel UPDATE.....6 70 3.4. Edge Node Discovery.......................................8 71 4. BGP UPDATE to Support SDWAN Segmentation.......................9 72 4.1. SDWAN Segmentation, SDWAN Virtual Topology and Client VPN.9 73 4.2. Constrained Propagation of Edge Capability...............10 74 5. Client Route UPDATE...........................................11 75 5.1. SDWAN VPN ID in Client Route Update......................12 76 5.2. SDWAN VPN ID in Data Plane...............................12 77 6. Hybrid Underlay Tunnel UPDATE.................................12 78 6.1. NLRI for Hybrid Underlay Tunnel Update...................12 79 6.2. SDWAN-Hybrid Tunnel Encoding.............................13 80 6.3. IPsec-SA-ID Sub-TLV......................................14 81 6.3.1. Encoding example #1 of using IPsec-SA-ID Sub-TLV....14 82 6.3.2. Encoding Example #2 of using IPsec-SA-ID Sub-TLV....16 83 6.4. Extended Port Sub-TLV....................................16 84 6.5. ISP of the Underlay network Sub-TLV......................19 85 7. IPsec SA Property Sub-TLVs....................................20 86 7.1. IPsec SA Nonce Sub-TLV...................................20 87 7.2. IPsec Public Key Sub-TLV.................................21 88 7.3. IPsec SA Proposal Sub-TLV................................22 89 7.4. Simplified IPsec Security Association sub-TLV............22 90 7.5. IPsec SA Encoding Examples...............................23 91 8. Error & Mismatch Handling.....................................24 92 9. Manageability Considerations..................................25 93 10. Security Considerations......................................26 94 11. IANA Considerations..........................................26 95 12. References...................................................26 96 12.1. Normative References....................................26 97 12.2. Informative References..................................26 98 13. Acknowledgments..............................................28 100 1. Introduction 102 [SDWAN-BGP-USAGE] illustrates how BGP is used as control plane for a 103 SDWAN network. SDWAN network refers to a policy-driven network over 104 multiple different underlay networks to get better WAN bandwidth 105 management, visibility, and control. 107 The document describes a BGP UPDATE for SDWAN edge nodes to announce 108 its properties to its RR which then propagates to the authorized 109 peers. 111 2. Conventions used in this document 113 Cloud DC: Off-Premise Data Centers that usually host applications 114 and workload owned by different organizations or 115 tenants. 117 Controller: Used interchangeably with SDWAN controller to manage 118 SDWAN overlay path creation/deletion and monitor the 119 path conditions between sites. 121 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 122 This is to differentiate from most commonly used PE- 123 based VPNs a la RFC 4364. 125 MP-NLRI: The MP_REACH_NLRI Path Attribute defined in RFC4760. 127 SDWAN End-point: can be the SDWAN edge node address, a WAN port 128 address (logical or physical) of a SDWAN edge node, or a 129 client port address. 131 OnPrem: On Premises data centers and branch offices 133 SDWAN: Software Defined Wide Area Network. In this document, 134 "SDWAN" refers to policy-driven transporting IP packets 135 over multiple different underlay networks to get better 136 WAN bandwidth management, visibility and control. 138 SDWAN Segmentation: Segmentation is the process of dividing the 139 network into logical sub-networks. 141 SDWAN VPN: referring to Client's VPN, which is like the VRF on the 142 PEs of a MPLS VPN. One SDWAN client VPN can be mapped 143 one or multiple SD-WAN virtual topologies. How Client 144 VPN is mapped to a SDWAN virtual topology is governed by 145 policies. 147 SDWAN Virtual Topology: Since SDWAN can connect any nodes, whereas 148 MPLS VPN connects a fixed number of PEs, one SDWAN 149 Virtual Topology refers to a set of edge nodes and the 150 tunnels (including both IPsec tunnels and/or MPLS 151 tunnels) interconnecting those edge nodes. 153 3. Framework of SDWAN Edge Discovery 155 3.1. The Objectives of SDWAN Edge Discovery 157 The objectives of SDWAN edge discovery is for a SDWAN edge node to 158 discover its authorized peers and their associated properties for 159 its attached clients traffic to communicate. The attributes to be 160 propagated includes the SDWAN (client) VPNs supported, the attached 161 routes under specific SDWAN VPNs, and the properties of the underlay 162 networks over which the client routes can be carried. 164 Some SDWAN peers are connected by both trusted VPNs and untrusted 165 public networks. Some SDWAN peers are connected only by untrusted 166 public networks. For the portion over untrusted networks, IPsec 167 Security Associations (IPsec SA) have to be established and 168 maintained. If an edge node has network ports behind the NAT, the 169 NAT properties needs to be discovered by authorized SDWAN peers. 171 Just like any VPN networks, the attached client's routes belonging 172 to specific SDWAN VPNs can only be exchanged to the SDWAN peer nodes 173 that are authorized to communicate. 175 3.2. Comparing with Pure IPsec VPN 177 Pure IPsec VPN has IPsec tunnels connecting all edge nodes via 178 public internet, therefore requires stringent authentication and 179 authorization (i.e. IKE Phase 1) before other properties of IPsec SA 180 can be exchanged. The IPsec Security Association (SA) between two 181 untrusted nodes typically requires the following configurations and 182 message exchanges: 184 - IPsec IKE to authenticate with each other 185 - Establish IPsec SA 186 o Local key configuration 187 o Remote Peer address (192.10.0.10<->172.0.01) 188 o IKEv2 Proposal directly sent to peer 189 o Encryption method, Integrity sha512 190 o Transform set 191 - Attached client prefixes discovery 192 o By running routing protocol within each IPsec SA 193 o If multiple IPsec SAs between two peer nodes are 194 established to achieve load sharing, each IPsec tunnel 195 needs to run its own routing protocol to exchange client 196 routes attached to the edges. 197 - Access List or Traffic Selector) 198 o Permit Local-IP1, Remote-IP2 200 In a BGP controlled SDWAN network, e.g. a MPLS based network adding 201 short-term capacity over Internet using IPsec, there are secure 202 connection between edge nodes and RR, via private path, TLS, DTLS, 203 etc. The authentication of peer nodes is managed by the RR. More 204 importantly, when an edge node needs to establish multiple IPsec 205 tunnels to many different edge nodes, all the management information 206 can be multiplexed into the secure management tunnel between RR and 207 the edge node. Therefore, there is reduced amount of authentication 208 in a BGP Controlled SDWAN network. 210 Client VPNs are configured via VRFs, just like the configuration of 211 the existing MPLS VPN. The IPsec equivalent traffic selectors for 212 local and remote routes is achieved by importing/exporting VPN Route 213 Targets. The binding of client routes to IPsec SA is dictated by 214 policies. As the result, the IPsec configuration for a BGP 215 controlled SDWAN (with mixed MPLS VPN) can be simplified as the 216 following: 218 - SDWAN controller has authority to authenticate edges and 219 peers. Remote Peer association is controlled by the SDWAN 220 Controller (RR) 221 - The IKEv2 proposals including the IPsec Transform set can be 222 sent directly to Peer or incorporated with BGP UPDATE. 223 - BGP UPDATE: Announce the client route reachability for all 224 permitted parallel tunnels/paths. 225 o No need to run multiple routing protocols in each IPsec 226 tunnel. 227 - using importing/exporting Route Targets under each client VPN 228 (VRF) to achieve the traffic selection (or permission) among 229 clients' routes attached to multiple edge nodes. 231 3.3. Client Route UPDATE and Hybrid Underlay Tunnel UPDATE 233 As described in [SDWAN-BGP-USAGE], two separate BGP UPDATE messages 234 are used for SDWAN Edge Discovery: 236 - UPDATE U1 for advertising the attached client routes, 237 This UPDATE is exactly the same as the BGP edge client route 238 UDPDATE. It uses the Encapsulation Extended Community and the 239 Color Extended Community to link with the Underlay Tunnels 240 UPDATE Message as specified by the section 8 of [Tunnel-Encap]. 242 A new Tunnel Type (SDWAN-Hybrid) needs to be added, to be used 243 by Encapsulation Extended Community or the Tunnel-Encap Path 244 Attribute [Tunnel-encap] to indicate mixed underlay networks. 246 - UPDATE U2 advertises the properties of the various tunnels, 247 including IPsec, terminated at the edge node. 248 This UPDATE is for an edge node to advertise the properties of 249 directly attached underlay networks, including the NAT 250 information, pre-configured IPsec SA identifiers, and/or the 251 underlay network ISP information. This UPDATE can also include 252 the detailed IPsec SA attributes, such as keys, nonce, 253 encryption algorithms, etc. 255 In the following figure: there are four types underlay paths between 256 C-PE1 and C-PE2: 258 a) MPLS-in-GRE path. 260 b) node-based IPsec tunnel [2.2.2.2<->1.1.1.1]. 262 c) port-based IPsec tunnel [192.0.0.1 <-> 192.10.0.10]; and 264 d) port-based IPsec tunnel [172.0.0.1 <-> 160.0.0.1]. 266 +---+ 267 +--------------|RR |----------+ 268 / Untrusted +-+-+ \ 269 / \ 270 / \ 271 +---------+ MPLS Path +-------+ 272 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 273 | | | | 274 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 275 | | | | 276 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr | 277 | 1.1.1.1 | |2.2.2.2| 278 +---------+ +-------+ 280 Figure 1: Hybrid SDWAN 282 C-PE2 uses UPDATE U1 to advertise the attached client routes: 284 UDPATE U1: 286 Extended community: RT for SDWAN VPN 1 287 NLRI: AFI=? & SAFI = 1/1 288 Prefix: 10.1.1.x; 20.1.1.x 289 NextHop: 2.2.2.2 (C-PE2) 290 Encapsulation Extended Community: tunnel-type=SDWAN-Hybrid 291 Color Extended Community: RED 293 The UPDATE U1 is recursively resolved to the UPDATE U2 which 294 specifies the detailed hybrid WAN underlay Tunnels terminated at the 295 C-PE2: 297 UPDATE U2: 299 NLRI: SAFI = SDWAN-Hybrid 300 (With Color RED encoded in the NLRI Site-Property field) 301 Prefix: 2.2.2.2 302 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] 303 IPSec SA for 192.0.0.1 304 Tunnel-End-Point Sub-TLV for 192.0.0.1 [Tunnel-encap] 305 IPsec-SA-ID sub-TLV [See the Section 6] 306 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] 307 IPSec SA for 308 Tunnel-End-Point Sub-TLV /* for 170.0.0.1 */ 309 IPsec-SA-ID sub-TLV 310 Tunnel Encap Attr MPLS-in-GRE [type=SDWAN-Hybrid] 311 Sub-TLV for MPLS-in-GRE [Section 3.2.6 of Tunnel-encap] 313 Note: [Tunnel-Encap] Section 11 specifies that each Tunnel Encap 314 Attribute can only have one Tunnel-End-Point sub-TLV. Therefore, two 315 separate Tunnel Encap Attributes are needed to indicate that the 316 client routes can be carried by either one. 318 3.4. Edge Node Discovery 320 The basic scheme of SDWAN Edge node discovery using BGP consists of: 322 - Secure connection to a SDWAN controller (i.e. RR in this 323 context): 324 For a SDWAN edge with both MPLS and IPsec path, the edge node 325 should already have secure connection to its controller, i.e. 326 RR in this context. For a remote SDWAN edge that is only 327 accessible via Internet, the SDWAN edge node, upon power up, 328 establishes a secure tunnel (such as TLS, SSL) with the SDWAN 329 central controller whose address is preconfigured on the edge 330 node. The central controller will inform the edge node of its 331 local RR. The edge node will establish a transport layer secure 332 session with the RR (such as TLS, SSL). 334 - The Edge node will advertise its own properties to its 335 designated RR via the secure connection. 337 - The RR propagates the received information to the authorized 338 peers. 340 - The authorized peers can establish the secure data channels 341 (IPsec) and exchange more information among each other. 342 For a SDWAN deployment with multiple RRs, it is assumed that there 343 are secure connections among those RRs. How secure connections being 344 established among those RRs is the out of the scope of the current 345 draft. The existing BGP UPDATE propagation mechanisms control the 346 edge properties propagation among the RRs. 348 For some special environment where the communication to RR are 349 highly secured, [SDN-IPsec] IKE-less can be deployed to simplify 350 IPsec SA establishment among edge nodes. 352 4. BGP UPDATE to Support SDWAN Segmentation 353 4.1. SDWAN Segmentation, SDWAN Virtual Topology and Client VPN 355 In SDWAN deployment, "SDWAN Segmentation" is a frequently used term, 356 referring to partitioning a network to multiple sub-networks, just 357 like what MPLS VPN does. "SDWAN Segmentation" is achieved by 358 creating SDWAN virtual topologies and SDWAN VPNs. A SDWAN virtual 359 topology consists of a set of edge nodes and the tunnels, including 360 both IPsec tunnels and/or MPLS VPN tunnels, interconnecting those 361 edge nodes. 363 A SDWAN VPN is same as a client VPN, which is configured in the same 364 way as the VRFs on PEs of a MPLS VPN. One SDWAN client VPN can be 365 mapped to one or multiple SD-WAN virtual topologies. How a Client 366 VPN is mapped to a SDWAN virtual topology is governed by policies 367 from the SDWAN controller. 369 Each SDWAN edge node may need to support multiple VPNs. Just like 370 Route Target is used to distinguish different MPLS VPNs, SDWAN VPN 371 ID is used to differentiate the SDWAN VPNs. For example, in the 372 picture below, the "Payment-Flow" on C-PE2 is only mapped to the 373 virtual topology of C-PEs to/from Payment Gateway, whereas other 374 flows can be mapped to a multipoint to multipoint virtual topology. 376 +---+ 377 +--------------|RR |----------+ 378 / Untrusted +-+-+ \ 379 / \ 380 / \ 381 +---------+ MPLS Path +-------+ 382 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 383 | | | | 384 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 385 | | | | 386 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr |11.2.2.x 387 | 1.1.1.1 | / |2.2.2.2| 388 +---------+ / +-------+ 389 \ / 390 \ /PaymentFlow 391 \ / 392 \ +----+----+ 393 +---------------| payment | 394 | Gateway | 395 +---------+ 397 Figure 2: SDWAN Virtual Topology & VPN 399 4.2. Constrained Propagation of Edge Capability 401 BGP has built-in mechanism to dynamically achieve the constrained 402 distribution of edge information. RFC4684 describes the BGP RT 403 constrained distribution. In a nutshell, a SDWAN edge sends RT 404 Constraint (RTC) NLRI to the RR for the RR to install an outbound 405 route filter, as shown in the figure below: 407 RT Constraint RT constraint 408 NLRI={SDWAN#1, SDWAN#2} NLRI={SDWAN#1, SDWAN#3} 409 -----> +---+ <----------- 410 +--------------------|RR1|------------------+ 411 | Outbound Filter +---+ Outbound Filter | 412 | Permit SDWAN#1,#2 Permit SDWAN#1,#3| 413 | Deny all Deny all | 414 | <------- ---------> | 415 | | 416 +-----+---+ MPLS Path +-----+-+ 417 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 418 | | | | 419 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 420 | | | | 421 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr | 422 | 1.1.1.1 | |2.2.2.2| 423 +---------+ +-------+ 424 SDWAN VPN #1 SDWAN VPN #1 425 SDWAN VPN #2 SDWAN VPN #3 426 Figure 3: Constraint propagation of Edge Property 428 However, a SDWAN overlay network can span across untrusted 429 networks, RR can't trust the RT Constraint (RTC) NLRI BGP UPDATE 430 from any nodes. RR can only process the RTC NLRI from authorized 431 peers for a SDWAN VPN. 433 It is out of the scope of this document on how RR is configured 434 with the policies to filter out unauthorized nodes for specific 435 SDWAN VPNs. 437 When the RR receives BGP UPDATE from an edge node, it propagates 438 the received UPDATE message to the nodes that are in the Outbound 439 Route filter for the specific SDWAN VPN. 441 5. Client Route UPDATE 443 The SDWAN network's Client Route UPDATE message is same as the MPLS 444 VPN client route UDPATE message. The SDWAN Client Route UPDATE 445 message uses the Encapsulation Extended Community and the Color 446 Extended Community to link with the Underlay Tunnels UPDATE Message. 448 5.1. SDWAN VPN ID in Client Route Update 450 SDWAN VPN is same as client VPN in BGP controlled SDWAN network. The 451 Route Target Extended Community should be included in a Client Route 452 UPDATE message to differentiate the client routes from routes 453 belonging to other VPNs. 455 5.2. SDWAN VPN ID in Data Plane 457 For a SDWAN edge node which can be reached by both MPLS and IPsec 458 paths, the client packets reached by MPLS network will be encoded 459 with the MPLS Labels based on the scheme specified by RFC8277. 461 For GRE Encapsulation within IPsec tunnel, the GRE key field can be 462 used to carry the SDWAN VPN ID. For NVO (VxLAN, GENEVE, etc.) 463 encapsulation within the IPsec tunnel, Virtual Network Identifier 464 (VNI) field is used to carry the SDWAN VPN ID. 466 6. Hybrid Underlay Tunnel UPDATE 468 The hybrid underlay tunnel UPDATE is to advertise the detailed 469 properties of hybrid types of tunnels terminated at a SDWAN edge 470 node. 472 A client route UDPATE is recursively tied to an underlay tunnel 473 UDPATE by the Color Extended Community included in client route 474 UPDATE. 476 6.1. NLRI for Hybrid Underlay Tunnel Update 478 A new NLRI is introduced within the MP_REACH_NLRI Path Attribute of 479 RFC4760, for advertising the detailed properties of hybrid types of 480 tunnels terminated at the edge node, with SAFI=SDWAN (code = 74): 482 +------------------+ 483 | NLRI Length | 1 octet 484 +------------------+ 485 | Site-Type | 2 Octet 486 +------------------+ 487 | Port-Local-ID | 4 octets 488 +------------------+ 489 | SDWAN-Color | 4 octets 490 +------------------+ 491 | SDWAN-Node-ID | 4 or 16 octets 492 +------------------+ 494 where: 496 - NLRI Length: 1 octet of length expressed in bits as defined in 497 [RFC4760]. 498 - Site Type: 2 octet value. The SDWAN Site Type defines the 499 different types of Site IDs to be used in the deployment. The 500 draft defines the following types: 501 Site-Type = 1: For a simple deployment, such as all edge 502 nodes under one SDWAN management system, the node ID is 503 enough for the SDWAN management to map the site to its 504 precise geolocation. 505 Site-Type = 2: For large SDWAN heterogeneous deployment where 506 a Geo-Loc Sub-TLV [LISP-GEOLoc]is needed to fully describe 507 the accurate location of the node. 508 - Port local ID: SDWAN edge node Port identifier, which is locally 509 significant. If the SDWAN NLRI applies to multiple ports, this 510 field is NULL. 511 - SDWAN-Color: to correlate with the Color-Extended-community 512 included in the client routes UPDATE. 513 - SDWAN Edge Node ID: The node's IPv4 or IPv6 address. 515 6.2. SDWAN-Hybrid Tunnel Encoding 517 A new Tunnel-Type=SDWAN-Hybrid (code point to be assigned by IANA) 518 is introduced to indicate hybrid underlay networks. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Tunnel-Type(=SDWAN-Hybrid ) | Length (2 Octets) | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Value | 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 SDWAN Hybrid Underlay network Sub-TLV Value Field 530 6.3. IPsec-SA-ID Sub-TLV 532 IPsec-SA-ID Sub-TLV is for the Hybrid Underlay Tunnel UPDATE to 533 reference one or more preestablished IPsec SAs by using their 534 identifiers, instead of listing all the detailed attributes of the 535 IPsec SAs. 537 Using IPsec-SA-ID Sub-TLV not only greatly reduces the size of BGP 538 UPDATE messages, but also allows the pairwise IPsec rekeying process 539 to be performed independently. 541 The following is the structure of the IPsec-SA-ID sub-TLV: 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type= IPsec-SA-ID subTLV | Length (2 Octets) | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | IPsec SA Identifier #1 | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | IPsec SA Identifier #2 | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 If the client traffic needs to be encapsulated in a specific type 553 within the IPsec ESP Tunnel, such as GRE or VxLAN, etc., the 554 corresponding Tunnel-Encap Sub-TLV needs to be prepended right 555 before the IPsec-SA-ID Sub-TLV. 557 6.3.1. Encoding example #1 of using IPsec-SA-ID Sub-TLV 559 This section provides an encoding example for the following 560 scenario: 562 - There are four IPsec SAs terminated at the same WAN Port 563 address (or the same node address) 565 - Two of the IPsec SAs use GRE (value =2) as Inner Encapsulation 566 within the IPsec Tunnel 567 - two of the IPsec SA uses VxLAN (value = 8) as the Inner 568 Encapsulation within its IPsec Tunnel. 570 Here is the encoding for the scenario: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Tunnel-Type =SDWAN-Hybrid | Length = | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Tunnel-end-Point Sub-TLV | 578 ~ ~ 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 ~ GRE Sub-TLV ~ 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | subTLV-Type = IPsec-SA-ID | Length = | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | IPsec SA Identifier = 1 | 585 +---------------------------------------------------------------+ 586 | IPsec SA Identifier = 2 | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 ~ VxLAN Sub-TLV ~ 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |subTLV-Type = IPsec-SA-ID | Length= | 591 +-------------------------------+-------------------------------+ 592 | IPsec SA Identifier = 3 | 593 +-------------------------------+-------------------------------+ 594 | IPsec SA Identifier = 4 | 595 +---------------------------------------------------------------+ 597 The Length of the Tunnel-Type = SDDWAN-Hybrid is the sum of the 598 following: 599 - Tunnel-end-point sub-TLV total length 600 - The GRE Sub-TLV total length, 601 - The IPsec-SA-ID Sub-TLV length, 602 - The VxLAN sub-TLV total length, and 603 - The IPsec-SA-ID Sub-TLV length. 605 6.3.2. Encoding Example #2 of using IPsec-SA-ID Sub-TLV 607 For IPsec SAs terminated at different endpoints, multiple Tunnel Encap 608 Attributes must be included. This section provides an encoding example for 609 the following scenario: 611 - there is one IPsec SA terminated at the WAN Port address 612 192.0.0.1; and another IPsec SA terminated at WAN Port 613 170.0.0.1; 614 - Both IPsec SAs use GRE (value =2) as Inner Encapsulation within 615 the IPsec Tunnel 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Tunnel-Type =SDWAN-Hybrid | Length = | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Tunnel-end-Point Sub-TLV | 623 ~ for 192.0.0.1 ~ 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 ~ GRE Sub-TLV ~ 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 ~ IPsec-SA-ID sub-TLV #1 ~ 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Tunnel-Type =SDWAN-Hybrid | Length = | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Tunnel-end-Point Sub-TLV | 632 ~ for 170.0.0.1 ~ 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 ~ GRE sub-TLV ~ 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 ~ IPsec-SA-ID sub-TLV #2 ~ 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 6.4. Extended Port Sub-TLV 641 When a SDWAN edge node is connected to an underlay network via a 642 port behind NAT devices, traditional IPsec uses IKE for NAT 643 negotiation. The location of a NAT device can be such that: 645 - Only the initiator is behind a NAT device. Multiple initiators 646 can be behind separate NAT devices. Initiators can also connect 647 to the responder through multiple NAT devices. 648 - Only the responder is behind a NAT device. 649 - Both the initiator and the responder are behind a NAT device. 651 The initiator's address and/or responder's address can be 652 dynamically assigned by an ISP or when their connection crosses a 653 dynamic NAT device that allocates addresses from a dynamic address 654 pool. 656 Because one SDWAN edge can connect to multiple peers via one 657 underlay network, the pair-wise NAT exchange as IPsec's IKE is not 658 efficient. In BGP Controlled SDWAN, NAT information of a WAN port is 659 advertised to its RR in the BGP UPDATE message. It is encoded as an 660 Extended sub-TLV that describes the NAT property if the port is 661 behind a NAT device. 663 A SDWAN edge node can inquire STUN (Session Traversal of UDP Through 664 Network Address Translation RFC 3489) Server to get the NAT 665 property, the public IP address and the Public Port number to pass 666 to peers. 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 |Port Ext Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | NAT Type | Encap-Type |Trans networkID| RD ID | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Local IP Address | 675 32-bits for IPv4, 128-bits for Ipv6 676 ~~~~~~~~~~~~ 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Local Port | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Public IP | 681 32-bits for IPv4, 128-bits for Ipv6 682 ~~~~~~~~~~~~ 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Public Port | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | ISP-Sub-TLV | 687 ~ ~ 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Where: 692 o Port Ext Type: indicate it is the Port Ext SubTLV. 693 o PortExt subTLV Length: the length of the subTLV. 694 o Flags: 695 - I bit (CPE port address or Inner address scheme) 696 If set to 0, indicate the inner (private) address is IPv4. 697 If set to 1, it indicates the inner address is IPv6. 699 - O bit (Outer address scheme): 700 If set to 0, indicate the public (outer) address is IPv4. 701 If set to 1, it indicates the public (outer) address is 702 IPv6. 704 - R bits: reserved for future use. Must be set to 0 now. 706 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 707 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 708 response from the STUN server). 709 o Encap Type.the supported encapsulation types for the port 710 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 711 without GRE, GRE (when packets don't need encryption) 712 o Transport Network ID.Central Controller assign a global unique 713 ID to each transport network. 714 o RD ID.Routing Domain ID.need to be global unique. 715 o Local IP.The local (or private) IP address of the port. 716 o Local Port.used by Remote SDWAN edge node for establishing 717 IPsec to this specific port. 718 o Public IP.The IP address after the NAT. If NAT is not used, 719 this field is set to NULL. 720 o Public Port.The Port after the NAT. If NAT is not used, this 721 field is set to NULL. 723 6.5. ISP of the Underlay network Sub-TLV 725 The purpose of the Underlay network Sub-TLV is to carry the ISP WAN 726 port properties with SDWAN SAFI NLRI. It would be treated as 727 optional Sub-TLV. The BGP originator decides whether to include this 728 Sub-TLV along with the SDWAN NLRI. If this Sub-TLV is present, it 729 would be processed by the BGP receiver and to determine what local 730 policies to apply for the remote end point of the Underlay tunnel. 732 The format of this Sub-TLV is as follows: 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Type | Length | Flag | Reserved | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |Connection Type| Port Type | Port Speed | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Where: 743 Type: To be assigned by IANA 745 Length: 6 bytes. 747 Flag: a 1 octet value. 749 Reserved: 1 octet of reserved bits. It SHOULD be set to zero on 750 transmission and MUST be ignored on receipt. 752 Connection Type: There are two different types of WAN 753 Connectivity. They are listed below as: 755 Wired - 1 756 WIFI - 2 757 LTE - 3 758 5G - 4 760 Port Type: There are different types of ports. They are listed 761 Below as: 763 Ethernet - 1 764 Fiber Cable - 2 765 Coax Cable - 3 766 Cellular - 4 768 Port Speed: The port seed is defined as 2 octet value. The values 769 are defined as Gigabit speed. 771 7. IPsec SA Property Sub-TLVs 773 This section describes the detailed IPsec SA properties sub-TLVs. 775 7.1. IPsec SA Nonce Sub-TLV 777 The Nonce Sub-TLV is based on the Base DIM sub-TLV as described the 778 Section 6.1 of [SECURE-EVPN]. IPsec SA ID is added to the sub-TLV, 779 which is to be referenced by the client route NLRI Tunnel Encap Path 780 Attribute for the IPsec SA. The following fields are removed 781 because: 783 - the Originator ID is carried by the NLRI, 784 - the Tenant ID is represented by the SDWAN VPN ID Extended 785 Community, and 786 - the Subnet ID are carried by the BGP route UPDATE. 788 The format of this Sub-TLV is as follows: 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | ID Length | Nonce Length |I| Flags | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Rekey | 796 | Counter | 797 +---------------------------------------------------------------+ 798 | IPsec SA ID | Reserved | 799 +---------------------------------------------------------------+ 800 | | 801 ~ Nonce Data ~ 802 | | 803 +---------------------------------------------------------------+ 805 IPsec SA ID - The 2 bytes IPSec SA ID could 0 or non-zero values. It 806 is cross referenced by client route's IPSec Tunnel Encap IPSec-SA-ID 807 in Section 6. When there are multiple IPsec SAs terminated at one 808 address, such as WAN port address or the node address, they are 809 differentiated by the different IPsec SA IDs. 811 7.2. IPsec Public Key Sub-TLV 813 The IPsec Public Key Sub-TLV is derived from the Key Exchange Sub- 814 TLV described in [SECURE-EVPN] with an addition of Duration filed to 815 define the IPSec SA life span. The edge nodes would pick the 816 shortest duration value between the SDWAN SAFI pairs. 818 The format of this Sub-TLV is as follows: 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Diffie-Hellman Group Num | Reserved | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | | 826 ~ Key Exchange Data ~ 827 | | 828 +---------------------------------------------------------------+ 829 | Duration | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 7.3. IPsec SA Proposal Sub-TLV 834 The IPsec SA Proposal Sub-TLV is to indicate the number of Transform 835 Sub-TLVs. This Sub-TLV aligns with the sub-TLV structure from 836 [SECURE-VPN] 838 The Transform Sub-sub-TLV will following the section 3.3.2 of 839 RFC7296. 841 7.4. Simplified IPsec Security Association sub-TLV 843 For a simple SDWAN network with edge nodes supporting only a few 844 pre-defined encryption algorithms, a simple IPsec sub-TLV can be 845 used to encode the pre-defined algorithms, as below: 847 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 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 |IPsec-simType |IPsecSA Length | Flag | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Transform | Mode | AH algorithms |ESP algorithms | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | ReKey Counter (SPI) | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | key1 length | Public Key ~ 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | key2 length | Nonce ~ 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Duration | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Where: 864 o IPsec-SimType: The type value has to be between 128~255 because 865 IPsec-SA subTLV needs 2 bytes for length to carry the needed 866 information. 867 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 868 o Flags: 1 octet of flags. None are defined at this stage. Flags 869 SHOULD be set to zero on transmission and MUST be ignored on 870 receipt. 871 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 873 o IPsec Mode (1 byte): the value can be Tunnel Mode or Transport 874 mode 875 o AH algorithms (1 byte): AH authentication algorithms supported, 876 which can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. 877 Each SDWAN edge node can have multiple authentication. 878 algorithms; send to its peers to negotiate the strongest one. 879 o ESP (1 byte): ESP authentication algorithms supported, which 880 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 881 SDWAN edge node can have multiple authentication algorithms; 882 send to its peers to negotiate the strongest one. Default 883 algorithm is AES-256. 884 o When node supports multiple authentication algorithms, the 885 initial UPDATE needs to include the "Transform Sub-TLV" 886 described by [SECURE-EVPN] to describe all of the 887 algorithms supported by the node. 889 o Rekey Counter (Security Parameter Index)): 4 bytes 890 o Public Key: IPsec public key 891 o Nonce.IPsec Nonce 892 o Duration: SA life span. 894 7.5. IPsec SA Encoding Examples 896 For the Figure 1 in Section 3, C-PE2 needs to advertise its IPsec SA 897 associated attributes, such as the public keys, the nonce, the 898 supported encryption algorithms for the IPsec tunnels terminated at 899 192.0.0.1, 170.1.1.1 and 2.2.2.2 respectively. 901 Using the IPsec Tunnel [ISP4: 160.0.0.1 <-> ISP2:170.0.0.1] as an 902 example: C-PE1 needs to advertise the following attributes for 903 establishing the IPsec SA: 904 SDWAN Node ID 905 SDWAN Color 906 Tunnel Encap Attr (Type=SDWAN-Hybrid) 907 Extended Port Sub-TLV for information about the Port 908 (including ISP Sub-TLV for information about the ISP2) 909 IPsec SA Nonce Sub-TLV, 910 IPsec SA Public Key Sub-TLV, 911 IPsec SA Sub-TLV for the supported transforms 912 {Transforms Sub-TLV - Trans 2, 913 Transforms Sub-TLV - Trans 3} 915 C-PE2 needs to advertise the following attributes for establishing 916 IPsec SA: 917 SDWAN Node ID 918 SDWAN Color 919 Tunnel Encap Attr (Type=SDWAN-Hybrid) 920 Extended Port Sub-TLV (including ISP Sub-TLV for information 921 about the ISP2) 922 IPsec SA Nonce Sub-TLV, 923 IPsec SA Public Key Sub-TLV, 924 IPsec SA Sub-TLV for the supported transforms 925 {Transforms Sub-TLV - Trans 2, 926 Transforms Sub-TLV - Trans 4} 928 As both end points support Transform #2, the Transform #2 will be 929 used for the IPsec Tunnel [ISP4: 160.0.0.1 <-> ISP2:170.0.0.1]. 931 8. Error & Mismatch Handling 933 Each C-PE device advertises SDWAN SAFI Underlay NLRI to the other C- 934 PE devices via BGP Route Reflector to establish pairwise SAs between 935 itself and every other remote C-PEs. During the SAFI NLRI 936 advertisement, the BGP originator would include either simple IPSec 937 Security Association properties defined in IPSec SA Sub-TLV based on 938 IPSec-SA-Type = 1 or full-set of IPSec Sub-TLVs including Nonce, 939 Public Key, Proposal and number of Transform Sub-TLVs based on 940 IPSec-SA-Type = 2. 942 The C-PE devices would compare the IPSec SA attributes between the 943 local and remote WAN ports. If there is a match on the SA Attributes 944 between the two ports, the IPSec Tunnel would be established. 946 The C-PE devices would not try to negotiate the base IPSec-SA 947 parameters between the local and the remote ports in the case of 948 simple IPSec SA exchange or the Transform sets between local and 949 remote ports if there is a mismatch on the Transform sets in the 950 case of full-set of IPSec SA Sub-TLVs. 952 As an example, using the Figure 1 in Section 3, to establish IPsec 953 Tunnel between C-PE1 and C-PE2 WAN Ports A2 and B2 [A2: 192.10.0.10 954 <-> B2:192.0.0.1]: 956 C-PE1 needs to advertise the following attributes for establishing 957 the IPsec SA: 958 NH: 192.10.0.10 959 SDWAN Node ID 960 SDWAN-Site-ID 961 Tunnel Encap Attr (Type=SDWAN) 962 ISP Sub-TLV for information about the ISP3 963 IPsec SA Nonce Sub-TLV, 964 IPsec SA Public Key Sub-TLV, 965 Proposal Sub-TLV with Num Transforms = 1 966 {Transforms Sub-TLV - Trans 1} 968 C-PE2 needs to advertise the following attributes for establishing 969 IPsec SA: 970 NH: 192.0.0.1 971 SDWAN Node ID 972 SDWAN-Site-ID 973 Tunnel Encap Attr (Type=SDWAN) 974 ISP Sub-TLV for information about the ISP1 975 IPsec SA Nonce Sub-TLV, 976 IPsec SA Public Key Sub-TLV, 977 Proposal Sub-TLV with Num Transforms = 1 978 {Transforms Sub-TLV - Trans 2} 980 As there is no matching transform between the WAN ports A2 and B2 in 981 C-PE1 and C-PE2 respectively, there will be no IPsec Tunnel be 982 established. 984 9. Manageability Considerations 986 TBD - this needs to be filled out before publishing 988 10. Security Considerations 990 The document describes the encoding for SDWAN edge nodes to 991 advertise its properties to their peers to its RR, which 992 propagates to the intended peers via untrusted networks. 994 The secure propagation is achieved by secure channels, such as 995 TLS, SSL, or IPsec, between the SDWAN edge nodes and the local 996 controller RR. 998 [More details need to be filled in here] 1000 11. IANA Considerations 1002 This document requires the following IANA actions. 1004 o Hybrid (SDWAN) Overlay SAFI = 74 assigned by IANA 1005 o IPsec-SA-ID Sub-TLV Type 1007 12. References 1009 12.1. Normative References 1011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1012 Requirement Levels", BCP 14, RFC 2119, March 1997. 1014 12.2. Informative References 1016 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 1017 (I2NSF) Problem Statement and Use Cases", July 2017 1019 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 1020 Address Family Identifier (SAFI) and the BGP Tunnel 1021 Encapsulation Attribute", April 2009. 1023 [CONTROLLER-IKE] D. Carrel, et al, "IPsec Key Exchange using a 1024 Controller", draft-carrel-ipsecme-controller-ike-01, work- 1025 in-progress. 1027 [LISP-GEOLOC] D. Farinacci, "LISP Geo-Coordinate Use-Case", draft- 1028 farinacci-lisp-geo-09, April 2020. 1030 [SDN-IPSEC] R. Lopez, G. Millan, "SDN-based IPsec Flow Protection", 1031 draft-ietf-i2nsf-sdn-ipsec-flow-protection-07, Aug 2019. 1033 [SECURE-EVPN] A. Sajassi, et al, "Secure EVPN", draft-sajassi-bess- 1034 secure-evpn-02, July 2019. 1036 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 1037 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 1039 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 1040 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 1041 work-in-progress, July 2018 1043 [DMVPN] Dynamic Multi-point VPN: 1044 https://www.cisco.com/c/en/us/products/security/dynamic- 1045 multipoint-vpn-dmvpn/index.html 1047 [DSVPN] Dynamic Smart VPN: 1048 http://forum.huawei.com/enterprise/en/thread-390771-1- 1049 1.html 1051 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 1052 storage, distribution and enforcement of policies for 1053 network security", Nov 2007. 1055 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 1056 Underlay to Cloud Overlay Problem Statement", draft-dm- 1057 net2cloud-problem-statement-02, June 2018 1059 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 1060 of Interconnecting Underlay with Cloud Overlay", draft-dm- 1061 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 1063 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 1064 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 1066 13. Acknowledgments 1068 Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for 1069 implementation contribution; Many thanks to Yoav Nir, Graham 1070 Bartlett, Jim Guichard, John Scudder, and Donald Eastlake for their 1071 review and discussions. 1073 This document was prepared using 2-Word-v2.0.template.dot. 1075 Authors' Addresses 1077 Linda Dunbar 1078 Futurewei 1079 Email: ldunbar@futurewei.com 1081 Sue Hares 1082 Hickory Hill Consulting 1083 Email: shares@ndzh.com 1085 Robert Raszuk 1086 Email: robert@raszuk.net 1088 Kausik Majumdar 1089 CommScope 1090 Email: Kausik.Majumdar@commscope.com