idnits 2.17.1 draft-ietf-idr-sdwan-edge-discovery-01.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 (March 5, 2022) is 775 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 258, but not defined == Missing Reference: 'RFC4364' is mentioned on line 136, but not defined == Missing Reference: 'Tunnel-encap' is mentioned on line 329, but not defined == Missing Reference: 'RFC9016' is mentioned on line 375, but not defined == Missing Reference: 'RFC4684' is mentioned on line 428, but not defined == Missing Reference: 'RFC8277' is mentioned on line 485, but not defined == Missing Reference: 'RFC3489' is mentioned on line 689, but not defined ** Obsolete undefined reference: RFC 3489 (Obsoleted by RFC 5389) == Missing Reference: 'SECURE-VPN' is mentioned on line 862, but not defined == Unused Reference: 'RFC8192' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 1082, but no explicit reference was found in the text == Unused Reference: 'RFC9061' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: 'CONTROLLER-IKE' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'LISP-GEOLOC' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'SDN-IPSEC' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 1105, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 1117, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-Problem' is defined on line 1121, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 1129, 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: September 5, 2022 Hickory Hill Consulting 5 R. Raszuk 6 NTT Network Innovations 7 K. Majumdar 8 CommScope 9 Gyan Mishra 10 Verizon 11 March 5, 2022 13 BGP UPDATE for SDWAN Edge Discovery 14 draft-ietf-idr-sdwan-edge-discovery-01 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 31, 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 an SDWAN edge node to 180 discover its authorized peers and their associated properties to 181 establish secure tunnels. The attributes to be propagated includes: 183 - the SDWAN (client) VPNs information, 184 - the attached routes under the SDWAN VPNs, 185 - the properties of the underlay networks over which the client 186 routes can be carried, and potentially more. 188 Some SDWAN peers are connected by both trusted VPNs and untrusted 189 public networks. Some SDWAN peers are connected only by untrusted 190 public networks. For the traffic over untrusted networks, IPsec 191 Security Associations (IPsec SA) must be established and maintained. 192 If an edge node has network ports behind a NAT, the NAT properties 193 need to be discovered by the authorized SDWAN peers. 195 Like any VPN networks, the attached client's routes belonging to 196 specific SDWAN VPNs can only be exchanged with the SDWAN peer nodes 197 authorized to communicate. 199 3.2. Comparing with Pure IPsec VPN 201 A pure IPsec VPN has IPsec tunnels connecting all edge nodes over 202 public networks. Therefore, it requires stringent authentication and 203 authorization (i.e., IKE Phase 1) before other properties of IPsec 204 SA can be exchanged. The IPsec Security Association (SA) between two 205 untrusted nodes typically requires the following configurations and 206 message exchanges: 208 - IPsec IKE to authenticate with each other 209 - Establish IPsec SA 210 o Local key configuration 211 o Remote Peer address (192.10.0.10<->172.0.01) 212 o IKEv2 Proposal directly sent to peer 213 o Encryption method, Integrity sha512 214 o Transform set 215 - Attached client prefixes discovery 216 o By running routing protocol within each IPsec SA 217 o If multiple IPsec SAs between two peer nodes are 218 established to achieve load sharing, each IPsec tunnel 219 needs to run its own routing protocol to exchange client 220 routes attached to the edges. 221 - Access List or Traffic Selector) 222 o Permit Local-IP1, Remote-IP2 224 In a BGP-controlled SDWAN network over hybrid MPLS VPN and public 225 internet underlay networks, all edge nodes and RRs are already 226 connected by private VPN paths. The RRs have the policies to manage 227 the authentication of all peer nodes. More importantly, when an edge 228 node needs to establish multiple IPsec tunnels to many edge nodes, 229 all the management information can be multiplexed into the secure 230 management tunnel between RR and the edge node. Therefore, the 231 amount of authentication in a BGP-Controlled SDWAN network can be 232 significantly reduced. 234 Client VPNs are configured via VRFs, just like the configuration of 235 the existing MPLS VPN. The IPsec equivalent traffic selectors for 236 local and remote routes are achieved by importing/exporting VPN 237 Route Targets. The binding of client routes to IPsec SA is dictated 238 by policies. As a result, the IPsec configuration for a BGP 239 controlled SDWAN (with mixed MPLS VPN) can be simplified as the 240 following: 242 - The SDWAN controller has the authority to authenticate edges 243 and peers. Remote Peer association is controlled by the SDWAN 244 Controller (RR) 245 - The IKEv2 proposals, including the IPsec Transform set, can 246 be sent directly to peers or incorporated in a BGP UPDATE. 247 - BGP UPDATE: Announces the client route reachability for all 248 permitted parallel tunnels/paths. 249 o There is no need to run multiple routing protocols in 250 each IPsec tunnel. 252 - Importing/exporting Route Targets under each client VPN (VRF) 253 achieves the traffic selection (or permission) among clients' 254 routes attached to multiple edge nodes. 256 3.3. Client Route UPDATE and Hybrid Underlay Tunnel UPDATE 258 As described in [SDWAN-BGP-USAGE], two separate BGP UPDATE messages 259 are used for SDWAN Edge Discovery: 261 - UPDATE U1 for advertising the attached client routes, 262 This UPDATE is precisely the same as the BGP edge client route 263 UPDATE. It uses the Encapsulation Extended Community and the 264 Color Extended Community to link with the Underlay Tunnels 265 UPDATE Message as specified in section 8 of [RFC9012]. 267 A new Tunnel Type (SDWAN-Hybrid) is added and used by the 268 Encapsulation Extended Community or the Tunnel-Encap Path 269 Attribute [RFC9012] to indicate mixed underlay networks. 271 - UPDATE U2 advertises the properties of the various tunnels, 272 including IPsec, terminated at the edge node. 273 This UPDATE is for an edge node to advertise the properties of 274 directly attached underlay networks, including the NAT 275 information, pre-configured IPsec SA identifiers, and/or the 276 underlay network ISP information. This UPDATE can also include 277 the detailed IPsec SA attributes, such as keys, nonce, 278 encryption algorithms, etc. 280 In the following figure: there are four types underlay paths between 281 C-PE1 and C-PE2: 283 a) MPLS-in-GRE path. 285 b) node-based IPsec tunnel [2.2.2.2<->1.1.1.1]. 287 c) port-based IPsec tunnel [192.0.0.1 <-> 192.10.0.10]; and 289 d) port-based IPsec tunnel [172.0.0.1 <-> 160.0.0.1]. 291 +---+ 292 +--------------|RR |----------+ 293 / Untrusted +-+-+ \ 294 / \ 295 / \ 296 +---------+ MPLS Path +-------+ 297 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 298 | | | | 299 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 300 | | | | 301 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr | 302 | 1.1.1.1 | |2.2.2.2| 303 +---------+ +-------+ 305 Figure 1: Hybrid SDWAN 307 C-PE2 uses UPDATE U1 to advertise the attached client routes: 309 UDPATE U1: 311 Extended community: RT for SDWAN VPN 1 312 NLRI: AFI=? & SAFI = 1/1 313 Prefix: 10.1.1.x; 20.1.1.x 314 NextHop: 2.2.2.2 (C-PE2) 315 Encapsulation Extended Community: tunnel-type=SDWAN-Hybrid 316 Color Extended Community: RED 318 The UPDATE U1 is recursively resolved to the UPDATE U2 which 319 specifies the detailed hybrid WAN underlay tunnels terminated at the 320 C-PE2: 322 UPDATE U2: 324 NLRI: SAFI = SDWAN-Hybrid 325 (With Color RED encoded in the NLRI Site-Property field) 326 Prefix: 2.2.2.2 327 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] 328 IPSec SA for 192.0.0.1 329 Tunnel-End-Point Sub-TLV for 192.0.0.1 [Tunnel-encap] 330 IPsec-SA-ID sub-TLV [See the Section 6] 331 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] 332 IPSec SA for 333 Tunnel-End-Point Sub-TLV /* for 170.0.0.1 */ 334 IPsec-SA-ID sub-TLV 335 Tunnel Encap Attr MPLS-in-GRE [type=SDWAN-Hybrid] 336 Sub-TLV for MPLS-in-GRE [Section 3.2.6 of Tunnel-encap] 338 Note: [RFC9012] Section 11 specifies that each Tunnel Encap 339 Attribute can only have one Tunnel-End-Point sub-TLV. Therefore, two 340 separate Tunnel Encap Attributes are needed to indicate that the 341 client routes can be carried by either one. 343 3.4. Edge Node Discovery 345 The basic scheme of SDWAN edge node discovery using BGP consists of 346 the following: 348 - Secure connection to a SDWAN controller (i.e., RR in this 349 context): 350 For an SDWAN edge with both MPLS and IPsec paths, the edge node 351 should already have a secure connection to its controller, 352 i.e., RR in this context. For an SDWAN edge that is only 353 accessible via Internet, the SDWAN edge, upon power-up, 354 establishes a secure tunnel (such as TLS or SSL) with the SDWAN 355 central controller whose address is preconfigured on the edge 356 node. The central controller informs the edge node of its local 357 RR. The edge node then establishes a transport layer secure 358 session with the RR (such as TLS or SSL). 360 - The Edge node will advertise its own properties to its 361 designated RR via the secure connection. 363 - The RR propagates the received information to the authorized 364 peers. 366 - The authorized peers can establish the secure data channels 367 (IPsec) and exchange more information among each other. 368 For an SDWAN deployment with multiple RRs, it is assumed that there 369 are secure connections among those RRs. How secure connections are 370 established among those RRs is out of the scope of this document. 371 The existing BGP UPDATE propagation mechanisms control the edge 372 properties propagation among the RRs. 374 For some environments where the communication to RR is highly 375 secured, [RFC9016] IKE-less can be deployed to simplify IPsec SA 376 establishment among edge nodes. 378 4. BGP UPDATE to Support SDWAN Segmentation 379 4.1. SDWAN Segmentation, SDWAN Virtual Topology and Client VPN 381 In SDWAN deployment, "SDWAN Segmentation" is a frequently used term, 382 referring to partitioning a network to multiple sub-networks, just 383 as MPLS VPN does. "SDWAN Segmentation" is achieved by creating SDWAN 384 virtual topologies and SDWAN VPNs. An SDWAN virtual topology 385 consists of a set of edge nodes and the tunnels (a.k.a. underlay 386 paths), including both IPsec tunnels and/or MPLS VPN tunnels, 387 interconnecting those edge nodes. 389 An SDWAN VPN is the same as a client VPN, which is configured in the 390 same way as the VRFs on PEs of an MPLS VPN. One SDWAN client VPN can 391 be mapped to multiple SD-WAN virtual topologies. SDWAN Controller 392 governs the policies of mapping a client VPN to SDWAN virtual 393 topologies. 395 Each SDWAN edge node may need to support multiple VPNs. Just as a 396 Route Target is used to distinguish different MPLS VPNs, an SDWAN 397 VPN ID is used to differentiate the SDWAN VPNs. For example, in the 398 picture below, the "Payment-Flow" on C-PE2 is only mapped to the 399 virtual topology of C-PEs to/from Payment Gateway, whereas other 400 flows can be mapped to a multipoint-to-multipoint virtual topology. 402 +---+ 403 +--------------|RR |----------+ 404 / Untrusted +-+-+ \ 405 / \ 406 / \ 407 +---------+ MPLS Path +-------+ 408 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 409 | | | | 410 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 411 | | | | 412 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr |11.2.2.x 413 | 1.1.1.1 | / |2.2.2.2| 414 +---------+ / +-------+ 415 \ / 416 \ /PaymentFlow 417 \ / 418 \ +----+----+ 419 +---------------| payment | 420 | Gateway | 421 +---------+ 423 Figure 2: SDWAN Virtual Topology & VPN 425 4.2. Constrained Propagation of Edge Capability 427 BGP has a built-in mechanism to dynamically achieve the 428 constrained distribution of edge information. [RFC4684] describes 429 the BGP RT constrained distribution. In a nutshell, an SDWAN edge 430 sends RT Constraint (RTC) NLRI to the RR for the RR to install an 431 outbound route filter, as shown in the figure below: 433 RT Constraint RT constraint 434 NLRI={SDWAN#1, SDWAN#2} NLRI={SDWAN#1, SDWAN#3} 435 -----> +---+ <----------- 436 +--------------------|RR1|------------------+ 437 | Outbound Filter +---+ Outbound Filter | 438 | Permit SDWAN#1,#2 Permit SDWAN#1,#3| 439 | Deny all Deny all | 440 | <------- ---------> | 441 | | 442 +-----+---+ MPLS Path +-----+-+ 443 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 444 | | | | 445 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 446 | | | | 447 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr | 448 | 1.1.1.1 | |2.2.2.2| 449 +---------+ +-------+ 450 SDWAN VPN #1 SDWAN VPN #1 451 SDWAN VPN #2 SDWAN VPN #3 452 Figure 3: Constraint propagation of Edge Property 454 However, a SDWAN overlay network can span across untrusted 455 networks, RR can't trust the RT Constraint (RTC) NLRI BGP UPDATE 456 from any nodes. RR can only process the RTC NLRI from authorized 457 peers for a SDWAN VPN. 459 It is out of the scope of this document on how RR is configured 460 with the policies to filter out unauthorized nodes for specific 461 SDWAN VPNs. 463 When the RR receives BGP UPDATE from an edge node, it propagates 464 the received UPDATE message to the nodes that are in the Outbound 465 Route filter for the specific SDWAN VPN. 467 5. Client Route UPDATE 469 The SDWAN network's Client Route UPDATE message is the same as the 470 MPLS VPN client route UDPATE message. The SDWAN Client Route UPDATE 471 message uses the Encapsulation Extended Community and the Color 472 Extended Community to link with the Underlay Tunnels UPDATE Message. 474 5.1. SDWAN VPN ID in Client Route Update 476 An SDWAN VPN is same as a client VPN in a BGP controlled SDWAN 477 network. The Route Target Extended Community should be included in a 478 Client Route UPDATE message to differentiate the client routes from 479 routes belonging to other VPNs. 481 5.2. SDWAN VPN ID in Data Plane 483 For an SDWAN edge node which can be reached by both MPLS and IPsec 484 paths, the client packets reached by MPLS network will be encoded 485 with the MPLS Labels based on the scheme specified by [RFC8277]. 487 For GRE Encapsulation within an IPsec tunnel, the GRE key field can 488 be used to carry the SDWAN VPN ID. For network virtual overlay 489 (VxLAN, GENEVE, etc.) encapsulation within the IPsec tunnel, the 490 Virtual Network Identifier (VNI) field is used to carry the SDWAN 491 VPN ID. 493 6. Hybrid Underlay Tunnel UPDATE 495 The hybrid underlay tunnel UPDATE is to advertise the detailed 496 properties of hybrid types of tunnels terminated at a SDWAN edge 497 node. 499 A client route UDPATE is recursively tied to an underlay tunnel 500 UDPATE by the Color Extended Community included in client route 501 UPDATE. 503 6.1. NLRI for Hybrid Underlay Tunnel Update 505 A new NLRI is introduced within the MP_REACH_NLRI Path Attribute of 506 RFC4760, for advertising the detailed properties of hybrid types of 507 tunnels terminated at the edge node, with SAFI=SDWAN (code = 74): 509 +------------------+ 510 | NLRI Length | 1 octet 511 +------------------+ 512 | Site-Type | 2 Octet 513 +------------------+ 514 | Port-Local-ID | 4 octets 515 +------------------+ 516 | SDWAN-Color | 4 octets 517 +------------------+ 518 | SDWAN-Node-ID | 4 or 16 octets 519 +------------------+ 521 where: 523 - NLRI Length: 1 octet of length expressed in bits as defined in 524 [RFC4760]. 525 - Site Type: 2 octet value. The SDWAN Site Type defines the 526 different types of Site IDs to be used in the deployment. This 527 document defines the following types: 528 Site-Type = 1: For a simple deployment, such as all edge 529 nodes under one SDWAN management system, the node ID is 530 enough for the SDWAN management to map the site to its 531 precise geolocation. 532 Site-Type = 2: For large SDWAN heterogeneous deployment where 533 a Geo-Loc Sub-TLV [LISP-GEOLoc]is needed to fully describe 534 the accurate location of the node. 535 - Port local ID: SDWAN edge node Port identifier, which is locally 536 significant. If the SDWAN NLRI applies to multiple ports, this 537 field is NULL. 538 - SDWAN-Color: to correlate with the Color-Extended-community 539 included in the client routes UPDATE. 540 - SDWAN Edge Node ID: The node's IPv4 or IPv6 address. 542 6.2. SDWAN-Hybrid Tunnel Encoding 544 A new BGP Tunnel-Type=SDWAN-Hybrid (code point TBD1) is specified 545 for the Tunnel Encapsulation Attribute to indicate hybrid underlay 546 networks. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Tunnel-Type(=SDWAN-Hybrid ) | Length (2 Octets) | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Sub-TLVs | 554 | | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 SDWAN Hybrid Underlay network Sub-TLV Value Field 558 6.3. IPsec-SA-ID Sub-TLV 560 IPsec-SA-ID Sub-TLV for the Hybrid Underlay Tunnel UPDATE indicates 561 one or more preestablished IPsec SAs by using their identifiers, 562 instead of listing all the detailed attributes of the IPsec SAs. 564 Using an IPsec-SA-ID Sub-TLV not only greatly reduces the size of 565 BGP UPDATE messages, but also allows the pairwise IPsec rekeying 566 process to be performed independently. 568 The following is the structure of the IPsec-SA-ID sub-TLV: 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 |Type= IPsec-SA-ID subTLV (TBD2)| Length (2 Octets) | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | IPsec SA Identifier #1 | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | IPsec SA Identifier #2 | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 If the client traffic needs to be encapsulated in a specific way 580 within the IPsec ESP Tunnel, such as GRE or VxLAN, etc., the 581 corresponding Tunnel-Encap Sub-TLV needs to be prepended right 582 before the IPsec-SA-ID Sub-TLV. 584 6.3.1. Encoding example #1 of using IPsec-SA-ID Sub-TLV 586 This section provides an encoding example for the following 587 scenario: 589 - There are four IPsec SAs terminated at the same WAN Port 590 address (or the same node address) 591 - Two of the IPsec SAs use GRE (value =2) as Inner Encapsulation 592 within the IPsec Tunnel 593 - two of the IPsec SA uses VxLAN (value = 8) as the Inner 594 Encapsulation within its IPsec Tunnel. 596 Here is the encoding for the scenario: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Tunnel-Type =SDWAN-Hybrid | Length = | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Tunnel-end-Point Sub-TLV | 604 ~ ~ 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 ~ GRE Sub-TLV ~ 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | subTLV-Type = IPsec-SA-ID | Length = | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | IPsec SA Identifier = 1 | 611 +---------------------------------------------------------------+ 612 | IPsec SA Identifier = 2 | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 ~ VxLAN Sub-TLV ~ 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 |subTLV-Type = IPsec-SA-ID | Length= | 617 +-------------------------------+-------------------------------+ 618 | IPsec SA Identifier = 3 | 619 +-------------------------------+-------------------------------+ 620 | IPsec SA Identifier = 4 | 621 +---------------------------------------------------------------+ 623 The Length of the Tunnel-Type = SDDWAN-Hybrid is the sum of the 624 following: 625 - Tunnel-end-point sub-TLV total length 626 - The GRE Sub-TLV total length, 627 - The IPsec-SA-ID Sub-TLV length, 628 - The VxLAN sub-TLV total length, and 629 - The IPsec-SA-ID Sub-TLV length. 631 6.3.2. Encoding Example #2 of using IPsec-SA-ID Sub-TLV 633 For IPsec SAs terminated at different endpoints, multiple Tunnel Encap 634 Attributes must be included. This section provides an encoding example for 635 the following scenario: 637 - there is one IPsec SA terminated at the WAN Port address 638 192.0.0.1; and another IPsec SA terminated at WAN Port 639 170.0.0.1; 640 - Both IPsec SAs use GRE (value =2) as Inner Encapsulation within 641 the IPsec Tunnel 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Tunnel-Type =SDWAN-Hybrid | Length = | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Tunnel-end-Point Sub-TLV | 649 ~ for 192.0.0.1 ~ 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 ~ GRE Sub-TLV ~ 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 ~ IPsec-SA-ID sub-TLV #1 ~ 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Tunnel-Type =SDWAN-Hybrid | Length = | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Tunnel-end-Point Sub-TLV | 658 ~ for 170.0.0.1 ~ 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 ~ GRE sub-TLV ~ 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 ~ IPsec-SA-ID sub-TLV #2 ~ 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 6.4. Extended Port Tunnel Encapsulation Attribute Sub-TLV 667 When a SDWAN edge node is connected to an underlay network via a 668 port behind NAT devices, traditional IPsec uses IKE for NAT 669 negotiation. The location of a NAT device can be such that: 670 - Only the initiator is behind a NAT device. Multiple initiators 671 can be behind separate NAT devices. Initiators can also connect 672 to the responder through multiple NAT devices. 673 - Only the responder is behind a NAT device. 674 - Both the initiator and the responder are behind a NAT device. 676 The initiator's address and/or responder's address can be 677 dynamically assigned by an ISP or when their connection crosses a 678 dynamic NAT device that allocates addresses from a dynamic address 679 pool. 681 Because one SDWAN edge can connect to multiple peers via one 682 underlay network, the pair-wise NAT exchange as IPsec's IKE is not 683 efficient. In BGP Controlled SDWAN, NAT information of a WAN port is 684 advertised to its RR in the BGP UPDATE message. It is encoded as an 685 Extended sub-TLV that describes the NAT property if the port is 686 behind a NAT device. 688 An SDWAN edge node can ask a STUN Server (Session Traversal of UDP 689 Through Network Address Translation [RFC3489]) to get the NAT 690 properties, the public IP address and the Public Port number to pass 691 to peers. 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 |Port Ext Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | NAT Type | Encap-Type |Trans networkID| RD ID | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Local IP Address | 700 32-bits for IPv4, 128-bits for Ipv6 701 ~~~~~~~~~~~~ 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Local Port | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Public IP | 707 32-bits for IPv4, 128-bits for Ipv6 708 ~~~~~~~~~~~~ 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Public Port | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | ISP-Sub-TLV | 713 ~ ~ 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 Where: 718 o Port Ext Type (TBD3): indicating it is the Port Ext SubTLV. 719 o PortExt subTLV Length: the length of the subTLV. 720 o Flags: 721 - I bit (CPE port address or Inner address scheme) 722 If set to 0, indicate the inner (private) address is IPv4. 723 If set to 1, it indicates the inner address is IPv6. 725 - O bit (Outer address scheme): 726 If set to 0, indicate the public (outer) address is IPv4. 727 If set to 1, it indicates the public (outer) address is 728 IPv6. 730 - R bits: reserved for future use. Must be set to 0 now. 732 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 733 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 734 response from the STUN server). 735 o Encap Type.the supported encapsulation types for the port 736 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 737 without GRE, GRE (when packets don't need encryption) 738 o Transport Network ID.Central Controller assign a global unique 739 ID to each transport network. 740 o RD ID.Routing Domain ID.need to be global unique. 741 o Local IP.The local (or private) IP address of the port. 742 o Local Port.used by Remote SDWAN edge node for establishing 743 IPsec to this specific port. 745 o Public IP.The IP address after the NAT. If NAT is not used, 746 this field is set to NULL. 747 o Public Port.The Port after the NAT. If NAT is not used, this 748 field is set to NULL. 750 6.5. Underlay Network Properties Sub-TLV 752 The purpose of the Underlay Network Sub-TLV is to carry the WAN port 753 properties with SDWAN SAFI NLRI. It would be treated as optional 754 Sub-TLV. The BGP originator decides whether to include this Sub-TLV 755 along with the SDWAN NLRI. If this Sub-TLV is present, it would be 756 processed by the BGP receiver and to determine what local policies 757 to apply for the remote end point of the underlay tunnel. 759 The format of this Sub-TLV is as follows: 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Type=TBD4 | Length | Flag | Reserved | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 |Connection Type| Port Type | Port Speed | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Where: 770 Type: TBD4. 772 Length: always 6 bytes. 774 Flag: a 1 octet value. 776 Reserved: 1 octet of reserved bits. It SHOULD be set to zero on 777 transmission and MUST be ignored on receipt. 779 Connection Type: There are two different types of WAN 780 Connectivity. They are listed below as: 782 Wired - 1 783 WIFI - 2 784 LTE - 3 785 5G - 4 786 Port Type: There are different types of ports. They are listed 787 Below as: 789 Ethernet - 1 790 Fiber Cable - 2 791 Coax Cable - 3 792 Cellular - 4 794 Port Speed: The port seed is defined as 2 octet value. The values 795 are defined as Gigabit speed. 797 7. IPsec SA Property Sub-TLVs 799 This section describes the detailed IPsec SA properties sub-TLVs. 801 7.1. IPsec SA Nonce Sub-TLV 803 The Nonce Sub-TLV is based on the Base DIM sub-TLV as described the 804 Section 6.1 of [SECURE-EVPN]. The IPsec SA ID is included in the 805 sub-TLV, which is to be referenced by the client route NLRI Tunnel 806 Encapsulation Path Attribute for the IPsec SA. The following fields 807 are removed because: 809 - the Originator ID is carried by the NLRI, 810 - the Tenant ID is represented by the SDWAN VPN ID Extended 811 Community, and 812 - the Subnet ID are carried by the BGP route UPDATE. 814 The format of this Sub-TLV is as follows: 816 0 1 2 3 817 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 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | ID Length | Nonce Length |I| Flags | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Rekey | 822 | Counter | 823 +---------------------------------------------------------------+ 824 | IPsec SA ID | Reserved | 825 +---------------------------------------------------------------+ 826 | | 827 ~ Nonce Data ~ 828 | | 829 +---------------------------------------------------------------+ 831 IPsec SA ID - The 2 bytes IPSec SA ID could 0 or non-zero values. It 832 is cross referenced by client route's IPSec Tunnel Encapsulation 833 IPSec-SA-ID SubTLV in Section 6. When there are multiple IPsec SAs 834 terminated at one address, such as WAN port address or the node 835 address, they are differentiated by the different IPsec SA IDs. 837 7.2. IPsec Public Key Sub-TLV 839 The IPsec Public Key Sub-TLV is derived from the Key Exchange Sub- 840 TLV described in [SECURE-EVPN] with an addition of Duration filed to 841 define the IPSec SA life span. The edge nodes would pick the 842 shortest duration value between the SDWAN SAFI pairs. 844 The format of this Sub-TLV is as follows: 846 0 1 2 3 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 | Diffie-Hellman Group Num | Reserved | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | | 852 ~ Key Exchange Data ~ 853 | | 854 +---------------------------------------------------------------+ 855 | Duration | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 7.3. IPsec SA Proposal Sub-TLV 860 The IPsec SA Proposal Sub-TLV is to indicate the number of Transform 861 Sub-TLVs. This Sub-TLV aligns with the sub-TLV structure from 862 [SECURE-VPN] 864 The Transform Sub-sub-TLV will following the section 3.3.2 of 865 RFC7296. 867 7.4. Simplified IPsec Security Association sub-TLV 869 For a simple SDWAN network with edge nodes supporting only a few 870 pre-defined encryption algorithms, a simple IPsec sub-TLV can be 871 used to encode the pre-defined algorithms, as below: 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 |IPsec-simType |IPsecSA Length | Flag | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Transform | Mode | AH algorithms |ESP algorithms | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | ReKey Counter (SPI) | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | key1 length | Public Key ~ 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | key2 length | Nonce ~ 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Duration | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 Where: 890 o IPsec-SimType: The type value has to be between 128~255 because 891 IPsec-SA subTLV needs 2 bytes for length to carry the needed 892 information. 893 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 894 o Flags: 1 octet of flags. None are defined at this stage. Flags 895 SHOULD be set to zero on transmission and MUST be ignored on 896 receipt. 897 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 899 o IPsec Mode (1 byte): the value can be Tunnel Mode or Transport 900 mode 901 o AH algorithms (1 byte): AH authentication algorithms supported, 902 which can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. 903 Each SDWAN edge node can have multiple authentication. 904 algorithms; send to its peers to negotiate the strongest one. 905 o ESP (1 byte): ESP authentication algorithms supported, which 906 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 907 SDWAN edge node can have multiple authentication algorithms; 908 send to its peers to negotiate the strongest one. Default 909 algorithm is AES-256. 910 o When node supports multiple authentication algorithms, the 911 initial UPDATE needs to include the "Transform Sub-TLV" 912 described by [SECURE-EVPN] to describe all of the 913 algorithms supported by the node. 915 o Rekey Counter (Security Parameter Index)): 4 bytes 916 o Public Key: IPsec public key 917 o Nonce.IPsec Nonce 918 o Duration: SA life span. 920 7.5. IPsec SA Encoding Examples 922 For the Figure 1 in Section 3, C-PE2 needs to advertise its IPsec SA 923 associated attributes, such as the public keys, the nonce, the 924 supported encryption algorithms for the IPsec tunnels terminated at 925 192.0.0.1, 170.1.1.1 and 2.2.2.2 respectively. 927 Using the IPsec Tunnel [ISP4: 160.0.0.1 <-> ISP2:170.0.0.1] as an 928 example: C-PE1 needs to advertise the following attributes for 929 establishing the IPsec SA: 930 SDWAN Node ID 931 SDWAN Color 932 Tunnel Encap Attr (Type=SDWAN-Hybrid) 933 Extended Port Sub-TLV for information about the Port 934 (including ISP Sub-TLV for information about the ISP2) 935 IPsec SA Nonce Sub-TLV, 936 IPsec SA Public Key Sub-TLV, 937 IPsec SA Sub-TLV for the supported transforms 938 {Transforms Sub-TLV - Trans 2, 939 Transforms Sub-TLV - Trans 3} 941 C-PE2 needs to advertise the following attributes for establishing 942 IPsec SA: 943 SDWAN Node ID 944 SDWAN Color 945 Tunnel Encap Attr (Type=SDWAN-Hybrid) 946 Extended Port Sub-TLV (including ISP Sub-TLV for information 947 about the ISP2) 948 IPsec SA Nonce Sub-TLV, 949 IPsec SA Public Key Sub-TLV, 950 IPsec SA Sub-TLV for the supported transforms 951 {Transforms Sub-TLV - Trans 2, 952 Transforms Sub-TLV - Trans 4} 954 As both end points support Transform #2, the Transform #2 will be 955 used for the IPsec Tunnel [ISP4: 160.0.0.1 <-> ISP2:170.0.0.1]. 957 8. Error & Mismatch Handling 959 Each C-PE device advertises a SDWAN SAFI Underlay NLRI to the other 960 C-PE devices via a BGP Route Reflector to establish pairwise SAs 961 between itself and every other remote C-PEs. During the SAFI NLRI 962 advertisement, the BGP originator would include either simple IPSec 963 Security Association properties defined in IPSec SA Sub-TLV based on 964 IPSec-SA-Type = 1 or full-set of IPSec Sub-TLVs including Nonce, 965 Public Key, Proposal and number of Transform Sub-TLVs based on 966 IPSec-SA-Type = 2. 968 The C-PE devices compare the IPSec SA attributes between the local 969 and remote WAN ports. If there is a match on the SA Attributes 970 between the two ports, the IPSec Tunnel is established. 972 The C-PE devices would not try to negotiate the base IPSec-SA 973 parameters between the local and the remote ports in the case of 974 simple IPSec SA exchange or the Transform sets between local and 975 remote ports if there is a mismatch on the Transform sets in the 976 case of full-set of IPSec SA Sub-TLVs. 978 As an example, using the Figure 1 in Section 3, to establish IPsec 979 Tunnel between C-PE1 and C-PE2 WAN Ports A2 and B2 [A2: 192.10.0.10 980 <-> B2:192.0.0.1]: 982 C-PE1 needs to advertise the following attributes for establishing 983 the IPsec SA: 984 NH: 192.10.0.10 985 SDWAN Node ID 986 SDWAN-Site-ID 987 Tunnel Encap Attr (Type=SDWAN) 988 ISP Sub-TLV for information about the ISP3 989 IPsec SA Nonce Sub-TLV, 990 IPsec SA Public Key Sub-TLV, 991 Proposal Sub-TLV with Num Transforms = 1 992 {Transforms Sub-TLV - Trans 1} 994 C-PE2 needs to advertise the following attributes for establishing 995 IPsec SA: 996 NH: 192.0.0.1 997 SDWAN Node ID 998 SDWAN-Site-ID 999 Tunnel Encap Attr (Type=SDWAN) 1000 ISP Sub-TLV for information about the ISP1 1001 IPsec SA Nonce Sub-TLV, 1002 IPsec SA Public Key Sub-TLV, 1003 Proposal Sub-TLV with Num Transforms = 1 1004 {Transforms Sub-TLV - Trans 2} 1006 As there is no matching transform between the WAN ports A2 and B2 in 1007 C-PE1 and C-PE2 respectively, there will be no IPsec Tunnel be 1008 established. 1010 9. Manageability Considerations 1012 TBD - this needs to be filled out before publishing 1014 10. Security Considerations 1016 The document describes the encoding for SDWAN edge nodes to 1017 advertise its properties to their peers to its RR, which 1018 propagates to the intended peers via untrusted networks. 1020 The secure propagation is achieved by secure channels, such as 1021 TLS, SSL, or IPsec, between the SDWAN edge nodes and the local 1022 controller RR. 1024 [More details need to be filled in here] 1026 11. IANA Considerations 1027 11.1. Hybrid (SDWAN) Overlay SAFI 1029 IANA has assigned SAFI = 74 as the Hybrid (SDWAN)SAFI. 1031 11.2. Tunnel Encapsulation Attribute Type 1033 IANA is requested to assign a type from the BGP Tunnel Encapsulation 1034 Attribute Tunnel Types as follows: 1036 Value Description Reference 1037 ----- ------------ --------- 1038 TBD1 SDWAN-Hybrid [this document] 1040 11.3 Tunnel Encapsulation Attribute Sub-TLV Types 1042 IANA is requested to assign three Types, as follows, in the BGP Tunnel 1043 Encapsulation Attribute Sub-TLVs regustry: 1045 Value Description Reference 1046 ----- ----------------------- --------------- 1047 TBD2 IPSEC-SA-ID [this document] 1048 TBD3 Port Extension [this document] 1049 TBD4 Underlay ISP Properties [this document] 1051 12. References 1053 12.1. Normative References 1055 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1056 Requirement Levels", BCP 14, RFC 2119, March 1997. 1058 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1059 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 1060 10.17487/RFC4271, January 2006, . 1063 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1064 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 1065 10.17487/RFC4760, January 2007, . 1068 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1069 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1070 May 2017, . 1072 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1073 "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 1074 10.17487/RFC9012, April 2021, . 1077 12.2. Informative References 1079 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 1080 (I2NSF) Problem Statement and Use Cases", July 2017 1082 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 1083 Address Family Identifier (SAFI) and the BGP Tunnel 1084 Encapsulation Attribute", April 2009. 1086 [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 1087 Garcia, "A YANG Data Model for IPsec Flow Protection Based 1088 on Software-Defined Networking (SDN)", RFC 9061, DOI 1089 10.17487/RFC9061, July 2021, . 1092 [CONTROLLER-IKE] D. Carrel, et al, "IPsec Key Exchange using a 1093 Controller", draft-carrel-ipsecme-controller-ike-01, work- 1094 in-progress. 1096 [LISP-GEOLOC] D. Farinacci, "LISP Geo-Coordinate Use-Case", draft- 1097 farinacci-lisp-geo-09, April 2020. 1099 [SDN-IPSEC] R. Lopez, G. Millan, "SDN-based IPsec Flow Protection", 1100 draft-ietf-i2nsf-sdn-ipsec-flow-protection-07, Aug 2019. 1102 [SECURE-EVPN] A. Sajassi, et al, "Secure EVPN", draft-sajassi-bess- 1103 secure-evpn-02, July 2019. 1105 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 1106 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 1107 work-in-progress, July 2018 1109 [DMVPN] Dynamic Multi-point VPN: 1110 https://www.cisco.com/c/en/us/products/security/dynamic- 1111 multipoint-vpn-dmvpn/index.html 1113 [DSVPN] Dynamic Smart VPN: 1114 http://forum.huawei.com/enterprise/en/thread-390771-1- 1115 1.html 1117 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 1118 storage, distribution and enforcement of policies for 1119 network security", Nov 2007. 1121 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 1122 Underlay to Cloud Overlay Problem Statement", draft-dm- 1123 net2cloud-problem-statement-02, June 2018 1125 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 1126 of Interconnecting Underlay with Cloud Overlay", draft-dm- 1127 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 1129 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 1130 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 1132 13. Acknowledgments 1134 Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for 1135 implementation contribution; Many thanks to Yoav Nir, Graham 1136 Bartlett, Jim Guichard, John Scudder, and Donald Eastlake for their 1137 review and suggestions. 1139 This document was prepared using 2-Word-v2.0.template.dot. 1141 Authors' Addresses 1143 Linda Dunbar 1144 Futurewei 1145 Email: ldunbar@futurewei.com 1147 Sue Hares 1148 Hickory Hill Consulting 1149 Email: shares@ndzh.com 1151 Robert Raszuk 1152 NTT Network Innovations 1153 Email: robert@raszuk.net 1155 Kausik Majumdar 1156 CommScope 1157 Email: Kausik.Majumdar@commscope.com 1159 Gyan Mishra 1160 Verizon Inc. 1161 Email: gyan.s.mishra@verizon.com 1163 Contributors' Addresses 1164 Donald Eastlake 1165 Futurewei 1166 Email: d3e3e3@gmail.com