idnits 2.17.00 (12 Aug 2021) /tmp/idnits15484/draft-dunbar-opsawg-private-networks-over-thin-cpe-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 is 1 instance of too long lines in the document, the longest one being 1 character 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2021 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF-framework' is mentioned on line 421, but not defined == Unused Reference: 'I2NSF-Framework' is defined on line 457, but no explicit reference was found in the text == Outdated reference: draft-ietf-i2nsf-framework has been published as RFC 8329 Summary: 1 error (**), 0 flaws (~~), 5 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 L. Yong 3 Intended status: Informational Song Xiao Lin 4 Huawei 6 Expires: April 2017 October 31, 2016 8 Client Defined Private Networks laid over Thin CPEs 9 draft-dunbar-opsawg-private-networks-over-thin-cpe-01 11 Abstract 13 This document specifies a type of private networks that 14 interconnect thin CPEs at multiple client sites by IP tunnels, or 15 more specifically, lay over multiple client sites' Thin CPEs via IP 16 tunnels. Those private overlay networks not only interconnect those 17 sites by secure IP tunnels but can also enforce the client specified 18 policies to govern how applications or hosts within those sites 19 communicate and how to access public internet. 21 Hosts or applications in those sites can be interconnected by Layer 22 2 networks or/and by Layer 3 networks. The network that the IP 23 tunnels are traversing can be IPv4 or IPv6 networks. This document 24 describes the special properties of the client defined networks over 25 Thin CPEs. 27 A separate draft will describes the special features that those IP 28 tunnels need to have in order to interconnect multiple sites as if 29 those sites are directly connected by wires and how communication 30 policies are enforced. 32 Status of This Document 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other documents 44 at any time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 31, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................4 67 2. Terminology....................................................4 68 2.1. Requirements Language.....................................4 69 2.2. Terms defined in this document............................4 70 3. Brief Description of the Private networks laid over Thin CPEs..6 71 4. Overlay Private Network Configuration from Client Perspective..8 72 4.1. Client Defined Overlay Private Networks...................8 73 4.2. Client's site Configuration...............................8 74 4.3. Internet Gateway for each Site............................9 75 4.4. Overlay-VPN Gateway.......................................9 76 4.5. Interconnection among Sites...............................9 77 5. Protocols needed for the Client Defined Overlay Private Networks 78 .................................................................10 79 5.1. Thin CPE Auto Instantiation..............................10 80 5.2. Network agnostic interworking............................10 81 5.3. Gateway Anchor Auto-Selection............................10 82 5.4. Middle boxes auto-creation and rules exchanges...........10 83 5.5. Thin CPE on Third Party location.........................11 84 5.6. Client Defined Polices for traffic to/from client sites..11 85 5.7. QoS policies.............................................11 86 5.8. Explicit Service functions chain specified by clients....11 87 5.9. Thin CPE monitoring......................................11 88 5.10. Alarm & Events via Thin CPE.............................11 89 5.11. Resource management via Thin CPE instantiated in Remote 90 Locations.....................................................11 91 5.12. Client traffic flows management, monitoring, and reporting 92 ..............................................................11 93 6. Networks carried by IP tunnels in conjunction with existing 94 L2VPN/L3VPN......................................................12 95 7. IANA Considerations...........................................12 96 8. Security Considerations.......................................12 97 9. References....................................................12 98 9.1. Normative References.....................................12 99 9.2. Informative Reference....................................12 100 10. Authors' Addresses...........................................12 101 11. Contributors Addresses.......................................13 103 1. Introduction 105 This document specifies a type of private networks that interconnect 106 thin CPEs at multiple client sites by IP tunnels, or more 107 specifically, lay over multiple client sites' Thin CPEs via IP 108 tunnels. Those private overlay networks not only interconnect those 109 sites by secure IP tunnels but can also enforce the client specified 110 policies to govern how applications or hosts within those sites 111 communicate and how to access public internet. 113 Hosts or applications in those sites can be interconnected by Layer 114 2 networks or/and by Layer 3 networks. The network that the IP 115 tunnels are traversing can be IPv4 or IPv6 networks. This document 116 describes the special properties of the client defined networks over 117 Thin CPEs. 119 For ease of description, the "Client Defined Private Overlay 120 Network" is also called the client's "Overlay Private Network" or 121 "Overlay Virtual Private Network (Overlay-VPN)" throughout this 122 document. 124 A separate draft will describes the special features that those IP 125 tunnels need to have in order to interconnect multiple sites as if 126 those sites are directly connected by wires and how communication 127 policies are enforced. 129 2. Terminology 131 2.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2.2. Terms defined in this document 139 Internet Gateway: a network function, which can be a physical device 140 in the provider site or a virtual function instantiated to connect 141 client site traffic to the public internet, and can enforce client 142 specified policies. 144 Overlay Private Network: private network over a set of thin CPEs at 145 multiple sites created by clients or users, who don't need to worry 146 about how thin CPEs are connected nor the protocol setting at 147 network side. The "Overlay Private Network" not only interconnects 148 multiple sites by (secure) IP tunnels but can also enforce the 149 client specified policies to govern how applications or hosts within 150 those sites communicate and how to access public internet. 152 Overlay-VPN: Overlay Private Network. 154 Provider site: the location where the provider have access to the 155 devices or equipment. 157 Site: A place that contains switches, routers, services, appliances 158 and these devices are configured to form L2 domain (s) or L3 domain. 159 For example an Enterprise company data center, a college campus 160 network center. For L3 subnets, either private IPv4 or IPv6 address 161 or public IPv4 or Ipv6 address can be used. 163 SITE: Site Interconnection Tunnel Encapsulation Protocol 165 Thin CPE: a simple device at a customer premise that maps the site 166 local traffic to either the IP tunnels connected to the Internet 167 Gateway, or the IP tunnels connected to the VPN Gateway. 169 Overlay-VPN Gateway: the function (which can be virtual) that 170 establish private (secure) connections to other sites belonging to 171 the same client. 173 3. Brief Description of the Private networks laid over Thin CPEs 175 The following figure depicts multiple overlay private networks that 176 interconnect the client's various sites. Note, the Overlay Private 177 Network is marked as "Overlay" in the figure. The client can create 178 multiple overlay private networks and then assign each site to 179 specific overlay private networks. The client also specify the 180 policies on what traffic to/from the clients can be exchanged with 181 external network, which are enforced by the "Internet gateways" 182 created by the provider. 184 _,....._ 185 ,-' `-. 186 / External `. 187 | Network | 188 `. / 189 `.__ _,-' 190 `'''' 191 | 192 +---------+ 193 +-+-------+ | 194 +-+-------+ | | 195 |Internet | +-+For enforcing policies 196 |Gateway x+-+ 197 +----+----+ 198 / \ 199 +---------+---+-----------------+ 200 +--------+ +-----+ 201 | L3 +--+ +----| | 202 |Network | | | | L2 | 203 +--------+ | +--+------+ | +--+--+ 204 | +-+--+ +--|Overlay1 | ++---+ | 205 | |Site|/ +-|-------+-+ +---------|Site+---+ 206 +--| 1 |\+----|Overlay2 |/ +----| 2 |-+ 207 +---++ +-+-------+-+ / +--+-+ | 208 / \ |Overlay3 |--+ | 209 +--------+ / \ +-+-------+ +---+-+ 210 | L2 +--+ \ | | | 211 |Network | \ | | L3 | 212 +--------+ \ | +-----+ 213 +-+-----+ 214 | Site | can be in Cloud DC, private DC 215 | 3 | or customer premises. 216 +-------+ 218 Figure 1 Overlay Private Networks interconnecting sites 220 Here are some key properties of Client defined Overlay Private 221 Networks: 223 - Each client "Site" has a Thin CPE that is connected to a VPN 224 gateway which is hosted in the provider site via IP Tunnel (which 225 can be secured per customer request). The Thin CPE can be software 226 image instantiated on virtual machines, physical CPE, or other 227 form factors. 229 ---------------+ 230 Site +-+--+| +--------+ 231 1 |Thin||<---->|Overlay +<======> Overlay VPN1, 232 |CPE || |VPN GW | Overlay VPN2 233 +-+--+| +--------+ 234 ---------------+ 235 Figure 2 site Thin CPE connect to Overlay GW via IP Tunnel 237 - Each Thin CPE is connected to an "Internet Gateway" via IP Tunnel 238 (that is automatically created by provider). The "Internet 239 Gateway", virtual or physical, can be located anywhere. An IP 240 Tunnel is created automatically between the Thin CPE and the 241 "Internet Gateway". 243 - When the provider don't own the infrastructure to interconnect 244 multiple sites, (secure) IP Tunnels are created among each site's 245 VPN Gateway, so that each site's local networks (L2 or L3) 246 attached to the Thin CPEs are interconnected as if those networks 247 are directly connected by physical wire. 249 - Some traffic between Thin CPE have to go through secure tunnel, 250 e.g. IPSec. Clients can specify what traffic to go through secure 251 tunnels without specifically worrying about how to establish or 252 maintain the secure tunnels. The client traffic can be carried by 253 VxLAN (for interconnecting layer 2 traffic) or GRE (for L3 traffic) 254 over the IPSEc tunnel. 256 - Client specifies the policies on how/what/when hosts from the 257 interconnected sites can communicate with external peers; E.g. 258 Hosts in one Layer 2 domain from one site may communicate with 259 hosts in different Layer 2 domains in different sites. 261 The Client Defined Overlay Networks can be viewed by client as their 262 own private networks. For ease of description, the terminology 263 "Overlay Private Network" or "Overlay-VPN" is used throughout this 264 document to refer to this kind of client defined overlay network 265 over Thin CPEs. 267 "Overlay Private Network" is different from the IETF's L2VPN or 268 L3VPN for the following reasons: 270 - Overlay-Private-Network is built upon IP network (whereas 271 L2VPN/L3VPN is built upon MPLS network), 273 - Traffic originated from a client's site (where Thin CPE is 274 instantiated) not only can communicate with hosts in other sites 275 of the client via IP tunnels, but also can communicate with public 276 internet (governed by the policies specified by the client), 278 - Client's site Thin CPE don't participate in IGP or BGP routing 279 with provider side. Client can specify the prefixes and/or VLANs 280 for each site so that they can be reached by external hosts, 282 - IP tunnel is automatically created between a Thin CPE and 283 provider site where VPN gateway and internet gateway are 284 instantiated and maintained. 286 4. Overlay Private Network Configuration from Client Perspective 288 4.1. Client Defined Overlay Private Networks 290 The client can specify multiple overlay private networks (a.k.a. 291 Overlay-VPNs). Client can specify which sites connect to which 292 Overlay-VPNs. Each Site can connect to multiple Overlay-VPNs. 294 As features on Thin CPE are very limited, each Overlay-VPN has its 295 own Overlay VPN gateway in provider site to connect to Thin CPE via 296 IP tunnel, as depicted in Figure 2 above. 298 4.2. Client's site Configuration 300 For each site, the client needs to specify: 302 - Site Identifier (include unique system Identifier, name, etc.) 304 - VLANs enabled on the site (i.e. the VLANs enabled on the client 305 facing ports of the Thin CPE). 307 - Subnets from the site (i.e. the subnets enabled on the client 308 facing ports of the Thin CPE) 310 - IP address for the Overlay-VPN Gateway that connect other sites 311 belonging to the client 313 - IP address for the Internet Gateway 315 The configuration on the site is mainly for the Thin CPE 316 instantiated on the site. Therefore, the client also needs to 317 specify which VLANs/subnets are enabled on the ports of the Thin CPE 318 facing the local network on the site. 320 4.3. Internet Gateway for each Site 322 Each site is associated with an Internet Gateway, which is 323 automatically created by the provider. The Interconnect gateway can 324 be a physical device on the provider site or a virtual function, to 325 connect client site traffic to the public internet, and can enforce 326 client specified policies. 328 Considering one client can have multiple sites in different 329 geographic locations, the client can specify different policies for 330 traffic to/from each site. 332 4.4. Overlay-VPN Gateway 334 The Overlay-VPN Gateway is on the provider site, connected to Thin 335 CPE via IP tunnel. The purpose of the Overlay-VPN Gateway is to 336 connect a site to its specified Overlay VPNs. Each site can be 337 connected to multiple Overlay VPNs. 339 For each Overlay-VPN gateway, the client needs to specify: 341 - Identifier 343 - Which VPN is the Gateway connected to 345 - Upstream bandwidth from Thin CPE to the Overlay VPN GW 347 - Downstream bandwidth from the Overlay VPN GW to the Thin CPE 349 4.5. Interconnection among Sites 351 For each Overlay VPN, the Client can choose which sites are 352 connected by specifying the VPN Gateway associated with each site. 354 5. Protocols needed for the Client Defined Overlay Private Networks 356 5.1. Thin CPE Auto Instantiation 358 Thin CPE is a simple device that maps the site local traffic to 359 either the IP tunnels connected to the Internet Gateway, or the IP 360 tunnels connected to the VPN Gateway. 362 5.2. Network agnostic interworking 364 IP tunnels are automatically created between Thin CPE and 365 (Internet/VPN) gateways based on the traffic to the access network. 367 For Layer 2 traffic from the client local site, VxLAN is used to 368 build the IP Tunnels to the site's Internet gateway or VPN gateway 369 respectively. 371 For Layer 3 traffic from the client local site, GRE is used to build 372 the IP Tunnels to the site's Internet gateway or VPN gateway 373 respectively. 375 If the client specifies secure connection to other sites, IPSec is 376 added to the tunnels between the Thin CPE and the VPN Gateway. 378 5.3. Gateway Anchor Auto-Selection 380 For each client site, internet gateway and VPN gateway will be 381 automatically instantiated. 383 There will be protocol extension needed for the creation/deletion 384 process and how NAT is used for client traffic from each site. 386 5.4. Middle boxes auto-creation and rules exchanges 388 To be added 390 5.5. Thin CPE on Third Party location 392 Thin CPEs can also be instantiated third party premises, such as 393 cloud data centers. The instantiated Thin CPE can establish IP 394 tunnels with the client's Internet Gateway or VPN Gateway. 396 5.6. Client Defined Polices for traffic to/from client sites 398 Depending on the policies specified by the clients, the Thin CPE 399 jointly with the virtual GW will select the appropriate network 400 security functions, i.e. (virtual) FW, IPS, IDS, or others to 401 enforce the policies specified by the clients. 403 The policies specified by the clients will be more expressed in 404 clients' oriented language, e.g. using client Identifier or virtual 405 addresses (instead of IP addresses of the actual packets traverse 406 the FW). Those policies will be translated to the implementable 407 rules to the chosen network security functions, such as FW. 409 5.7. QoS policies 411 To be added 413 5.8. Explicit Service functions chain specified by clients 415 Clients can query network service functions available to them and 416 the capabilities of those functions. Then, the client can choose a 417 set of them, either in strict sequence or simply as a set to apply 418 to their traffic. 420 The policies to service functions can follow the guideline specified 421 by [I2NSF-framework]. 423 5.9. Thin CPE monitoring 425 5.10. Alarm & Events via Thin CPE 427 To be added 429 5.11. Resource management via Thin CPE instantiated in Remote Locations 431 To be added 433 5.12. Client traffic flows management, monitoring, and reporting 435 To be added 437 6. Networks carried by IP tunnels in conjunction with existing 438 L2VPN/L3VPN 440 7. IANA Considerations 442 To be added 444 8. Security Considerations 446 To be added. 448 9. References 450 9.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC2119, March 1997. 455 9.2. Informative Reference 457 [I2NSF-Framework] Lopez, D, et al, "Framework for Interface to 458 Network security functions", draft-ietf-i2nsf-framework-04, 459 Oct 2016 461 10. Authors' Addresses 463 Linda Dunbar 464 Huawei Technologies 465 Email: linda.dunbar@huawei.com 467 Lucy Yong 468 Huawei Technologies 469 Email: lucy.yong@huawei.com 471 Song Xiao Li 472 Huawei Technologies 473 Email: sxlin@huawei.com 475 11. Contributors Addresses 477 Xuan Ming fu 478 Huawei Technologies 479 xuanmingfu@huawei.com