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