idnits 2.17.1 draft-dunbar-idr-sdwan-port-safi-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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 10, 2019) is 1775 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SDWAN-BGP-USAGE' is mentioned on line 112, but not defined == Missing Reference: 'RFC4760' is mentioned on line 219, but not defined == Unused Reference: 'RFC2119' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 508, 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: 0 errors (**), 0 flaws (~~), 16 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 Futurewei 3 Intended status: Experimental S. Hares 4 Expires: Dec 10, 2019 Hickory Hill Consulting 6 June 10, 2019 8 Subsequent Address Family Indicator for SDWAN Ports 9 draft-dunbar-idr-sdwan-port-safi-02 11 Abstract 13 The document specifies a new BGP NLRI and SAFI for advertising 14 properties of a SDWAN edge node WAN ports that face untrusted 15 networks, such as the public internet. Those WAN ports may get 16 assigned IP addresses from the Internet Service Providers (ISPs), 17 may get assigned dynamic IP addresses via DHCP, or may have private 18 addresses (e.g. inside third party Cloud DCs). Packets sent over 19 those SDWAN WAN ports might need to be encrypted (depending on the 20 user policies) or need to go through NAT. SDWAN edge needs to 21 propagate those WAN ports properties to its SDWAN controller, which 22 propagates to the authorized peers and manage the IPsec SAs among 23 those peers for encrypting traffic via the untrusted networks. 25 BGP Route Reflectors (RR) are proposed to propagate this information 26 to the controlled group of other edges in order to allow scaling of 27 the WAN ports property propagation in SDWAN Overlay. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on December 10, 2019. 52 Copyright Notice 54 Copyright (c) 2019 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction...................................................3 70 2. Conventions used in this document..............................5 71 3. SDWAN NLRI Format..............................................5 72 3.1. SDWAN Route Type..........................................7 73 3.2. Port Distinguisher........................................8 74 3.3. SDWAN Site ID.............................................8 75 3.4. Extended Port Property....................................8 76 3.5. IPsec Security Association Property......................10 77 3.6. Remote Endpoint..........................................11 78 4. Manageability Considerations..................................12 79 5. Security Considerations.......................................12 80 6. IANA Considerations...........................................12 81 7. References....................................................12 82 7.1. Normative References.....................................13 83 7.2. Informative References...................................13 84 8. Acknowledgments...............................................14 86 1. Introduction 88 [Net2Cloud-Problem] introduces using SDWAN to reach workloads in 89 dynamic third party data centers and aggregate multiple underlay 90 paths, including public untrusted networks, provided by different 91 service providers. However, scaling the combination of routes and 92 IPsec SAs key management can be an issue when the number of nodes 93 interconnected by the SDWAN overlay paths reaches 10,000 to 100,000 94 nodes. 96 [SDWAN-BGP-USAGE] describes multiple SDWAN scenarios and how/why 97 using BGP as control plane for the SDWAN networks. 99 This document describes a new BGP NLRI and SAFI to advertise 100 properties of WAN ports facing the public internet. This new SAFI & 101 NLRI is for the Scenario #2 of the [SDWAN-BGP-USAGE] where one 102 "SDWAN" edge node having multiple ports some of which connected to 103 private networks and others connected to public untrusted networks. 104 The packets sent over the private networks can go natively without 105 encryption (for better performance), only the packets sent over the 106 public networks needs IPsec SA. 108 The new SAFI and NLRI are for advertising the properties of WAN 109 ports facing public untrusted networks, through which data packets 110 have to be encrypted using IPsec. 112 The [SDWAN-BGP-USAGE] document describes the three functional tiers 113 for the control plane of SDWAN Scenario #2: 115 . Tier 1 (Edge Router of SDWAN): Each Edge SDWAN router 116 registers with the SDWAN Controller using a secure connection 117 (e.g. TLS). During the registration process, the controller 118 may suggest a specific BGP RR peer for the Edge SDWAN router 119 to exchange BGP route with. 121 After registering, each Edge Router sends routes + SDWAN WAN 122 ports information (NAT and security information) via the SDWAN 123 SAFI + NLRI to the BGP RR. Due to the sensitivity of the 124 information, the BGP peering session MUST be configured to run 125 over a Secure TCP (TLS). 127 . Tier 2: Route Reflector that combines information from the 128 security information from the SDWAN controller, the WAN ports 129 properties from SDWAN edge routers, and 131 . Tier 3: Client routes distribution, just like EVPN or L3VPN, 132 except including additional paths over the WAN ports facing 133 the public Internet. 135 Traffic go through the private networks links natively without 136 encryption and are encrypted when sent out the WAN ports facing 137 public Internet. 139 The BGP peers use a new BGP NLRI and SAFI to pass the SDWAN Internet 140 WAN ports properties, such as NAT and security association (SA). 141 This information includes the Port-ID and port related NAT 142 information, SDWAN-SITE-ID, SDWAN Node-ID, and IPsec security 143 information. 145 Centralized----------------------------------------------- 146 controller | 147 | | 148 | +---+ | 149 | Peer Group 1 |RR | Peer Group 2 | 150 | +======+====+=+ +======+====+=====+ | 151 | / / | +---+ | \ \ | 152 | / / | | | \ | 153 | +-+-+ +-+--+ +-+-+ +-+-+ +-+-+ +-+-+ | 154 | |CPE| | CPE|--|CPE| |CPE| |CPE| |CPE| | 155 ---| 1 | | 2 | | 3 | |4 | | 5 | | 6 |----| 156 +---+ +----+ +---+ +---+ +---+ +---+ 157 Tenant 1 Tenant 2 159 Figure 1: SDWAN Capability Advertisement via RR 161 Note: All CPEs (CPE1, CPE2, CPE, CPE4, CPE5, and CPE) connect to the 162 centralized controller, but only 2 connections are show in this 163 diagram. 165 2. Conventions used in this document 167 Cloud DC: Off-Premise Data Centers that usually host applications 168 and workload owned by different organizations or 169 tenants. 171 Controller: Used interchangeably with SDWAN controller to manage 172 SDWAN overlay path creation/deletion and monitor the 173 path conditions between sites. 175 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 176 This is to differentiate from most commonly used PE- 177 based VPNs a la RFC 4364. 179 SDWAN End-point: An WAN port (logical or physical) of a SDWAN node. 180 (If "endpoint" is used, it refers to a SDWAN End-point). 182 OnPrem: On Premises data centers and branch offices 184 SDWAN: Software Defined Wide Area Network. In this document, 185 "SDWAN" refers to the solutions of pooling WAN bandwidth 186 from multiple underlay networks to get better WAN 187 bandwidth management, visibility & control. When the 188 underlay networks are private networks, traffic can 189 traverse without additional encryption; when the 190 underlay networks are public, such as Internet, some 191 traffic needs to be encrypted when traversing through 192 (depending on user provided policies). 194 3. SDWAN NLRI Format 196 The new SAFI code point 74 has been assigned by IANA as the 197 Subsequent Address Family Identifier for advertising properties of 198 WAN ports that face untrusted networks. Depending on user policies, 199 some packets through those WAN ports will need encryption. 201 The SDWAN SAFI (code point 74 assigned by IANA) uses a new NLRI 202 defined as follows: 204 +------------------+ 205 | NLRI Length | 1 octet 206 +------------------+ 207 | SDWAN-Type | 2 Octets 208 +------------------+ 209 |Port-Distinguisher| 4 octets 210 +------------------+ 211 | SDWAN-Site-ID | 4 octets 212 +------------------+ 213 | SDWAN-Node-ID | 4 or 16 octets 214 +------------------+ 216 where: 218 - NLRI Length: 1 octet of length expressed in bits as defined in 219 [RFC4760]. 220 - SDWAN-Type: to define the encoding of the rest of the SDWAN 221 NLRI. 222 - Port Distinguisher: SDWAN node Port identifier. There can be 223 many ports on a SDWAN node; each port can have different 224 properties. For example, some ports may get ISP or DHCP assigned 225 IP addresses (IPv4 or IPv6), some may have private IP addresses 226 that packets to/from those ports have to traverse NAT. 227 The detailed properties about the port are further encoded in 228 the subsequent subTLVs, e.g. Port-subTLV. 230 - SDWAN-Site-ID: used to identify a common property shared by a 231 set of SDWAN nodes, such as the property of a specific 232 geographic location shared by a group of SDWAN nodes. 233 - SDWAN Node ID: the SDWAN node identifier, which can be the 234 node's system ID or the loopback address (IPv4 or IPv6) of the 235 SDWAN node. 237 The content of the SDWAN Port properties is encoded in the Tunnel 238 Encapsulation Attribute originally defined in [Tunnel-Encap] using a 239 new Tunnel-Type TLV (code point to be assigned by IANA from the "BGP 240 Tunnel Encapsulation Attribute Tunnel Types" registry). 242 SDWAN SAFI (=74) NLRI: < SDWAN-Type, Length, Port-distinguisher, 243 SDWAN-Site-ID, SDWAN-Node-ID> 244 Attributes: 245 Tunnel Encaps Attribute 246 Tunnel Type: SDWAN Port Property 247 NAT SubTLV 248 IPsec-SA Attribute SubTLV 249 Port-subTLV 251 Where 252 - NAT SubTLV is for describing additional information about the 253 SDWAN tunnel end-points, such as NAT property. 254 - IPsec-SA SubTLV is for the node to establish IPsec SA with 255 other peers. 256 - Port-subTLV is for additional properties of the WAN port. 258 The Tunnel Encaps Attribute are defined as follows: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Tunnel-Type(2 Octets) | Length (2 Octets) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 | Value | 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 1: SDWAN Tunnel Encapsulation TLV Value Field 271 Where: 272 Tunnel Type is SDWAN Port Property (to be assigned by IANA). 274 3.1. SDWAN Route Type 276 A new Route Type that defines the encoding of the rest of the SDWAN 277 NLRI, and a set of sub-TLVs to specify its end-point attributes, 278 policies associated with the Ports: 280 3.2. Port Distinguisher 282 One (SDWAN) node can have multiple ports, and each port can support 283 multiple IPsec SA to different peers. The Port Distinguisher is to 284 uniquely identify a port (or link). 286 The property of the port are encoded in the subTLV attached to the 287 SDWAN NLRI: 289 a) The IP address (IPv4 or IPv6) & AS number of the Port 290 b) NAT information for ports with Private IP address 291 c) IPsec Security Association related information if the port is 292 facing public network and traffic through which have to be 293 encrypted. 294 Detailed encoding for those properties are described in Section 3.4 295 & Section 3.5 respectively. 297 3.3. SDWAN Site ID 299 SDWAN Site ID is used to identify a common property shared by a set 300 of SDWAN nodes/ports, such as the property of a specific geographic 301 location. The property is used to steer an overlay route to traverse 302 specific geographic locations for various reasons, such as to comply 303 regulatory rules, to utilize specific value added services, or 304 others. 306 3.4. Extended Port Property 308 EncapExt sub-TLV is for describing additional information about a 309 SDWAN port, such as the NAT property if the port has private 310 address, the network identifier that the port is part of, etc. 312 A SDWAN edge node can inquire STUN (Session Traversal of UDP Through 313 Network Address Translation RFC 3489) Server to get the NAT 314 property, the public IP address and the Public Port number to pass 315 to peers. 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |EncapExt Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | NAT Type | Encap-Type |Trans networkID| RD ID | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Local IP Address | 324 32-bits for IPv4, 128-bits for Ipv6 325 ~~~~~~~~~~~~ 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Local Port | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Public IP | 330 32-bits for IPv4, 128-bits for Ipv6 331 ~~~~~~~~~~~~ 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Public Port | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Where: 338 o EncapExt Type: indicate it is the EncapExt SubTLV. 339 o EncapExt subTLV Length: the length of the subTLVE. 340 o Flags: 341 - I bit (CPE port address or Inner address scheme) 342 If set to 0, indicate the inner (private) address is IPv4. 343 If set to 1, it indicates the inner address is IPv6. 345 - O bit (Outer address scheme): 346 If set to 0, indicate the public (outer) address is IPv4. 347 If set to 1, it indicates the public (outer) address is 348 IPv6. 350 - R bits: reserved for future use. Must be set to 0 now. 352 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 353 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 354 response from the STUN server). 355 o Encap Type.the supported encapsulation types for the port 356 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 357 without GRE, GRE (when packets don't need encryption) 359 o Transport Network ID.Central Controller assign a global unique 360 ID to each transport network. 361 o RD ID.Routing Domain ID.Need to be global unique. 362 o Local IP.The local (or private) IP address of the port. 363 o Local Port.used by Remote SDWAN node for establishing IPsec to 364 this specific port. 365 o Public IP.The IP address after the NAT. If NAT is not used, 366 this field is set to NULL. 367 o Public Port.The Port after the NAT. If NAT is not used, this 368 field is set to NULL. 370 3.5. IPsec Security Association Property 372 The IPsecSA sub-TLV is for the SDWAN node to establish IPsec 373 security association with their peers via the port that face 374 untrusted network: 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |IPsec-SA Type |IPsecSA Length | Flag | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Transform | Transport | AH | ESP | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | SPI | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | key1 length | key1 | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | key2 length | key2 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | key3 length | key3 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Duration | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Where: 395 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 396 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 397 for length to carry the needed information. 398 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 399 o Flags: 1 octet of flags. None are defined at this stage. Flags 400 SHOULD be set to zero on transmission and MUST be ignored on 401 receipt. 402 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 403 o Transport (1 byte): the value can be Tunnel Mode or Transport 404 mode 405 o AH (1 byte): AH authentication algorithms supported, which can 406 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 407 SDWAN node can have multiple authentication algorithms; send to 408 its peers to negotiate the strongest one. 409 o ESP (1 byte): ESP authentication algorithms supported, which 410 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 411 SDWAN node can have multiple authentication algorithms; send to 412 its peers to negotiate the strongest one. Default algorithm is 413 AES-256. 414 o SPI: 4 bytes 415 o Key1.AH authentication key 416 o Key2.ESP authentication key 417 o Key3.ESP encryption "public" key 418 o Duration: SA life span. 420 3.6. Remote Endpoint 422 The Remote Endpoint sub-TLV is not used for SDWAN NLRI because 423 o The network to which a SDWAN port is connected might have 424 identifier that is more than the AS number. SDWAN controller 425 might use its own specific identifier for the network. 426 o The Transport-Network-ID in the EncapExt sub-TLV represents the 427 SDWAN unique network identifier. 429 If the Remote Endpoint Sub-TLV is present, it is ignored by other 430 SDWAN nodes. 432 4. Operation of SDWAN routers: 434 The processing steps on CPE1 to announce the SDWAN combination of 435 routes, NAT and IPsec information via BGP are: 437 1. Advertise the SDWAN capability information and port properties, 438 such as Port identifiers and supported properties etc. to RR via the 439 SDWAN SAFI NLRI. 441 2. RR propagate the information to CPE2 & CPE 3. 443 3. CPE2 and CPE3 can choose to establish IPsec SA with the CPE1 444 after receiving the CPE1 WAN properties from RR. 446 Note: Tenant separation is achieved by different SDWAN nodes being 447 added to different Peer Group. 449 4. Manageability Considerations 451 TBD - this needs to be filled out before publishing 453 5. Security Considerations 455 The document is to address how SDWAN nodes advertise its SDWAN 456 capability to their peers via untrusted & unsecure networks. 458 The secure propagation is achieved by secure channels, such as 459 TLS, SSL, or IPsec, between the SDWAN nodes and the local 460 controller RR. 462 [More details need to be filled in here] 464 6. IANA Considerations 466 This document requires the following IANA actions. 468 o SDWAN Overlay SAFI = 74 assigned by IANA 469 o SDWAN Route Type 471 7. References 472 7.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 7.2. Informative References 478 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 479 (I2NSF) Problem Statement and Use Cases", July 2017 481 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 482 Address Family Identifier (SAFI) and the BGP Tunnel 483 Encapsulation Attribute", April 2009. 485 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 486 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 488 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 489 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 490 work-in-progress, July 2018 492 [DMVPN] Dynamic Multi-point VPN: 493 https://www.cisco.com/c/en/us/products/security/dynamic- 494 multipoint-vpn-dmvpn/index.html 496 [DSVPN] Dynamic Smart VPN: 497 http://forum.huawei.com/enterprise/en/thread-390771-1- 498 1.html 500 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 501 storage, distribution and enforcement of policies for 502 network security", Nov 2007. 504 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 505 Underlay to Cloud Overlay Problem Statement", draft-dm- 506 net2cloud-problem-statement-02, June 2018 508 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 509 of Interconnecting Underlay with Cloud Overlay", draft-dm- 510 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 512 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 513 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 515 8. Acknowledgments 517 Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for 518 implementation contribution; Many thanks to Jim Guichard, John 519 Scudder, Darren Dukes, Andy Malis, Rachel Huang and Donald Eastlake 520 for their review and contributions. 522 This document was prepared using 2-Word-v2.0.template.dot. 524 Authors' Addresses 526 Linda Dunbar 527 Futurewei 528 Email: ldunbar@futurewei.com 530 Sue Hares 531 Hickory Hill Consulting 532 Email: shares@ndzh.com