idnits 2.17.1 draft-dunbar-idr-bgp-sdwan-overlay-ext-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 59 instances of too long lines in the document, the longest one being 15 characters in excess of 72. 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 (November 6, 2018) is 1988 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Tunnel-Encaps' is mentioned on line 205, but not defined == Missing Reference: 'RFC4456' is mentioned on line 283, but not defined == Missing Reference: 'RFC4760' is mentioned on line 348, but not defined == Missing Reference: 'Net2Cloud-problem' is mentioned on line 549, but not defined == Unused Reference: 'RFC2119' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 596, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8192 == Outdated reference: A later version (-01) exists of draft-rosen-bess-secure-l3vpn-00 ** Downref: Normative reference to an Informational draft: draft-rosen-bess-secure-l3vpn (ref. 'VPN-over-Internet') -- Possible downref: Non-RFC (?) normative reference: ref. 'DMVPN' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSVPN' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T-X1036' == Outdated reference: A later version (-07) exists of draft-dm-net2cloud-problem-statement-02 ** Downref: Normative reference to an Informational draft: draft-dm-net2cloud-problem-statement (ref. 'Net2Cloud-Problem') == Outdated reference: A later version (-04) exists of draft-dm-net2cloud-gap-analysis-02 ** Downref: Normative reference to an Informational draft: draft-dm-net2cloud-gap-analysis (ref. 'Net2Cloud-gap') == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-10 Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft H. Wang 3 Intended status: Standards Track W. Hao 4 Expires: January 2019 Huawei 6 November 6, 2018 8 BGP Extension for SDWAN Overlay Networks 9 draft-dunbar-idr-bgp-sdwan-overlay-ext-02 11 Abstract 13 The document defines a new BGP SAFI with a new NLRI in order to 14 advertise a SD-WAN edge node's capabilities in establishing SD-WAN 15 overlay tunnels with other SD-WAN nodes through third party 16 untrusted networks. The goal is for SD-WAN network to scale, 17 enabling SD-WAN overlay tunnels among large number of SD-WAN nodes 18 to be established with few provisioning needed, and allow services 19 to be carried by different SD-WAN tunnels based on user specified 20 criteria. 22 A "SD-WAN" tunnel refers to a point-to-point IPsec overlay path 23 between two end-points that can aggregate multiple different types 24 of underlay networks. An "end-point" is referring to a port on a SD- 25 WAN node throughout this document. 27 This document specifies new sub-TLVs for the SD-WAN Tunnel 28 Encapsulation Attribute. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. This document may not be modified, 37 and derivative works of it may not be created, except to publish it 38 as an RFC and to translate it into languages other than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 This Internet-Draft will expire on May 6, 2009. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with 68 respect to this document. Code Components extracted from this 69 document must include Simplified BSD License text as described in 70 Section 4.e of the Trust Legal Provisions and are provided without 71 warranty as described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction...................................................3 76 2. Conventions used in this document..............................4 77 3. Why need new SAFI for SD-WAN Overlay Network...................4 78 4. Overview of the BGP Extension for SD-WAN.......................7 79 5. SD-WAN Over Tunnel NLRI Format.................................9 80 6. SD-WAN Tunnel Encapsulation Attribute sub-TLV:.................9 81 6.1. IPsec SA sub-TLV.........................................10 82 6.2. EncapsExt sub-TLV........................................11 84 7. SD-WAN Tunnel Advertisement Method:...........................13 85 8. Manageability Considerations..................................14 86 9. Security Considerations.......................................14 87 10. IANA Considerations..........................................14 88 11. References...................................................14 89 11.1. Normative References....................................15 90 11.2. Informative References..................................15 91 12. Acknowledgments..............................................16 93 1. Introduction 95 The document defines a new BGP SAFI with a new NLRI in order to 96 advertise a SD-WAN edge node's capabilities in establishing SD-WAN 97 Tunnels with other SD-WAN nodes through third party networks. The 98 goal is for SD-WAN overlay network to scale, enabling SD-WAN overlay 99 tunnels among large number of SD-WAN nodes to be established with 100 few provisioning needed. 102 A "SD-WAN" tunnel refers to a point-to-point IPsec overlay path 103 between two end-points that can aggregate multiple different types 104 of untrusted underlay networks. 106 This document specifies new sub-TLVs for the SD-WAN Tunnel 107 Attributes. 109 [Net2Cloud-Problem] describes the problems that enterprises face 110 today in transitioning their IT infrastructure to support digital 111 economy, such as the need to connect enterprises' branch offices to 112 dynamic workloads in different Cloud DCs, or aggregating multiple 113 paths provided by different service providers to achieve better 114 experience. 116 Even though SD-WAN has been used as a flexible way to reach 117 workloads in dynamic third party data centers or aggregate multiple 118 underlay paths, scaling becomes a big issue when there are hundreds 119 or thousands of nodes to be interconnected by the SD-WAN overlay 120 paths. 122 BGP is widely used by underlay networks. This document expand the 123 BGP to make SD-WAN overlay network scale better. 125 2. Conventions used in this document 127 Cloud DC: Off-Premise Data Centers that usually host applications 128 and workload owned by different organizations or 129 tenants. 131 Controller: Used interchangeably with SD-WAN controller to manage 132 SD-WAN overlay path creation/deletion and monitor the 133 path conditions between sites. 135 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 136 This is to differentiate from most commonly used PE- 137 based VPNs a la RFC 4364. 139 SD-WAN End-point: a port (logical or physical) of a SD-WAN node. 141 OnPrem: On Premises data centers and branch offices 143 SD-WAN: Software Defined Wide Area Network, which can mean many 144 different things. In this document, "SD-WAN" refers to 145 the solutions specified by ONUG (Open Network User 146 Group), which build point-to-point IPsec overlay paths 147 between two end-points (or branch offices) that need to 148 intercommunicate. 150 3. Why need new SAFI for SD-WAN Overlay Network 152 A SD-WAN Overlay tunnel is an IPsec tunnel over multiple untrusted 153 underlay networks. For a small sized SD-WAN network, traditional hub 154 & spoke model using NHRP or DSVPN/DMVPN with a hub node (or 155 controller) managing SD-WAN tunnels end-points (e.g. local & public 156 addresses and tunnel identifiers mapping) can work reasonably well. 157 However, for a large SD-WAN network, say more than 100 nodes with 158 different types of topologies, the traditional approach becomes very 159 messy, complex and error prone. 161 In addition, hosts/applications attached to SD-WAN edge nodes can 162 belong to different tenants, requiring SD-WAN nodes to establish 163 different tunnels to different SD-WAN nodes. As shown in the figure 164 below, C1 node alone has to establish following SD-WAN tunnels: 166 - two SD-WAN tunnels to C2: one for Tenant 1, another one for Tenant 167 2, 168 - One SD-WAN tunnel to C3 for Tenant 1, and 169 - two SD-WAN tunnels to C4: one for Tenant 1, another one for Tenant 170 2, 172 +----------+ 173 +--------+ Tenant 2 | 174 | +----------+ 175 +--------+ | +--------+ 176 | Tenant +--+ | +----| Tenant | 177 | 1 | | | | | 1 | 178 +--------+ | ................. | | +--------+ 179 | +-+-+ +-+-+ | 180 +--|C1 |---+ +---|C2 |-----+ +---------+ 181 +-+-+ | | +---+ /-----+ Tenant 1| 182 / . +-----+ . / +---------+ 183 / . +--| RR |--+ . / +---------+ 184 / . | +-----+ \ . /------+ Tenant 3| 185 | . | Overlay \ . / +---------+ 186 | . | untrusted +--+--+ +--------+ 187 +--------+ | . | Networks | C4 | | Tenant | 188 | Tenant +--+ . | | |----| 2 | 189 | 2 | . \ +---+ +--+--+ +--------+ 190 +--------+ .....+C3 +..........+ 191 +---+ 192 | 193 | 194 ===================== 195 | | 196 +--------+ +--------+ 197 | Tenant | | Tenant | 198 | 2 | | 3 | 199 +--------+ +--------+ 201 This document proposes a method of using BGP for a SD-WAN node to 202 advertise its SD-WAN capabilities and SD-WAN end-point properties to 203 other SD-WAN nodes. 205 [Tunnel-Encaps] removed SAFI =7 (which was specified by RFC5512) for 206 distributing encapsulation tunnel information. [Tunnel-Encap] 207 require Tunnels being associated with routes. 209 The mechanisms described by [Tunnel-Encap] cannot be effectively 210 used for SD-WAN overlay network because: 212 - SD-WAN Tunnel needs to be established before data arrival because it 213 takes several rounds of negotiation between two end-points to agree 214 upon the encryption algorithms, exchange public keys, and be 215 authorized to communicate with each other. Unlike an EVPN PE, which 216 can always establish VxLAN tunnel to a another PE, an IPsec tunnel 217 between two points might fail to be established due to no agreed 218 upon encryption mechanism. 219 - Different services, routes, or VLANs can be carried by one SD-WAN 220 tunnel; same service/routes/VLAN can be carried by different SD-WAN 221 tunnels at different time depending on the policies specified by 222 users. When one SD-WAN tunnel encounter more congestion or delay, a 223 subset of the services/routes/VLAN carried by the SD-WAN tunnel have 224 to be switched to a different SD-WAN tunnel. 225 - When a VLAN or a route is deleted/added from/to an SD-WAN edge node, 226 the SD-WAN Tunnel between this edge node and another edge should not 227 be impacted. 228 - Managing IPsec Keys and re-Keys are complicated, it does not scale 229 well if a SD-WAN end point has to manage many fine-grained tunnels 230 with its peers, such as per route, per VLAN based SD-WAN IPsec 231 tunnel. 232 - Sometimes, a SD-WAN tunnel has to traverse a specific location due 233 to policies or running environment. 235 There is a suggestion on using a "Fake Route" for a SD-WAN node to 236 use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points 237 properties. However, using "Fake Route" can create deployment 238 complexity for large SD-WAN networks with many tunnels. For example, 239 for a SD-WAN network with hundreds of nodes, with each node having 240 many ports & many end-points to establish SD-WAN tunnels to their 241 corresponding peers, the node would need many "fake addresses". For 242 large SD-WAN networks (such as has more than 10000 nodes), each node 243 might need 10's thousands of "fake addresses", which is very 244 difficult to manage and needs lots of configuration to get the nodes 245 provisioned. 247 The key value proposition of SD-WAN is its dynamic nature. Most SD- 248 WAN deployment requires the following key properties: 250 - Zero Touch Provisioning: meaning a SD-WAN edge node needs to be plug 251 and play. The huge amount of "fake addresses" configurations required 252 by the [Tunnel-Encap] mechanism make it not possible to be used for 253 SD-WAN tunnels. 254 - The IP address of ports to a SD-WAN node can be dynamic (e.g. 255 assigned by DHCP); therefore, there is no fixed IP address that can 256 be used to uniquely to represent a SD-WAN tunnel end-point. 257 "System-ID + PortID" can usually uniquely identify a SD-WAN 258 end-point. That means the nexthop of a SD-WAN tunnel can be 259 "System-ID + Port ID". Sometimes, a SD-WAN tunnel end-point can 260 be associated with "private IP" + "public IP" (if NAT is used.) 262 Another very important reason for needing a specific SAFI for SD-WAN 263 Overlay is for many intermediate nodes that do not terminate SD-WAN 264 tunnels to ignore the NLRI SD-WAN Overlay SAFI update messages, to 265 avoid the extra processing incurred. 267 [Net2Cloud-gap] has more in-depth analysis of the gaps of available 268 protocols in support SD-WAN overlay networks. 270 4. Overview of the BGP Extension for SD-WAN 272 To avoid confusion of different interpretation of SD-WAN, the BGP 273 SD-WAN Overlay NLRI extension described in this document is for a 274 SD-WAN deployment with the following characteristics: 276 - There is a Central Controller, which can be reached by an SD-WAN node 277 upon power up, and a TLS or SSL secure channel can be established 278 between the SD-WAN node and the Central Controller. 279 - The Central Controller can designate a Local Controller in the 280 proximity of the SD-WAN node; the Local Controller and the SD-WAN 281 nodes might be connected by third party untrusted network. In the 282 context of using BGP to control the SD-WAN overlay network, Route 283 Reflector (RR, [RFC4456]) can act as a Local Controller. The SD-WAN 284 node can establish a secure connection (TLS, SSL, etc) to the Local 285 Controller (RR). 287 The BGP SD-WAN Overlay NLRI extension described in this document is 288 for SD-WAN nodes to advertise their SD-WAN capabilities & tunnel 289 end-points attributes to peers belonging to the same tenant, such as 290 a. to advertise the identifiers of ports that support establishing SD-WAN 291 overlay tunnels to other peers, 292 b. to advertise ports private addresses (or dynamically assigned IP 293 addresses), 294 c. to advertise its supported IPsec capability, such as the supported 295 encryption algorithms, etc. 297 Since there are secure channels (TLS, SSL, etc.) established between 298 the Local Controller (i.e. RR) and SD-WAN nodes, the NLRI can be 299 advertised to their peers belonging to the same tenants via the 300 secure channel to/from the RR. 302 The BGP extension for the advertisement of SD-WAN tunnels includes 303 following components: 305 - A new Subsequent Address Family Identifier (SAFI=74) whose NLRI 306 identifies a (SD-WAN) overlay tunnel, the properties of the tunnel 307 end-points, and the associated policies. 308 - A new Route Type that defines the encoding of the rest of the SD-WAN 309 Overlay NLRI, and a set of sub-TLVs to specify the tunnel & its end- 310 point attributes, policies associated with the tunnel, etc. Here are 311 the sub-TLVs needed for SD-WAN tunnel: 312 o Tunnel IPsec configuration attributes, such as public keys, the 313 encryption algorithms, etc. 314 o Tunnel Encap Extension, which is for specify specific attributes 315 associated for SD-WAN tunnel end-points. 316 - Port Distinguisher: one (SD-WAN) node can have multiple ports, and 317 each port can support multiple SD-WAN tunnels to different peers. The 318 Port Distinguisher is used to describe port (or link identifier). 319 - SD-WAN Color: used to identify a common property shared by a set of 320 SD-WAN nodes, such as the property of a specific geographic location. 321 The property is used to steer an overlay route to traverse specific 322 geographic locations for various reasons, such as to comply 323 regulatory rules, to utilize specific value added services, or 324 others. 326 5. SD-WAN Over Tunnel NLRI Format 328 The new SAFI=74, the SD-WAN Overlay SAFI, has been assigned by IANA, 329 from the "Subsequent Address Family Identifiers (SAFI) Parameters" 330 registry. 332 The SD-WAN Overlay SAFI (=74) uses a new NLRI defined as follows: 334 +------------------+ 335 | NLRI Length | 1 octet 336 +------------------+ 337 | Route-Type | 1 Octet 338 +------------------+ 339 | Port-ID | 4 octets 340 +------------------+ 341 | SD-WAN-color | 4 octets 342 +------------------+ 343 | SD-WAN-Node-ID | 4 or 16 octets 344 +------------------+ 345 where: 347 - NLRI Length: 1 octet of length expressed in bits as defined in 348 [RFC4760]. 349 - Route-Type: to define the encoding of the rest of the SD-WAN Overlay 350 NLRI. 351 - Port ID: one (SD-WAN) node can have multiple ports, and each port can 352 support multiple SD-WAN tunnels to different peers. The Port ID is 353 used to identify the port, a.k.a. link identifier. 354 - SD-WAN-color: used to identify a common property shared by a set of 355 SD-WAN nodes, such as the property of a specific geographic location. 356 - SD-WAN Node ID: the SD-WAN NLRI advertisement is sent out by the SD- 357 WAN node to indicate all the available ports supporting SD-WAN 358 tunnels. The SD-WAN Node ID can be the node's system ID, such as the 359 loopback address of the SD-WAN node. 361 6. SD-WAN Tunnel Encapsulation Attribute sub-TLV: 363 The SD-WAN overlay tunnel end-points property is encoded in the 364 Tunnel Encapsulation Attribute originally defined in [Tunnel- 365 Encap]using a new Tunnel-Type TLV (SD-WAN Tunnel Type, with the code 366 point to be assigned by IANA) from the "BGP Tunnel Encapsulation 367 Attribute Tunnel Types". 369 The SD-WAN Tunnel End-Point Property Encoding structure is as 370 follows: 372 Overlay SAFI (=74) NLRI: < Route-Type, Length, Port-ID, SD-WAN-color, 373 SD-WAN-Node-ID> 374 Attributes: 375 Tunnel Encaps Attribute 376 Tunnel Type: SD-WAN-Tunnel 377 EncapExt SubTLV 378 IPsec-SA Attribute SubTLV 380 Where 381 - Encap-Ext SubTLV is for describing additional information about the 382 SD-WAN tunnel end-points, such as NAT property. 383 - IPsec-SA SubTLV is for the node to establish IPsec SA with other 384 peers. 386 The Tunnel Encaps Attribute are defined as follows: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Tunnel-Type(2 Octets) | Length (2 Octets) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 | Value | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 1: SD-WAN Tunnel Encapsulation TLV Value Field 399 Where: 400 Tunnel Type is SD-WAN (to be assigned by IANA). 402 6.1. IPsec SA sub-TLV 404 The IPsecSA sub-TLV is for the SD-WAN node to establish IPsec 405 security association with their peers: 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |IPsec-SA Type |IPsecSA Length | Flag | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Transform | Transport | AH | ESP | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | SPI | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | key1 length | key1 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | key2 length | key2 | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | key3 length | key3 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Duration | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Where: 426 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 427 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 428 for length to carry the needed information. 429 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 430 o Flags: 1 octet of flags. None are defined at this stage. Flags 431 SHOULD be set to zero on transmission and MUST be ignored on 432 receipt. 433 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 434 o Transport (1 byte): the value can be Tunnel Mode or Transport 435 mode 436 o AH (1 byte): AH authentication algorithms supported, which can 437 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each SD- 438 WAN node can have multiple authentication algorithms; send to 439 its peers to negotiate the strongest one. 440 o ESP (1 byte): ESP authentication algorithms supported, which 441 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 442 SD-WAN node can have multiple authentication algorithms; send 443 to its peers to negotiate the strongest one. Default algorithm 444 is AES-256. 445 o SPI: 4 bytes 446 o Key1.AH authentication key 447 o Key2.ESP authentication key 448 o Key3.ESP encryption "public" key 449 o Duration: SA life span. 451 6.2. EncapsExt sub-TLV 453 EncapsExt sub-TLV is for describing additional information about the 454 SD-WAN tunnel end-points, such as NAT property. A SD-WAN edge node 455 can inquire STUN (Session Traversal of UDP Through Network Address 456 Translation RFC 3489) Server to get the NAT property, the public IP 457 address and the Public Port number to pass to peers. 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 |EncapExt Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | NAT Type | Encap-Type |Trans networkID| RD ID | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Local IP Address | 466 32-bits for IPv4, 128-bits for Ipv6 467 ~~~~~~~~~~~~ 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Local Port | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Public IP | 472 32-bits for IPv4, 128-bits for Ipv6 473 ~~~~~~~~~~~~ 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Public Port | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Where: 480 o EncapExt Type: indicate it is the EncapExt SubTLV. 481 o EncapExt subTLV Length: the length of the subTLVE. 482 o Flags: 483 - I bit (CPE port address or Inner address scheme) 484 If set to 0, indicate the inner (private) address is IPv4. 485 If set to 1, it indicates the inner address is IPv6. 487 - O bit (Outer address scheme): 488 If set to 0, indicate the public (outer) address is IPv4. 489 If set to 1, it indicates the public (outer) address is 490 IPv6. 492 - R bits: reserved for future use. Must be set to 0 now. 494 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 495 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 496 response from the STUN server). 497 o Encap Type.SD-WAN tunnel encapsulation types, such as 498 IPsec+GRE, IPsec+VxLAN, IPsec without GRE, GRE (when tunnel is 499 over secure underlay network) 500 o Transport Network ID.Central Controller assign a global unique 501 ID to each transport network. 502 o RD ID.Routing Domain ID.Need to be global unique. 503 o Local IP.The local (or private) IP address of the tunnel end- 504 point. 505 o Local Port.used by Remote SD-WAN node for establishing IPsec to 506 this specific port. 507 o Public IP.The IP address after the NAT. 508 o Public Port.The Port after the NAT. 510 7. SD-WAN Tunnel Advertisement Method: 512 +---+ 513 Peer Group 1 |RR | Peer Group 2 514 +======+====+=+ +======+====+=====+ 515 / / | +---+ | \ \ 516 / / | | | \ 517 +-+-+ +-+--+ +-+-+ +-+-+ +-+-+ +-+-+ 518 |CPE| | CPE|--|CPE| |CPE| |CPE| |CPE| 519 | 1 | | 2 | | 3 | |4 | | 5 | | 6 | 520 +---+ +----+ +---+ +---+ +---+ +---+ 521 Tenant 1 Tenant 2 523 For SD-WAN overlay network, the SD-WAN edge nodes (a.k.a. CPEs) belonging 524 to the same Tenant can be far apart and can be connected by third party 525 untrusted networks. Therefore, it is not appropriate for a SD-WAN node 526 (CPE) to advertise its SD-WAN tunnel properties to its immediate neighbors. 527 Each CPE propagates its SD-WAN tunnel attributes via the secure channel 528 established with RR. 530 The processing steps on CPE1 are as follow: 531 - Report the SD-WAN tunnel information, such as IPsec property, NAT, 532 etc. to RR via the Overlay SAFI NLRI. 533 - RR propagate the information to CPE2 & CPE 3. 535 - CPE2 and CPE3 can establish IPsec SA with the CPE1 after receiving 536 the Overlay SAFI NLRI from RR. 538 Tenant separation is achieved by different SD-WAN nodes being added 539 to different Peer Group. 541 8. Manageability Considerations 543 TBD 545 9. Security Considerations 547 The intention of this draft is to identify the gaps in current and 548 proposed SD-WAN approaches that can address requirements 549 identified in [Net2Cloud-problem]. 551 Several of these approaches have gaps in meeting enterprise 552 security requirements when tunneling their traffic over the 553 Internet, as is the general intention of SD-WAN. See the 554 individual sections above for further discussion of these security 555 gaps. 557 10. IANA Considerations 559 This document requires the following IANA actions. 561 o SD-WAN Overlay SAFI = 74 assigned by IANA 562 o SD-WAN Route Type 563 o SD-WAN Tunnel Type 564 o IPsec-SA Type 565 o EncapExt Type 567 11. References 568 11.1. Normative References 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 11.2. Informative References 574 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 575 (I2NSF) Problem Statement and Use Cases", July 2017 577 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 578 Address Family Identifier (SAFI) and the BGP Tunnel 579 Encapsulation Attribute", April 2009. 581 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 582 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 584 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 585 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 586 work-in-progress, July 2018 588 [DMVPN] Dynamic Multi-point VPN: 589 https://www.cisco.com/c/en/us/products/security/dynamic- 590 multipoint-vpn-dmvpn/index.html 592 [DSVPN] Dynamic Smart VPN: 593 http://forum.huawei.com/enterprise/en/thread-390771-1- 594 1.html 596 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 597 storage, distribution and enforcement of policies for 598 network security", Nov 2007. 600 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 601 Underlay to Cloud Overlay Problem Statement", draft-dm- 602 net2cloud-problem-statement-02, June 2018 604 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 605 of Interconnecting Underlay with Cloud Overlay", draft-dm- 606 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 608 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 609 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 611 12. Acknowledgments 613 Acknowledgements to Jim Guichard, John Scudder, Darren Dukes, Andy 614 Malis and Donald Eastlake for their review and contributions. 616 This document was prepared using 2-Word-v2.0.template.dot. 618 Authors' Addresses 620 Linda Dunbar 621 Huawei 622 Email: Linda.Dunbar@huawei.com 624 Haibo Wang 625 Huawei 626 Email: rainsword.wang@huawei.com 628 WeiGuo Hao 629 Huawei Technologies Co.,Ltd. 630 Email: haoweiguo@huawei.com