idnits 2.17.1 draft-ietf-l3vpn-as2547-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1428. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([BGP-MPLS-IP-VPN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 210: '... the procedures of [BGP-MPLS-IP-OSPF-VPN] MUST be implemented.) In an...' RFC 2119 keyword, line 211: '...s links, the IGP MUST be a separate IG...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2004) is 7105 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: 'L3VPN-REQs' is mentioned on line 86, but not defined == Missing Reference: 'L3VPN-REQ' is mentioned on line 201, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-07 == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-02 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-framework (ref. 'L3VPN-FRMWRK') == Outdated reference: A later version (-02) exists of draft-ietf-l3vpn-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-requirements (ref. 'L3VPN-REQS') == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-security-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-security-framework (ref. 'L3VPN-SEC-FRMWRK') == Outdated reference: A later version (-06) exists of draft-ietf-l3vpn-ospf-2547-01 == Outdated reference: A later version (-05) exists of draft-ietf-l3vpn-ipsec-2547-02 == Outdated reference: A later version (-15) exists of draft-rosen-vpn-mcast-07 == Outdated reference: A later version (-01) exists of draft-ietf-l3vpn-l3vpn-auth-00 == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-ce-based-02 == Outdated reference: A later version (-07) exists of draft-ietf-l3vpn-mpls-vpn-mib-05 == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-vpn-vr-02 Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: April 2005 6 October 2004 8 Applicability Statement for BGP/MPLS IP VPNs 10 draft-ietf-l3vpn-as2547-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, we certify that any applicable 15 patent or other IPR claims of which we are aware have been disclosed, 16 or will be disclosed, and any of which we become aware will be 17 disclosed, in accordance with RFC 3668. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document provides an Applicability Statement for the VPN 40 ("Virtual Private Network") solution described in [BGP-MPLS-IP-VPN] 41 and other documents listed in the References section. 43 Table of Contents 45 1 Introduction ......................................... 3 46 2 SP Provisioning Model ................................ 5 47 3 Supported Topologies and Traffic Types ............... 7 48 4 Isolated Exchange of Data and Routing Information .... 8 49 5 Access Control and Authentication .................... 9 50 6 Security Considerations .............................. 10 51 6.1 Protection of User Data .............................. 10 52 6.2 SP Security Measures ................................. 11 53 6.3 Security Framework Template .......................... 12 54 7 Addressing ........................................... 19 55 8 Interoperability and Interworking .................... 20 56 9 Network Access ....................................... 20 57 9.1 Physical/Link Layer Topology ......................... 20 58 9.2 Temporary Access ..................................... 20 59 9.3 Access Connectivity .................................. 21 60 10 Service Access ....................................... 21 61 10.1 Internet Access ...................................... 21 62 10.2 Other Services ....................................... 22 63 11 SP Routing ........................................... 22 64 12 Migration Impact ..................................... 23 65 13 Scalability .......................................... 23 66 14 QoS, SLA ............................................. 26 67 15 Management ........................................... 28 68 15.1 Management by the Provider ........................... 28 69 15.2 Management by the Customer ........................... 29 70 16 Acknowledgments ...................................... 29 71 17 Normative References ................................. 29 72 18 Informative References ............................... 30 73 19 Author's Address ..................................... 31 74 20 Intellectual Property Statement ...................... 31 75 21 Full Copyright Statement ............................. 32 77 1. Introduction 79 This document provides an Applicability Statement for the VPN 80 ("Virtual Private Network") solution described in [BGP-MPLS-IP-VPN] 81 and other documents listed in the References section. We refer to 82 these as "BGP/MPLS IP VPNs", because BGP ("Border Gateway Protocol") 83 is used to distribute the routes, and MPLS ("Multiprotocol Label 84 Switching") is used indicate that particular packets need to follow 85 particular routes. The characteristics of BGP/MPLS IP VPNs are 86 compared with the requirements specified in [L3VPN-REQs]. 88 A VPN service is provided by a "Service Provider" (SP) to a 89 "Customer" (sometimes referred to as an "Enterprise") . BGP/MPLS IP 90 VPNs are intended for the situation in which: 92 - The Customer: 94 * uses the VPN only for carrying IP packets. 96 * does not want to manage a routed backbone; the customer may 97 be using routing within his sites, but wishes to outsource 98 the inter-site routing to the SP. 100 * wants the SP to make the backbone and its routing completely 101 transparent to the customer's own routing. 103 If the customer has a routed infrastructure at his sites, he 104 does not want his site routing algorithms to need to be aware 105 of any part of the SP backbone network, other than the PE 106 ("Provider Edge") routers to which the sites are attached. 107 In particular, the customer does not want his routers to need 108 to be aware of either the native structure of the SP 109 backbone, or of an overlay topology of tunnels through the SP 110 backbone. 112 - The Service Provider: 114 * has an IP backbone, with MPLS-enabled edge routers, and 115 possibly (though not necessarily) with MPLS-enabled core 116 routers. 118 * wants to provide a service which meets the customer 119 requirements above. 121 * does not want to maintain a distinct overlay topology of 122 tunnels for each customer. 124 The basic principle is to model each VPN as a self-contained 125 "internet", where each site makes one or more access connections to a 126 SP, sends the SP its routing information, and then relies on the SP 127 to distribute routing information to and from the other sites in that 128 same VPN. The service differs from Internet service, however, in 129 that the SP strictly controls the distribution of this routing 130 information so that routes from within a VPN are not sent outside the 131 VPN, unless that is explicitly authorized by the customer. In fact, 132 even within the VPN, the distribution of routes may be controlled by 133 the SP so as to meet some policy of the customer. 135 The routers at a given customer site need not be routing peers of the 136 routers at other customer sites, and indeed need not know anything 137 about the internal structure of other customer sites. In fact, 138 different routing protocols may run at the different sites, with each 139 site using whatever protocol is most appropriate for that particular 140 site. 142 If EBGP (the BGP procedures used between BGP speakers from different 143 Autonomous Systems) is used on the access links which connect a 144 Provider's Edge router ("PE router") to a Customer's Edge router ("CE 145 router"), then the SP and the customer do NOT peer in any IGP 146 ("Interior Gateway Protocol", i.e, intra-domain routing algorithm). 148 BGP/MPLS IP VPNs are optimized for the situation in which a customer 149 (an enterprise) expects a service provider to operate and maintain 150 the customer's "backbone" (i.e., the customer's inter-site routing). 151 As such, the service provider becomes a "business partner" of the 152 enterprise. The technical mechanisms accommodate the case in which a 153 number of closely cooperating SPs can jointly offer the VPN service 154 to a customer, in that the BGP-based route distribution mechanisms 155 can operate between different SPs. If a set of SPs have sufficient 156 agreements with respect to QoS ("Quality of Service"), SLA ("Service 157 Level Agreement"), etc., then the customer's VPN could have sites 158 attached to different SPs from that set. 160 [BGP-MPLS-IP-VPN] specifies the inter-AS ("Autonomous System") 161 mechanisms that allow a single VPN to have sites attached to 162 different SPs. However, the design center is not an environment 163 where a given VPN is spread among a very large number (e.g., 164 hundreds) of SPs. 166 In cases where remote offices, individual telecommuters, etc., must 167 use the public Internet to access the VPN, it is possible to "tunnel" 168 the remote traffic to a PE router, and the PE router will treat the 169 traffic as if it had arrived over an interface connected to the PE. 170 Remote PPP ("Point-to-Point Protocol") connections can be tunneled 171 via L2TP ("Layer 2 Tunneling Protocol") to a PE router; IPsec tunnels 172 can also be used to tunnel traffic to a PE router across the public 173 Internet. Of course when the public Internet is used, issues such as 174 QoS and SLAs must be carefully considered. 176 Some customers want to connect their sites over the public Internet, 177 creating a VPN "virtual backbone", purchasing connectivity for a 178 given site from whatever ISP ("Internet Service Provider") offers the 179 best price for connecting that site. A BGP/MPLS IP VPN is not an 180 appropriate solution for such customers; they instead need to 181 consider solutions (either customer-managed or provider-managed) 182 which interconnect their sites via an overlay of secure tunnels 183 across the Internet. (See, for example, [IPSEC-VPN].) 185 Some customers who do not want to connect their sites via secure 186 site-to-site tunnels across the Internet, may nevertheless want to 187 maintain complete control over the routing in their VPN backbone. 188 These customers will not want a "managed routing service" such as is 189 provided by BGP/MPLS IP VPNs, since that hides all details of the 190 backbone routing and topology from the customer. Rather, they may 191 prefer a "virtual router" service, in which the tunnels through the 192 SP networks are visible as links to the customer's routing algorithm. 193 (See, for example, [VR-VPN].) 195 2. SP Provisioning Model 197 If a particular VPN attaches to a particular PE router, the SP must 198 configure that PE router with a VRF ("Virtual Routing and Forwarding 199 table"), a routing table that is specific to the specified VPN. 200 (This is known as a VFI, "VPN Forwarding Instance", in the language 201 of [L3VPN-REQ] and [L3VPN-FRMWRK].) Each interface or sub-interface 202 at that PE which attaches to a site in the specified VPN (i.e., each 203 local access link of that VPN) must be configured so as to be 204 associated with that VRF. Each such interface may be unnumbered, or 205 may be assigned an address which is unique within the VPN's address 206 space. In general, a routing algorithm needs to be run on each of 207 these links (though static routing can be used instead). The routing 208 algorithm can be EBGP, or an IGP such as RIP ("Routing Information 209 Protocol") or OSPF ("Open Shortest Path First"). (IF OSPF is used, 210 the procedures of [BGP-MPLS-IP-OSPF-VPN] MUST be implemented.) In an 211 IGP is run on the access links, the IGP MUST be a separate IGP 212 instance, different than the IGP instance running among the backbone 213 routers, and different than the IGP instance running on the access 214 links of any other VPN. Static routing is also allowed. 216 The VRF is populated automatically with routes distributed from 217 locally attached CE routers via whatever routing algorithm is run on 218 the PE/CE links. It is also populated automatically with routes 219 distributed from other VRFs via BGP. Standard routing decision 220 processes are used to automatically select the proper routes. Static 221 configuration of routes in the VRF is optional. 223 Each PE router must run BGP, and must be pre-configured with the 224 identities of a small set of BGP Route Reflectors, with which it is 225 to peer via IBGP. ("IBGP" refers to the BGP procedures used between 226 BGP speakers from the same Autonomous System.) 228 In lieu of using Route Reflectors, one could configure each PE with 229 the identities of all the other PEs, and set up a full mesh of IBGP 230 connections. While this might be adequate for small networks, it 231 would not scale well to large networks; the use of Route Reflectors 232 is necessary to achieve scalability. See section 4.3.3 of [BGP- 233 MPLS-IP-VPN] for a more complete discussion of the use of Route 234 Reflectors, and related scalability mechanisms such as Outbound Route 235 Filtering. 237 Each VRF must be configured with three parameters: 239 - A Route Distinguisher. This is a globally unique 8-byte value. 240 Each VRF may have a unique Route Distinguisher (RD), or there may 241 be a single unique RD for an entire VPN. When BGP is used to 242 distribute VPN routing information across the SP backbone, this 243 value is prepended to the VPN's IPv4 address prefixes, creating a 244 new address family, the VPN-IPv4 address family. Thus even when 245 two VPNs have overlapping IPv4 address spaces, they have unique 246 VPN-IPv4 address spaces. 248 - One or more Export Route Targets. A Route Target (RT) is a 249 globally unique 8-byte value which BGP carries, as the Extended 250 Communities Route Target attribute, along with routes that are 251 exported form the VRF. 253 - One or more Import Route Targets. This RT is used to select 254 routes to be imported from other VRFs into this VRF. 256 In the simplest cases and most common cases, the Export RT, Import 257 RT, and RD can be identical, and all VRFs in the same VPN will 258 distribute routes to each other (a typical intranet). In more 259 complex cases, they can be set differently, allowing a very fine 260 degree of control over the distribution of routes among VRFs. This 261 can be used to create extranets, or to enforce various customer 262 policies. In complicated cases, particular Export RTs can be 263 assigned to particular routes using router management mechanisms. 264 One advantage to not requiring the RD to be the same as any RT is 265 that this may allow an RD value to be automatically determined for 266 each VRF; RT values on the other hand must always be configured. 268 Adding a new site to a VPN is a matter of attaching the site's CE 269 router to a PE router, configuring the interface, and, if a VRF for 270 that VPN already exists in the PE router, associating that interface 271 with the VRF. If a VRF for that VPN does not already exist in the 272 PE, then one must be configured as specified above. Changes to the 273 configuration of a PE are automatically reflected via BGP to the 274 other PEs. 276 The RTs and RDs are made unique by being structured as an SP 277 identifier followed by a number which is assigned by the identified 278 SP. SPs may be identified by their AS numbers, or by a registered IP 279 address owned by that SP. 281 Although RTs are encoded as BGP Extended Communities, the encoding 282 itself distinguishes them from any other kind of BGP Extended 283 Community. 285 3. Supported Topologies and Traffic Types 287 The scheme is optimized for full inter-site connectivity, in the 288 sense that this is what the simplest configurations provide. 290 However, the SP has full control, through the mechanism of Route 291 Targets, of the distribution of routing information among the set of 292 VRFs. This enables the SP to provide hub-and-spoke or partial mesh 293 connectivity as well as full mesh connectivity. 295 Note that, strictly speaking, the scheme does not create a topology, 296 as it does not create layer 2 connections among the sites. It does 297 however allow for control over the IP connectivity among the sites. 298 It is also possible to constrain the distribution of routing in 299 arbitrary ways, e.g., so that data from site A to site B must travel 300 through a third site C. (In fact, if it is desired to do so, this 301 level of control can be specified at the granularity of a single 302 route.) 304 It is possible for some of the routes from a particular customer site 305 A to be distributed to one set of remote sites, while other routes 306 from site A are distributed to a different set of remote sites. This 307 is done with the Route Target mechanism previously described. 309 Unicast IP traffic is fully supported. Customer IP packets are 310 passed transparently. 312 Multicast IP traffic is optionally supported, if the SP provides the 313 optional mechanisms of [BGP-MPLS-MCAST-VPN]. There are however 314 scaling implications to the use of these mechanisms. Discussion of 315 these implications is deferred. 317 Non-IP traffic is not supported. If support for non-IP traffic is 318 necessary, either the SP must additionally provide a layer 2 319 tunneling service, or the customer must use IP tunneling. 321 In general, customer routers at different sites do not become routing 322 peers. However, a customer may, if he so desires, allow routers at 323 different sites to be routing peers over a link which is NOT part of 324 the VPN service. Such peering relationships are known as "IGP 325 backdoors". To ensure the proper operation of routing when IGP 326 backdoors are present, each VPN route that is distributed by the SP 327 is distributed along with a corresponding routing metric. This 328 enables the customer's IGP to compare the "backdoor routes" properly 329 with the routes that use the SP backbone. In the particular case 330 where a customer running OSPF within his sites wishes to have IGP 331 backdoors, he should run OSPF on the PE-CE link, and the PEs should 332 run the procedures of [BGP-MPLS-IP-OSPF-VPN]. (The CEs do NOT 333 require any special OSPF procedures.) 335 4. Isolated Exchange of Data and Routing Information 337 The Route Target mechanism is used to control the distribution of 338 routing information, so that routes from one VPN do not get sent to 339 another. VPN routes are treated by BGP as a different address family 340 than general Internet routes. Routes from a VRF do not get leaked to 341 the Internet unless the VRF has been explicitly configured to allow 342 it (and this is NOT the default). 344 The way in which a particular VPN is divided into sites, or the 345 topology of any particular VPN site, are hidden from the Internet and 346 from other VPNs. (Of course, if a particular site can receive 347 Internet traffic, and if it responds to traceroute probes from the 348 Internet, then any user of the Internet can learn something about the 349 site topology. The fact that the site is in a VPN does not make this 350 any easier or any harder.) 352 Similarly, Internet routes do not get leaked into the VPN, unless a 353 VRF of that VPN is explicitly configured to import the Internet 354 routes. 356 Proper configuration is essential to maintaining the isolation. In 357 particular, each access link must be associated with the proper VRF 358 for that access link, and each VRF must be configured with the proper 359 set of RTs. 361 A number of means for exchanging reachability information between the 362 PE and CE devices are supported: static routing, EBGP, and RIP are 363 supported by the procedures of [BGP-MPLS-IP-VPN]. If the procedures 364 of [BGP-MPLS-IP-OSPF-VPN] and [BGP-MPLS-IP-OSPF-DNbit] are 365 implemented, OSPF may be used. If OSPF is used between two VPN sites 366 which are in the same OSPF area, and if it is desired for routes over 367 the VPN backbone to be preferred to the OSPF intra-site routes, then 368 the "sham link" procedures of [BGP-MPLS-IP-OSPF-VPN] must be used. 370 The routing protocols used among the customer routers are not in any 371 way restricted by the VPN scheme, as whatever IGP is used within the 372 VPN, the PE/CE access links may run EBGP, or may otherwise be in a 373 different routing domain than the site's internal links. 375 BGP is used for passing routing information among SPs. BGP may be 376 authenticated by use of the TCP MD5 option, or by operating through 377 an IPsec tunnel. 379 Data traveling between two customer sites is encapsulated while in 380 transit through the backbone. The encapsulation contains sufficient 381 information to ensure that the packet is sent to the proper PE 382 router, and then, in conjunction with the VRF and related information 383 at that PE, to the proper CE routers. 385 If two VPNs attach to the same PE, there is strict separation of 386 forwarding at that PE, as well as strict separation of the routing 387 information. 389 Isolation of traffic is similar to that provided by classical L2 VPNs 390 which are based on Frame Relay or ATM ("Asynchronous Transfer Mode"). 391 As in classical L2 VPNs, the customer must rely on the SP to properly 392 configure the backbone network to ensure proper isolation, and to 393 maintain the security of his communications gear. 395 5. Access Control and Authentication 397 No particular means of PE/CE authentication is specified for BGP/MPLS 398 IP VPNs. PE/CE mutual authentication may be done via any mechanism 399 supported by the routing protocol in which the CE and PE are peers 400 (e.g., use of the TCP MD5 authentication when the CE/PE protocol is 401 BGP), or by any other mechanism that may be desired. With such 402 mechanisms in place, a CE may not join a VPN until the CE 403 authenticates itself to the Service Provider. 405 There is however no standardized method which requires a CE to 406 authenticate itself to the customer network (rather than to the SP) 407 before the CE is allowed to join the VPN. This is for further study. 409 No particular means is specified for controlling which user data 410 packets can be forwarded by BGP/MPLS IP VPNs. BGP/MPLS IP VPNs are 411 compatible with ACLs ("Access Control Lists") and any other filtering 412 features that are supported on the PE routers. Routing can be set up 413 so that extranet traffic is directly through a firewall, if that is 414 desired. 416 It is possible for various sorts of "tunnel interfaces" to be 417 associated with a VRF. In this case, whatever authentication is 418 natively used in the establishment of the tunnel interface may be 419 used. For example, an IPsec tunnel can be used as an "access link" 420 to attach a remote user or site to a VRF. The authentication 421 procedure in this case is part of IPsec, not part of the VPN scheme. 423 Where L2TP is used, each PPP session carried in an L2TP tunnel can be 424 associated with a VRF. The SP's AAA ("Authentication, Authorization, 425 and Accounting") server can be used to determine the VPN to which the 426 PPP session belongs, and then the customer's AAA server can be given 427 the opportunity to authenticate that session as well. 429 6. Security Considerations 431 6.1. Protection of User Data 433 No particular means of ensuring user data security is specified for 434 BGP/MPLS IP VPNs. 436 The optional procedures of [BGP-MPLS-IPsec-VPN] may be used to 437 provide authentication and/or encryption of user data as it travels 438 from the ingress PE to the egress PE. However, the data is exposed 439 at those two PEs, as well as on the PE/CE access links. 441 The customer may provide his own user data security by using IPsec 442 tunnels that terminate within the customer sites. Such tunnels are 443 transparent to the VPN scheme. Schemes that discover the remote 444 tunnel endpoints automatically and then set up the tunnels 445 automatically as needed are the best fit with this VPN technology. 446 Note that there is no requirement in general that IPsec tunnels 447 between customer sites terminate at CE routers. 449 The use of end-to-end transport mode IPsec by the customer is also 450 transparent to the VPN scheme. In fact, the VPN scheme is compatible 451 with any use of security by the customer, as long as a cleartext IP 452 header is passed from CE to PE. 454 When data must cross the Internet to reach the ingress PE router, 455 IPsec tunnels between the enduser and the PE router can be used; the 456 PE router must then associate each IPsec tunnel with the proper VRF. 457 This association would have to be based on user-specific information 458 provided by the IKE ("Internet Key Exchange") protocol, such as a 459 VPN-id. 461 If data is going from one SP network to another, and must cross the 462 public Internet to get between those two networks, IPsec tunnels can 463 be used to secure the data. This would require bilateral agreement 464 between the two SPs. BGP connections can also be passed through an 465 IPsec tunnel if this is deemed necessary, in order to protect user 466 data, by a pair of SPs. QoS/SLA factors would have to be carefully 467 considered in this case. 469 6.2. SP Security Measures 471 The SP is responsible for preventing illegitimate traffic from 472 entering a VPN. VPN traffic is always encapsulated while traveling 473 on the backbone, so preventing illegitimate traffic is a matter of 474 ensuring that the PE routers to the encapsulation/decapsulation 475 correctly, and that encapsulations have not been "spoofed", i.e., 476 that the encapsulated packets were actually encapsulated by PE 477 routers. 479 This requires the SP to take various security measures. The PE and P 480 routers must themselves be secure against breakins (either from 481 someone physically present or from the Internet), and neither P nor 482 PE routers should form routing adjacencies to other P or PE routers 483 without benefit of some kind of security. This may be authentication 484 in the IGP, or physical security. 486 The CE/PE access link should be secured in some manner, though the 487 provider may make it the responsibility of the customer to ensure 488 that the CE is secure from compromise. If the CE/PE access link is a 489 tunnel over the Internet, then of course some sort of authentication 490 protocol should always be used. 492 LDP ("Label Distribution Protocol") sessions and BGP sessions between 493 PE and/or P routers should be authenticated. This can be done via 494 the TCP MD5 option, or by use of IPsec. 496 If the SP is providing the VPN service over an MPLS backbone, it 497 should not accept MPLS packets from its external interfaces (i.e. 498 interfaces to CE devices or to other providers' networks) unless the 499 top label of the packet was legitimately distributed to the system 500 from which the packet is being received. If the packet's incoming 501 interface leads to a different SP (rather than to a customer), an 502 appropriate trust relationship must also be present, including the 503 trust that the other SP also provides appropriate security measures. 505 If the SP is providing the VPN service by using an IP (rather than an 506 MPLS) encapsulation, or if it accepts IP-encapsulated VPN packets 507 from other SPs, it should apply filtering at its borders so that it 508 does not accept from other SPs or from customers any IP packets which 509 are addressed to the PE routers, unless appropriate trust 510 relationships are in place. 512 Cryptographic authentication of the encapsulated data packets is 513 certainly advantageous when there are multiple SPs providing a single 514 VPN. 516 When a dynamic routing protocol is run on the link between a CE 517 router and a PE router, routing instability in the private network 518 may have an effect on the PE router. For example, an unusually large 519 number of routing updates could be sent from the CE router to the PE 520 router, placing an unusually large processing load on the PE router. 521 This can potentially be used as a Denial of Service attack on the PE 522 router. 524 This issue can be mitigated via resource partitioning in the PE, in 525 order to limit the amount of resources (e.g., CPU and memory) which 526 any one VPN is permitted to use in PE routers. Also, rate limits may 527 be applied to the routing traffic sent from the CE to the PE. 528 Alternately, when this problem is detected, the CE to PE interface 529 may be shut down. 531 Network management traffic from the CE to the PE may be rate limited 532 (for example, to prevent network management traffic from CE to PE to 533 be used in a "Denial of Service", or "DoS" attack). 535 6.3. Security Framework Template 537 Section 8 of [L3VPN-SEC-FRMWRK] provides "a brief template that may 538 be used to evaluate and summarize how a given PPVPN ("Provider- 539 Provisioned Virtual Private Network") approach (solution) measures up 540 against the PPVPN Security Framework." It further states "an 541 evaluation of a given PPVPN approach using this template should 542 appear in the applicability statement for each PPVPN approach." The 543 purpose of this subsection is provide the information in the form 544 required by this template. Security requirements that are relevant 545 only to L2VPNs are not applicable and are not further discussed. 547 - Does the approach provides complete IP address space separation 548 for each L3 VPN? 550 Yes. 552 The IP address prefixes from a particular VPN appear in their 553 native form only in routing tables that are specific to the 554 particular VPN. They are distributed in their native form only 555 by routing instances which are specific to the particular VPN. 556 When address prefixes from different VPNs are combined into a 557 common table, or distributed by a common mechanism, the address 558 prefixes are first prepended with a Route Distinguisher (RD). 559 The RD is a 64-bit quantity, structured so that globally unique 560 RD values can easily be created by an SP. As long as no two VPNs 561 are assigned the same RD value, complete IP address space 562 separation is provided. It is however possible for an SP to 563 misconfigure the RD assignments. 565 - Does the approach provide complete IP route separation for each 566 L3 VPN? 568 Yes. 570 The distribution of routes is controlled by assigning import and 571 export Route Targets (RTs). A route which is exported from a VRF 572 carries an RT specified by the SP as an export RT for that VRF. 573 The route can be imported into other VRFs only if the RT which it 574 carries has been configured by the SP as an import RT for those 575 other VRFS. Thus the SP has complete control over the set of VRFs 576 to which a route will be distributed. It is of course possible 577 for the SP to misconfigure the RT assignments. 579 - Does the approach provides a means to prevent improper cross- 580 connection of sites in separate VPNs. 582 This requirement is addressed in a way which is beyond the scope 583 of the VPN mechanisms. 585 In BGP/MPLS IP VPNs, an SP makes a particular site part of a 586 particular VPN by configuring the PE router's interface to that 587 site to be associated with a particular VRF in that PE. The VRF 588 is configured with import and export RTs, and it is the way in 589 which VRFs are configured with RTs in the various PEs that 590 results in a particular set of sites being connected as a VPN. 592 Connecting the sites properly in this way is regarded as a 593 network management function, and the VPN scheme itself does not 594 provide a means to prevent misconfiguration. 596 The VPN scheme does not provide any particular method for 597 ensuring that a given interface from a PE leads to the CE that is 598 expected to be there. If a routing algorithm is run on a 599 particular PE/CE interface, any security procedures which the 600 routing algorithm provides (e.g., MD5 authentication of BGP 601 sessions) can be used; this is outside the scope of the VPN 602 scheme. Also, a CE can attach to a PE via an IPsec tunnel, if 603 this is desired, for a greater degree of security. 605 - Does the approach provide a means to detect improper cross- 606 connection of sites in separate VPNs? 608 The base specifications for BGP/MPLS IP VPNs do not provide a 609 means for detecting that a site has been connected to the wrong 610 VPN. However, the optional procedure specified in [CE-VERIF] 611 does provide such a means. Basically, each PE obtains, via 612 protocol, a secret from each CE to which it is directly attached. 613 When the routes from a given CE are distributed, the secret from 614 that CE is attached as an attribute of the route. This secret 615 will ultimately be distributed to any other CE that receives any 616 route from the given CE. A CE which is not supposed to be part 617 of a given VPN will not know the right secret, and if it is 618 connected to the given VPN the other CEs in that VPN will realize 619 that a CE that doesn't know the proper secret has been connected 620 to the VPN. 622 - Does the approach protect against the introduction of 623 unauthorized packets into each VPN? 625 We must look separately at the various points at which one might 626 attempt to introduce unauthorized packets. 628 * Packets arriving at a PE over a PE/CE interface 630 If a given PE is directly connected to a given CE, the PE 631 will accept any packets which the CE sends it. The VPN 632 scheme has no special procedures for determining that these 633 packets actually came from the CE. However, various means of 634 securing the PE/CE connection can be used (for instance, the 635 PE and CE can be connected by an IPsec tunnel) if desired. 636 That is, this aspect of the requirement can be addressed by 637 means which are outside the scope of the VPN specification. 639 Once a packet has been accepted from a CE by a PE, the packet 640 is routed by according to the VRF associated with that PE's 641 interface to that CE. Such packets can only be sent along 642 routes which are in that VRF. There is no way a packet from 643 a CE can be routed to an arbitrary VPN. In particular, there 644 is nothing a VPN user can do to cause any particular packet 645 to be sent to the wrong VPN. So this aspect of the 646 requirement is fully addressed. 648 * Packets arriving at a PE over an interface from the backbone 650 The optional procedures of [BGP-MPLS-IPsec-VPN] can be used 651 to ensure that a packet which is received by a PE from the 652 backbone will not be recognized as a VPN packet unless it 653 actually is one. Those procedures also ensure that a 654 received VPN packet came from a particular PE, and that it 655 carries the MPLS label which that PE put on it. These 656 procedures protect the packet from ingress PE to egress PE, 657 but do not protect the PE/CE interfaces. 659 If the optional procedures of [BGP-MPLS-IPsec-VPN] are not 660 used, then the following considerations apply. 662 Undetected corruption of the routing information carried in a 663 packet's VPN encapsulation can result in misdelivery of the 664 packet, possibly to the wrong VPN. 666 If a packet enters an SP's network on an interface other than 667 a PE/CE interface, the SP should ensure that the packet 668 either does not look like a VPN packet or else is not routed 669 to a PE router. This can be done in a variety of ways that 670 are outside the scope of the VPN scheme. E.g., IP packets 671 addressed to the PE routers can be filtered, MPLS packets 672 (or, e.g., MPLS-in-IP) from outside the SP network can be 673 refused, etc. 675 In the case of a multi-provider L3VPN backbone, the SP will 676 have to know which interfaces lead to SPs that are VPN 677 partners, so that VPN packets can be allowed to flow on those 678 interfaces. 680 If the public Internet is used as the L3VPN backbone, 681 protection against unauthorized packets cannot be achieved by 682 the above measures. IPsec tunnels should always be used to 683 carry VPN traffic across the public Internet. 685 - "Does the approach provides confidentiality (secrecy) protection, 686 sender authentication, integrity protection, or protection 687 against replay attacks for PPVPN user data?" 689 If these are desired, they must be provided by mechanisms which 690 are outside the scope of the VPN mechanisms. For instance, the 691 users can use secure protocols on and end-to-end basis, e.g., 692 IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc. 694 - "Does the approach provide protection against unauthorized 695 traffic pattern analysis for PPVPN user data?" 697 Preventing an observer from obtaining traffic pattern analysis 698 from the SP network is beyond the scope of the VPN mechanisms. 700 - "Do the control protocol(s) used for each of the following 701 functions provide for message integrity and peer authentication?" 703 * VPN membership discovery 705 This requirement is fully satisfied. Membership discovery is 706 done by means of BGP. Control message integrity and peer 707 authentication in BGP may be achieved by use of the TCP MD5 708 option. 710 * Tunnel establishment 712 The answer to this question depends of course on the tunnel 713 protocol and tunnel establishment protocol; a variety of 714 different tunneling schemes can be used in BGP/MPLS IP VPNs. 715 Thus this question is out of scope. 717 In the common case where the tunnels are MPLS LSRs 718 established by LDP, then control message integrity and peer 719 authentication may be achieved by use of the TCP MD5 option. 721 * VPN topology and reachability advertisement 723 With respect to PE-PE interactions, the relevant control 724 protocol is BGP, so control message integrity and peer 725 authentication can be achieved by use of the TCP MD5 option. 727 With respect to CE-PE interactions, the answer depends on the 728 protocol used for exchanging information between PE and CE, 729 as the security mechanisms (if any) of those protocols would 730 need to be used. In the common case where the CE-PE protocol 731 is BGP, the TCP MD5 option can be used. 733 * VPN provisioning and management 735 The protocols procedures for provisioning VPNs and managing 736 the PE routers are outside the scope of the VPN scheme. 738 * VPN monitoring and attack detection and reporting 740 The protocols and procedures for monitoring the VPNs are 741 outside the scope of the VPN scheme. 743 - "What protection does the approach provide against PPVPN-specific 744 DoS attacks (i.e. Inter-trusted-zone DoS attacks)?" 746 * "Protection of the service provider infrastructure against 747 Data Plane or Control Plane DoS attacks originated in a 748 private (PPVPN user) network and aimed at PPVPN mechanisms." 750 The PE/CE interfaces of a given VPN will generally be 751 addressable from within that VPN. Apart from that, a user 752 within an L3VPN has no more access to the service provider 753 infrastructure than does any user of the Internet. Therefore 754 we will focus in this section on possible DoS attacks against 755 a PE router that may occur when traffic from within a VPN is 756 addressed to a PE router. 758 A user within the VPN may address traffic to a PE router and 759 may attempt to send an excessive amount of traffic to it. 760 Presumably the PE routers will not accept unauthorized TCP 761 connections or SNMP ("Simple Network Management Protocol") 762 commands, so such traffic will be thrown away; the danger is 763 that the PE may need to use a significant proportion of its 764 capacity to discard such traffic. However, this case is no 765 different than the case of any SP access router which 766 attaches to subscriber equipment. The presence of the VPN 767 mechanisms does not make the PE any more or less vulnerable 768 to DoS attacks from arbitrary endusers. 770 * "Protection of the service provider infrastructure against 771 Data Plane or Control Plane DoS attacks originated in the 772 Internet and aimed at PPVPN mechanisms." 774 DoS attacks of this sort can be prevented if the PE routers 775 are not addressable from the Internet. Alternatively, an SP 776 can apply address filtering at its boundaries so that packets 777 from the Internet are filtered if they are addressed to a PE 778 router. 780 * "Protection of PPVPN users against Data Plane or Control 781 Plane DoS attacks originated from the Internet or from other 782 PPVPN users and aimed at PPVPN mechanisms." 784 Mechanisms already discussed prevent users in a VPN from 785 receiving packets from the Internet, unless this is 786 specifically allowed. In the case where it is specifically 787 allowed, it is no different than any other situation in which 788 a network is connected to the Internet, and there is no 789 special vulnerability to DoS attacks due to the L3VPN 790 mechanisms. 792 There is nothing to prevent a user in a VPN from mounting a 793 DoS attack against other users in the VPN. However, the 794 L3VPN mechanisms make this neither more nor less likely. 796 - "Does the approach provide protection against unstable or 797 malicious operation of a PPVPN user network?" 799 * "Protection against high levels of, or malicious design of, 800 routing traffic from PPVPN user networks to the service 801 provider network" 803 If a dynamic routing algorithm is running on the PE/CE 804 interface, it can be used to mount an attack on the PE 805 router, by having the CE present the PE with an excessive 806 number of routing events. If an enduser within a VPN 807 successfully attacks the routing algorithm of the VPN, that 808 might also result in an excessive number of routing events 809 being seen by the PE router. This sort of attack can be 810 ameliorated by having the PE limit the amount of its 811 resources that can be expended processing routing events from 812 a particular VPN. If the PE/CE routing algorithm is BGP, then 813 such mechanisms as route flap damping may be appropriate as 814 well. 816 * "Protection against high levels of, or malicious design of, 817 network management traffic from PPVPN user networks to the 818 service provider network." 820 A user in a BGP/MPLS IP VPN has no more ability than any 821 Internet user to send management traffic to the service 822 provider network. 824 * "Protection against worms and probes originated in the PPVPN 825 user networks, sent towards the service provider network." 827 A user in a BGP/MPLS IP VPN has no more ability than any 828 Internet user to send worms or probes to the service provider 829 network. 831 7. Addressing 833 Overlapping customer addresses are supported. There is no 834 requirement that such addresses be in conformance with RFC 1918. 835 There is no requirement that customer VPN addresses be distinct from 836 addresses in the SP network. 838 Any set of addresses used in the VPN can be supported, irrespective 839 of how they are assigned, how well they aggregate, whether they are 840 public or private. However, the set of addresses which are reachable 841 from a given site must be unique. 843 Network address translation for packets leaving/entering a VPN is 844 possible, and is transparent to the VPN scheme. 846 There is nothing in the architecture to preclude the mechanisms from 847 being extended to support IPv6, provided that the appropriate IPv6- 848 capable routing algorithms are in place. I.e., PE/CE routing must 849 support IPv6, and the PE-PE BGP must support the labeled IPv6 address 850 family. The latter has not been specified, but its specification is 851 obvious from the specification of the labeled IPv4 address family. 852 The IGP used in the SP backbone need not be IPv6 capable in order to 853 support customer IPv6 networks. 855 In theory, the same could be said of other network layers, but in 856 practice a customer who has non-IP traffic to carry must expect to 857 carry it either in site-to-site IP tunnels, or using some additional 858 service (such as a layer 2 service) from the SP. 860 Layer 2 addresses and identifiers are never carried across the SP 861 backbone. 863 No restrictions are placed on the customer's addressing schemes or 864 policies. Note though that the SP may place restrictions on the 865 number of routes from a given customer site, or may charge 866 differentially depending on the number of such routes, and such 867 restrictions may have implications for the customer's addressing 868 scheme. In particular, addressing schemes which facilitate route 869 aggregation on a per-site basis will result in the most efficient use 870 of the SP's resources, and this may be reflected in SP charging 871 policies. 873 8. Interoperability and Interworking 875 Interoperability should be ensured by proper implementation of the 876 published standards. 878 Direct PE-PE interworking over the SP backbone with other VPN 879 solutions is not supported. 881 As all the different types of L3VPNs are IP networks, they can of 882 course interwork in the same way that any two IP networks can 883 interwork. For example, a single site can contain a CE router of one 884 VPN scheme and a CE router of another VPN scheme, and these CE 885 routers could be IGP peers, or they might even be the same CE router. 886 This would result in the redistribution of routes from one type of 887 VPN to the other, providing the necessary interworking. 889 9. Network Access 891 9.1. Physical/Link Layer Topology 893 The architecture and protocols do not restrict the link layer or the 894 physical layer in any manner. 896 9.2. Temporary Access 898 Temporary access via PPP is possible, using industry standard PPP- 899 based authentication mechanisms. For example: 901 - A dial-up user (or other PPP user) is authenticated by the PE, 902 using the SP's AAA server, based on a login string or on the 903 number dialed. 905 - The SP's AAA server returns a VPN-id to PE. 907 - The PE assigns the user to a VRF, based on that VPN-id. 909 - The user is then authenticated by a AAA server within the VPN 910 (i.e., managed by the customer rather than by the SP). This AAA 911 server would typically be addressed through the VRF (i.e., may be 912 in VPN's private address space). 914 - The user gets disconnected if either authentication step is 915 unsuccessful. 917 IPsec access to a VRF is also possible. In this case, the security 918 association is between the enduser and the SP. 920 In these ways, a user can access a BGP/MPLS IP VPN via the public 921 Internet. 923 There is no explicit support for mobility, other than what is stated 924 above. 926 9.3. Access Connectivity 928 Homing of a CE to two or more PEs is fully supported, whether the PEs 929 are on the same SP network or not. 931 If a CE is connected to two or more PEs, all its CE-PE links can be 932 used to carry traffic in both directions. In particular, traffic 933 from different ingress PEs to a particular CE may arrive at that CE 934 over different PE-CE links. This depends on the backbone network 935 routing between the CE and the various ingress PEs. 937 If a VRF on a particular ingress PE contains several routes to a 938 particular destination, then traffic from that ingress PE can be 939 split among these routes. If these routes end with different PE-CE 940 links, then traffic from that ingress PE will be split among those 941 links. 943 BGP contains a multitude of knobs which allow a SP to control the 944 traffic sent on one PE-CE link as opposed to the other. One can also 945 make use of the Link Bandwidth extended community [BGP-EXT-COMM] to 946 control how traffic is distributed among multiple egress PE-CE links. 948 The VPN scheme is of course compatible with the use of traffic 949 engineering techniques,RSVP-TE (Resource Reservation Protocol - 950 Traffic Engineering) based or otherwise, in the backbone network. 952 10. Service Access 954 10.1. Internet Access 956 Internet access and VPN access are possible from the same site. This 957 is even possible over the same interface, as long as the VPN's 958 internal addresses are distinct from the addresses of the systems 959 which must be reached via the Internet. This requires only that 960 Internet routes as well as VPN routes be imported into the VRF 961 associated with that interface. This may be as simple as putting a 962 default route to the Internet into that VRF. 964 The "route to the Internet" which is in a particular VRF need not 965 lead directly to the Internet, it may lead to a firewall or other 966 security device at another site of the VPN. The VPN customer can 967 cause this to happen simply by exporting a default route from the 968 site with the firewall. Generally, a site with a firewall will use a 969 different virtual interface for Internet access than for VPN access, 970 since the firewall needs to distinguish the "clean interface" from 971 the "dirty interface". 973 In such a configuration, the customer would export his routes to the 974 Internet via the firewall's dirty interface, but would export the 975 same routes to the VPN via the clean interface. Thus all traffic 976 from the Internet would come through the dirty interface, then though 977 the firewall, and possibly go to another VPN site though the clean 978 interface. This also allows any necessary NAT ("Network Address 979 Translation") functionality to be done in the firewall. 981 10.2. Other Services 983 Any externally provided service can be accessed from the VPN, 984 provided that it can be addressed with an address that is not 985 otherwise in use within the VPN. Access can be firewalled or non- 986 firewalled. If the client accessing the service does not have a 987 globally unique IP address, and a single server provides a service to 988 multiple VPNs, NAT will have to be applied to the client's packets 989 before they reach the server. This can be done at a customer site, 990 or by a VRF-specific NAT function in a PE router. 992 11. SP Routing 994 Routing through the backbone is independent of the VPN scheme, and is 995 unaffected by the presence or absence of VPNs. The only impact is 996 that the backbone routing must carry routes to the PE routers. 998 The VPN routes themselves are carried in BGP as a distinct address 999 family, different than the address family that is used to carry 1000 "ordinary" IP routes. These routes are passed from PE router to Route 1001 Reflector to PE router, and are never seen by the P routers. The 1002 Route Reflectors that carry the VPN routes can be entirely separate 1003 from the Route Reflectors that carry the "ordinary" IP routes. 1005 The fact that two PE routers support a common VPN does not require 1006 those PE routers to form an IGP routing adjacency between themselves. 1007 The number of adjacencies in the backbone IGP is independent of and 1008 unrelated to the number of VPNs supported by any set of PE routers. 1010 No VPN-specific protection and restoration mechanisms are needed; 1011 these are general routing considerations, and the VPN scheme is 1012 compatible with any protection and restoration mechanisms that may be 1013 available. 1015 The SP does not manage the customer's IGP in any way, and routes are 1016 never leaked between the SP's IGP and any customer's IGP. 1018 If the PE/CE protocol is EBGP, the SP and the customer do not ever 1019 participate in a common IGP. 1021 12. Migration Impact 1023 Generally, this means replacement of an existing legacy backbone with 1024 VPN backbone. The general migration mechanism would be to hook up 1025 the sites one at a time to the VPN backbone, and to start giving the 1026 routes via the VPN backbone preference to routes via the legacy 1027 backbone. Details depend on the legacy backbone's IGP. In general, 1028 one would have to manipulate the IGP metrics to provide the proper 1029 route preference. 1031 If the legacy backbone routing protocol is OSPF, then migration is 1032 best done with OSPF as the PE/CE protocol and the PE supporting the 1033 [BGP-MPLS-IP-OSPF-VPN] procedures, OR with BGP as the PE/CE protocol, 1034 and the CE supporting the BGP/OSPF interaction specified in [BGP- 1035 MPLS-IP-OSPF-VPN]. 1037 With other legacy backbone routing protocols, the proper metrics must 1038 be set at the point (PE or CE) where the BGP routes from the SP 1039 network are being redistributed into the legacy IGP. 1041 13. Scalability 1043 There is no upper limit on the number of VPNs per SP network, as 1044 there is no one box in the SP network which needs to know of all 1045 VPNs. Knowledge of a particular VPN is confined to the PE routers 1046 that attach to sites in that VPN, and to the BGP Route Reflectors 1047 which receive routing data from those PEs; other systems maintain no 1048 state at all for the VPN. Note though that there is no need for any 1049 one Route Reflector to know of all VPNs. 1051 If the SP is providing the VPN service over an MPLS backbone, then 1052 the backbone IGP must carry a host route for every LSP ("Label 1053 Switched Path") egress node within the routing domain. Every PE 1054 router in the routing domain is an LSP egress node. If there are 1055 VPNs attached to PE routers that are within the routing domain, as 1056 well as PE routers which are in some second routing domain, then the 1057 border routers leading towards the second routing domain will also be 1058 LSP egress nodes. Thus the sum of the number of PE routers plus 1059 number of border routers within a routing domain is limited by the 1060 number of routes that can be carried within the domain's IGP. This 1061 does not seem to create any practical scalability issue. 1063 There is no upper limit on the number of site interfaces per VPN, as 1064 state for a particular interface is maintained only at the PE router 1065 to which that interface attaches. The number of site interfaces per 1066 VPN at a given PE router is limited only by the number of interfaces 1067 which that PE router can support. 1069 The number of routes per VPN is constrained only by the number of 1070 routes that can be supported in BGP, the number of routes which can 1071 be maintained in the PEs that attach to that VPN, and the number of 1072 routes which can be maintained in the BGP Route Reflectors which hold 1073 the routes of that VPN. 1075 The major constraint in considering scalability is the number of 1076 routes which a given PE can support. In general, a given PE can 1077 support as many VPNs as it has interfaces (including virtual 1078 interfaces or "sub-interfaces", not just physical interfaces), but it 1079 is constrained in the total number of routes it can handle. The 1080 number of routes a given PE must handle depends on the particular set 1081 of VPNs it attaches to, and the number of routes in each such VPN, 1082 and the number of "non-VPN" Internet routes (if any) that it must 1083 also handle. 1085 The SP may need to engage in significant planning to ensure that 1086 these limits are not often reached. If these limits are reached, it 1087 may be necessary either to replace the PE with one of larger 1088 capacity, or to reorganize the way in which access links lead from 1089 CEs to PEs, in order to better concentrate the set of access links 1090 from sites that are in the same VPN. Rehoming a site to a different 1091 PE may not involve actual rewiring; if the access technology is 1092 switched, this is a matter of provisioning, but may still be a 1093 significant undertaking. If it is necessary to have down time while 1094 performing the rehoming, the customer is impacted as well. Rehoming 1095 can also be done "virtually", by creating a layer 2 tunnel from a 1096 CE's "old" PE to its "new" PE. 1098 An important consideration to remember is that one may have any 1099 number of INDEPENDENT BGP systems carrying VPN routes. This is 1100 unlike the case of the Internet, where the Internet BGP system must 1101 carry all the Internet routes. The difference stems from the fact 1102 that all Internet addresses much be reachable from each other, but a 1103 given VPN address is only supposed to be reachable from other 1104 addresses in the same VPN. 1106 Scalability is also affected by the rate of changes in the 1107 reachability advertisements from CE to PE, as changes reported by a 1108 CE to its attached PE may be propagated to the other PEs. BGP 1109 mechanisms to control the rate of reported changes should be used by 1110 the SP. 1112 Another constraint on the number of VPNs which can be supported by a 1113 particular PE router is based on the number of routing instances 1114 which the PE router can support. If the PE/CE routing is static, or 1115 is done by BGP, the number of routing protocol instances in a PE 1116 device does not depend on the number of CEs supported by the PE 1117 device. In the case of BGP, a single BGP protocol instance can 1118 support all CEs that exchange routing information using BGP. If the 1119 CE/PE router is done via RIP or OSPF, then the PE must maintain one 1120 RIP or OSPF instance per VRF. Note that the number of routing 1121 instances which can be supported may be different for different 1122 routing protocols. 1124 Inter-AS scenarios constructed according to option (b) of section 10 1125 of [BGP-MPLS-IP-VPN] require BGP "border routers" to hold the routes 1126 for a set of VPNs. If two SPs share in a small number of VPNs, a 1127 single border router between them provide adequate capacity. As the 1128 number of shared VPNs increases, additional border routers may be 1129 needed to handle the increased number of routes. Again, no single 1130 border router would handle all the routes from all the VPNs, so an 1131 increase in the number of VPNs can always be supported by adding more 1132 border routers. 1134 Inter-AS scenarios constructed according to option (c) of section 10 1135 of [BGP-MPLS-IP-VPN] eliminates the need for border routers to 1136 contain VPN routes (thus improving scalability in that dimension), 1137 but at the cost of requiring that each AS have a route to the PEs in 1138 the others. 1140 (Inter-AS scenarios constructed according to option (a) of section 10 1141 of [BGP-MPLS-IP-VPN] do not scale well.) 1143 The solution of [BGP-MPLS-IP-VPN] is intended to simplify CE and site 1144 operations, by hiding the structure of the rest of the VPN from a 1145 site, and by hiding the structure of the backbone. Thus CEs need 1146 have only a single sub-interface to the backbone, CEs at one site 1147 need not even be aware of the existence of CEs at another, and CEs at 1148 one site need not be routing peers of CEs at another. CEs are never 1149 routing peers of P routers. These factors help to scale the 1150 customer's network, but limiting the number of adjacencies each CE 1151 must see, and by limiting the total number of links which the 1152 customer's IGP must handle. 1154 The solution of [BGP-MPLS-IP-VPN] is also intended to simplify the 1155 SP's VPN provisioning, so that potentially the SP will have to do 1156 little more than say which sites belong to which VPNs. However, as 1157 the system scales up, planning is needed to determine which PEs 1158 should home which VPNs, and which BGP RRs should take which VPNs' 1159 routing information. 1161 P routers maintain NO per-VPN state at all; the only requirement on 1162 them is to maintain routes to the PE routers. When MPLS is used, a P 1163 router must also maintain one multipoint-to-point LSP for each such 1164 route. 1166 However, certain VPN multicast schemes require per-multicast-group 1167 state in the P routers, summed over all VPNs. Others require only no 1168 state in the P routers at all, but will result in sending more 1169 unnecessary traffic. The complete set of tradeoffs for multicast is 1170 not that well understood yet. 1172 Note that as the scaling of a particular PE is primarily a matter of 1173 the total number of routes which it must maintain, scalability is 1174 facilitated if the addresses are assigned in a way that permits them 1175 to be aggregated. (I.e., if the customers have a sensible addressing 1176 plan.) 1178 When a dynamic routing protocol is run on the link between a CE 1179 router and a PE router, routing instability in the private network 1180 may have an effect on the PE router. For example, an unusually large 1181 number of routing updates could be sent from the CE router to the PE 1182 router, placing an unusually large processing load on the PE router. 1184 This issue can be mitigated via resource partitioning in the PE, in 1185 order to limit the amount of resources (e.g., CPU and memory) which 1186 any one VPN is permitted to use in PE routers. Also, rate limits may 1187 be applied to the routing traffic sent from the CE to the PE. 1188 Alternately, when this problem is detected, the CE to PE interface 1189 may be shut down. 1191 14. QoS, SLA 1193 The provision of appropriate QoS capabilities may require any 1194 combination of the following: 1196 - QoS in the access network. 1198 - Admission control (policing) by the PE router on the ingress 1199 access links. 1201 - Traffic conditioning (shaping) by the PE router on the ingress 1202 access links. 1204 - Traffic engineering in the backbone. 1206 - Intserv/diffserv classification by the PE, for traffic arriving 1207 from the CE. Once the PE classifies the user packets, this 1208 classification needs to be preserved in the encapsulation (MPLS 1209 or IP) used to send the packet across the backbone. 1211 - DSCP ("Differentiated Services Codepoint") mapping. 1213 - DSCP transparency. 1215 - Random Early Discard in the backbone. 1217 None of these features are VPN-specific. The ability to support them 1218 depends on whether the features are available on the edge and core 1219 platforms, rather than on any particular VPN scheme. 1221 MPLS support for differentiated services is detailed in RFC3270 1222 [MPLS-DIFFSERV]. DSCP mapping and transparency is covered in section 1223 2.6 of that document. 1225 It is possible to use traffic engineering to provide, e.g., 1226 guaranteed bandwidth between two PEs for the traffic of a given VPN. 1227 The VRF entries for that VPN in each PE need to be modified so that 1228 the traffic to the other PE is directed onto the traffic engineered 1229 path. How this is done is a local matter. 1231 BGP/MPLS IP VPNs can support both the "hose model" and the "pipe 1232 model" of Qos. In the "pipe model", a particular quality of service 1233 (e.g., a guaranteed amount of bandwidth) would be applied to all or 1234 some of the packets traveling between a given pair of CEs. In the 1235 "hose model", a particular quality of service (e.g., a guaranteed 1236 amount of bandwidth) would be applied to all traffic to or from a 1237 particular CE, irrespective of which other CE the traffic is going to 1238 or coming from. Since BGP/MPLS IP VPNs do not usually make use of 1239 CE-CE tunnels, the hose model is the more natural fit. Providing the 1240 pipe model would require the use of traffic engineering to explicitly 1241 create the necessary tunnels. 1243 Many of the requirements specified in [L3VPN-REQS] stipulate that the 1244 NMS ("Network Monitoring System") should support SLAs monitoring and 1245 verification between the SP and the various customers by measurement 1246 of the indicators defined within the context of the SLA. The 1247 measurement of these indicators (i.e.: counters) can be achieved when 1248 BGP/MPLS IP VPNs are used by employing a combination of the MIB 1249 ("Management Information Base") module designed for BGP/MPLS IP VPNs 1250 [L3VPN-MIB] as well as other standard MIB modules such as the IF-MIB 1251 [IF-MIB]. Devices supporting these MIB modules can calculate SLAs 1252 based on real-time performance measurements using indicators and 1253 threshold crossing alerts. Devices can make these thresholds 1254 configurable either via a management interface such as SNMP. 1256 15. Management 1258 The L3VPN Requirements document [L3VPN-REQS] stipulates that The term 1259 "Provider Provisioned VPN" refers to VPNs for which the service 1260 provider participates in management and provisioning of the VPN. RFC 1261 BGP/MPLS IP VPNs can be provisioned and managed to meet these 1262 requirements. The following subsections will outline how devices 1263 supporting BGP/MPLS IP VPNs can satisfy these requirements. 1265 15.1. Management by the Provider 1267 The SP manages all the VPN-specific information in the PE device. 1268 This can be done using the MIB designed for BGP/MPLS IP VPNs [L3VPN- 1269 MIB], in combination with other standard MIB modules such as IF-MIB 1270 [IF-MIB], and other MPLS MIB modules [LSRMIB], [LDPMIB], [TEMIB], 1271 [FTNMIB]. 1273 Devices supporting BGP/MPLS IP VPNs that employ the management 1274 interface characteristics described above will also support the ITU-T 1275 Telecommunications Management Network Model "FCAPS" functionalities 1276 as required in the the L3VPN Requirements document. These include: 1277 Fault, Configuration, Accounting, Provisioning, and Security. 1279 In BGP/MPLS IP VPNs, the SP is not required to manage the CE devices. 1280 However, if it is desired for the SP to do so, the SP may manage CE 1281 devices from a central site, provided that a route to the central 1282 site is exported into the CE's VPN, and the central site is in a VPN 1283 into which the routes to the managed CE devices have been imported. 1284 This is a form of extranet. 1286 If the central site is managing CE devices from several VPNs, those 1287 CE devices must have mutually unique addresses. Note that this does 1288 not enable the CE devices from different VPNs to reach each other. 1290 The CE devices have no VPN-specific information in them. Hence the 1291 fact that they are connected together into a VPN does not require 1292 them to have any VPN-specific management MIB modules or capabilities. 1294 15.2. Management by the Customer 1296 CE devices may be managed from within the VPN, transparently to the 1297 SP. The CE devices have no VPN-specific information in them, and the 1298 fact that they are tied together into a VPN does not impact the 1299 customer's management of them. 1301 Customer access to a PE device is totally at the discretion of the 1302 SP, but is not required by the solution. The PE device is a routing 1303 peer of a CE device, and can be pinged, etc. 1305 If a customer is permitted to access the PE router for management 1306 purposes, the functions available to any particular customer need to 1307 be strictly controlled, and the use of resource partitioning may be 1308 appropriate. 1310 Network management traffic from the CE to the PE may be rate limited 1311 (for example, to prevent network management traffic from CE to PE to 1312 be used in a DoS attack). 1314 16. Acknowledgments 1316 Many thanks to Jeremy De Clercq, Luyuan Fang, Dave McDysan, Ananth 1317 Nagarajan, Yakov Rekhter, and Muneyoshi Suzuki, for their comments, 1318 criticisms, and help in preparing this document. Thanks also to 1319 Thomas Nadeau for his help with the section on management, to 1320 Francois LeFaucheur for his help with the section on QoS, and to Ross 1321 Callon for his review of the document. 1323 17. Normative References 1325 [BGP-EXT-COMM] "BGP Extended Communities Attribute", Sangli, Tappan, 1326 Rekhter draft-ietf-idr-bgp-ext-communities-07.txt, March 2004 1328 [BGP-MPLS-IP-VPN] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., 1329 draft-ietf-l3vpn-rfc2547bis-02.txt, June 2004 1331 [L3VPN-FRMWRK] "A Framework for Provider Provisioned Virtual Private 1332 Networks", Callon, Suzuki, De Clercq, Gleeson, Malis, Muthukrishnan, 1333 Rosen, Sargor, Yu, draft-ietf-l3vpn-framework-00.txt, March 2003 1335 [L3VPN-REQS] "Service requirements for Provider Provisioned Virtual 1336 Private Networks", Carugi, McDysan, Fang, Johansson, Nagarajan, 1337 Sumimoto, Wilder, draft-ietf-l3vpn-requirements-01.txt, June 2004 1339 [L3VPN-SEC-FRMWRK] "Security Framework for Provider Provisioned 1340 Virtual Private Networks", Fang, Behringer, Callon, Chiussi, De 1341 Clercq, Duffy, Hitchen, Knight, draft-ietf-l3vpn-security-framework- 1342 01.txt, March 2004 1344 18. Informative References 1346 [BGP-MPLS-IP-OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS IP 1347 VPNs", draft-ietf-l3vpn-ospf-2547-01.txt, Rosen, Psenak, Pillay- 1348 Esnault, February 2004 1350 [BGP-MPLS-IP-OSPF-DNbit] "Using an LSA Options Bit to Prevent Looping 1351 in BGP/MPLS IP VPNs", Rosen, Psenak, Pillay-Esnault, draft-ietf- 1352 ospf-2547-dnbit-04.txt, March 2004 1354 [BGP-MPLS-IPsec-VPN] "Use of PE-PE IPsec in BGP/MPLS IP VPNs", Rosen, 1355 De Clercq, Paridaens, T'Joens, Sargor, draft-ietf-l3vpn-ipsec-2547- 1356 02.txt, March 2004 1358 [BGP-MPLS-MCAST-VPN] "Multicast in BGP/MPLS VPNs", Rosen, Cai, 1359 Wijsnands, draft-rosen-vpn-mcast-07.txt, May 2004 1361 [CE-VERIF] "CE-to-CE Member Verification for Layer 3 VPNs", Bonica, 1362 Rekhter, Raszuk, Rosen, Tappan, draft-ietf-l3vpn-l3vpn-auth-00.txt, 1363 September 2003 1365 [FTNMIB] RFC 3814, "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE 1366 (FTN) Management Information Base", Nadeau, Srinivasan, Viswanathan, 1367 June 2004 1369 [IPSEC-VPN] "An Architecture for Provider Provisioned CE-based 1370 Virtual Private Networks using IPsec", De Clercq, Paridaens, 1371 Krywaniuk, Wang, draft-ietf-l3vpn-ce-based-02.txt, February 2004 1373 [LDPMIB] RFC 3815, "Definitions of Managed Objects for the 1374 Multiprotocol Label Switching, Label Distribution Protocol (LDP)", 1375 Cucchiara, et al., June 2004 1377 [LSRMIB] RFC 3813, "MPLS Label Switch Router Management Information 1378 Base", Srinivasan, Viswanathan, Nadeau, June 2004 1380 [MPLS-DIFFSERV] RFC 3270, "Multi-Protocol Label Switching (MPLS) 1381 Support of Differentiated Services", Le Faucheur, Wu, Davie, Davari, 1382 Vaananen, Krishnan, Cheval, Heinanen, May 2002 1384 [L3VPN-MIB] "MPLS/BGP Virtual Private Network Management Information 1385 Base Using SMIv2", Nadeau, et al., draft-ietf-l3vpn-mpls-vpn-mib- 1386 05.txt, August 2004 1388 [IF-MIB] "RFC 2863, The Interfaces Group MIB", McCloghrie, 1389 Kastenholtz, June 2000 1391 [TEMIB] RFC 3812, "MPLS Traffic Engineering Management Information 1392 Base Using SMIv2", Srinivasan, Viswanathan,Nadeau, June 2004 1394 [VR-VPN] "Network Based IP VPN Architecture using Virtual Routers", 1395 Knight, Ould-Brahim, Gleeson, draft-ietf-l3vpn-vpn-vr-02.txt, April 1396 2004 1398 19. Author's Address 1400 Eric C. Rosen 1401 Cisco Systems, Inc. 1402 1414 Massachusetts Avenue 1403 Boxborough, MA 01719 1404 E-mail: erosen@cisco.com 1406 20. Intellectual Property Statement 1408 The IETF takes no position regarding the validity or scope of any 1409 Intellectual Property Rights or other rights that might be claimed to 1410 pertain to the implementation or use of the technology described in 1411 this document or the extent to which any license under such rights 1412 might or might not be available; nor does it represent that it has 1413 made any independent effort to identify any such rights. Information 1414 on the procedures with respect to rights in RFC documents can be 1415 found in BCP 78 and BCP 79. 1417 Copies of IPR disclosures made to the IETF Secretariat and any 1418 assurances of licenses to be made available, or the result of an 1419 attempt made to obtain a general license or permission for the use of 1420 such proprietary rights by implementers or users of this 1421 specification can be obtained from the IETF on-line IPR repository at 1422 http://www.ietf.org/ipr. 1424 The IETF invites any interested party to bring to its attention any 1425 copyrights, patents or patent applications, or other proprietary 1426 rights that may cover technology that may be required to implement 1427 this standard. Please address the information to the IETF at ietf- 1428 ipr@ietf.org. 1430 21. Full Copyright Statement 1432 Copyright (C) The Internet Society (2004). This document is subject 1433 to the rights, licenses and restrictions contained in BCP 78 and 1434 except as set forth therein, the authors retain all their rights. 1436 This document and the information contained herein are provided on an 1437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1439 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1440 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1441 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.