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