idnits 2.17.1 draft-ietf-l3vpn-as-vr-02.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 3978, Section 5.1 on line 26. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1320. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1308), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 1308. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 5) being 60 lines 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.) 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 (August 2006) is 6457 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: 'RFC2119' is mentioned on line 55, but not defined == Missing Reference: 'COREVPN' is mentioned on line 177, but not defined == Missing Reference: 'L3VPNVR' is mentioned on line 818, but not defined == Unused Reference: 'RFC2764' is defined on line 1256, but no explicit reference was found in the text Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Layer 3 VPN Working Group 3 Internet Draft Ananth Nagarajan 4 Document: draft-ietf-l3vpn-as-vr-02.txt Juniper Networks 5 Expires: February 2007 6 Junichi Sumimoto 7 Muneyoshi Suzuki 8 NTT Corporation 10 Paul Knight 11 Nortel Networks 13 Benson Schliesser 14 SAVVIS Communications 16 August 2006 18 Applicability Statement for Virtual Router-based Layer 3 PPVPN 19 Approaches 21 Status of this Memo 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with Section 6 of BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 This document is an applicability statement for Layer 3 Provider 46 Provisioned VPNs (L3 PPVPNs) that are based on Virtual Router (VR) 47 approaches. This document describes how VR-based approaches meet the 48 key requirements that are outlined in the PPVPN Applicability 49 Statements Guideline document. 51 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Service Provider Provisioning Model............................3 60 2.1 Auto-Discovery.............................................4 61 3. Supported Topology and Traffic Types...........................4 62 4. Isolated Exchange of Routing and Data Information..............5 63 4.1 Isolation of Routing Information...........................5 64 4.2 Isolation of Data..........................................6 65 5. Access Control and Authentication..............................6 66 6. Security.......................................................6 67 6.1 Protection of User Data....................................6 68 6.2 Service Provider Security Measures.........................7 69 6.3 PPVPN Security Framework Template..........................8 70 7. Addressing.....................................................8 71 8. Interoperability and Interworking..............................8 72 9. Network Access.................................................9 73 9.1 Physical and Link Layer Topology...........................9 74 9.2 Temporary Access...........................................9 75 9.3 Access Connectivity........................................9 76 10. Service Access................................................9 77 10.1 Internet Access...........................................9 78 10.2 Hosting, ASP, other services..............................9 79 11. Service Provider Routing.....................................10 80 11.1 Core Router Awareness of Mechanisms Used.................11 81 12. Migration Impacts............................................11 82 13. Scalability..................................................12 83 14. QoS/SLA......................................................13 84 15. SLA Monitoring...............................................13 85 16. Management...................................................14 86 16.1 Service Provider Management of Customer Site.............14 87 16.2 Customer Management of VR................................14 88 16.3 Service Provider Network Management......................14 89 17. Security considerations......................................15 90 Appendix A: Responses to Security Evaluation Template..........16 91 References.......................................................26 92 Acknowledgments..................................................27 93 Author's Addresses...............................................27 95 1. 96 Introduction 98 The virtual router concept for L3 PPVPNs is described in [PPVPNVR]. 99 Based on the taxonomy of PPVPNs described in [FRAMEWORK], Virtual 100 Router based approaches are classified as PE-based Layer 3 PPVPNs. 102 VR-based PPVPNs are used in the following situations: 104 - The customer wishes to outsource the maintenance and management of 105 inter-site VPN connectivity to the Service Provider (SP). 107 - The SP desires to provide VPN service without upgrading its core 108 network to support any specific technology (e.g., MPLS), i.e., the SP 109 wants to provide a Layer 3 VPN service over a range of core network 110 technologies, including existing IP routed or Layer 2 switched core 111 networks, MPLS, or a combination of these technologies. 113 - The customer is not aware of the topology or mechanisms used in 114 the SP core network and is responsible for routing between customer 115 routers, which is independent of the routing used in the SP core. The 116 customer-facing sides of the PE devices in the SP network are visible 117 to the customer. The logical links between VRs are also visible to 118 the customer, and optionally it is possible for the full private 119 network topology (including the logical links) to be visible to 120 routers within a site. 122 - The customer wishes to exercise control of routing functions at 123 the CE routers at each of its VPN sites, while depending on the SP to 124 provide transport for data traffic and for the customer's routing 125 information across the SP core. From the viewpoint of any of the 126 customer's routers, there will usually appear to be a single router 127 hop to any other VPN site. The only routes exchanged between the CE 128 routers and the PE devices are the customer's internal routes (with 129 the possible addition of routes desired by the customer for Internet 130 access via the SP, such as a default route). 132 - The customer sends IP traffic across the VPN, possibly including 133 non-IP traffic encapsulated in IP by the customer. 135 - The VPN service provider does not own a backbone network but 136 wishes to provide PPVPN services over a backbone obtained from some 137 other provider. 139 - Several cooperating SPs desire to offer PPVPN service at points 140 that span multiple administrative domains of the backbone, perhaps 141 over the public Internet. 143 This document describes how Virtual Router based VPN approaches 144 satisfy key requirements listed in the PPVPN Service Requirements 145 document [REQTS] and the PPVPN Security Framework [SEC-FRMWK]. 147 2. 148 Service Provider Provisioning Model 150 Virtual Routers (VRs) can interact with other routers so as to be 151 indistinguishable from an individual physical router. However, 152 multiple instances of VRs can be configured within a single physical 153 device. This provides a significant improvement in manageability and 154 provisioning flexibility. In addition, there is potential statistical 155 multiplexing gain on "uplinks" from the PE router to P router, 156 compared with use of multiple physical routers. Each VR can maintain 157 its own separate routing tables, so if two virtual routers are in the 158 same physical router, an interaction of one VR with one of its peers 159 does not have any effect on the interaction of another VR with any of 160 its own peers. In some implementations, VRs may share physical 161 interface bandwidth. 163 VPNs are constructed via tunnels connecting VR pairs across the 164 service provider backbone network. Per-VR routing protocol 165 instantiations are run to distribute VPN reachability information. 166 VPN membership information distribution is treated separately, and is 167 achieved via sharing a VPN-ID, for example [RFC2685], between VRs 168 that are members of a specific VPN. The detailed VR model is 169 described in [PPVPNVR]. 171 2.1 172 Auto-Discovery 174 In the VR-based PPVPNS, various auto discovery mechanisms are 175 supported. VPN discovery can be achieved through directory servers 176 [RADIUS-DIS], explicit configuration via a management platform, using 177 multicast [COREVPN] or by piggybacking VPN membership and topology 178 information via routing protocols such as BGP [VPN-BGP]. A 179 combination of these mechanisms may also be used on a PE. For 180 example, for some VPNs topology discovery is done only through a 181 management platform. For others, dynamic topology discovery is 182 achieved using existing routing protocol. BGP-based auto-discovery 183 is described in [VPN-BGP], and may be used for membership and 184 topology discovery. 186 It is important to note that, for the VR architecture, the auto- 187 discovery mechanism is only used to automatically exchange control 188 VPN information between VRs. It is not intended for interchange of 189 the VPN routing information, which is accomplished by standard 190 routing protocols running between the VRs, as discussed in [PPVPNVR]. 192 3. 193 Supported Topology and Traffic Types 195 VR-based PPVPNs can be constructed using either MPLS or IP tunnels 196 (GRE, IP-in-IP, L2TP, IPSec) in the core network, or Layer 2 197 connections such as ATM or Frame Relay. The choice of the tunneling 198 mechanism may impact other properties of the VPN itself, including 199 scalability, manageability, QoS, security, etc. For example, the use 200 of IPSec tunnels for encryption may impact forwarding performance on 201 some devices, and therefore impact the number of sites or routes per 202 VPN, the number of VPNs per PE, etc. The performance of IPSec tunnels 203 may be improved through the use of dedicated hardware, which allows 204 greater performance and scaling but potentially at increased cost. 206 Tunnels are created on a per-VPN basis. For transport across the 207 network, a number of these tunnels may be aggregated and carried 208 within a PE-PE tunnel. The SP has a high degree of flexibility in 209 configuring the topology of a VPN interconnecting customer sites. The 210 topology can be full-mesh, partial-mesh, or any arbitrary topology 211 that has been agreed to by the customer and the SP. 213 4. 214 Isolated Exchange of Routing and Data Information 216 By definition of a Virtual Private Network, the details of its 217 addressing, topology, connectivity, and reachability as well as the 218 data that it transports are implicitly considered to be private, and 219 should therefore be isolated from other networks, including others 220 that may be supported with the PPVPN infrastructure. [FRAMEWORK] 222 4.1 223 Isolation of Routing Information 225 In any PPVPN, the SP is responsible for maintaining isolation between 226 networks except as explicitly intended by the VPN owner. In the VR 227 model, a key mechanism for maintaining isolation is through isolating 228 routing information, thereby constraining the distribution of 229 reachability information. 231 The VR model of PPVPNs provides for isolation by instantiating 232 multiple Virtual Routers (VR) on a single physical platform to 233 support multiple VPNs. [PPVPNVR] Each VR has its own logical 234 interfaces, routing tables, forwarding tables, and routing protocol 235 instances. Note that a VR may share physical interfaces with other 236 VRs, depending on the implementation and specific topology. This 237 provides for isolated topology, addressing, and reachability for the 238 VPN. 240 Addressing and Reachability includes the assignment, discovery, and 241 distribution of source and/or destination information for the PPVPN. 242 The isolation of this information implies that other networks, 243 including other VPNs and the Internet, will have no visibility into 244 the PPVPN except as explicitly configured. 246 Routing information carried between VRs is carried in through the 247 same tunnels as data itself, and is therefore segregated from the 248 underlying backbone infrastructure by the same mechanisms that 249 segregate data between VPNs. 251 This model supports arbitrary routing architectures, including 252 support for back-door links among customer VPN sites or other 253 potentially unique routing architecture requirements. The support 254 for arbitrary routing architectures, however, is accompanied by 255 scalability and management issues. These issues are discussed later 256 in this document. 258 In the VR approach, virtual routers are connected to the CEs through 259 local links, and to each other across the backbone through tunneling 260 services provided by the service provider across the backbone. All 261 data traffic within the VR-based VPN is isolated from non-VPN traffic 262 by these mechanisms. 264 Some VR implementations may provide the ability for customers to 265 exercise limited management operations upon the VRs which are 266 connected to the customer CEs. This may allow the customer to view 267 routing tables, or traffic statistics, or to exercise some control 268 over the customers routing. VRs MUST NOT allow any customer to 269 circumvent the isolation of routing or data among VPNs. 271 4.2 272 Isolation of Data 274 Data for different VPNs in the VR model is segregated through the use 275 of different link-layer connections or tunnels over a common SP 276 backbone. [PPVPNVR] Examples of such tunnels include GRE, L2TP, 277 IPSec, MPLS or Layer 2 connections such as ATM or Frame Relay. It 278 should be noted that this isolation can be impacted by 279 misconfiguration. 281 5. 282 Access Control and Authentication 284 CE-PE authentication has not been specified for VR-based VPNs. PE/CE 285 mutual authentication may be done via any mechanism supported by the 286 routing protocol in which the CE and PE are peers (e.g., use of the 287 TCP MD5 authentication when the CE/PE protocol is BGP), or by any 288 other mechanism that may be desired by the customer. 290 In order for VR-based PPVPNs to support confidentiality, integrity, 291 authentication, and replay attack prevention, mechanisms such as 292 IPsec may be used as tunneling mechanism or used over VPN tunnels. 293 Even with the use of IPsec, the security level offered is dependent 294 on the scope of the IPsec security associations: encrypting on a CE- 295 to-CE basis (as in CE-based VPNs) will offer a wider scope of 296 protection than only encrypting on a PE-to-PE basis (as in PE-based 297 VPNs), since the CE-PE link remains unencrypted in the latter case. 298 However, PE-PE IPsec offers substantial advantages in efficiency, 299 outsourcing, and integration with the dynamic membership and dynamic 300 routing nature of the PPVPN. CE-PE IPsec can also be used to protect 301 traffic on the CE-PE section of the network. In this case the 302 traffic is only unprotected by IPsec within the PE device. Policy- 303 based security and access control mechanisms or firewalls may be used 304 between sites in the same VPN. These can be implemented on the PE 305 router, or on the CE. 307 6. 308 Security 310 6.1 311 Protection of User Data 313 As described above, end-to-end (CE-to-CE) IPSec may be used to 314 protect user data. SPs may choose to provide CE-based IPSec as a 315 value added service. If the SP core network is also part of the 316 public Internet, the SP may choose to provide PE-to-PE IPSec as the 317 tunneling mechanism between VRs. 319 If inter-SP VPNs are to be provided, IPSec tunnels may be used. The 320 impact on QoS and SLAs in this case will have to be studied. 322 In general, user data is protected via the inherent isolation 323 provided by the inter-VR tunnels. Varying levels of security of user 324 data may be provided based on the type of tunnel that is used. 326 6.2 327 Service Provider Security Measures 329 In general, the SP should ensure that non-VPN traffic does not 330 accidentally or maliciously enter a VPN. Since VRs can be configured 331 very specifically for a customer, the SP can offer customers anti- 332 spoofing or other traffic or route filtering services tailored for 333 the customer's network. The SP's PE and P devices should be protected 334 against intrusion or denial of service attacks. This is especially 335 important because the SP core network may be used to provide general 336 Internet services apart from VPN services. Therefore any Denial of 337 Service attack or misconfiguration that impacts other VPN services 338 and Internet services should be prevented. Since most of the traffic 339 from CE to PE, apart from control (routing and network management) 340 traffic, gets encapsulated to be carried across the SP network, the 341 possibility of users sending traffic to other (non-PE) systems in the 342 core network is minimized or eliminated. The inherent isolation of VR 343 mechanisms helps provide this protection against attacks from 344 customer sites, but additional specific measures are available: 346 - VR routing sessions can be authenticated between the PE and CE, 347 and among PEs. 349 - If BGP is used as an auto-discovery mechanism between VRs, it 350 should be further authenticated using mechanisms such as TCP MD5. 352 - Filtering of any management data entering the PE should be 353 performed in order to prevent the acceptance of unauthorized packets 354 from customers or other SPs into that PE. 356 Denial of Service attacks may occur via routing traffic or network 357 management traffic, either intentionally or accidentally via routing 358 instabilities or misconfigurations in the VPN. With Virtual router 359 VPNs, in many cases a dynamic routing protocol will be run between CE 360 routers and VRs within PE routers. Either the same or a different 361 dynamic routing protocol may be run between VR instances in each PE 362 associated with a VPN. If routing is unstable in the private network, 363 it is possible for this instability to be propagated to the PE 364 routers. For example, in some cases a large number of routing updates 365 could be sent from the CE router to a VR within a PE router, or 366 between VR instances in different PE routers. This could potentially 367 place a major or excessive processing load on the PE routers. 369 This issue can be mitigated via resource partitioning in the PE, in 370 order to limit the amount of resources (e.g., CPU and memory) which 371 any one VR is permitted to use in PE routers. Also, rate limits may 372 be applied to the routing traffic sent from the CE to the PE. 373 Alternately, when this problem is detected on the CE to PE link, the 374 CE to PE interface may be shut down. 376 In order to prevent DoS attacks due to network management traffic, 377 the functions available to the customer need to be strictly 378 controlled. It may also be useful to limit the resource use of this 379 capability. Resource partitioning may be appropriate internal to PE 380 routers, and network management traffic from the CE to the PE may be 381 rate limited (for example, to prevent network management traffic from 382 CE to PE from being used in a DoS attack). 384 6.3 385 PPVPN Security Framework Template 387 As stated in the "PPVPN Security Framework" [SEC-FRMWK], "An 388 evaluation of a given PPVPN approach using this template should 389 appear in the applicability statement for each PPVPN approach." 390 Please refer to Appendix A for this detailed response. 392 7. 393 Addressing 395 Virtual Routers may provide any or all of the services which are 396 provided by a physical router, including Network Address Translation 397 (NAT), packet filtering, etc. These VR capabilities can simplify the 398 process of joining previously independent site networks, which may 399 have overlapping address spaces. NAT can be used to satisfy intra- 400 VPN non-unique addressing requirements. This facilitates the 401 construction of short-term or ad-hoc VPNS. It should be noted, 402 however, that NAT has accompanying scaling problems, and other 403 mechanisms are needed to ensure proper routing updates, when two 404 sites share the same routing domain. 406 Non-unique and private customer addresses may be supported by using 407 encapsulation within the tunneling mechanisms employed between VR 408 pairs (e.g., GRE, IP-in-IP etc.). As such, support for private 409 addressing as specified in [RFC1918] allows for non-unique addresses 410 between different VPNs. 412 8. 413 Interoperability and Interworking 415 Interoperability and Interworking of VR-based VPNs with other L3 416 PPVPN mechanisms such as [RFC2547bis] is for further study. Since 417 VRs provide all IP router functionalities, various VR-based solutions 418 interwork and interoperate to the extent that IP networks 419 interoperate and interwork. 421 9. 422 Network Access 424 9.1 425 Physical and Link Layer Topology 427 VR-based mechanisms do not affect the choice of physical and link 428 layer technologies or topologies. 430 9.2 431 Temporary Access 433 Temporary access for a dial-up user to a VR can be provided via PPP 434 and AAA, using a Remote Access Server. Other access mechanisms such 435 as IPSec can also be used. Thus, it is possible provide login and 436 password based access to a VR-based VPN from an authorized user 437 connected to the Internet. 439 9.3 440 Access Connectivity 442 Multi-homing of CEs to multiple VRs (within the same or different 443 PEs) is supported. The PEs (and consequently the VRs) may belong to 444 different SPs. 446 Load sharing based on IGP or other traffic engineering mechanisms 447 used in the SP core are naturally supported by VR-based VPNs. 449 10. 450 Service Access 452 10.1 453 Internet Access 455 Simultaneous VPN and Internet Access can be supported via various 456 mechanisms. A specific VR may be assigned as a default VR that is 457 connected to the Internet. If a single VR is to be used to carry a 458 customer's VPN as well as Internet traffic, Internet traffic can be 459 distinguished from VPN traffic by associating a default VPN-ID with 460 Internet traffic and pointing it to a default route to the Internet. 461 This default route to the Internet need not be direct, but may 462 instead point to a firewall or other security device which may use 463 different interfaces for VPN access and Internet access. 465 10.2 466 Hosting, ASP, other services 468 All of the above "external" services can be supported by associating 469 a separate address for every service that is not being used within 470 the VPN. If a single server (for example, a web hosting server) is 471 used to provide a particular service to all VPNs, NAT may be used to 472 provide a unique address for clients to access that particular 473 integrated into the PE. The scaling impacts of adding NAT to the PE 474 will have to be considered. 476 11. 477 Service Provider Routing 479 VR-based PPVPNs do not impose any additional requirements on the IGP 480 used in the service provider core network. However, if the customer 481 VPN runs an IGP, the VRs (and consequently the PEs) must support that 482 IGP. This customer IGP need not be the same as the IGP running in the 483 Service Provider's core network. 485 From the customers viewpoint of its VPN IGP routing topology (if it 486 uses one), the SPs network topology appears much simpler than it may 487 actually be. Depending on the VR implementation, the SPs service 488 offering, and the SPs physical topology, it may appear as either a 489 single large router with interfaces for each VPN site, as a full 490 mesh, with two routers between any two sites, as a hub-and spoke 491 topology (when the customer wants all inter-site traffic to pass 492 through one or more specific sites, for application of services such 493 as security filtering), or other arbitrary topology. In general, the 494 SP's actual core routing topology is invisible to the customer. 496 Fault handling is a specific problem when the timers used for the VR- 497 to-VR routing peering are shorter than the timers used for the 498 routing peering within the service provider(s) network. In this case 499 a single failure within a service provider network may look like a 500 collection of un-correlated failures in the VPN. 502 Moreover, since a VR doesn't really "know" what causes the failure, 503 the VR may react to such a failure by re-routing along some other 504 tunnel, while this other tunnel may be also affected by the same 505 failure. As a result, this would slow down routing convergence within 506 the VPN. 508 To avoid the problems mentioned above one may consider making the 509 timers used for the VR-to-VR peering longer than the timers used for 510 the routing peering within the service provider network (so that 511 failures within the service provider network would be "invisible" to 512 the VR-VR tunnels). But that has its own set of problems. While 513 this may be possible to accomplish within a single routing domain 514 (one needs to appropriately set the IGP timers within the domain), 515 doing this in a network that includes more than one routing domain 516 may be difficult (as timers include both IGP and BGP timers, and 517 moreover, timers include IGP timers in several routing domains). 518 Another consequence of making the timers used for the VR-to-VR 519 peering over the tunnels longer than the timers used for the routing 520 peering within the service provider network is that it would increase 521 the amount of traffic that will be "black holed" in the case of VR 522 failures. 524 A key aspect of the issue here is that layer 3 problems in the SP 525 network may appear as layer 2 problems in the VPN. Thus stability of 526 the SP network, with an emphasis on quick recovery, is a key element 527 in delivering satisfactory service. 529 Prevention of Denial of Service attacks caused by routing 530 instabilities has been discussed in Section 6.2. 532 11.1 533 Core Router Awareness of Mechanisms Used 535 Since tunnels are established between VR pairs, the core router (P 536 router) does not have any information of the mechanisms used to 537 construct the VPN. If MPLS is the tunneling mechanism that is used 538 between the VRs, the core routers may have to be MPLS enabled in 539 order to leverage the benefits of MPLS tunnels (e.g., traffic 540 engineering). As such, while the core routers are not aware of VPN- 541 specific information, they should support requirements to meet 542 relevant SLAs. (e.g., for guaranteed QoS, the core routers may need 543 to support appropriate QoS mechanisms). 545 12. 546 Migration Impacts 548 Similar to other Layer 3 PPVPN architectures, any CE using services 549 provided using the VR approach can access a PE similar to the way it 550 would access another CE router in a private network using leased 551 lines. As the VR approach makes use of standard routing protocols 552 without any extensions, there is no requirement for additional 553 capabilities on the part of CEs in order to interoperate with a VR- 554 based PPVPN. 556 Key design considerations include: 558 - The PEs will introduce extra router hops 560 - If the VR-VR backbone routing protocol differs from the sites, 561 then IGP metric implications should be carefully evaluated. This 562 would be particularly true for multihomed VPN sites. 564 In general, a VR-based PPVPN offers the customer a greatly simplified 565 network topology compared to a customer-managed private network, 566 since each CE router sees a single link as the next-hop route to all 567 other VPN sites. There is no need to configure multiple physical or 568 logical interfaces on the CE routers. 570 Multi-homed VPN sites or sites with back-door connections will 571 involve design decisions as to whether each of the multiple links 572 should operate as a backup link or as a load-sharing link. 574 Also, since the VR approach does not depend on the backbone 575 architecture in terms of routing protocols, a VR-based L3 PPVPN can 576 be offered on a service provider core network without the need for 577 specific core technologies. For example, the core network does not 578 need specific mechanisms like MPLS to be implemented on the P 579 routers. Similarly, if the core network is a Layer 2 network based 580 on ATM or Frame Relay, VR-based VPNs can still be constructed. 582 It should be noted, however, that core network mechanisms would 583 determine the overall properties and services that may be provided 584 over the VPN. For example, in order to support customer QoS SLAs, 585 the core network should be robustly engineered or should support QoS 586 mechanisms, in addition to SLA marking at the PE. 588 Thus, while migration impacts in the case of basic VPN functionality 589 using VR are minimal from the customers' or providers' point of view, 590 appropriate core mechanisms may be necessary for certain services. 592 13. 593 Scalability 595 VR is a technology for implementing logical routing instances in a PE 596 device. A PE device may contain more than one VR and a VR supports 597 one VPN. Therefore, scalability of a VR and conventional physical 598 router are basically the same, e.g., if different routing protocols 599 are used for customer and network sides of a VR or physical router, 600 the load is increased compared with the case when the same protocols 601 are used. 603 The major factor contributing to scalability constraint in the VR 604 approach is the number of VRs which can be supported by a PE. This is 605 because, the number of VRs in a PE device is equal to the number of 606 VPNs which are supported by the PE. 608 Resources used by a VR instance include memory and processor 609 resources, used to support VPN tunnel mechanisms, routing protocol 610 instances, route tables, interface management, etc. The extent to 611 which these resources are utilized impact scalability. 613 Much of the resource utilization for a given VPN will be affected by 614 the topology of the VPN. For instance, a VPN with a full-mesh 615 topology will require that VRs have more peers for the VPN tunneling 616 mechanism, for routing protocol adjacencies, for security protocols, 617 etc., while a hub-and-spoke model will constrain the resources 618 required for 'spoke' PE routers. 620 From a VR perspective, scalability also depends on whether the same 621 routing protocols are used between VRs as in the backbone network. If 622 the inter-VR routing protocols are different from the backbone IGP, 623 the scaling and management impacts for configuring routing protocols 624 on a per-VR basis may be significant. For example, it may be 625 necessary to maintain OSPF databases for the entire customer VPN 626 topology, as opposed to maintaining information for only directly 627 connected customer sites. Additionally, the customer IGP may need to 628 maintain information about the entire VR topology, for the VRs which 629 are connected to the customer's CEs. Other concerns include routing 630 loop avoidance, route redistribution, etc. Thus, while the VR model 631 allows the routing protocols between customers and VRs to be 632 different than the backbone IGP, this flexibility can be accompanied 633 by scalability concerns. Mechanisms such as OSPF areas may be used 634 to circumvent such scaling issues. 636 It is normal in many cases for a VR located in a PE router to run a 637 routing instance with each other VR which is part of the same VPN. In 638 some cases this could result in a large number of routing 639 adjacencies. The number of routing adjacencies could aggravate the 640 impact of instability in routing in the private network, or aggravate 641 the impact of routing protocol DOS attack described in Section 6.2. 643 As mentioned in Section 6.2, this can be mitigated by appropriate 644 resource partitioning in the PE, and by rate limiting of routing 645 packets, including packets from CE to PE and well as packets from PE 646 to PE. Also, while this consideration may limit the number of VRs 647 which may potentially be supported from a single PE device, it does 648 not have any significant effect on the overall scaling of a network 649 implementing the VR approach. 651 14. 652 QoS/SLA 654 VR-based PPVPNs support any kind of QoS that the core network and the 655 tunneling mechanism used support. 657 VR-based VPNs can utilize different quality of service mechanisms. 658 QoS mechanisms developed for physical routers can be used with VRs, 659 on a per-VR basis. e.g. classification, policing, drop policies, 660 traffic shaping and scheduling/bandwidth reservation. The 661 architecture allows separate quality of service engineering of the 662 VPNs and the backbone. However, the tunneling mechanisms themselves 663 should support relevant QoS mechanisms. 665 15. 666 SLA Monitoring 668 VR-based VPNs can implement a variety of methods to monitor 669 compliance with Service Level Agreements. Since the links between 670 VRs make use of tunnels across the underlying backbone network, the 671 SLA monitoring capabilities of the backbone network can be used to 672 monitor the performance of the inter-VR links. Because the inter-VR 673 links are tunnels, and the SLA monitoring capabilities of the 674 backbone network may not include per-tunnel monitoring capabilities, 675 some VR implementations support additional SLA monitoring mechanisms. 676 Performance to SLA requirements within the PEs hosting the VRs is 677 typically monitored via internal processes to ensure compliance from 678 end to end. In addition, either the service provider or the VPN 679 customer can use all existing SLA tracking tools (round trip time 680 measurement, traceroute mapping, etc.) within the VR-based VPN. 682 16. 683 Management 685 16.1 686 Service Provider Management of Customer Site 688 The SP may choose to manage the customer site (i.e., the CE devices) 689 for added revenue. If the SP uses a centralized customer management 690 system, care should be taken to uniquely identify various CEs 691 belonging to different VPNs, so that CE devices from different VPNs 692 do not reach each other. 694 The customer may desire to have access to the PE device for 695 monitoring purposes (e.g., ping, traceroute). Providing such access 696 is at the discretion of the SP. 698 Traffic statistics in order to prove SLAs to customers may be 699 provided on a periodic basis. Other statistics that can show 700 enhanced SP capabilities, including protection against Denial of 701 Service attacks, failure etc., can be provided to the customer. 703 16.2 704 Customer Management of VR 706 Some VR implementations may provide the ability for customers to 707 exercise limited management operations upon the VRs which are 708 connected to the customer CEs. This may allow the customer to view 709 routing tables, or traffic statistics, or to exercise some control 710 over the customers routing. 711 Customer network management and troubleshooting systems will 712 generally have less ability to gather information from the VRs than 713 from the customers own routers, and will also have little or no 714 ability to directly change VR configurations. The customers systems 715 should be planned so as to accommodate the restricted capabilities of 716 the VRs to respond to customer network management processes. 718 Prevention of Denial of Service attacks due to network management 719 traffic originating from customer management of the VR has been 720 discussed in Section 6.2. 722 16.3 723 Service Provider Network Management 725 When an SP provides VR-based VPN services, it is highly likely that 726 the PE devices used are complex because of the number of VRs 727 supported, the number of routing adjacencies between VR pairs, 728 maintenance of tunnel and VPN-specific information and possibly other 729 information such as QoS. Thus the management of the PE is extremely 730 critical for the SP. If the SP core is also used to provide Internet 731 services, adequate mechanisms should be in place in order to not 732 allow misconfigurations or instabilities in the PE control plane to 733 affect the general Internet operations or impact other VPN customers. 734 In addition to normal SP network management, prevention of Denial of 735 Service attacks must be in place in the PEs. Resource partitioning 736 and rate limiting, as described in Section 6.2 are examples of such 737 mechanisms. 739 17. 740 Security considerations 742 There are no additional security considerations besides those already 743 addressed in this document in Section 6, and in Appendix A. VR-based 744 VPNs are expected to meet the security framework described in [SEC- 745 FRMWK]. 747 Appendix A: Responses to Security Evaluation Template 749 This Appendix presents an evaluation of how the Virtual Router model 750 measures up against the Security Evaluation Template developed in the 751 PPVPN Security Framework [SEC-FRMWK]. As stated in that document, 752 "An evaluation of a given PPVPN approach using this template should 753 appear in the applicability statement for each PPVPN approach." 755 NOTE: For ease of reference to the PPVPN Security Framework [SEC- 756 FRMWK], the assertion numbering scheme from the Security Template of 757 that document is retained in this Appendix. 759 1. The approach provides complete IP address space separation for 760 each L3 VPN. 762 The VR approach completely addresses the requirement by instantiating 763 a separate VR for each VPN that is configured on any specific PE. 764 Each VR maintains separate routing tables, so each L3 VPN has 765 complete IP address separation from other VPNs. Connections between 766 VRs in the same VPN are tunneled across the Service Provider's 767 network, providing separation between the IP address space of the SP 768 and each VPN. 770 2. The approach provides complete L2 address space separation for 771 each L2 VPN. 773 The requirement is not applicable to the VR approach because VR is a 774 L3 VPN. 776 3. The approach provides complete VLAN ID space separation for each 777 L2 VPN. 779 The requirement is not applicable to the VR approach because VR is a 780 L3 VPN. 782 4. The approach provides complete IP route separation for each L3 783 VPN. 785 The VR approach completely addresses the requirement by instantiating 786 a separate VR for each VPN that is configured on any specific PE. 787 Each VR maintains separate routing tables, so each L3 VPN has 788 complete IP route separation from other VPNs. Routes for each VPN 789 are distributed by tunneling across the Service Provider's network 790 between VRs of the same VPN, providing separation between the various 791 VPN routes, and between the routes of the SP and each VPN. 793 5. The approach provides complete L2 forwarding separation for each 794 L2 VPN. 796 The requirement is not applicable to the VR approach because VR is a 797 L3 VPN. 799 6. The approach provides a means to prevent improper cross-connection 800 of sites in separate VPNs. 802 The VR approach completely addresses the requirement by using a VPN- 803 ID to positively identify the VPN membership of each VR. The VPN ID 804 is used when BGP is used for auto-discovery. It might also be used 805 when a management system is used for discovery, in which case the 806 VPN-ID is used by the appropriate MIB, for example [VR-MIB]. VRs of 807 different VPNs will not form routing adjacencies or exchange VPN 808 data. Alternatively, CE to CE authentication [L3-VERIF], could also 809 be used to protect against the threat of improper cross-connection. 811 7. The approach provides a means to detect improper cross-connection 812 of sites in separate VPNs. 814 The VR approach partially addresses the requirement by using a VPN-ID 815 to positively identify the VPN membership of each VR. VRs connected 816 to the wrong VPN (for instance, through an ATM or MPLS configuration 817 error) would not establish routing adjacencies or exchange VPN data. 818 However, there is not a requirement in [L3VPNVR] to specifically 819 detect improper cross-connection. The improper cross-connection 820 would simply result in a non-working VPN link, which would need to be 821 detected and corrected by normal troubleshooting techniques. 823 In the case of misconfiguration of a VR with the wrong VPN-ID and 824 other VPN attributes, the VR approach does not specify a method of 825 detecting the improper cross-connection. However, a method of 826 detecting PE misconfiguration is described in [L3-VERIF], based on 827 tokens exchanged between CEs and PEs. The VR approach is compatible 828 with either the BGP-based or UDP-based token exchange models that are 829 described in that document, to address the case of misconfiguration 830 of VPN membership on the PE. 832 8. The approach protects against the introduction of unauthorized 833 packets into each VPN. 835 a. In the CE-PE link 837 The VR approach completely addresses the requirement by supporting 838 the optional use of IPsec protection for the CE-PE link. The VR 839 approach allows a choice of CE-PE link configurations, thereby 840 allowing the PPVPN customer and the PPVPN Service Provider to select 841 the link type which will provide the desired degree of protection 842 against this threat. However, the VR approach by itself does not 843 provide specific packet-by-packet protection against this threat. 845 b. In a single- or multi- provider PPVPN backbone 847 The VR approach partially addresses the requirement by specifying the 848 use of tunnels between VRs across the backbone. Thus it provides 849 protection against the introduction of unauthorized packets to the 850 full extent of the underlying tunnel technologies. However, the VR 851 model by itself does not completely address the requirement, because 852 it allows the use of tunneling technologies such as GRE or IP-in-IP 853 which may not provide protection against this threat. 855 With the optional use of IPsec, the VR approach completely supports 856 the requirement. 858 c. In the Internet used as PPVPN backbone 860 The VR approach partially addresses the requirement by specifying the 861 use of tunnels between VRs across the backbone, including across the 862 Internet. IPsec tunnels provide reliable protection against the 863 introduction of unauthorized packets in this case, and the VR model 864 completely addresses the requirement when IPsec is used. However, 865 the VR model by itself does not completely address the requirement, 866 because it allows the use of tunneling technologies such as GRE or 867 IP-in-IP which may not provide protection against this threat. 869 9. The approach provides confidentiality (secrecy) protection for 870 PPVPN user data. 872 a. In the CE-PE link 874 The VR approach completely addresses the requirement by supporting 875 the optional use of IPsec protection for the CE-PE link. However, 876 the VR approach by itself does not provide specific confidentiality 877 protection. 879 b. In a single- or multi- provider PPVPN backbone 881 The VR approach completely addresses the requirement by supporting 882 the optional use of IPsec protection for the backbone links. Other 883 tunnel types offer varying degrees of confidentiality. 885 c. In the Internet used as PPVPN backbone 887 The VR approach completely addresses the requirement by supporting 888 the optional use of IPsec protection for the backbone links, 889 including links over the Internet. Other tunnel types offer varying 890 degrees of confidentiality, and may not be reliably supported over an 891 arbitrary Internet path. 893 10. The approach provides sender authentication for PPVPN user data. 895 a. In the CE-PE link 897 The VR approach completely addresses the requirement by supporting 898 the optional use of IPsec authentication on the CE-PE link. When the 899 IPsec Security Association is established, the use of authentication 900 can be specified. Authentication will be applied to each packet. 901 When IPsec is not used, the VR approach does not inherently provide 902 sender authentication on the CE-PE link. 904 b. In a single- or multi- provider PPVPN backbone 906 The VR approach partially addresses the requirement of sender 907 authentication across the backbone, through the use of the VPN-ID. 908 The VPN-ID acts to authenticate the VRs configured on the PEs to each 909 other as senders across the backbone, although it does not 910 authenticate the CE senders, since the VPN-ID is only used between 911 the VRs. This is a cryptographically weak authentication, but since 912 the PE configurations are managed by the Service Provider(s) and 913 should not be subject to manipulation by attackers, it is of 914 significant value against accidental misconfiguration. 916 In addition, IPsec authentication can be configured between the VRs, 917 and between the CEs and VRs, so that a chain of authentication can be 918 established between CE senders across the PPVPN. With the use of 919 IPsec, the VR approach completely addresses the requirement across 920 the backbone in either a single- or multi-provider case. 922 c. In the Internet used as PPVPN backbone 924 The VR approach partially addresses the requirement of sender 925 authentication across the Internet through the use of IPsec and the 926 VPN-ID, as discussed in the previous response (10.b). 928 11. The approach provides integrity protection for PPVPN user data. 930 a. In the CE-PE link 931 b. In a single- or multi- provider PPVPN backbone 932 c. In the Internet used as PPVPN backbone 934 In each situation (11.a-c), the VR approach completely addresses the 935 requirement of integrity protection, through the optional use of 936 IPsec. Integrity checking is typically performed along with the 937 authentication protection discussed in item 10 above. The VR 938 approach does not provide additional integrity checking in its basic 939 form. 941 12. The approach provides protection against replay attacks for PPVPN 942 user data. 944 a. In the CE-PE link 945 b. In a single- or multi- provider PPVPN backbone 946 c. In the Internet used as PPVPN backbone 948 In each situation (12.a-c), the VR approach completely addresses the 949 requirement of protection against replay attacks, through the 950 optional use of IPsec with replay protection enabled. Replay attack 951 protection is accomplished by checking the sequence number in the 952 IPsec AH or ESP packet header, and is typically performed along with 953 the authentication protection discussed in item 10 above. The VR 954 approach does not provide additional replay attack protection in its 955 basic form. 957 13. The approach provides protection against unauthorized traffic 958 pattern analysis for PPVPN user data. 960 a. In the CE-PE link 962 The VR approach partially addresses the requirement of protection 963 against traffic pattern analysis through the optional use of IPsec on 964 the CE-PE link. Since IPsec-protected traffic on the CE-PE link only 965 reveals the amount of traffic between the CE and PE, and not the 966 ultimate destination of that traffic within the VPN, only limited 967 information on traffic patterns could be gained by analyzing any 968 particular CE-PE link. If an attacker is able to measure the traffic 969 on all CE-PE links of a VPN, then a fairly detailed traffic pattern 970 analysis could be performed. Where the CE-PE traffic is not 971 protected by IPsec in the VR approach, the traffic would be visible 972 to an attacker with access to the data stream, and the attacker could 973 derive a significant amount of traffic pattern analysis information. 974 However, note that it is unusual for an attacker to have access to 975 the data stream on any CE-PE link, unless the user taps the line or 976 compromises the CE or PE devices. In this case, traffic pattern 977 analysis may be a relatively minor concern compared to other concerns 978 of direct data interception. 980 b. In a single- or multi- provider PPVPN backbone 982 The VR approach partially addresses the requirement of protection 983 against traffic pattern analysis through the optional use of IPsec on 984 the backbone. This obscures the actual source and destination of 985 traffic, along with the traffic contents. Only the fact that data is 986 being transmitted between PEs or VRs can be detected through traffic 987 interception. If multiple CEs of a single VPN are connected to a 988 single VR, then an attacker analyzing the backbone traffic would not 989 be able to distinguish between traffic to or from the various CEs. 990 In addition, an attacker would need to obtain detailed information on 991 the internal configurations of the Service Provider's PE devices in 992 order to correlate captured backbone traffic with any particular VPN. 994 An optional extension to the VR approach completely addresses the 995 requirement of protection against traffic pattern analysis by using a 996 backbone virtual router in addition to using IPsec on the backbone. 997 Since the backbone VR links act to multiplex data of multiple VPNs, 998 and the IPsec obscures other information which could identify the VPN 999 source or destination, an attacker would face an almost 1000 insurmountable obstacle to reliable traffic pattern analysis based on 1001 capturing backbone traffic. 1003 c. In the Internet used as PPVPN backbone 1005 Similar to (13.c.) above for a provider-managed backbone, the VR 1006 approach provides either partial or complete protection, using IPsec 1007 and the backbone VR, over the Internet. Traffic interception may be 1008 a somewhat more likely problem on the Internet than on a SP backbone, 1009 but the VR approach provides a means of addressing the threat in 1010 either case. 1012 14. The control protocol(s) used for each of the following functions 1013 provide for message integrity and peer authentication: 1015 a. VPN membership discovery 1017 The VR approach can use several types of membership discovery, 1018 including BGP-based auto-discovery and configuration. When BGP-based 1019 auto-discovery is used, the VR approach completely addresses the 1020 requirement of providing control message integrity and peer 1021 authentication using the MD5 option. The protection of configuration 1022 mechanisms for VR approaches is outside the scope of the VR 1023 mechanism. VPN membership discovery using the VR approach provides 1024 integrated peer authentication through the use of the VPN-ID, which 1025 is common to all VRs within a single VPN. 1027 b. Tunnel establishment 1029 The VR approach does not specify a control protocol for tunnel 1030 establishment, but when IPsec tunnels are used, the VR approach 1031 completely addresses the requirement of providing message integrity 1032 and peer authentication. In addition, the use of the VPN-ID provides 1033 an integrated method of peer authentication among VRs within a single 1034 VPN. 1036 c. VPN topology and reachability advertisement 1037 i. PE-PE 1039 In the VR approach, VPN topology and reachability advertisement uses 1040 standard routing protocols between the VRs, carried within tunnels. 1041 These routing protocols can provide message integrity and peer 1042 authentication when the protocol supports it, as in MD5 options. In 1043 addition, when IPsec is used for the tunnels, it provides complete 1044 support for security for any routing protocol running between the VRs 1045 (between the PEs). 1047 ii. PE-CE 1049 The VR approach uses standard routing protocols between the VR (PE) 1050 and CE to provide VPN topology and reachability advertisement. The 1051 security features of routing protocols, such as MD5 options, can be 1052 applied, with or without IPsec. In addition, the VR-CE link can be 1053 protected with IPsec to provide complete support for securing the 1054 routing protocols. In the VR approach, some aspects of topology and 1055 reachability in the PE-CE relationship will be configured rather than 1056 exchanged dynamically. The security of configuration mechanisms is 1057 beyond the scope of the VR specification. 1059 d. VPN provisioning and management 1061 The VPN provisioning and management requirement is addressed in a way 1062 that is beyond the scope of the VR approach. Most parts of the VPN 1063 provisioning and management will be performed via configuration 1064 within the VR model, and thus there are no specific protocols defined 1065 within the VR VPN scheme for these functions. 1067 e. VPN monitoring and attack detection and reporting 1069 VPN monitoring and attack detection and reporting requirements are 1070 addressed in a way that is beyond the scope of the VR approach. Most 1071 parts of these functions will be performed via a variety of network 1072 management tools within the VR model, and thus there are no specific 1073 protocols defined within the VR VPN scheme for these functions. 1074 Since the VR approach is based on standard router functionality, the 1075 management technologies which have been developed in the industry for 1076 router security will be widely applicable for VR-based VPNs. 1078 f. Other VPN-specific control protocols, if any. 1080 Since the VR approach is based on standard router operations, there 1081 are no VPN-specific control protocols defined for the VR model. 1083 The following questions solicit free-form answers. 1085 15. Describe the protection, if any, the approach provides against 1086 PPVPN-specific DOS attacks (i.e. Inter-trusted-zone DOS attacks): 1088 a. Protection of the service provider infrastructure against Data 1089 Plane or Control Plane DOS attacks originated in a private 1090 (PPVPN user) network and aimed at PPVPN mechanisms. 1092 In the VR approach, the service provider-managed VRs typically appear 1093 to the PPVPN users to be a single router connecting all of the VPN 1094 sites. 1096 The VRs should be configured to allow only three types of traffic 1097 from the user VPN sites: 1098 - routing protocols 1099 - data packets destined for another site within the same VPN as the 1100 originating site 1101 - data packets with non-VPN destinations, if permitted by the Service 1102 Provider. 1104 This configuration serves to prevent most types of control plane 1105 attacks, since any type of direct connection from a VPN site to the 1106 VR's management functions using protocols such as SNMP, ftp, tftp, 1107 rlogin, rsh, etc., should be disallowed. The VR allows the same 1108 types of configurations as are common on physical routers to enforce 1109 this kind of configuration. 1111 A control plane attack might still be able to attempt to use the 1112 first type of traffic, while a data plane attack might use the latter 1113 two. These cases are discussed below. 1115 A control plane attack might consist of the CE device sending 1116 improper routing information to the VR. This could consist of 1117 unauthorized or malformed routes, rapid announcement and/or 1118 withdrawal of proper routes, or some combination of these. Since the 1119 VR has the same mechanisms as a physical router, the VR can use well- 1120 known routing security features to provide protection against this 1121 kind of attack, including route filters and route flap damping, or it 1122 could be configured with the allowable routes for the specific VPN 1123 site, and not accept routing updates from the site. The VPN 1124 mechanisms in the VR do not make it more susceptible to control plane 1125 attacks such as those based on routing protocols. 1127 A data plane attack on the VR would consist of a CE transmitting a 1128 large amount of traffic to the VR. Since the VR has all of the 1129 mechanisms of a physical router, it can be configured to handle the 1130 traffic using the same techniques as any Service Provider router. 1131 The VPN mechanisms in the VR do not make it more susceptible to DoS 1132 attacks based on traffic flooding. 1134 The VR architecture used in the PE devices provides for isolation of 1135 the operation of the VRs configured on it. Thus measures taken to 1136 defend against excessive traffic from one VPN site should not be able 1137 to affect the operation of other VRs in that PE, or elsewhere in the 1138 network. 1140 b. Protection of the service provider infrastructure against Data 1141 Plane or Control Plane DOS attacks originated in the Internet 1142 and aimed at PPVPN mechanisms. 1144 Both data plane and control plane DoS attacks which originate in the 1145 Internet can be prevented by overall design of Service Provider 1146 network, for instance by the use of filtering to block any packets 1147 destined to internal SP devices such as VRs. Internal SP devices may 1148 also be configured with private or non-routable addresses to help 1149 prevent access from the Internet. The VPN mechanisms in the VR do 1150 not make it more susceptible to DoS attacks from the Internet. Since 1151 VRs have the capabilities of physical routers, they can use the 1152 techniques available to Service Provider routers to provide various 1153 protective measures. 1155 c. Protection of PPVPN users against Data Plane or Control Plane 1156 DOS attacks originated from the Internet or from other PPVPN 1157 users and aimed at PPVPN mechanisms. 1159 The VR model completely supports protection of PPVPN users from 1160 either data plane or control plane DoS attacks directly from the 1161 Internet, unless Internet connectivity is specifically configured for 1162 an individual VPN. Since inter-VR links are tunneled, there is no 1163 opportunity for non-VPN traffic, such as Internet traffic, to be 1164 introduced into the VPN. 1166 If an individual VPN includes PPVPN-mediated Internet connectivity as 1167 a configured option, then the VR(s) providing the Internet access 1168 should be configured with appropriate firewall policies to protect 1169 against Dos (and other) attacks. 1171 The mechanisms discussed above in (15.a) and (15.b) for protection of 1172 the Service Provider infrastructure from VPN-based and Internet-based 1173 DoS attacks also serve to protect other VPNs from attacks from these 1174 sources. The VPN mechanisms used in the VR approach do not make it 1175 more susceptible to propagating DoS attacks among VPNs, since the 1176 basic VR architecture defines effective separation of all PE 1177 resources among the VRs. 1179 Attacks from one VPN site toward another VPN site in the same VPN are 1180 outside the scope of the VR approach, although the VR model makes it 1181 possible to configure firewall protections including internal attack 1182 protection at each VR if this service is desired. 1184 16. Describe the protection, if any, the approach provides against 1185 unstable or malicious operation of a PPVPN user network: 1187 a. Protection against high levels of, or malicious design of, 1188 routing traffic from PPVPN user networks to the service 1189 provider network. 1191 This is discussed in the response to (15.a) above. Since the VR has 1192 the same mechanisms as a physical router, the VR can use well-known 1193 routing security features to provide protection against this kind of 1194 attack, including route filters and route flap damping, or it could 1195 be configured with the allowable routes for the specific VPN site, 1196 and not accept routing updates from the site. 1198 b. Protection against high levels of, or malicious design of, 1199 network management traffic from PPVPN user networks to the 1200 service provider network. 1202 Since the VR approach imbues each VR with the capabilities of 1203 physical routers, including filtering and firewall functionality, the 1204 VRs should be configured by the Service Provider with appropriate 1205 filters to block network management traffic directed at any Service 1206 Provider system. Network management traffic from PPVPN users does 1207 not have any privileged access to the Service Provider network 1208 outside of the VR-VR tunnels, so they will be blocked by the same 1209 mechanisms which prevent this kind of attack from anywhere in the 1210 Internet. 1212 c. Protection against worms and probes originated in the PPVPN 1213 user networks, sent towards the service provider network. 1215 Similar to the filtering capabilities which the VR and use to block 1216 network management traffic, the VR can be configured to block any 1217 kind of traffic directed at any component of the service provider 1218 network. Since the traffic originating in PPVPN user networks is 1219 contained in tunnels after it is received at the VR serving any 1220 particular VPN site, the VR approach makes it fairly simple to 1221 prevent traffic originating in PPVPN user networks from being able to 1222 reach any Service Provider device. Worms or probes from PPVPN users 1223 do not have any privileged access to the Service Provider network 1224 outside of the VR-VR tunnels, so they will be blocked by the same 1225 mechanisms which prevent this kind of attack from anywhere in the 1226 Internet. 1228 17. Is the approach subject to any approach-specific vulnerabilities 1229 not specifically addressed by this template? If so describe the 1230 defense or mitigation, if any, the approach provides for each. 1232 The authors are not aware of any VR-specific vulnerabilities not 1233 addressed by this template. 1235 References 1237 Informative References 1239 [PPVPNVR] Ould-Brahim, H., et al., "Network based IP VPN 1240 Architecture using Virtual Routers", work in progress. 1241 [FRAMEWORK] R. Callon, et al., "A Framework for Layer 3 Provider 1242 Provisioned Virtual Private Networks," RFC 4410. 1243 [REQTS] McDysan, D., et al., "Service requirements for Layer 3 1244 Provider Provisioned Virtual Private Networks", RFC 4031. 1245 [SEC-FRMWK] Fang, L., et al., "Security Framework for Provider 1246 Provisioned Virtual Private Networks", RFC 4111. 1247 [RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 1248 2685, September 1999. 1249 [RADIUS-DIS] Heinanen J., "Using Radius for PE-Based VPN Discovery", 1250 work in progress. 1251 [VPN-BGP] Ould-Brahim, H., et al, "Using BGP as an Auto-Discovery 1252 Mechanism for Network-based VPNs", work in progress. 1253 [RFC1918] Rekhter, Y. et al., "Address Allocation for Private 1254 Internets," RFC 1918, February 1996. 1255 [RFC2547bis] Rosen E., et al, "BGP/MPLS VPNs", RFC 4364. 1256 [RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual 1257 Private Networks", RFC 2764, February 2000. 1258 [L3-VERIF] Bonica, R. et al., "CE-to-CE Member Verification for 1259 Layer 3 VPNs",work in progress. 1260 [VR-MIB] Seltzer, E et al., � Virtual Router Management Information 1261 Base Using SMIv2�, work in progress 1263 Acknowledgments 1265 The authors of this draft would like to acknowledge the suggestions 1266 and comments received from the entire Layer 3 Applicability Statement 1267 Design Team formed in the PPVPN working group. Besides the authors, 1268 the members of the design team include Marco Carugi, Eric Rosen, 1269 Jeremy De Clercq, Luyuan Fang, Dave McDysan, Cliff Wang, Olivier 1270 Paridaens, Tom Nadeau, Yakov Rekhter and Rick Wilder. Thanks are also 1271 due to the authors of [PPVPNVR], especially Hamid Ould-Brahim. Many 1272 thanks are due to the constructive comments made by Ross Callon and 1273 Mark Duffy. 1275 Author's Addresses 1277 Ananth Nagarajan 1278 Juniper Networks 1279 E-mail: ananth@juniper.net 1281 Muneyoshi Suzuki 1282 NTT Information Sharing Platform Labs. 1283 3-9-11, Midori-cho, 1284 Musashino-shi, Tokyo 180-8585, Japan 1285 Email: suzuki.muneyoshi@lab.ntt.co.jp 1287 Junichi Sumimoto 1288 NTT Communications Corporation 1289 3-20-2 Nishi-Shinjuku, 1290 Shinjuku-ku, Tokyo 163-1421, Japan 1291 E-mail: j.sumimoto@ntt.com 1293 Paul Knight 1294 Nortel Networks 1295 600 Technology Park Drive 1296 Billerica, MA 01821 1297 +1-978-288-6414 1298 E-mail: paul.knight@nortel.com 1300 Benson Schliesser 1301 SAVVIS Communications 1302 1 Savvis Parkway 1303 St. Louis, MO 63017 USA 1304 +1-877-203-1097 1305 Email: bensons@savvis.net 1306 Full Copyright Statement 1308 Copyright (C) The Internet Society (2006). All Rights Reserved. 1310 This document is subject to the rights, licenses and restrictions 1311 contained in BCP 78, and except as set forth therein, the authors 1312 retain all their rights. 1314 This document and the information contained herein are provided on an 1315 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1316 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1317 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1318 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1319 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1322 Acknowledgement: 1324 Funding for the RFC Editor function is currently provided by the 1325 Internet Society.