idnits 2.17.1 draft-dunbar-idr-bgp-sdwan-overlay-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 instances of too long lines in the document, the longest one being 6 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 (October 19, 2018) is 2014 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 202, but not defined == Missing Reference: 'RFC4456' is mentioned on line 259, but not defined == Missing Reference: 'RFC4760' is mentioned on line 327, but not defined == Missing Reference: 'Net2Cloud-problem' is mentioned on line 509, but not defined == Unused Reference: 'RFC2119' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 557, but no explicit reference was found in the text == 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 (~~), 17 warnings (==), 1 comment (--). 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 October 19, 2018 8 BGP Extension for SDWAN Overlay Networks 9 draft-dunbar-idr-bgp-sdwan-overlay-ext-00 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 networks. The goal is for SD-WAN network to scale, enabling SD-WAN 17 overlay tunnels among large number of SD-WAN nodes to be established 18 with few provisioning needed. 20 A "SD-WAN" tunnel refers to a point-to-point IPsec overlay path 21 between two end-points that can aggregate multiple different types 22 of underlay networks. 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 Tunnel 26 Encapsulation Attribute. 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 April 21, 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..............................4 75 3. Why need new SAFI for SD-WAN Overlay Network...................4 76 4. Overview of the BGP Extension for SD-WAN.......................7 77 5. SD-WAN Over Tunnel NLRI Format.................................8 78 6. SD-WAN Tunnel Encapsulation Attribute sub-TLV:.................9 79 6.1. IPsec SA sub-TLV.........................................10 80 6.2. EncapsExt sub-TLV........................................11 81 7. SD-WAN Tunnel Advertisement Method:...........................12 82 8. Manageability Considerations..................................13 83 9. Security Considerations.......................................13 84 10. IANA Considerations..........................................13 85 11. References...................................................13 86 11.1. Normative References....................................14 87 11.2. Informative References..................................14 88 12. Acknowledgments..............................................15 90 1. Introduction 92 The document defines a new BGP SAFI with a new NLRI in order to 93 advertise a SD-WAN edge node's capabilities in establishing SD-WAN 94 Tunnels with other SD-WAN nodes through third party networks. The 95 goal is for SD-WAN overlay network to scale, enabling SD-WAN overlay 96 tunnels among large number of SD-WAN nodes to be established with 97 few provisioning needed. 99 A "SD-WAN" tunnel refers to a point-to-point IPsec overlay path 100 between two end-points that can aggregate multiple different types 101 of untrusted underlay networks. 103 This document specifies new sub-TLVs for the SD-WAN Tunnel 104 Attributes. 106 [Net2Cloud-Problem] describes the problems that enterprises face 107 today in transitioning their IT infrastructure to support digital 108 economy, such as the need to connect enterprises' branch offices to 109 dynamic workloads in different Cloud DCs, or aggregating multiple 110 paths provided by different service providers to achieve better 111 experience. 113 Even though SD-WAN has been used as a flexible way to reach 114 workloads in dynamic third party data centers or aggregate multiple 115 underlay paths, scaling becomes a big issue when there are hundreds 116 or thousands of nodes to be interconnected by the SD-WAN overlay 117 paths. 119 BGP is widely used by underlay networks. This document expand the 120 BGP to make SD-WAN overlay network scale better. 122 2. Conventions used in this document 124 Cloud DC: Off-Premise Data Centers that usually host applications 125 and workload owned by different organizations or 126 tenants. 128 Controller: Used interchangeably with SD-WAN controller to manage 129 SD-WAN overlay path creation/deletion and monitor the 130 path conditions between sites. 132 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 133 This is to differentiate from most commonly used PE- 134 based VPNs a la RFC 4364. 136 SD-WAN End-point: a port (logical or physical) of a SD-WAN node. 138 OnPrem: On Premises data centers and branch offices 140 SD-WAN: Software Defined Wide Area Network, which can mean many 141 different things. In this document, "SD-WAN" refers to 142 the solutions specified by ONUG (Open Network User 143 Group), which build point-to-point IPsec overlay paths 144 between two end-points (or branch offices) that need to 145 intercommunicate. 147 3. Why need new SAFI for SD-WAN Overlay Network 149 A SD-WAN Overlay tunnel is an IPsec tunnel over multiple untrusted 150 underlay networks. For a small sized SD-WAN network, traditional hub 151 & spoke model using NHRP or DSVPN/DMVPN with a hub node (or 152 controller) managing SD-WAN tunnels end-points (e.g. local & public 153 addresses and tunnel identifiers mapping) can work reasonably well. 154 However, for a large SD-WAN network, say more than 100 nodes with 155 different types of topologies, the traditional approach becomes very 156 messy, complex and error prone. 158 In addition, hosts/applications attached to SD-WAN edge nodes can 159 belong to different tenants, requiring SD-WAN nodes to establish 160 different tunnels to different SD-WAN nodes. As shown in the figure 161 below, C1 node alone has to establish following SD-WAN tunnels: 163 - two SD-WAN tunnels to C2: one for Tenant 1, another one for Tenant 164 2, 165 - One SD-WAN tunnel to C3 for Tenant 1, and 166 - two SD-WAN tunnels to C4: one for Tenant 1, another one for Tenant 167 2, 169 +----------+ 170 +--------+ Tenant 2 | 171 | +----------+ 172 +--------+ | +--------+ 173 | Tenant +--+ | +----| Tenant | 174 | 1 | | | | | 1 | 175 +--------+ | ................. | | +--------+ 176 | +-+-+ +-+-+ | 177 +--|C1 |---+ +---|C2 |-----+ +---------+ 178 +-+-+ | | +---+ /-----+ Tenant 1| 179 / . +-----+ . / +---------+ 180 / . +--| RR |--+ . / +---------+ 181 / . | +-----+ \ . /------+ Tenant 3| 182 | . | Overlay \ . / +---------+ 183 | . | untrusted +--+--+ +--------+ 184 +--------+ | . | Networks | C4 | | Tenant | 185 | Tenant +--+ . | | |----| 2 | 186 | 2 | . \ +---+ +--+--+ +--------+ 187 +--------+ .....+C3 +..........+ 188 +---+ 189 | 190 | 191 ===================== 192 | | 193 +--------+ +--------+ 194 | Tenant | | Tenant | 195 | 2 | | 3 | 196 +--------+ +--------+ 198 This document proposes a method of using BGP for a SD-WAN node to 199 advertise its SD-WAN capabilities and SD-WAN end-point properties to 200 other SD-WAN nodes. 202 [Tunnel-Encaps] removed SAFI =7 (which was specified by RFC5512) for 203 distributing encapsulation tunnel information. [Tunnel-Encap] 204 require Tunnels being associated with routes. 206 The mechanisms described by [Tunnel-Encap] cannot be effectively 207 used for SD-WAN overlay network because a SD-WAN Tunnel needs to be 208 established before data arrival. There is no routes to be associated 209 with the SD-WAN Tunnel. 211 There is a suggestion on using a "Fake Route" for a SD-WAN node to 212 use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points 213 properties. However, using "Fake Route" can create deployment 214 complexity for large SD-WAN networks with many tunnels. For example, 215 for a SD-WAN network with hundreds of nodes, with each node having 216 many ports & many end-points to establish SD-WAN tunnels to their 217 corresponding peers, the node would need many "fake addresses". For 218 large SD-WAN networks (such as has more than 10000 nodes), each node 219 might need 10's thousands of "fake addresses", which is very 220 difficult to manage and needs lots of configuration to get the nodes 221 provisioned. 223 The key value proposition of SD-WAN is its dynamic nature. Most SD- 224 WAN deployment requires the following key properties: 226 - Zero Touch Provisioning: meaning a SD-WAN edge node needs to be plug 227 and play. The huge amount of "fake addresses" configurations required 228 by the [Tunnel-Encap] mechanism make it not possible to be used for 229 SD-WAN tunnels. 230 - The IP address of ports to a SD-WAN node can be dynamic (e.g. 231 assigned by DHCP); therefore, there is no fixed IP address that can 232 be used to uniquely to represent a SD-WAN tunnel end-point. 233 "System-ID + PortID" can usually uniquely identify a SD-WAN 234 end-point. That means the nexthop of a SD-WAN tunnel can be 235 "System-ID + Port ID". Sometimes, a SD-WAN tunnel end-point can 236 be associated with "private IP" + "public IP" (if NAT is used.) 238 Another very important reason for needing a specific SAFI for SD-WAN 239 Overlay is for many intermediate nodes that do not terminate SD-WAN 240 tunnels to ignore the NLRI SD-WAN Overlay SAFI update messages, to 241 avoid the extra processing incurred. 243 [Net2Cloud-gap] has more in-depth analysis of the gaps of available 244 protocols in support SD-WAN overlay networks. 246 4. Overview of the BGP Extension for SD-WAN 248 To avoid confusion of different interpretation of SD-WAN, the BGP 249 SD-WAN Overlay NLRI extension described in this document is for a 250 SD-WAN deployment with the following characteristics: 252 - There is a Central Controller, which can be reached by an SD-WAN node 253 upon power up, and a TLS or SSL secure channel can be established 254 between the SD-WAN node and the Central Controller. 255 - The Central Controller can designate a Local Controller in the 256 proximity of the SD-WAN node; the Local Controller and the SD-WAN 257 nodes might be connected by third party untrusted network. In the 258 context of using BGP to control the SD-WAN overlay network, Route 259 Reflector (RR, [RFC4456]) can act as a Local Controller. The SD-WAN 260 node can establish a secure connection (TLS, SSL, etc) to the Local 261 Controller (RR). 263 The BGP SD-WAN Overlay NLRI extension described in this document is 264 for SD-WAN nodes to advertise their SD-WAN capabilities & tunnel 265 end-points attributes to peers belonging to the same tenant, such as 266 a. to advertise the identifiers of ports that support establishing SD-WAN 267 overlay tunnels to other peers, 268 b. to advertise ports private addresses (or dynamically assigned IP 269 addresses), 270 c. to advertise its supported IPsec capability, such as the supported 271 encryption algorithms, etc. 273 Since there are secure channels (TLS, SSL, etc.) established between 274 the Local Controller (i.e. RR) and SD-WAN nodes, the NLRI can be 275 advertised to their peers belonging to the same tenants via the 276 secure channel to/from the RR. 278 The BGP extension for the advertisement of SD-WAN tunnels includes 279 following components: 281 - A new Subsequent Address Family Identifier (SAFI) whose NLRI 282 identifiers a (SD-WAN) overlay tunnel, the properties of the tunnel 283 end-points, and the associated policies. 284 - A new Route Type that defines the encoding of the rest of the SD-WAN 285 Overlay NLRI, and a set of sub-TLVs to specify the tunnel & its end- 286 point attributes, policies associated with the tunnel, etc. Here are 287 the sub-TLVs needed for SD-WAN tunnel: 289 o Tunnel IPsec configuration attributes, such as public keys, the 290 encryption algorithms, etc. 291 o Tunnel Encap Extension, which is for specify specific attributes 292 associated for SD-WAN tunnel end-points. 293 - Port Distinguisher: one (SD-WAN) node can have multiple ports, and 294 each port can support multiple SD-WAN tunnels to different peers. The 295 Port Distinguisher is used to describe port (or link identifier). 296 - SD-WAN Color: used to identify a common property shared by a set of 297 SD-WAN nodes, such as the property of a specific geographic location. 298 The property is used to steer an overlay route to traverse specific 299 geographic locations for various reasons, such as to comply 300 regulatory rules, to utilize specific value added services, or 301 others. 303 5. SD-WAN Over Tunnel NLRI Format 305 The new SAFI is defined: the SD-WAN Overlay SAFI, (code point to be 306 assigned by IANA, from the "Subsequent Address Family Identifiers 307 (SAFI0 Parameters" registry). 309 The SD-WAN Overlay SAFI uses a new NLRI defined as follows: 311 +------------------+ 312 | NLRI Length | 1 octet 313 +------------------+ 314 | Route-Type | 1 Octet 315 +------------------+ 316 | Length | 1 Octet 317 +------------------+ 318 | Port-ID | 4 octets 319 +------------------+ 320 | SD-WAN-color | 4 octets 321 +------------------+ 322 | SD-WAN-Node-ID | 4 or 16 octets 323 +------------------+ 324 where: 326 - NLRI Length: 1 octet of length expressed in bits as defined in 327 [RFC4760]. 328 - Route-Type: to define the encoding of the rest of the SD-WAN Overlay 329 NLRI. 330 - Length: 1 octet. 332 - Port ID: one (SD-WAN) node can have multiple ports, and each port can 333 support multiple SD-WAN tunnels to different peers. The Port ID is 334 used to identify the port, a.k.a. link identifier. 335 - SD-WAN-color: used to identify a common property shared by a set of 336 SD-WAN nodes, such as the property of a specific geographic location. 337 - SD-WAN Node ID: the SD-WAN NLRI advertisement is sent out by the SD- 338 WAN node to indicate all the available ports supporting SD-WAN 339 tunnels. The SD-WAN Node ID can be the node's system ID, such as the 340 loopback address of the SD-WAN node. 342 6. SD-WAN Tunnel Encapsulation Attribute sub-TLV: 344 The SD-WAN overlay tunnel end-points property is encoded in the 345 Tunnel Encapsulation Attribute originally defined in [Tunnel- 346 Encap]using a new Tunnel-Type TLV (SD-WAN Tunnel Type, with the code 347 point to be assigned by IANA) from the "BGP Tunnel Encapsulation 348 Attribute Tunnel Types". 350 The SD-WAN Tunnel End-Point Property Encoding structure is as 351 follows: 353 Overlay SAFI NLRI: < Route-Type, Length, Port-ID, SD-WAN-color, SD-WAN- 354 Node-ID> 355 Attributes: 356 Tunnel Encaps Attribute 357 Tunnel Type: SD-WAN-Tunnel 358 EncapExt SubTLV 359 IPsec-SA Attribute SubTLV 361 Where 362 - Encap-Ext SubTLV is for describing additional information about the 363 SD-WAN tunnel end-points, such as NAT property. 364 - IPsec-SA SubTLV is for the node to establish IPsec SA with other 365 peers. 367 The Tunnel Encaps Attribute are defined as follows: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Tunnel-Type(2 Octets) | Length (2 Octets) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 | Value | 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 1: SD-WAN Tunnel Encapsulation TLV Value Field 380 Where: 381 Tunnel Type is SD-WAN (to be assigned by IANA). 383 6.1. IPsec SA sub-TLV 385 The IPsecSA sub-TLV is for the SD-WAN node to establish IPsec 386 security association with their peers: 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |IPsec-SA Type |IPsecSA Length | Flag | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Transform | Transport | AH | ESP | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | SPI | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | key1 length | key1 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | key2 length | key2 | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | key3 length | key3 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Duration | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Where: 407 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 408 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 409 for length to carry the needed information. 410 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 411 o Flags: 1 octet of flags. None are defined at this stage. Flags 412 SHOULD be set to zero on transmission and MUST be ignored on 413 receipt. 414 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 415 o Transport (1 byte): the value can be Tunnel Mode or Transport 416 mode 417 o AH (1 byte): AH authentication algorithms supported, which can 418 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each SD- 419 WAN node can have multiple authentication algorithms; send to 420 its peers to negotiate the strongest one. 421 o ESP (1 byte): ESP authentication algorithms supported, which 422 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 423 SD-WAN node can have multiple authentication algorithms; send 424 to its peers to negotiate the strongest one. Default algorithm 425 is AES-256. 426 o SPI: 4 bytes 427 o Key1.AH authentication key 428 o Key2.ESP authentication key 429 o Key3.ESP encryption "public" key 430 o Duration: SA life span. 432 6.2. EncapsExt sub-TLV 434 EncapsExt sub-TLV is for describing additional information about the 435 SD-WAN tunnel end-points, such as NAT property. A SD-WAN edge node 436 can inquire STUN (Session Traversal of UDP Through Network Address 437 Translation RFC 3489) Server to get the NAT property, the public IP 438 address and the Public Port number to pass to peers. 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |EncapExt Type | EncapExt subTLV Length | Flag | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | NAT Type | Encap-Type |Trans networkID| RD ID | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Private IP Address | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Private Port | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Public IP | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Public Port | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Where: 457 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 458 Cone; Port Restricted Cone; or Symmetric 459 o Encap Type.SD-WAN tunnel encapsulation types, such as 460 IPsec+GRE, IPsec+VxLAN, IPsec without GRE, GRE (when tunnel is 461 over secure underlay network) 462 o Transport Network ID.Central Controller assign a global unique 463 ID to each transport network. 464 o RD ID.Routing Domain ID.Need to be global unique. 465 o Private IP.The local IP address of the tunnel end-point. 466 o Private Port.used by Remote SD-WAN node for establishing IPsec 467 to this specific port. 468 o Public IP.The IP address after the NAT. 469 o Public Port.The Port after the NAT. 471 7. SD-WAN Tunnel Advertisement Method: 473 +---+ 474 Peer Group 1 |RR | Peer Group 2 475 +======+====+=+ +======+====+=====+ 476 / / | +---+ | \ \ 477 / / | | | \ 478 +-+-+ +-+--+ +-+-+ +-+-+ +-+-+ +-+-+ 479 |CPE| | CPE|--|CPE| |CPE| |CPE| |CPE| 480 | 1 | | 2 | | 3 | |4 | | 5 | | 6 | 481 +---+ +----+ +---+ +---+ +---+ +---+ 482 Tenant 1 Tenant 2 484 For SD-WAN overlay network, the SD-WAN edge nodes (a.k.a. CPEs) belonging 485 to the same Tenant can be far apart and can be connected by third party 486 untrusted networks. Therefore, it is not appropriate for a SD-WAN node 487 (CPE) to advertise its SD-WAN tunnel properties to its immediate neighbors. 488 Each CPE propagates its SD-WAN tunnel attributes via the secure channel 489 established with RR. 491 The processing steps on CPE1 are as follow: 492 - Report the SD-WAN tunnel information, such as IPsec property, NAT, 493 etc. to RR via the Overlay SAFI NLRI. 494 - RR propagate the information to CPE2 & CPE 3. 495 - CPE2 and CPE3 can establish IPsec SA with the CPE1 after receiving 496 the Overlay SAFI NLRI from RR. 498 Tenant separation is achieved by different SD-WAN nodes being added 499 to different Peer Group. 501 8. Manageability Considerations 503 TBD 505 9. Security Considerations 507 The intention of this draft is to identify the gaps in current and 508 proposed SD-WAN approaches that can address requirements 509 identified in [Net2Cloud-problem]. 511 Several of these approaches have gaps in meeting enterprise 512 security requirements when tunneling their traffic over the 513 Internet, as is the general intention of SD-WAN. See the 514 individual sections above for further discussion of these security 515 gaps. 517 10. IANA Considerations 519 This document requires the following IANA actions. 521 o SD-WAN Overlay SAFI 522 o SD-WAN Route Type 523 o SD-WAN Tunnel Type 524 o IPsec-SA Type 525 o EncapExt Type 527 11. References 528 11.1. Normative References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 11.2. Informative References 535 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 536 (I2NSF) Problem Statement and Use Cases", July 2017 538 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 539 Address Family Identifier (SAFI) and the BGP Tunnel 540 Encapsulation Attribute", April 2009. 542 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 543 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 545 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 546 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 547 work-in-progress, July 2018 549 [DMVPN] Dynamic Multi-point VPN: 550 https://www.cisco.com/c/en/us/products/security/dynamic- 551 multipoint-vpn-dmvpn/index.html 553 [DSVPN] Dynamic Smart VPN: 554 http://forum.huawei.com/enterprise/en/thread-390771-1- 555 1.html 557 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 558 storage, distribution and enforcement of policies for 559 network security", Nov 2007. 561 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 562 Underlay to Cloud Overlay Problem Statement", draft-dm- 563 net2cloud-problem-statement-02, June 2018 565 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 566 of Interconnecting Underlay with Cloud Overlay", draft-dm- 567 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 569 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 570 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 572 12. Acknowledgments 574 Acknowledgements to Jim Guichard, Andy Malis and Donald Eastlake for 575 their review and contributions. 577 This document was prepared using 2-Word-v2.0.template.dot. 579 Authors' Addresses 581 Linda Dunbar 582 Huawei 583 Email: Linda.Dunbar@huawei.com 585 Haibo Wang 586 Huawei 587 Email: rainsword.wang@huawei.com 589 WeiGuo Hao 590 Huawei Technologies Co.,Ltd. 591 Email: haoweiguo@huawei.com