idnits 2.17.1 draft-ietf-idr-sdwan-edge-discovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 10 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 31, 2021) is 961 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 256, but not defined == Missing Reference: 'RFC4364' is mentioned on line 136, but not defined == Missing Reference: 'Tunnel-encap' is mentioned on line 327, but not defined == Missing Reference: 'RFC9016' is mentioned on line 373, but not defined == Missing Reference: 'RFC4684' is mentioned on line 425, but not defined == Missing Reference: 'RFC8277' is mentioned on line 482, but not defined == Missing Reference: 'RFC3489' is mentioned on line 686, but not defined ** Obsolete undefined reference: RFC 3489 (Obsoleted by RFC 5389) == Missing Reference: 'SECURE-VPN' is mentioned on line 859, but not defined == Unused Reference: 'RFC8192' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC9061' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'CONTROLLER-IKE' is defined on line 1089, but no explicit reference was found in the text == Unused Reference: 'LISP-GEOLOC' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'SDN-IPSEC' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 1110, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-Problem' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 1126, but no explicit reference was found in the text ** Downref: Normative reference to an Draft Standard RFC: RFC 4271 ** Downref: Normative reference to an Draft Standard RFC: RFC 4760 ** Downref: Normative reference to an Proposed Standard RFC: RFC 9012 == 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: 5 errors (**), 0 flaws (~~), 31 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: February 31, 2022 Hickory Hill Consulting 5 R. Raszuk 6 NTT Network Innovations 7 K. Majumdar 8 CommScope 9 Gyan Mishra 10 Verizon 11 August 31, 2021 13 BGP UPDATE for SDWAN Edge Discovery 14 draft-ietf-idr-sdwan-edge-discovery-00 16 Abstract 18 The document describes the encoding of BGP UPDATE messages for the 19 SDWAN edge node discovery. 21 In the context of this document, BGP Route Reflector (RR) is the 22 component of the SDWAN Controller that receives the BGP UPDATE from 23 SDWAN edges and in turns propagates the information to the intended 24 peers that are authorized to communicate via the SDWAN overlay 25 network. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on Dec 30, 2020. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................3 67 2. Conventions used in this document..............................3 68 3. Framework of SDWAN Edge Discovery..............................5 69 3.1. The Objectives of SDWAN Edge Discovery....................5 70 3.2. Comparing with Pure IPsec VPN.............................5 71 3.3. Client Route UPDATE and Hybrid Underlay Tunnel UPDATE.....7 72 3.4. Edge Node Discovery.......................................9 73 4. BGP UPDATE to Support SDWAN Segmentation......................10 74 4.1. SDWAN Segmentation, SDWAN Virtual Topology and Client VPN10 75 4.2. Constrained Propagation of Edge Capability...............11 76 5. Client Route UPDATE...........................................12 77 5.1. SDWAN VPN ID in Client Route Update......................13 78 5.2. SDWAN VPN ID in Data Plane...............................13 79 6. Hybrid Underlay Tunnel UPDATE.................................13 80 6.1. NLRI for Hybrid Underlay Tunnel Update...................13 81 6.2. SDWAN-Hybrid Tunnel Encoding.............................15 82 6.3. IPsec-SA-ID Sub-TLV......................................15 83 6.3.1. Encoding example #1 of using IPsec-SA-ID Sub-TLV....16 84 6.3.2. Encoding Example #2 of using IPsec-SA-ID Sub-TLV....17 85 6.4. Extended Port Tunnel Encapsulation Attribute Sub-TLV.....18 86 6.5. Underlay Network Properties Sub-TLV......................20 87 7. IPsec SA Property Sub-TLVs....................................21 88 7.1. IPsec SA Nonce Sub-TLV...................................21 89 7.2. IPsec Public Key Sub-TLV.................................22 90 7.3. IPsec SA Proposal Sub-TLV................................23 91 7.4. Simplified IPsec Security Association sub-TLV............23 92 7.5. IPsec SA Encoding Examples...............................24 93 8. Error & Mismatch Handling.....................................25 94 9. Manageability Considerations..................................26 95 10. Security Considerations......................................27 96 11. IANA Considerations..........................................27 97 11.1. Hybrid (SDWAN) Overlay SAFI.............................27 98 11.2. Tunnel Encapsulation Attribute Type.....................27 99 12. References...................................................28 100 12.1. Normative References....................................28 101 12.2. Informative References..................................28 102 13. Acknowledgments..............................................30 104 1. Introduction 106 [SDWAN-BGP-USAGE] illustrates how BGP [RFC4271] is used as a control 107 plane for a SDWAN network. SDWAN network refers to a policy-driven 108 network over multiple different underlay networks to get better WAN 109 bandwidth management, visibility, and control. 111 The document describes BGP UPDATE messages for an SDWAN edge node to 112 announce its properties to its RR which then propagates that 113 information to the authorized peers. 115 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 The following acronyms and terms are used in this document: 124 Cloud DC: Off-Premise Data Centers that usually host applications 125 and workload owned by different organizations or 126 tenants. 128 Controller: Used interchangeably with SDWAN controller to manage 129 SDWAN overlay path creation/deletion and monitor the 130 path conditions between sites. 132 CPE: Customer (Edge) Premises Equipment. 134 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 135 This is to differentiate such VPNs from most commonly 136 used PE-based VPNs discussed in [RFC4364]. 138 MP-NLRI: Multi-Protocol Network Layer Reachability Information 139 [MP_REACH_NLRI] Path Attribute defined in RFC4760. 141 SDWAN End-point: can be the SDWAN edge node address, a WAN port 142 address (logical or physical) of a SDWAN edge node, or a 143 client port address. 145 OnPrem: On Premises data centers and branch offices. 147 RR Route Reflector. 149 SDWAN: Software Defined Wide Area Network. In this document, 150 "SDWAN" refers to policy-driven transporting IP packets 151 over multiple different underlay networks to get better 152 WAN bandwidth management, visibility and control. 154 SDWAN Segmentation: Segmentation is the process of dividing the 155 network into logical sub-networks. 157 SDWAN VPN: refers to the Client's VPN, which is like the VRF on the 158 PEs of a MPLS VPN. One SDWAN client VPN can be mapped 159 one or multiple SD-WAN virtual topologies. How Client 160 VPN is mapped to a SDWAN virtual topology is governed by 161 policies. 163 SDWAN Virtual Topology: Since SDWAN can connect any nodes, whereas 164 MPLS VPN connects a fixed number of PEs, one SDWAN 165 Virtual Topology refers to a set of edge nodes and the 166 tunnels (including both IPsec tunnels and/or MPLS 167 tunnels) interconnecting those edge nodes. 169 VPN Virtual Private Network. 171 VRF VPN Routing and Forwarding instance. 173 WAN Wide Area Network. 175 3. Framework of SDWAN Edge Discovery 177 3.1. The Objectives of SDWAN Edge Discovery 179 The objectives of SDWAN edge discovery are for a SDWAN edge node to 180 discover its authorized peers and their associated properties for 181 its attached clients' traffic to communicate. The attributes to be 182 propagated includes the SDWAN (client) VPNs supported, the attached 183 routes under specific SDWAN VPNs, and the properties of the underlay 184 networks over which the client routes can be carried. 186 Some SDWAN peers are connected by both trusted VPNs and untrusted 187 public networks. Some SDWAN peers are connected only by untrusted 188 public networks. For the portion over untrusted networks, IPsec 189 Security Associations (IPsec SA) have to be established and 190 maintained. If an edge node has network ports behind a NAT, the NAT 191 properties needs to be discovered by authorized SDWAN peers. 193 Just like any VPN networks, the attached client's routes belonging 194 to specific SDWAN VPNs can only be exchanged with the SDWAN peer 195 nodes that are authorized to communicate. 197 3.2. Comparing with Pure IPsec VPN 199 A pure IPsec VPN has IPsec tunnels connecting all edge nodes via 200 public internet; it therefore requires stringent authentication and 201 authorization (i.e. IKE Phase 1) before other properties of IPsec SA 202 can be exchanged. The IPsec Security Association (SA) between two 203 untrusted nodes typically requires the following configurations and 204 message exchanges: 206 - IPsec IKE to authenticate with each other 207 - Establish IPsec SA 208 o Local key configuration 209 o Remote Peer address (192.10.0.10<->172.0.01) 210 o IKEv2 Proposal directly sent to peer 211 o Encryption method, Integrity sha512 212 o Transform set 213 - Attached client prefixes discovery 214 o By running routing protocol within each IPsec SA 215 o If multiple IPsec SAs between two peer nodes are 216 established to achieve load sharing, each IPsec tunnel 217 needs to run its own routing protocol to exchange client 218 routes attached to the edges. 219 - Access List or Traffic Selector) 220 o Permit Local-IP1, Remote-IP2 222 In a BGP controlled SDWAN network, e.g. a MPLS based network adding 223 short-term capacity over Internet using IPsec, there are secure 224 connection between edge nodes and RR, via private path, TLS, DTLS, 225 etc. The authentication of peer nodes is managed by the RR. More 226 importantly, when an edge node needs to establish multiple IPsec 227 tunnels to many different edge nodes, all the management information 228 can be multiplexed into the secure management tunnel between RR and 229 the edge node. Therefore, there is reduced amount of authentication 230 in a BGP Controlled SDWAN network. 232 Client VPNs are configured via VRFs, just like the configuration of 233 the existing MPLS VPN. The IPsec equivalent traffic selectors for 234 local and remote routes is achieved by importing/exporting VPN Route 235 Targets. The binding of client routes to IPsec SA is dictated by 236 policies. As the result, the IPsec configuration for a BGP 237 controlled SDWAN (with mixed MPLS VPN) can be simplified as the 238 following: 240 - The SDWAN controller has authority to authenticate edges and 241 peers. Remote Peer association is controlled by the SDWAN 242 Controller (RR) 243 - The IKEv2 proposals, including the IPsec Transform set, can 244 be sent directly to peers or incorporated in a BGP UPDATE. 245 - BGP UPDATE: Announces the client route reachability for all 246 permitted parallel tunnels/paths. 247 o No need to run multiple routing protocols in each IPsec 248 tunnel. 250 - Importing/exporting Route Targets under each client VPN (VRF) 251 achieves the traffic selection (or permission) among clients' 252 routes attached to multiple edge nodes. 254 3.3. Client Route UPDATE and Hybrid Underlay Tunnel UPDATE 256 As described in [SDWAN-BGP-USAGE], two separate BGP UPDATE messages 257 are used for SDWAN Edge Discovery: 259 - UPDATE U1 for advertising the attached client routes, 260 This UPDATE is exactly the same as the BGP edge client route 261 UDPDATE. It uses the Encapsulation Extended Community and the 262 Color Extended Community to link with the Underlay Tunnels 263 UPDATE Message as specified by the section 8 of [RFC9012]. 265 A new Tunnel Type (SDWAN-Hybrid) is added and used by the 266 Encapsulation Extended Community or the Tunnel-Encap Path 267 Attribute [RFC9012] to indicate mixed underlay networks. 269 - UPDATE U2 advertises the properties of the various tunnels, 270 including IPsec, terminated at the edge node. 271 This UPDATE is for an edge node to advertise the properties of 272 directly attached underlay networks, including the NAT 273 information, pre-configured IPsec SA identifiers, and/or the 274 underlay network ISP information. This UPDATE can also include 275 the detailed IPsec SA attributes, such as keys, nonce, 276 encryption algorithms, etc. 278 In the following figure: there are four types underlay paths between 279 C-PE1 and C-PE2: 281 a) MPLS-in-GRE path. 283 b) node-based IPsec tunnel [2.2.2.2<->1.1.1.1]. 285 c) port-based IPsec tunnel [192.0.0.1 <-> 192.10.0.10]; and 287 d) port-based IPsec tunnel [172.0.0.1 <-> 160.0.0.1]. 289 +---+ 290 +--------------|RR |----------+ 291 / Untrusted +-+-+ \ 292 / \ 293 / \ 294 +---------+ MPLS Path +-------+ 295 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 296 | | | | 297 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 298 | | | | 299 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr | 300 | 1.1.1.1 | |2.2.2.2| 301 +---------+ +-------+ 303 Figure 1: Hybrid SDWAN 305 C-PE2 uses UPDATE U1 to advertise the attached client routes: 307 UDPATE U1: 309 Extended community: RT for SDWAN VPN 1 310 NLRI: AFI=? & SAFI = 1/1 311 Prefix: 10.1.1.x; 20.1.1.x 312 NextHop: 2.2.2.2 (C-PE2) 313 Encapsulation Extended Community: tunnel-type=SDWAN-Hybrid 314 Color Extended Community: RED 316 The UPDATE U1 is recursively resolved to the UPDATE U2 which 317 specifies the detailed hybrid WAN underlay Tunnels terminated at the 318 C-PE2: 320 UPDATE U2: 322 NLRI: SAFI = SDWAN-Hybrid 323 (With Color RED encoded in the NLRI Site-Property field) 324 Prefix: 2.2.2.2 325 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] 326 IPSec SA for 192.0.0.1 327 Tunnel-End-Point Sub-TLV for 192.0.0.1 [Tunnel-encap] 328 IPsec-SA-ID sub-TLV [See the Section 6] 329 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] 330 IPSec SA for 331 Tunnel-End-Point Sub-TLV /* for 170.0.0.1 */ 332 IPsec-SA-ID sub-TLV 333 Tunnel Encap Attr MPLS-in-GRE [type=SDWAN-Hybrid] 334 Sub-TLV for MPLS-in-GRE [Section 3.2.6 of Tunnel-encap] 336 Note: [RFC9012] Section 11 specifies that each Tunnel Encap 337 Attribute can only have one Tunnel-End-Point sub-TLV. Therefore, two 338 separate Tunnel Encap Attributes are needed to indicate that the 339 client routes can be carried by either one. 341 3.4. Edge Node Discovery 343 The basic scheme of SDWAN Edge node discovery using BGP consists of 344 the following: 346 - Secure connection to a SDWAN controller (i.e. RR in this 347 context): 348 For a SDWAN edge with both MPLS and IPsec path, the edge node 349 should already have secure connection to its controller, i.e. 350 RR in this context. For a remote SDWAN edge that is only 351 accessible via Internet, the SDWAN edge node, upon power up, 352 establishes a secure tunnel (such as TLS or SSL) with the SDWAN 353 central controller whose address is preconfigured on the edge 354 node. The central controller will inform the edge node of its 355 local RR. The edge node will establish a transport layer secure 356 session with the RR (such as TLS or SSL). 358 - The Edge node will advertise its own properties to its 359 designated RR via the secure connection. 361 - The RR propagates the received information to the authorized 362 peers. 364 - The authorized peers can establish the secure data channels 365 (IPsec) and exchange more information among each other. 366 For an SDWAN deployment with multiple RRs, it is assumed that there 367 are secure connections among those RRs. How secure connections being 368 established among those RRs is the out of the scope of this 369 document. The existing BGP UPDATE propagation mechanisms control the 370 edge properties propagation among the RRs. 372 For some special environments where the communication to RR are 373 highly secured, [RFC9016] IKE-less can be deployed to simplify IPsec 374 SA establishment among edge nodes. 376 4. BGP UPDATE to Support SDWAN Segmentation 377 4.1. SDWAN Segmentation, SDWAN Virtual Topology and Client VPN 379 In SDWAN deployment, "SDWAN Segmentation" is a frequently used term, 380 referring to partitioning a network to multiple sub-networks, just 381 as MPLS VPN does. "SDWAN Segmentation" is achieved by creating SDWAN 382 virtual topologies and SDWAN VPNs. A SDWAN virtual topology consists 383 of a set of edge nodes and the tunnels, including both IPsec tunnels 384 and/or MPLS VPN tunnels, interconnecting those edge nodes. 386 An SDWAN VPN is the same as a client VPN, which is configured in the 387 same way as the VRFs on PEs of a MPLS VPN. One SDWAN client VPN can 388 be mapped to one or multiple SD-WAN virtual topologies. How a Client 389 VPN is mapped to a SDWAN virtual topology is governed by policies 390 from the SDWAN controller. 392 Each SDWAN edge node may need to support multiple VPNs. Just as a 393 Route Target is used to distinguish different MPLS VPNs, an SDWAN 394 VPN ID is used to differentiate the SDWAN VPNs. For example, in the 395 picture below, the "Payment-Flow" on C-PE2 is only mapped to the 396 virtual topology of C-PEs to/from Payment Gateway, whereas other 397 flows can be mapped to a multipoint to multipoint virtual topology. 399 +---+ 400 +--------------|RR |----------+ 401 / Untrusted +-+-+ \ 402 / \ 403 / \ 404 +---------+ MPLS Path +-------+ 405 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 406 | | | | 407 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 408 | | | | 409 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr |11.2.2.x 410 | 1.1.1.1 | / |2.2.2.2| 411 +---------+ / +-------+ 412 \ / 413 \ /PaymentFlow 414 \ / 415 \ +----+----+ 416 +---------------| payment | 417 | Gateway | 418 +---------+ 420 Figure 2: SDWAN Virtual Topology & VPN 422 4.2. Constrained Propagation of Edge Capability 424 BGP has a built-in mechanism to dynamically achieve the 425 constrained distribution of edge information. [RFC4684] describes 426 the BGP RT constrained distribution. In a nutshell, an SDWAN edge 427 sends RT Constraint (RTC) NLRI to the RR for the RR to install an 428 outbound route filter, as shown in the figure below: 430 RT Constraint RT constraint 431 NLRI={SDWAN#1, SDWAN#2} NLRI={SDWAN#1, SDWAN#3} 432 -----> +---+ <----------- 433 +--------------------|RR1|------------------+ 434 | Outbound Filter +---+ Outbound Filter | 435 | Permit SDWAN#1,#2 Permit SDWAN#1,#3| 436 | Deny all Deny all | 437 | <------- ---------> | 438 | | 439 +-----+---+ MPLS Path +-----+-+ 440 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 441 | | | | 442 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 443 | | | | 444 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr | 445 | 1.1.1.1 | |2.2.2.2| 446 +---------+ +-------+ 447 SDWAN VPN #1 SDWAN VPN #1 448 SDWAN VPN #2 SDWAN VPN #3 449 Figure 3: Constraint propagation of Edge Property 451 However, a SDWAN overlay network can span across untrusted 452 networks, RR can't trust the RT Constraint (RTC) NLRI BGP UPDATE 453 from any nodes. RR can only process the RTC NLRI from authorized 454 peers for a SDWAN VPN. 456 It is out of the scope of this document on how RR is configured 457 with the policies to filter out unauthorized nodes for specific 458 SDWAN VPNs. 460 When the RR receives BGP UPDATE from an edge node, it propagates 461 the received UPDATE message to the nodes that are in the Outbound 462 Route filter for the specific SDWAN VPN. 464 5. Client Route UPDATE 466 The SDWAN network's Client Route UPDATE message is the same as the 467 MPLS VPN client route UDPATE message. The SDWAN Client Route UPDATE 468 message uses the Encapsulation Extended Community and the Color 469 Extended Community to link with the Underlay Tunnels UPDATE Message. 471 5.1. SDWAN VPN ID in Client Route Update 473 An SDWAN VPN is same as a client VPN in a BGP controlled SDWAN 474 network. The Route Target Extended Community should be included in a 475 Client Route UPDATE message to differentiate the client routes from 476 routes belonging to other VPNs. 478 5.2. SDWAN VPN ID in Data Plane 480 For an SDWAN edge node which can be reached by both MPLS and IPsec 481 paths, the client packets reached by MPLS network will be encoded 482 with the MPLS Labels based on the scheme specified by [RFC8277]. 484 For GRE Encapsulation within an IPsec tunnel, the GRE key field can 485 be used to carry the SDWAN VPN ID. For network virtual overlay 486 (VxLAN, GENEVE, etc.) encapsulation within the IPsec tunnel, the 487 Virtual Network Identifier (VNI) field is used to carry the SDWAN 488 VPN ID. 490 6. Hybrid Underlay Tunnel UPDATE 492 The hybrid underlay tunnel UPDATE is to advertise the detailed 493 properties of hybrid types of tunnels terminated at a SDWAN edge 494 node. 496 A client route UDPATE is recursively tied to an underlay tunnel 497 UDPATE by the Color Extended Community included in client route 498 UPDATE. 500 6.1. NLRI for Hybrid Underlay Tunnel Update 502 A new NLRI is introduced within the MP_REACH_NLRI Path Attribute of 503 RFC4760, for advertising the detailed properties of hybrid types of 504 tunnels terminated at the edge node, with SAFI=SDWAN (code = 74): 506 +------------------+ 507 | NLRI Length | 1 octet 508 +------------------+ 509 | Site-Type | 2 Octet 510 +------------------+ 511 | Port-Local-ID | 4 octets 512 +------------------+ 513 | SDWAN-Color | 4 octets 514 +------------------+ 515 | SDWAN-Node-ID | 4 or 16 octets 516 +------------------+ 518 where: 520 - NLRI Length: 1 octet of length expressed in bits as defined in 521 [RFC4760]. 522 - Site Type: 2 octet value. The SDWAN Site Type defines the 523 different types of Site IDs to be used in the deployment. This 524 document defines the following types: 525 Site-Type = 1: For a simple deployment, such as all edge 526 nodes under one SDWAN management system, the node ID is 527 enough for the SDWAN management to map the site to its 528 precise geolocation. 529 Site-Type = 2: For large SDWAN heterogeneous deployment where 530 a Geo-Loc Sub-TLV [LISP-GEOLoc]is needed to fully describe 531 the accurate location of the node. 532 - Port local ID: SDWAN edge node Port identifier, which is locally 533 significant. If the SDWAN NLRI applies to multiple ports, this 534 field is NULL. 535 - SDWAN-Color: to correlate with the Color-Extended-community 536 included in the client routes UPDATE. 537 - SDWAN Edge Node ID: The node's IPv4 or IPv6 address. 539 6.2. SDWAN-Hybrid Tunnel Encoding 541 A new BGP Tunnel-Type=SDWAN-Hybrid (code point TBD1) is specified 542 for the Tunnel Encapsulation Attribute to indicate hybrid underlay 543 networks. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Tunnel-Type(=SDWAN-Hybrid ) | Length (2 Octets) | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Sub-TLVs | 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 SDWAN Hybrid Underlay network Sub-TLV Value Field 555 6.3. IPsec-SA-ID Sub-TLV 557 IPsec-SA-ID Sub-TLV for the Hybrid Underlay Tunnel UPDATE indicates 558 one or more preestablished IPsec SAs by using their identifiers, 559 instead of listing all the detailed attributes of the IPsec SAs. 561 Using an IPsec-SA-ID Sub-TLV not only greatly reduces the size of 562 BGP UPDATE messages, but also allows the pairwise IPsec rekeying 563 process to be performed independently. 565 The following is the structure of the IPsec-SA-ID sub-TLV: 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 |Type= IPsec-SA-ID subTLV (TBD2)| Length (2 Octets) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | IPsec SA Identifier #1 | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | IPsec SA Identifier #2 | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 If the client traffic needs to be encapsulated in a specific way 577 within the IPsec ESP Tunnel, such as GRE or VxLAN, etc., the 578 corresponding Tunnel-Encap Sub-TLV needs to be prepended right 579 before the IPsec-SA-ID Sub-TLV. 581 6.3.1. Encoding example #1 of using IPsec-SA-ID Sub-TLV 583 This section provides an encoding example for the following 584 scenario: 586 - There are four IPsec SAs terminated at the same WAN Port 587 address (or the same node address) 588 - Two of the IPsec SAs use GRE (value =2) as Inner Encapsulation 589 within the IPsec Tunnel 590 - two of the IPsec SA uses VxLAN (value = 8) as the Inner 591 Encapsulation within its IPsec Tunnel. 593 Here is the encoding for the scenario: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Tunnel-Type =SDWAN-Hybrid | Length = | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Tunnel-end-Point Sub-TLV | 601 ~ ~ 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 ~ GRE Sub-TLV ~ 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | subTLV-Type = IPsec-SA-ID | Length = | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | IPsec SA Identifier = 1 | 608 +---------------------------------------------------------------+ 609 | IPsec SA Identifier = 2 | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 ~ VxLAN Sub-TLV ~ 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 |subTLV-Type = IPsec-SA-ID | Length= | 614 +-------------------------------+-------------------------------+ 615 | IPsec SA Identifier = 3 | 616 +-------------------------------+-------------------------------+ 617 | IPsec SA Identifier = 4 | 618 +---------------------------------------------------------------+ 620 The Length of the Tunnel-Type = SDDWAN-Hybrid is the sum of the 621 following: 622 - Tunnel-end-point sub-TLV total length 623 - The GRE Sub-TLV total length, 624 - The IPsec-SA-ID Sub-TLV length, 625 - The VxLAN sub-TLV total length, and 626 - The IPsec-SA-ID Sub-TLV length. 628 6.3.2. Encoding Example #2 of using IPsec-SA-ID Sub-TLV 630 For IPsec SAs terminated at different endpoints, multiple Tunnel Encap 631 Attributes must be included. This section provides an encoding example for 632 the following scenario: 634 - there is one IPsec SA terminated at the WAN Port address 635 192.0.0.1; and another IPsec SA terminated at WAN Port 636 170.0.0.1; 637 - Both IPsec SAs use GRE (value =2) as Inner Encapsulation within 638 the IPsec Tunnel 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Tunnel-Type =SDWAN-Hybrid | Length = | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Tunnel-end-Point Sub-TLV | 646 ~ for 192.0.0.1 ~ 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 ~ GRE Sub-TLV ~ 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 ~ IPsec-SA-ID sub-TLV #1 ~ 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Tunnel-Type =SDWAN-Hybrid | Length = | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Tunnel-end-Point Sub-TLV | 655 ~ for 170.0.0.1 ~ 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 ~ GRE sub-TLV ~ 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 ~ IPsec-SA-ID sub-TLV #2 ~ 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 6.4. Extended Port Tunnel Encapsulation Attribute Sub-TLV 664 When a SDWAN edge node is connected to an underlay network via a 665 port behind NAT devices, traditional IPsec uses IKE for NAT 666 negotiation. The location of a NAT device can be such that: 667 - Only the initiator is behind a NAT device. Multiple initiators 668 can be behind separate NAT devices. Initiators can also connect 669 to the responder through multiple NAT devices. 670 - Only the responder is behind a NAT device. 671 - Both the initiator and the responder are behind a NAT device. 673 The initiator's address and/or responder's address can be 674 dynamically assigned by an ISP or when their connection crosses a 675 dynamic NAT device that allocates addresses from a dynamic address 676 pool. 678 Because one SDWAN edge can connect to multiple peers via one 679 underlay network, the pair-wise NAT exchange as IPsec's IKE is not 680 efficient. In BGP Controlled SDWAN, NAT information of a WAN port is 681 advertised to its RR in the BGP UPDATE message. It is encoded as an 682 Extended sub-TLV that describes the NAT property if the port is 683 behind a NAT device. 685 An SDWAN edge node can ask a STUN Server (Session Traversal of UDP 686 Through Network Address Translation [RFC3489]) to get the NAT 687 properties, the public IP address and the Public Port number to pass 688 to peers. 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 |Port Ext Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | NAT Type | Encap-Type |Trans networkID| RD ID | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Local IP Address | 697 32-bits for IPv4, 128-bits for Ipv6 698 ~~~~~~~~~~~~ 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Local Port | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Public IP | 704 32-bits for IPv4, 128-bits for Ipv6 705 ~~~~~~~~~~~~ 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Public Port | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | ISP-Sub-TLV | 710 ~ ~ 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Where: 715 o Port Ext Type (TBD3): indicating it is the Port Ext SubTLV. 716 o PortExt subTLV Length: the length of the subTLV. 717 o Flags: 718 - I bit (CPE port address or Inner address scheme) 719 If set to 0, indicate the inner (private) address is IPv4. 720 If set to 1, it indicates the inner address is IPv6. 722 - O bit (Outer address scheme): 723 If set to 0, indicate the public (outer) address is IPv4. 724 If set to 1, it indicates the public (outer) address is 725 IPv6. 727 - R bits: reserved for future use. Must be set to 0 now. 729 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 730 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 731 response from the STUN server). 732 o Encap Type.the supported encapsulation types for the port 733 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 734 without GRE, GRE (when packets don't need encryption) 735 o Transport Network ID.Central Controller assign a global unique 736 ID to each transport network. 737 o RD ID.Routing Domain ID.need to be global unique. 738 o Local IP.The local (or private) IP address of the port. 739 o Local Port.used by Remote SDWAN edge node for establishing 740 IPsec to this specific port. 742 o Public IP.The IP address after the NAT. If NAT is not used, 743 this field is set to NULL. 744 o Public Port.The Port after the NAT. If NAT is not used, this 745 field is set to NULL. 747 6.5. Underlay Network Properties Sub-TLV 749 The purpose of the Underlay Network Sub-TLV is to carry the WAN port 750 properties with SDWAN SAFI NLRI. It would be treated as optional 751 Sub-TLV. The BGP originator decides whether to include this Sub-TLV 752 along with the SDWAN NLRI. If this Sub-TLV is present, it would be 753 processed by the BGP receiver and to determine what local policies 754 to apply for the remote end point of the underlay tunnel. 756 The format of this Sub-TLV is as follows: 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type=TBD4 | Length | Flag | Reserved | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 |Connection Type| Port Type | Port Speed | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 Where: 767 Type: TBD4. 769 Length: always 6 bytes. 771 Flag: a 1 octet value. 773 Reserved: 1 octet of reserved bits. It SHOULD be set to zero on 774 transmission and MUST be ignored on receipt. 776 Connection Type: There are two different types of WAN 777 Connectivity. They are listed below as: 779 Wired - 1 780 WIFI - 2 781 LTE - 3 782 5G - 4 783 Port Type: There are different types of ports. They are listed 784 Below as: 786 Ethernet - 1 787 Fiber Cable - 2 788 Coax Cable - 3 789 Cellular - 4 791 Port Speed: The port seed is defined as 2 octet value. The values 792 are defined as Gigabit speed. 794 7. IPsec SA Property Sub-TLVs 796 This section describes the detailed IPsec SA properties sub-TLVs. 798 7.1. IPsec SA Nonce Sub-TLV 800 The Nonce Sub-TLV is based on the Base DIM sub-TLV as described the 801 Section 6.1 of [SECURE-EVPN]. The IPsec SA ID is included in the 802 sub-TLV, which is to be referenced by the client route NLRI Tunnel 803 Encapsulation Path Attribute for the IPsec SA. The following fields 804 are removed because: 806 - the Originator ID is carried by the NLRI, 807 - the Tenant ID is represented by the SDWAN VPN ID Extended 808 Community, and 809 - the Subnet ID are carried by the BGP route UPDATE. 811 The format of this Sub-TLV is as follows: 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | ID Length | Nonce Length |I| Flags | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Rekey | 819 | Counter | 820 +---------------------------------------------------------------+ 821 | IPsec SA ID | Reserved | 822 +---------------------------------------------------------------+ 823 | | 824 ~ Nonce Data ~ 825 | | 826 +---------------------------------------------------------------+ 828 IPsec SA ID - The 2 bytes IPSec SA ID could 0 or non-zero values. It 829 is cross referenced by client route's IPSec Tunnel Encapsulation 830 IPSec-SA-ID SubTLV in Section 6. When there are multiple IPsec SAs 831 terminated at one address, such as WAN port address or the node 832 address, they are differentiated by the different IPsec SA IDs. 834 7.2. IPsec Public Key Sub-TLV 836 The IPsec Public Key Sub-TLV is derived from the Key Exchange Sub- 837 TLV described in [SECURE-EVPN] with an addition of Duration filed to 838 define the IPSec SA life span. The edge nodes would pick the 839 shortest duration value between the SDWAN SAFI pairs. 841 The format of this Sub-TLV is as follows: 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Diffie-Hellman Group Num | Reserved | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | | 849 ~ Key Exchange Data ~ 850 | | 851 +---------------------------------------------------------------+ 852 | Duration | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 7.3. IPsec SA Proposal Sub-TLV 857 The IPsec SA Proposal Sub-TLV is to indicate the number of Transform 858 Sub-TLVs. This Sub-TLV aligns with the sub-TLV structure from 859 [SECURE-VPN] 861 The Transform Sub-sub-TLV will following the section 3.3.2 of 862 RFC7296. 864 7.4. Simplified IPsec Security Association sub-TLV 866 For a simple SDWAN network with edge nodes supporting only a few 867 pre-defined encryption algorithms, a simple IPsec sub-TLV can be 868 used to encode the pre-defined algorithms, as below: 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 |IPsec-simType |IPsecSA Length | Flag | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Transform | Mode | AH algorithms |ESP algorithms | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | ReKey Counter (SPI) | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | key1 length | Public Key ~ 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | key2 length | Nonce ~ 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Duration | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 Where: 887 o IPsec-SimType: The type value has to be between 128~255 because 888 IPsec-SA subTLV needs 2 bytes for length to carry the needed 889 information. 890 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 891 o Flags: 1 octet of flags. None are defined at this stage. Flags 892 SHOULD be set to zero on transmission and MUST be ignored on 893 receipt. 894 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 896 o IPsec Mode (1 byte): the value can be Tunnel Mode or Transport 897 mode 898 o AH algorithms (1 byte): AH authentication algorithms supported, 899 which can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. 900 Each SDWAN edge node can have multiple authentication. 901 algorithms; send to its peers to negotiate the strongest one. 902 o ESP (1 byte): ESP authentication algorithms supported, which 903 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 904 SDWAN edge node can have multiple authentication algorithms; 905 send to its peers to negotiate the strongest one. Default 906 algorithm is AES-256. 907 o When node supports multiple authentication algorithms, the 908 initial UPDATE needs to include the "Transform Sub-TLV" 909 described by [SECURE-EVPN] to describe all of the 910 algorithms supported by the node. 912 o Rekey Counter (Security Parameter Index)): 4 bytes 913 o Public Key: IPsec public key 914 o Nonce.IPsec Nonce 915 o Duration: SA life span. 917 7.5. IPsec SA Encoding Examples 919 For the Figure 1 in Section 3, C-PE2 needs to advertise its IPsec SA 920 associated attributes, such as the public keys, the nonce, the 921 supported encryption algorithms for the IPsec tunnels terminated at 922 192.0.0.1, 170.1.1.1 and 2.2.2.2 respectively. 924 Using the IPsec Tunnel [ISP4: 160.0.0.1 <-> ISP2:170.0.0.1] as an 925 example: C-PE1 needs to advertise the following attributes for 926 establishing the IPsec SA: 927 SDWAN Node ID 928 SDWAN Color 929 Tunnel Encap Attr (Type=SDWAN-Hybrid) 930 Extended Port Sub-TLV for information about the Port 931 (including ISP Sub-TLV for information about the ISP2) 932 IPsec SA Nonce Sub-TLV, 933 IPsec SA Public Key Sub-TLV, 934 IPsec SA Sub-TLV for the supported transforms 935 {Transforms Sub-TLV - Trans 2, 936 Transforms Sub-TLV - Trans 3} 938 C-PE2 needs to advertise the following attributes for establishing 939 IPsec SA: 940 SDWAN Node ID 941 SDWAN Color 942 Tunnel Encap Attr (Type=SDWAN-Hybrid) 943 Extended Port Sub-TLV (including ISP Sub-TLV for information 944 about the ISP2) 945 IPsec SA Nonce Sub-TLV, 946 IPsec SA Public Key Sub-TLV, 947 IPsec SA Sub-TLV for the supported transforms 948 {Transforms Sub-TLV - Trans 2, 949 Transforms Sub-TLV - Trans 4} 951 As both end points support Transform #2, the Transform #2 will be 952 used for the IPsec Tunnel [ISP4: 160.0.0.1 <-> ISP2:170.0.0.1]. 954 8. Error & Mismatch Handling 956 Each C-PE device advertises a SDWAN SAFI Underlay NLRI to the other 957 C-PE devices via a BGP Route Reflector to establish pairwise SAs 958 between itself and every other remote C-PEs. During the SAFI NLRI 959 advertisement, the BGP originator would include either simple IPSec 960 Security Association properties defined in IPSec SA Sub-TLV based on 961 IPSec-SA-Type = 1 or full-set of IPSec Sub-TLVs including Nonce, 962 Public Key, Proposal and number of Transform Sub-TLVs based on 963 IPSec-SA-Type = 2. 965 The C-PE devices compare the IPSec SA attributes between the local 966 and remote WAN ports. If there is a match on the SA Attributes 967 between the two ports, the IPSec Tunnel is established. 969 The C-PE devices would not try to negotiate the base IPSec-SA 970 parameters between the local and the remote ports in the case of 971 simple IPSec SA exchange or the Transform sets between local and 972 remote ports if there is a mismatch on the Transform sets in the 973 case of full-set of IPSec SA Sub-TLVs. 975 As an example, using the Figure 1 in Section 3, to establish IPsec 976 Tunnel between C-PE1 and C-PE2 WAN Ports A2 and B2 [A2: 192.10.0.10 977 <-> B2:192.0.0.1]: 979 C-PE1 needs to advertise the following attributes for establishing 980 the IPsec SA: 981 NH: 192.10.0.10 982 SDWAN Node ID 983 SDWAN-Site-ID 984 Tunnel Encap Attr (Type=SDWAN) 985 ISP Sub-TLV for information about the ISP3 986 IPsec SA Nonce Sub-TLV, 987 IPsec SA Public Key Sub-TLV, 988 Proposal Sub-TLV with Num Transforms = 1 989 {Transforms Sub-TLV - Trans 1} 991 C-PE2 needs to advertise the following attributes for establishing 992 IPsec SA: 993 NH: 192.0.0.1 994 SDWAN Node ID 995 SDWAN-Site-ID 996 Tunnel Encap Attr (Type=SDWAN) 997 ISP Sub-TLV for information about the ISP1 998 IPsec SA Nonce Sub-TLV, 999 IPsec SA Public Key Sub-TLV, 1000 Proposal Sub-TLV with Num Transforms = 1 1001 {Transforms Sub-TLV - Trans 2} 1003 As there is no matching transform between the WAN ports A2 and B2 in 1004 C-PE1 and C-PE2 respectively, there will be no IPsec Tunnel be 1005 established. 1007 9. Manageability Considerations 1009 TBD - this needs to be filled out before publishing 1011 10. Security Considerations 1013 The document describes the encoding for SDWAN edge nodes to 1014 advertise its properties to their peers to its RR, which 1015 propagates to the intended peers via untrusted networks. 1017 The secure propagation is achieved by secure channels, such as 1018 TLS, SSL, or IPsec, between the SDWAN edge nodes and the local 1019 controller RR. 1021 [More details need to be filled in here] 1023 11. IANA Considerations 1024 11.1. Hybrid (SDWAN) Overlay SAFI 1026 IANA has assigned SAFI = 74 as the Hybrid (SDWAN)SAFI. 1028 11.2. Tunnel Encapsulation Attribute Type 1030 IANA is requested to assign a type from the BGP Tunnel Encapsulation 1031 Attribute Tunnel Types as follows: 1033 Value Description Reference 1034 ----- ------------ --------- 1035 TBD1 SDWAN-Hybrid [this document] 1037 11.3 Tunnel Encapsulation Attribute Sub-TLV Types 1039 IANA is requested to assign three Types, as follows, in the BGP Tunnel 1040 Encapsulation Attribute Sub-TLVs regustry: 1042 Value Description Reference 1043 ----- ----------------------- --------------- 1044 TBD2 IPSEC-SA-ID [this document] 1045 TBD3 Port Extension [this document] 1046 TBD4 Underlay ISP Properties [this document] 1048 12. References 1050 12.1. Normative References 1052 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1053 Requirement Levels", BCP 14, RFC 2119, March 1997. 1055 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1056 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 1057 10.17487/RFC4271, January 2006, . 1060 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1061 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 1062 10.17487/RFC4760, January 2007, . 1065 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1066 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1067 May 2017, . 1069 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1070 "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 1071 10.17487/RFC9012, April 2021, . 1074 12.2. Informative References 1076 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 1077 (I2NSF) Problem Statement and Use Cases", July 2017 1079 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 1080 Address Family Identifier (SAFI) and the BGP Tunnel 1081 Encapsulation Attribute", April 2009. 1083 [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 1084 Garcia, "A YANG Data Model for IPsec Flow Protection Based 1085 on Software-Defined Networking (SDN)", RFC 9061, DOI 1086 10.17487/RFC9061, July 2021, . 1089 [CONTROLLER-IKE] D. Carrel, et al, "IPsec Key Exchange using a 1090 Controller", draft-carrel-ipsecme-controller-ike-01, work- 1091 in-progress. 1093 [LISP-GEOLOC] D. Farinacci, "LISP Geo-Coordinate Use-Case", draft- 1094 farinacci-lisp-geo-09, April 2020. 1096 [SDN-IPSEC] R. Lopez, G. Millan, "SDN-based IPsec Flow Protection", 1097 draft-ietf-i2nsf-sdn-ipsec-flow-protection-07, Aug 2019. 1099 [SECURE-EVPN] A. Sajassi, et al, "Secure EVPN", draft-sajassi-bess- 1100 secure-evpn-02, July 2019. 1102 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 1103 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 1104 work-in-progress, July 2018 1106 [DMVPN] Dynamic Multi-point VPN: 1107 https://www.cisco.com/c/en/us/products/security/dynamic- 1108 multipoint-vpn-dmvpn/index.html 1110 [DSVPN] Dynamic Smart VPN: 1111 http://forum.huawei.com/enterprise/en/thread-390771-1- 1112 1.html 1114 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 1115 storage, distribution and enforcement of policies for 1116 network security", Nov 2007. 1118 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 1119 Underlay to Cloud Overlay Problem Statement", draft-dm- 1120 net2cloud-problem-statement-02, June 2018 1122 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 1123 of Interconnecting Underlay with Cloud Overlay", draft-dm- 1124 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 1126 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 1127 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 1129 13. Acknowledgments 1131 Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for 1132 implementation contribution; Many thanks to Yoav Nir, Graham 1133 Bartlett, Jim Guichard, John Scudder, and Donald Eastlake for their 1134 review and suggestions. 1136 This document was prepared using 2-Word-v2.0.template.dot. 1138 Authors' Addresses 1140 Linda Dunbar 1141 Futurewei 1142 Email: ldunbar@futurewei.com 1144 Sue Hares 1145 Hickory Hill Consulting 1146 Email: shares@ndzh.com 1148 Robert Raszuk 1149 NTT Network Innovations 1150 Email: robert@raszuk.net 1152 Kausik Majumdar 1153 CommScope 1154 Email: Kausik.Majumdar@commscope.com 1156 Gyan Mishra 1157 Verizon Inc. 1158 Email: gyan.s.mishra@verizon.com 1160 Contributors' Addresses 1161 Donald Eastlake 1162 Futurewei 1163 Email: d3e3e3@gmail.com