idnits 2.17.1 draft-dunbar-idr-bgp-sdwan-overlay-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 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 1, 2018) is 1996 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 325, but not defined == Missing Reference: 'Net2Cloud-problem' is mentioned on line 522, but not defined == Unused Reference: 'RFC2119' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 570, 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 1, 2018 8 BGP Extension for SDWAN Overlay Networks 9 draft-dunbar-idr-bgp-sdwan-overlay-ext-01 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. 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 1, 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...................................................14 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=74) whose NLRI 282 identifies 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=74, the SD-WAN Overlay SAFI, has been assigned by IANA, 306 from the "Subsequent Address Family Identifiers (SAFI) Parameters" 307 registry. 309 The SD-WAN Overlay SAFI (=74) uses a new NLRI defined as follows: 311 +------------------+ 312 | NLRI Length | 1 octet 313 +------------------+ 314 | Route-Type | 1 Octet 315 +------------------+ 316 | Port-ID | 4 octets 317 +------------------+ 318 | SD-WAN-color | 4 octets 319 +------------------+ 320 | SD-WAN-Node-ID | 4 or 16 octets 321 +------------------+ 322 where: 324 - NLRI Length: 1 octet of length expressed in bits as defined in 325 [RFC4760]. 326 - Route-Type: to define the encoding of the rest of the SD-WAN Overlay 327 NLRI. 328 - Port ID: one (SD-WAN) node can have multiple ports, and each port can 329 support multiple SD-WAN tunnels to different peers. The Port ID is 330 used to identify the port, a.k.a. link identifier. 332 - SD-WAN-color: used to identify a common property shared by a set of 333 SD-WAN nodes, such as the property of a specific geographic location. 334 - SD-WAN Node ID: the SD-WAN NLRI advertisement is sent out by the SD- 335 WAN node to indicate all the available ports supporting SD-WAN 336 tunnels. The SD-WAN Node ID can be the node's system ID, such as the 337 loopback address of the SD-WAN node. 339 6. SD-WAN Tunnel Encapsulation Attribute sub-TLV: 341 The SD-WAN overlay tunnel end-points property is encoded in the 342 Tunnel Encapsulation Attribute originally defined in [Tunnel- 343 Encap]using a new Tunnel-Type TLV (SD-WAN Tunnel Type, with the code 344 point to be assigned by IANA) from the "BGP Tunnel Encapsulation 345 Attribute Tunnel Types". 347 The SD-WAN Tunnel End-Point Property Encoding structure is as 348 follows: 350 Overlay SAFI (=74) NLRI: < Route-Type, Length, Port-ID, SD-WAN-color, 351 SD-WAN-Node-ID> 352 Attributes: 353 Tunnel Encaps Attribute 354 Tunnel Type: SD-WAN-Tunnel 355 EncapExt SubTLV 356 IPsec-SA Attribute SubTLV 358 Where 359 - Encap-Ext SubTLV is for describing additional information about the 360 SD-WAN tunnel end-points, such as NAT property. 361 - IPsec-SA SubTLV is for the node to establish IPsec SA with other 362 peers. 364 The Tunnel Encaps Attribute are defined as follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Tunnel-Type(2 Octets) | Length (2 Octets) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 | Value | 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Figure 1: SD-WAN Tunnel Encapsulation TLV Value Field 377 Where: 378 Tunnel Type is SD-WAN (to be assigned by IANA). 380 6.1. IPsec SA sub-TLV 382 The IPsecSA sub-TLV is for the SD-WAN node to establish IPsec 383 security association with their peers: 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 |IPsec-SA Type |IPsecSA Length | Flag | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Transform | Transport | AH | ESP | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | SPI | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | key1 length | key1 | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | key2 length | key2 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | key3 length | key3 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Duration | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Where: 404 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 405 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 406 for length to carry the needed information. 407 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 408 o Flags: 1 octet of flags. None are defined at this stage. Flags 409 SHOULD be set to zero on transmission and MUST be ignored on 410 receipt. 411 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 412 o Transport (1 byte): the value can be Tunnel Mode or Transport 413 mode 414 o AH (1 byte): AH authentication algorithms supported, which can 415 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each SD- 416 WAN node can have multiple authentication algorithms; send to 417 its peers to negotiate the strongest one. 419 o ESP (1 byte): ESP authentication algorithms supported, which 420 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 421 SD-WAN node can have multiple authentication algorithms; send 422 to its peers to negotiate the strongest one. Default algorithm 423 is AES-256. 424 o SPI: 4 bytes 425 o Key1.AH authentication key 426 o Key2.ESP authentication key 427 o Key3.ESP encryption "public" key 428 o Duration: SA life span. 430 6.2. EncapsExt sub-TLV 432 EncapsExt sub-TLV is for describing additional information about the 433 SD-WAN tunnel end-points, such as NAT property. A SD-WAN edge node 434 can inquire STUN (Session Traversal of UDP Through Network Address 435 Translation RFC 3489) Server to get the NAT property, the public IP 436 address and the Public Port number to pass to peers. 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |EncapExt Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | NAT Type | Encap-Type |Trans networkID| RD ID | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Private IP Address | 445 32-bits for IPv4, 128-bits for Ipv6 446 ~~~~~~~~~~~~ 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Private Port | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Public IP | 451 32-bits for IPv4, 128-bits for Ipv6 452 ~~~~~~~~~~~~ 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Public Port | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Where: 459 o EncapExt Type: indicate it is the EncapExt SubTLV. 460 o EncapExt subTLV Length: the length of the subTLVE. 461 o Flags: 462 o I bit: if set to 0, indicate the private address is IPv4. 463 If set to 1, it indicates the private address is IPv6. 464 o O bit: if set to 0, indicate the public address is IPv4. 465 If set to 1, it indicates the public address is IPv6. 466 o R bits: reserved for future use. Must be set to 0 now. 468 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 469 Cone; Port Restricted Cone; or Symmetric 470 o Encap Type.SD-WAN tunnel encapsulation types, such as 471 IPsec+GRE, IPsec+VxLAN, IPsec without GRE, GRE (when tunnel is 472 over secure underlay network) 473 o Transport Network ID.Central Controller assign a global unique 474 ID to each transport network. 475 o RD ID.Routing Domain ID.Need to be global unique. 476 o Private IP.The local IP address of the tunnel end-point. 477 o Private Port.used by Remote SD-WAN node for establishing IPsec 478 to this specific port. 479 o Public IP.The IP address after the NAT. 480 o Public Port.The Port after the NAT. 482 Note: need to support IPv6 for Private IP addresses 484 7. SD-WAN Tunnel Advertisement Method: 486 +---+ 487 Peer Group 1 |RR | Peer Group 2 488 +======+====+=+ +======+====+=====+ 489 / / | +---+ | \ \ 490 / / | | | \ 491 +-+-+ +-+--+ +-+-+ +-+-+ +-+-+ +-+-+ 492 |CPE| | CPE|--|CPE| |CPE| |CPE| |CPE| 493 | 1 | | 2 | | 3 | |4 | | 5 | | 6 | 494 +---+ +----+ +---+ +---+ +---+ +---+ 495 Tenant 1 Tenant 2 497 For SD-WAN overlay network, the SD-WAN edge nodes (a.k.a. CPEs) belonging 498 to the same Tenant can be far apart and can be connected by third party 499 untrusted networks. Therefore, it is not appropriate for a SD-WAN node 500 (CPE) to advertise its SD-WAN tunnel properties to its immediate neighbors. 501 Each CPE propagates its SD-WAN tunnel attributes via the secure channel 502 established with RR. 504 The processing steps on CPE1 are as follow: 505 - Report the SD-WAN tunnel information, such as IPsec property, NAT, 506 etc. to RR via the Overlay SAFI NLRI. 507 - RR propagate the information to CPE2 & CPE 3. 508 - CPE2 and CPE3 can establish IPsec SA with the CPE1 after receiving 509 the Overlay SAFI NLRI from RR. 511 Tenant separation is achieved by different SD-WAN nodes being added 512 to different Peer Group. 514 8. Manageability Considerations 516 TBD 518 9. Security Considerations 520 The intention of this draft is to identify the gaps in current and 521 proposed SD-WAN approaches that can address requirements 522 identified in [Net2Cloud-problem]. 524 Several of these approaches have gaps in meeting enterprise 525 security requirements when tunneling their traffic over the 526 Internet, as is the general intention of SD-WAN. See the 527 individual sections above for further discussion of these security 528 gaps. 530 10. IANA Considerations 532 This document requires the following IANA actions. 534 o SD-WAN Overlay SAFI = 74 assigned by IANA 535 o SD-WAN Route Type 536 o SD-WAN Tunnel Type 537 o IPsec-SA Type 538 o EncapExt Type 540 11. References 542 11.1. Normative References 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 11.2. Informative References 548 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 549 (I2NSF) Problem Statement and Use Cases", July 2017 551 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 552 Address Family Identifier (SAFI) and the BGP Tunnel 553 Encapsulation Attribute", April 2009. 555 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 556 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 558 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 559 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 560 work-in-progress, July 2018 562 [DMVPN] Dynamic Multi-point VPN: 563 https://www.cisco.com/c/en/us/products/security/dynamic- 564 multipoint-vpn-dmvpn/index.html 566 [DSVPN] Dynamic Smart VPN: 567 http://forum.huawei.com/enterprise/en/thread-390771-1- 568 1.html 570 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 571 storage, distribution and enforcement of policies for 572 network security", Nov 2007. 574 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 575 Underlay to Cloud Overlay Problem Statement", draft-dm- 576 net2cloud-problem-statement-02, June 2018 578 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 579 of Interconnecting Underlay with Cloud Overlay", draft-dm- 580 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 582 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 583 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 585 12. Acknowledgments 587 Acknowledgements to Jim Guichard, John Scudder, Darren Dukes, Andy 588 Malis and Donald Eastlake for their review and contributions. 590 This document was prepared using 2-Word-v2.0.template.dot. 592 Authors' Addresses 594 Linda Dunbar 595 Huawei 596 Email: Linda.Dunbar@huawei.com 598 Haibo Wang 599 Huawei 600 Email: rainsword.wang@huawei.com 602 WeiGuo Hao 603 Huawei Technologies Co.,Ltd. 604 Email: haoweiguo@huawei.com