idnits 2.17.1 draft-ietf-l3vpn-requirements-00.txt: -(268): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1770): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1771): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2443): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2444): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2489): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 33 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2723 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 834 has weird spacing: '...sioning adm...' == Line 2485 has weird spacing: '...tecture usin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-2026' is mentioned on line 18, but not defined == Missing Reference: 'RFC-2119' is mentioned on line 66, but not defined == Missing Reference: 'RFC2547bis' is mentioned on line 210, but not defined ** Obsolete undefined reference: RFC 2547 (Obsoleted by RFC 4364) == Missing Reference: 'IPsec-PPVPN' is mentioned on line 211, but not defined == Missing Reference: 'RFC2661' is mentioned on line 376, but not defined == Missing Reference: 'RFC1777' is mentioned on line 535, but not defined ** Obsolete undefined reference: RFC 1777 (Obsoleted by RFC 3494) == Missing Reference: 'RFC2251' is mentioned on line 535, but not defined ** Obsolete undefined reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Missing Reference: 'RFC1918' is mentioned on line 626, but not defined == Missing Reference: 'RFC2385' is mentioned on line 1689, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Unused Reference: 'RFC 3377' is defined on line 2403, but no explicit reference was found in the text == Unused Reference: 'RFC 1918' is defined on line 2406, but no explicit reference was found in the text == Unused Reference: 'RFC 2026' is defined on line 2408, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 2410, but no explicit reference was found in the text == Unused Reference: 'RFC 2251' is defined on line 2426, but no explicit reference was found in the text == Unused Reference: 'RFC 2661' is defined on line 2433, but no explicit reference was found in the text == Unused Reference: 'RFC 2685' is defined on line 2435, but no explicit reference was found in the text == Unused Reference: 'RFC 2983' is defined on line 2437, but no explicit reference was found in the text == Unused Reference: 'RFC 3031' is defined on line 2439, but no explicit reference was found in the text == Unused Reference: 'RFC 3270' is defined on line 2443, but no explicit reference was found in the text == Unused Reference: '2547bis' is defined on line 2448, but no explicit reference was found in the text == Unused Reference: '2917bis' is defined on line 2450, but no explicit reference was found in the text == Unused Reference: 'L2 MPLS' is defined on line 2466, but no explicit reference was found in the text == Unused Reference: 'NBVPN-FR' is defined on line 2474, but no explicit reference was found in the text == Unused Reference: 'QPIM' is defined on line 2487, but no explicit reference was found in the text == Unused Reference: 'RFC 2547' is defined on line 2489, but no explicit reference was found in the text == Unused Reference: 'RFC 2975' is defined on line 2493, but no explicit reference was found in the text == Unused Reference: 'VPLS REQ' is defined on line 2497, but no explicit reference was found in the text == Unused Reference: 'VPN-VR' is defined on line 2514, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 10 errors (**), 0 flaws (~~), 34 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT M. Carugi 3 Internet Engineering Task Force Nortel Networks 4 Document: D. McDysan 5 draft-ietf-l3vpn-requirements-00.txt MCI 6 April 2003 (Co-Editors) 7 Category: Informational 8 Expires: October 2003 10 Service requirements for Layer 3 Provider Provisioned Virtual 11 Private Networks: 12 14 Status of this memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026 ([RFC-2026]). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This document is a product of the IETF's Provider Provisioned 36 Virtual Private Network (ppvpn) working group. Comments should be 37 addressed to WG's mailing list at ppvpn@ppvpn.francetelecom.com. The 38 charter for ppvpn may be found at 39 http://www.ietf.org/html.charters/ppvpn-charter.html 41 Copyright (C) The Internet Society (2000). All Rights Reserved. 42 Distribution of this memo is unlimited. 44 Abstract 46 This document provides requirements for Layer 3 Provider Provisioned 47 Virtual Private Networks (PPVPNs). It identifies requirements 48 applicable to a number of individual approaches that a Service 49 Provider may use for the provisioning of a VPN service. This 50 document expresses a service provider perspective, based upon past 51 experience of IP-based service offerings and the ever-evolving needs 52 of the customers of such services. Toward this end, it first defines 53 terminology and states general requirements. Detailed requirements 54 are expressed from a customer as well as a service provider 55 perspective. 56 Carugi et al 1 58 Service requirements for Layer 3 PPVPNs April, 2003 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 64 this document are to be interpreted as described in RFC 2119 ([RFC- 65 2119]). 67 Table of Contents 68 1 Introduction....................................................5 69 1.1 Scope of this document.........................................5 70 1.2 Outline........................................................5 71 2 Contributing Authors............................................6 72 3 Definitions.....................................................6 73 3.1 Virtual Private Network Components.............................6 74 3.2 Users, Sites, Customers and Agents.............................6 75 3.3 Intranets, Extranets, and VPNs 7 76 3.4 Networks of Customer and Provider Devices......................7 77 3.5 Access Networks, Tunnels, and Hierarchical Tunnels.............8 78 3.6 Use of Tunnels and roles of CE and PE in L3 PPVPNs.............8 79 3.6.1 PE-Based Layer 3 PPVPNs and Virtual Forwarding Instances..8 80 3.6.2 CE-Based PPVPN Tunnel Endpoints and Functions............10 81 3.7 Customer and Provider Network Management......................10 82 4 Service Requirements Common to Customers and Service Providers.11 83 4.1 Traffic Types.................................................11 84 4.2 Topology......................................................11 85 4.3 Isolated Exchange of Data and Routing Information.............11 86 4.4 Security......................................................12 87 4.4.1 User data security.......................................12 88 4.4.2 Access control...........................................12 89 4.4.3 Site authentication and authorization....................12 90 4.5 Addressing....................................................12 91 4.6 Quality of Service............................................13 92 4.6.1 QoS Standards............................................13 93 4.6.2 Service Models...........................................14 94 4.7 Service Level Specification and Agreements....................15 95 4.8 Management....................................................16 96 4.9 Interoperability..............................................16 97 4.10 Interworking..................................................17 98 5 Customer Requirements..........................................17 99 5.1 VPN Membership (Intranet/Extranet)............................17 100 5.2 Service Provider Independence.................................17 101 5.3 Addressing....................................................17 102 5.4 Routing Protocol Support......................................18 103 5.5 Quality of Service and Traffic Parameters.....................18 104 5.5.1 Application Level QoS Objectives.........................18 105 5.5.2 DSCP Transparency........................................18 106 5.6 Service Level Specification/Agreement.........................19 107 5.7 Customer Management of a VPN..................................19 108 5.8 Isolation.....................................................19 109 5.9 Security......................................................19 110 5.10 Migration Impact..............................................20 112 Carugi et al Informational - Expires October 2003 2 114 Service requirements for Layer 3 PPVPNs April, 2003 116 5.11 Network Access................................................20 117 5.11.1 Physical/Link Layer Technology...........................20 118 5.11.2 Temporary Access.........................................21 119 5.11.3 Sharing of the Access Network............................21 120 5.11.4 Access Connectivity......................................21 121 5.12 Service Access................................................23 122 5.12.1 Internet Access..........................................23 123 5.12.2 Hosting, Application Service Provider....................23 124 5.12.3 Other Services...........................................24 125 5.13 Hybrid VPN Service Scenarios..................................24 126 6 Service Provider Network Requirements..........................24 127 6.1 Scalability...................................................24 128 6.1.1 Service Provider Capacity Sizing Projections.............24 129 6.1.2 Solution-Specific Metrics................................25 130 6.2 Addressing....................................................26 131 6.3 Identifiers...................................................26 132 6.4 Discovering VPN Related Information...........................27 133 6.5 SLA and SLS Support...........................................27 134 6.6 Quality of Service (QoS) and Traffic Engineering..............28 135 6.7 Routing.......................................................28 136 6.8 Isolation of Traffic and Routing..............................29 137 6.9 Security......................................................29 138 6.9.1 Support for Securing Customer Flows......................29 139 6.9.2 Authentication Services..................................30 140 6.9.3 Resource Protection......................................30 141 6.10 Inter-AS (SP)VPNs.............................................31 142 6.10.1 Routing Protocols........................................31 143 6.10.2 Management...............................................32 144 6.10.3 Bandwidth and QoS Brokering..............................32 145 6.10.4 Security Considerations..................................32 146 6.11 PPVPN Wholesale...............................................33 147 6.12 Tunneling Requirements........................................33 148 6.13 Support for Access and Backbone Technologies..................34 149 6.13.1 Dedicated Access Networks................................34 150 6.13.2 On-Demand Access Networks................................34 151 6.13.3 Backbone Networks........................................34 152 6.14 Protection, Restoration.......................................35 153 6.15 Interoperability..............................................35 154 6.16 Migration Support.............................................36 155 7 Service Provider Management Requirements.......................36 156 7.1 Fault management..............................................36 157 7.2 Configuration Management......................................37 158 7.2.1 Configuration Management for PE-Based VPNs...............38 159 7.2.2 Configuration management for CE-based VPN................38 160 7.2.3 Provisioning Routing.....................................39 161 7.2.4 Provisioning Network Access..............................39 162 7.2.5 Provisioning Security Services...........................39 163 7.2.6 Provisioning VPN Resource Parameters.....................39 164 7.2.7 Provisioning Value-Added Service Access..................39 165 7.2.8 Provisioning Hybrid VPN Services.........................41 166 7.3 Accounting....................................................41 167 7.4 Performance Management........................................41 169 Carugi et al Informational - Expires October 2003 3 171 Service requirements for Layer 3 PPVPNs April, 2003 173 7.4.1 Performance Monitoring...................................41 174 7.4.2 SLA and QoS management features..........................42 175 7.5 Security Management...........................................42 176 7.5.1 Management Access Control................................42 177 7.5.2 Authentication...........................................42 178 7.6 Network Management Techniques.................................43 179 8 Security Considerations........................................43 180 9 Acknowledgements...............................................44 181 10 References.....................................................44 182 10.1 Normative References..........................................44 183 10.2 Non-normative References......................................45 184 11 Authors' address...............................................46 186 Carugi et al Informational - Expires October 2003 4 188 Service requirements for Layer 3 PPVPNs April, 2003 190 1 Introduction 191 This section describes the scope and outline of the document. 193 1.1 Scope of this document 194 This document provides requirements specific to Layer 3 Provider 195 Provisioned Virtual Private Networks (PPVPN). Requirements that are 196 generic to L2 and L3 VPNs are contained in [PPVPN-GR]. It identifies 197 requirements that may apply to one or more individual approaches 198 that a Service Provider may use for the provisioning of a Layer 3 199 (e.g., IP) VPN service. The content of this document makes use of 200 the terminologies and common components for deploying Layer 3 PPVPNs 201 defined in [PPVPN-FR]. 203 The specification of any technical means to provide PPVPN services 204 is outside the scope of this document. Other documents, such as the 205 framework document [PPVPN-FR] and several sets of documents, one set 206 per each individual technical approach providing PPVPN services, are 207 intended to cover this aspect. 209 This document describes requirements for two types of network-based 210 L3 PPVPNs: aggregated routing VPNs [RFC2547bis] and virtual routers 211 [PPVPN-VR] and one type of CE-based PPVPN [IPsec-PPVPN]. The 212 approach followed in this document distinguishes PPVPN types as to 213 where the endpoints of tunnels exist as detailed in the PPVPN 214 framework document [PPVPN-FR]. Terminology regarding whether 215 equipment faces a customer or the service provider network is used 216 to define the various types of PPVPN solutions. 218 This document is intended as a "checklist" of requirements that will 219 provide a consistent way to evaluate and document how well each 220 individual approach satisfies specific requirements. The 221 applicability statement documents for each individual approach 222 should document the results of this evaluation. 224 This document provides requirements from several points of view. It 225 begins with common customer and service provider point of view, 226 followed by a customer perspective, and concludes with specific 227 needs of a Service Provider (SP). These requirements provide high- 228 level PPVPN features expected by an SP in provisioning PPVPN to make 229 them beneficial to his or her customers. These general requirements 230 include SP requirements for security, privacy, manageability, 231 interoperability and scalability, including service provider 232 projections for number, complexity, and rate of change of customer 233 VPNs over the next several years. 235 1.2 Outline 236 The outline of the rest of this document is as follows. Section 2 237 defines terminology. Section 3 provides common requirements that 238 apply to both customer and service providers. Section 4 states 239 requirements from a customer perspective. Section 5 states network 240 requirements from a service provider perspective. Section 6 states 242 Carugi et al Informational - Expires October 2003 5 244 Service requirements for Layer 3 PPVPNs April, 2003 246 service provider management requirements. Section 7 describes 247 security considerations. Section 8 lists acknowledgements. Section 9 248 provides a list of references cited herein. Section 10 lists the 249 author�s addresses. 251 2 Contributing Authors 252 This document was the combined effort of the editors and the 253 following authors who contributed to this document: 254 Luyuan Fang 255 Ananth Nagarajan 256 Junichi Sumimoto 257 Rick Wilder 259 3 Definitions 260 This section provides the definition of terms and concepts used 261 throughout the document. 262 [Editor's Note: this section may be moved to another PPVPN RFC that 263 defines terminology.] 265 3.1 Virtual Private Network Components 266 This document uses the word �private� in VPN in the sense of 267 ownership, which is different from the use of the similar word 268 �privacy� used in discussions regarding security. The term �virtual 269 private� means that the offered service retains at least some 270 aspects of a privately owned customer network. 272 The term "Virtual Private Network" (VPN) refers to the communication 273 between a set of sites, making use of a shared network 274 infrastructure. Multiple sites of a private network may therefore 275 communicate via the public infrastructure, in order to facilitate 276 the operation of the private network. The logical structure of the 277 VPN, such as topology, addressing, connectivity, reachability, and 278 access control, is equivalent to part of or all of a conventional 279 private network using private facilities. 281 The term �Provider Provisioned VPN� refers to VPNs for which the 282 service provider participates in management and provisioning of the 283 VPN. 285 3.2 Users, Sites, Customers and Agents 286 User: A user is an entity (e.g., a human being using a host, a 287 server, or a system) that has been authorized to use a VPN service. 289 Site: A site is a set of users that have mutual IP reachability 290 without use of a specific service provider network. A site may 291 consist of a set of users that are in geographic proximity. 292 However, two geographic locations connected via another provider's 293 network would also constitute a single site since communication 294 between the two locations does not involve the use of the service 295 provider offering the VPN service. 297 Carugi et al Informational - Expires October 2003 6 299 Service requirements for Layer 3 PPVPNs April, 2003 301 Customer: A single organization, corporation, or enterprise that 302 administratively controls a set of sites. 304 Agent: A set of users designated by a customer who has the 305 authorization to manage a customer's VPN service offering. 307 3.3 Intranets, Extranets, and VPNs 309 Intranet: An intranet restricts communication to a set of sites that 310 belong to one customer. An example is branch offices at different 311 sites that require communication to a headquarters site. 313 Extranet: An extranet allows the specification of communication 314 between a set of sites that belong to different customers. In other 315 words, two or more organizations have access to a specified set of 316 each other's sites. Examples of an extranet scenario include 317 multiple companies cooperating in joint software development, a 318 service provider having access to information from the vendors' 319 corporate sites, different companies, or universities participating 320 in a consortium. An extranet often has further restrictions on 321 reachability, for example, at the host and individual transport 322 level. 324 Note that an intranet or extranet can exist across a single service 325 provider network or across multiple service providers. 327 Virtual Private Network (VPN): The term VPN is used within this 328 document to refer to a specific set of sites as either an intranet 329 or an extranet that have been configured to allow communication. 330 Note that a site is a member of at least one VPN, and may be a 331 member of many VPNs. 333 3.4 Networks of Customer and Provider Devices 334 PPVPNs are composed of the following types of devices. 336 Customer Edge (CE) device: A CE device faces the users at a customer 337 site. The CE has an access connection to a PE device. It may be a 338 router or a switch that allows users at a customer site to 339 communicate over the access network with other sites in the VPN. In 340 a CE-based PPVPN, the service provider manages (at least partially) 341 the CE device. 343 Provider Edge (PE) device: A PE device faces the provider network on 344 one side and attaches via an access connection over one or more 345 access networks to one or more CE devices. It may be a router or a 346 label switching-router. 348 Note that the definitions of Customer Edge and Provider Edge do not 349 necessarily map to the physical deployment of equipment on customer 350 premises or a provider point of presence. 352 Carugi et al Informational - Expires October 2003 7 354 Service requirements for Layer 3 PPVPNs April, 2003 356 Provider (P) device: A device within a provider network that 357 interconnects PE devices, but does not have any direct attachment to 358 CE. 360 Service Provider (SP) network: An SP network is a set of 361 interconnected PE and P devices administered by a single service 362 provider. 364 3.5 Access Networks, Tunnels, and Hierarchical Tunnels 365 VPNs are built between CEs using access networks, tunnels, and 366 hierarchical tunnels. 368 Access connection: An access connection provides connectivity 369 between a CE and a PE. This includes dedicated physical circuits, 370 virtual circuits, such as frame Relay or ATM, Ethernet, or IP 371 tunnels (e.g., IPsec, L2TP). 373 Access network: An access network provides access connections 374 between CE and PE devices. It may be a TDM network, L2 network 375 (e.g. FR, ATM, and Ethernet), or an IP network over which access is 376 tunneled (e.g., using L2TP [RFC2661]). 378 Tunnel: A tunnel between two entities is formed by encapsulating 379 packets within another encapsulating header for purpose of 380 transmission between those two entities in support of a VPN 381 application. Examples of protocols commonly used for tunneling are: 382 GRE, IPsec, IP-in-IP tunnels, and MPLS. 384 Hierarchical Tunnel: Encapsulating one tunnel within another forms a 385 hierarchical tunnel. The innermost tunnel protocol header defines a 386 logical association between two entities (e.g., between CEs or PEs) 387 [VPN TUNNEL]. Note that the tunneling protocols need not be the same 388 at different levels in a hierarchical tunnel. 390 3.6 Use of Tunnels and roles of CE and PE in L3 PPVPNs 391 This section summarizes the point where tunnels terminate and the 392 functions implemented in the CE and PE devices that differentiate 393 the two major categories of PPVPNs for which requirements are 394 stated, namely PE-based and CE-based PPVPNs. See the PPVPN framework 395 document for more detail [PPVPN-FR]. 397 3.6.1 PE-Based Layer 3 PPVPNs and Virtual Forwarding Instances 398 In a PE-based layer 3 PPVPN service, a customer site receives IP 399 layer (i.e., layer 3) service from the SP. The PE is attached via an 400 access connection to one or more CEs. The PE performs forwarding of 401 user data packets based on information in the IP layer header, such 402 as an IPv4 or IPv6 destination address. The CE sees the PE as a 403 layer 3 device such as an IPv4 or IPv6 router. 405 Virtual Forwarding Instance (VFI): In a PE-based layer 3 VPN 406 service, the PE contains a VFI for each L3 VPN that it serves. The 407 VFI terminates tunnels for interconnection with other VFIs and also 409 Carugi et al Informational - Expires October 2003 8 411 Service requirements for Layer 3 PPVPNs April, 2003 413 terminates access connections for accommodating CEs. VFI contains 414 information regarding how to forward data received over the access 415 connection to the CE to VFIs in other PEs supporting the same L3 416 VPN. The VFI includes the router information base and forwarding 417 information base for a L3 VPN [PPVPN-FR]. A VFI enables router 418 functions dedicated to serving a particular VPN, such as separation 419 of forwarding and routing and support for overlapping address 420 spaces. Routing protocols in the PEs and the CEs interact to 421 populate the VFI. 423 The following narrative and figures provide further explanation of 424 the way PE devices use tunnels and hierarchical tunnels. Figure 3.1 425 illustrates the case where a PE uses a separate tunnel for each VPN. 426 As shown in the figure, the tunnels provide communication between 427 the virtual switching/forwarding instances in each of the PE 428 devices. 430 +----------+ +----------+ 431 +-----+ |PE device | |PE device | +-----+ 432 | CE | | | | | | CE | 433 | dev | Access | +------+ | | +------+ | Access | dev | 434 | of | conn. | |VFI of| | Tunnel | |VFI of| | conn. | of | 435 |VPN A|----------|VPN A |==================|VPN A |----------|VPN A| 436 +-----+ | +------+ | | +------+ | +-----+ 437 | | | | 438 +-----+ Access | +------+ | | +------+ | Access +-----+ 439 |CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE | 440 | dev |----------|VPN B |==================|VPN B |----------| dev | 441 | of | | +------+ | | +------+ | | of | 442 |VPN B| | | | | |VPN B| 443 +-----+ +----------+ +----------+ +-----+ 444 Figure 3.1 PE Usage of Separate Tunnels to Support VPNs 446 Figure 3.2 illustrates the case where a single hierarchical tunnel 447 is used between PE devices to support communication for VPNs. The 448 innermost encapsulating protocol header provides the means for the 449 PE to determine the VPN for which the packet is directed. 450 +----------+ +----------+ 451 +-----+ |PE device | |PE device | +-----+ 452 | CE | | | | | | CE | 453 | dev | Access | +------+ | | +------+ | Access | dev | 454 | of | conn. | |VFI of| | | |VFI of| | conn. | of | 455 |VPN A|----------|VPN A | | Hierarchical |VPN A |----------|VPN A| 456 +-----+ | +------+\| Tunnel | +------+ | +-----+ 457 | >==================< | 458 +-----+ Access | +------+/| |\+------+ | Access +-----+ 459 | CE | conn. | |VFI of| | | |VFI of| | conn. | CE | 460 | dev |----------|VPN B | | | |VPN B |----------| dev | 461 | of | | +------+ | | +------+ | | of | 462 |VPN B| | | | | |VPN B| 463 +-----+ +----------+ +----------+ +-----+ 464 Figure 3.2 PE Usage of a Shared Hierarchical Tunnels to Support VPNs 466 Carugi et al Informational - Expires October 2003 9 468 Service requirements for Layer 3 PPVPNs April, 2003 470 3.6.2 CE-Based PPVPN Tunnel Endpoints and Functions 471 Figure 3.3 illustrates the CE-based L3 VPN reference model. In this 472 configuration, typically a single level of tunnel (e.g., IPsec) 473 terminates at pairs of CEs. Usually, a CE serves a single customer 474 site and therefore the forwarding and routing is physically separate 475 from all other customers. Furthermore, the PE is not aware of the 476 membership of specific CE devices to a particular VPN. Hence, the 477 VPN functions are implemented using provisioned configurations on 478 the CE devices and the shared PE and P network is used to only 479 provide the routing and forwarding that supports the tunnel 480 endpoints on between CE devices. The tunnel topology connecting the 481 CE devices may be a full or partial mesh, depending upon VPN 482 customer requirements and traffic patterns. 484 +---------+ +--------------------------------+ +---------+ 485 | | | | | | 486 | | | +------+ +------+ : +------+ 487 +------+ : | | | | | | : | CE | 488 | CE | : | | | P | | PE | : |device| 489 |device| : +------+ Tunnel |router| |device| : | of | 490 | of |=:================================================:=|VPN A| 491 |VPN A| : | | +------+ +------+ : +------+ 492 +------+ : | PE | | | : | 493 +------+ : |device| | | : | 494 | CE | : | | Tunnel +------+ : +------+ 495 |device|=:================================================:=| CE | 496 | of | : +------+ | PE | : |device| 497 |VPN B| : | | |device| : | of | 498 +------+ : | | +----------+ +----------+ | | : |VPN B| 499 | : | | | Customer | | Network | +------+ : +------+ 500 |Customer | | |management| |management| | | : | 501 |interface| | | function | | function | | |Customer | 502 | | | +----------+ +----------+ | |interface| 503 | | | | | | 504 +---------+ +--------------------------------+ +---------+ 505 | Access | |<-------- SP network(s) ------->| | Access | 506 | network | | | | network | 508 Figure 3.3 Provider Provisioned CE-based L3 VPN 510 3.7 Customer and Provider Network Management 511 Customer Network Management Function: A Customer network management 512 function provides the means for a customer agent to query or 513 configure customer specific information, or receive alarms regarding 514 his or her VPN. Customer specific information includes data related 515 to contact, billing, site, access network, IP address, routing 516 protocol parameters, etc. It may also include confidential data, 517 such as encryption keys. It may use a combination of proprietary 518 network management system, SNMP manager, or directory service (e.g., 519 LDAP [RFC1777] [RFC2251]). 521 Carugi et al Informational - Expires October 2003 10 523 Service requirements for Layer 3 PPVPNs April, 2003 525 Provider Network Management Function: A provider network management 526 function provides many of the same capabilities as a customer 527 network management system across all customers. This would not 528 include customer confidential information, such as keying material. 529 The intent of giving the provider a view comparable to that of 530 customer network management is to aid in troubleshooting and problem 531 resolution. Such a system also provides the means to query, 532 configure, or receive alarms regarding any infrastructure supporting 533 the PPVPN service. It may use a combination of proprietary network 534 management system, SNMP manager, or directory service (e.g., LDAP 535 [RFC1777] [RFC2251]). 537 4 Service Requirements Common to Customers and Service Providers 538 This section contains requirements that apply to both the customer 539 and the provider, or are of an otherwise general nature. 540 [Editor's Note: Some of the material in this section is generic to 541 L2 and L3 VPNs and may be deleted if the draft proposed for [PPVPN- 542 GR] is accepted.] 544 4.1 Traffic Types 545 PPVPN services must support unicast traffic and should support 546 multicast traffic. It is highly desirable to support L3 multicast 547 limited in scope to an intranet or extranet. The solution should be 548 able to support a large number of such intranet or extranet specific 549 multicast groups in a scalable manner. 551 4.2 Topology 552 A PPVPN should support arbitrary, customer agent defined inter-site 553 connectivity, ranging, for example, from hub-and-spoke, partial mesh 554 to full mesh topology. To the extent possible, a PPVPN service 555 should be independent of the geographic extent of the deployment. 557 A PPVPN should support multiple VPNs per customer site. 559 To the extent possible, the PPVPN services should be independent of 560 access network technology. 562 4.3 Isolated Exchange of Data and Routing Information 563 A mechanism for isolating the distribution of reachability 564 information to only those sites associated with a VPN must be 565 provided. 567 PPVPN solutions shall define means that prevent routers in a VPN 568 from interaction with unauthorized entities and avoid introducing 569 undesired routing information that could corrupt the VPN 570 routing information base [VPN-CRIT]. 572 A means to constrain, or isolate, the distribution of addressed data 573 to only those VPN sites determined either by routing data and/or 574 configuration must be provided. 576 Carugi et al Informational - Expires October 2003 11 578 Service requirements for Layer 3 PPVPNs April, 2003 580 A single site shall be capable of being in multiple VPNs. The VPN 581 solution must ensure that traffic is exchanged only with those sites 582 that are in the same VPN. 584 The internal structure of a VPN should not be advertised nor 585 discoverable from outside that VPN. 587 Note that isolation of forwarded data and/or exchange of 588 reachability information to only those sites that are part of a VPN 589 may be viewed as a form of security, for example, [Y.1311.1],[MPLS 590 SEC]. 592 4.4 Security 593 A range of security features should be supported by the suite of 594 PPVPN solutions [VPN SEC]. Each PPVPN solution should state which 595 security features it supports and how such features can be 596 configured on a per customer basis. 598 4.4.1 User data security 599 PPVPN solutions that support user data security should use standard 600 methods (e.g., IPsec) to achieve confidentiality, integrity, 601 authentication and replay attack prevention. 603 4.4.2 Access control 604 A PPVPN solution may also have the ability to activate the 605 appropriate filtering capabilities upon request of a customer [VPN- 606 NEEDS]. A filter provides a mechanism so that access control can be 607 invoked at the point(s) of communication between different 608 organizations involved in an extranet. Access control can be 609 implemented by a firewall, access control lists on routers or 610 similar mechanisms to apply policy-based access control to transit 611 traffic. 613 4.4.3 Site authentication and authorization 615 A L3 VPN solution requires authentication and authorization of the 616 following: 617 - temporary and permanent access for users connecting to sites 618 (authentication and authorization BY the site) 619 - the site itself (authentication and authorization FOR the site) 621 4.5 Addressing 622 A service provider shall accept unique IP addresses obtained by a 623 customer or be capable of providing unique IP addresses to a 624 customer. In the event that IP addresses are not unique, an L3 VPN 625 service shall support overlapping customer addresses, for example 626 non-unique private IP addresses [RFC1918]. 628 IP addresses must be unique within the set of sites reachable from 629 the VPNs of which a particular site is a member. 631 Carugi et al Informational - Expires October 2003 12 633 Service requirements for Layer 3 PPVPNs April, 2003 635 A VPN solution must support IPv4 and IPv6 as both the encapsulating 636 and encapsulated protocol. 638 A VPN service should be capable of translating customer private IP 639 addresses for communicating with IP systems having public addresses. 641 FR and ATM link layer identifiers (i.e., DLCI and VPI/VCI) shall be 642 unique only on a physical interface basis. 644 Normally, Ethernet MAC addresses on access connections are globally 645 unique. 647 4.6 Quality of Service 648 To the extent possible, L3 VPN QoS should be independent of the 649 access network technology. 651 4.6.1 QoS Standards 652 According to the PPVPN charter, a non-goal is the development of new 653 protocols or extension of existing ones. Therefore, with regards to 654 QoS support, a PPPVN shall be able to support QoS in one or more of 655 the following already standardized modes: 656 - Best Effort (support mandatory for all PPVPN types) 657 - Aggregate CE Interface Level QoS (i.e., �hose� level) 658 - Site-to-site, or �pipe� level QoS 659 - Intserv (i.e., RSVP) signaled 660 - Diffserv marked 661 - Across packet-switched access networks 663 Note that all cases involving QoS may require that the CE and/or PE 664 perform shaping and/or policing. 666 PPVPN CE should be capable of supporting integrated services 667 (Intserv) for certain customers in support of session applications, 668 such as switched voice or video. Intserv-capable CE devices shall 669 support the following Internet standards: 670 - Resource reSerVation Protocol (RSVP) [RFC 2205] 671 - Guaranteed Quality of Service providing a strict delay bound 672 [RFC 2212] 673 -Controlled Load Service providing performance equivalent to that 674 of an unloaded network [RFC 2211] 676 PPVPN CE and PE should be capable of supporting differentiated 677 service (diffserv). In diffserv Per Hop Behavior PHB - a description 678 of the externally observable forwarding behavior of a DS node 679 applied to a particular DS behavior aggregate [RFC 2475]. Diffserv- 680 capable PPVPN CE and PE shall support the following per hop behavior 681 (PHB) types: 682 - Expedited Forwarding (EF) - the departure rate of an aggregate 683 class of traffic from a router that must equal or exceed a 684 configured rate [RFC 3246]. 685 - Assured Forwarding (AF) - is a means for a provider DS domain to 686 offer different levels of forwarding assurances for IP packets 688 Carugi et al Informational - Expires October 2003 13 690 Service requirements for Layer 3 PPVPNs April, 2003 692 received from a customer DS domain. Four AF classes are defined, 693 where each AF class is in each DS node allocated a certain amount of 694 forwarding resources (e.g., buffer space and bandwidth) [RFC 2597]. 696 A customer, CE, or PE device supporting a L3 VPN service may 697 classify a packet for a particular Intserv or Diffserv service based 698 on upon one or more of the following IP header fields: protocol ID, 699 source port number, destination port number, destination address, or 700 source address. 702 For a specifiable set of Internet traffic, L3 PPVPN devices should 703 support Random Early Detection (RED) to provide graceful degradation 704 in the event of network congestion. 706 The need to provide QoS will occur primarily in the access network, 707 since that will often be the bottleneck. This is likely to occur 708 since the backbone effectively statistically multiplexes many users, 709 is traffic engineered, and in some cases also includes capacity for 710 restoration and growth. There are two directions of QoS management 711 that must be considered in any PPVPN service regarding QoS: 712 - From the CE across the access network to the PE 713 - From the PE across the access network to CE 715 PPVPN CE and PE devices should be capable of supporting QoS across a 716 subset of the access networks defined in section 5.11, such as: 717 - ATM Virtual Connections (VCs) 718 - Frame Relay Data Link Connection Identifiers (DLCIs) 719 - 802.1d Prioritized Ethernet 720 - MPLS-based access 721 - Multilink Multiclass PPP 722 - QoS-enabled wireless (e.g., LMDS, MMDS) 723 - Cable modem [DOCSIS 1.1] 724 - QoS-enabled Digital Subscriber Line (DSL) 726 4.6.2 Service Models 727 A service provider must be able to offer QoS service to a customer 728 for at least the following generic service types: managed access VPN 729 service or an edge-to-edge QoS service. 731 A managed access L3 PPVPN service provides QoS on the access 732 connection between the CE and the PE. For example, diffserv would be 733 enabled only on the CE router and the customer-facing ports of the 734 PE router. Note that this service would not require implementation 735 of DiffServ in the SP IP backbone. The SP may use policing for 736 inbound traffic at the PE. The CE may perform shaping for outbound 737 traffic. Another example of a managed access L3 VPN service is where 738 the SP performs the packet classification and diffserv marking. An 739 SP may provide several packet classification profiles that customers 740 may select, or may offer a service that offers custom profiles based 741 upon customer specific requirements. In general, more complex QoS 742 policies should be left to the customer for implementation. 744 Carugi et al Informational - Expires October 2003 14 746 Service requirements for Layer 3 PPVPNs April, 2003 748 An edge-to-edge QoS VPN service provides QoS from provider edge to 749 provider edge. The provider edge may be either PE or CE depending 750 upon the service demarcation point between the provider and the 751 customer. Such a service may be provided across one or more provider 752 backbones. The CE requirements for this service model are the same 753 as the managed access VPN service. However, in this service QoS is 754 provided from one edge of the SP network(s) to the other edge. 756 4.7 Service Level Specification and Agreements 757 A Service Level Specification (SLS) may be defined per access 758 network connection, per VPN, per VPN site, and/or per VPN route. The 759 service provider may define objectives and the measurement interval 760 for at least the SLS using the following Service Level Objective 761 (SLO) parameters: 763 O QoS and traffic parameters for the Intserv flow or Diffserv class 764 O Availability for the site, VPN, or access connection 765 O Duration of outage intervals per site, route or VPN 766 O Service activation interval (e.g., time to turn up a new site) 767 O Trouble report response time interval 768 O Time to repair interval 769 O Total traffic offered to the site, route or VPN 770 O Measure of non-conforming traffic for the site, route or VPN 772 The above list contains items from [Y.1241], as well as other items 773 typically part of SLAs for currently deployed VPN services [FRF.13]. 774 See RFC 3198 for generic definitions of SLS, SLA, and SLO. 776 The provider network management system shall measure, and report as 777 necessary, whether measured performance meets or fails to meet the 778 above SLS objectives. 780 The service provider and the customer may negotiate a contractual 781 arrangement that includes a Service Level Agreement (SLA) regarding 782 compensation if the provider does not meet an SLS performance 783 objective. Details of such compensation are outside the scope of 784 this document. 786 SLS measurements for quality based on the DiffServ scheme should be 787 based upon the following classification [Y.1311.1]: 789 A Point-to-Point SLS, sometimes also referred to as the "Pipe" 790 model, defines traffic parameters in conjunction with the QoS 791 objectives for traffic exchanged between a pair of VPN sites (i.e., 792 points). A Point-to-Point SLS is analogous to the SLS typically 793 supported over point-to-point Frame Relay or ATM PVCs or an edge- 794 to-edge MPLS tunnel. The set of SLS specifications to all other 795 reachable VPN sites would define the overall Point-to-Point SLS for 796 a specific site. 798 A Point-to-Cloud SLS, sometimes also referred as the "Hose" model, 799 defines traffic parameters in conjunction with the QoS objectives 801 Carugi et al Informational - Expires October 2003 15 803 Service requirements for Layer 3 PPVPNs April, 2003 805 for traffic exchanged between a CE and a PE for traffic destined to 806 a set (either all or a subset) of other sites in the VPN (i.e., the 807 cloud), as applicable. In other words, a point-to-cloud SLS defines 808 compliance in terms of all packets transmitted from a given VPN 809 site toward the SP network on an aggregate basis (i.e., regardless 810 of the destination VPN site of each packet). 812 A Cloud-to-Point SLS, is the case where flows originating from 813 multiple sources may congest the interface from the network toward 814 a specific site, which this SLS does not cover. 816 Traffic parameters and actions should be defined for packets to and 817 from the demarcation between the service provider and the site. For 818 example, policing may be defined on ingress and shaping on egress. 820 4.8 Management 821 An SP and its customers must be able to manage the capabilities and 822 characteristics of their VPN services. To the extent possible, 823 automated operations and interoperability with standard management 824 platforms should be supported. 826 The ITU-T Telecommunications Management Network (TMN) model has the 827 following generic requirements structure: 828 O Engineer, deploy and manage the switching, routing and 829 transmission resources supporting the service, from a network 830 perspective (network element management); 831 O Manage the VPNs deployed over these resources (network 832 management); 833 o Manage the VPN service (service management); 834 o Manage the VPN business, mainly provisioning administrative 835 and accounting information related to the VPN service customers 836 (business management). 838 Service management should include the TMN 'FCAPS' functionalities, 839 as follows: Fault, Configuration, Accounting, Provisioning, and 840 Security, as detailed in section 7. 842 4.9 Interoperability 843 Each technical solution should support the Internet standards (in 844 terms of compatibility and modularity). 846 Multi-vendor interoperability at network element, network and 847 service levels among different implementations of the same technical 848 solution should be guaranteed (that will likely rely on the 849 completeness of the corresponding standard). This is a central 850 requirement for SPs and customers. 852 The technical solution must be multi-vendor interoperable not only 853 within the SP network infrastructure, but also with the customer's 854 network equipment and services making usage of the PPVPN service. 856 Carugi et al Informational - Expires October 2003 16 858 Service requirements for Layer 3 PPVPNs April, 2003 860 4.10 Interworking 861 Interworking scenarios among different solutions providing PPVPN 862 services is highly desirable. See the PPVPN framework document for 863 more details on interworking scenarios [PPVPN-FR]. Interworking 864 should be supported in a scalable manner. 866 Interworking scenarios must consider at least traffic and routing 867 isolation, security, QoS, access, and management aspects. This 868 requirement is essential in the case of network migration, to ensure 869 service continuity among sites belonging to different portions of 870 the network. 872 5 Customer Requirements 873 This section captures additional requirements from a customer 874 perspective. 876 5.1 VPN Membership (Intranet/Extranet) 877 When an extranet is formed, a customer agent from each of the 878 organizations must approve addition of a site to an extranet VPN. 879 The intent of this requirement is to ensure that both organizations 880 approve extranet communication before the PPVPN allows exchange of 881 traffic and routing information. 883 5.2 Service Provider Independence 884 Customers may require VPN service that spans multiple administrative 885 domains or service provider networks. Therefore, a VPN service must 886 be able to span multiple AS and SP networks, but still act and 887 appear as a single, homogenous VPN from a customer point of view. 889 A customer might also start with a VPN provided in a single AS with 890 a certain SLA but then ask for an expansion of the service spanning 891 multiple ASs/SPs. In this case, as well as for all kinds of multi- 892 AS/SP VPNs, VPN service should be able to deliver the same SLA to 893 all sites in a VPN regardless of the AS/SP to which it homes. 895 5.3 Addressing 896 A customer requires support from a L3 VPN for the following 897 addressing IP assignment schemes: 898 o customer assigned, non-unique, or RFC 1918 private addresses 899 o globally unique addresses obtained by the customer 900 o globally unique addresses statically assigned by the PPVPN 901 service provider 902 o on-demand, dynamically assigned IP addresses (e.g., DHCP), 903 irrespective of whether the access is temporary (e.g., remote) or 904 permanent (i.e., dedicated) 906 In the case of combined L3 PPVPN service with non-unique or private 907 addresses and Internet access, mechanisms that permit the exchange 908 of traffic between the customer's private address space and the 909 global unique Internet address space must be supported, for example, 910 NAT. 912 Carugi et al Informational - Expires October 2003 17 914 Service requirements for Layer 3 PPVPNs April, 2003 916 5.4 Routing Protocol Support 917 There should be no restriction on the routing protocols used between 918 CE and PE routers, or between CE routers. At least the following 919 protocols must be supported: static routing, IGP, such as RIP, OSPF, 920 IS-IS, and BGP [PPVPN-FR]. 922 5.5 Quality of Service and Traffic Parameters 923 QoS is expected to be an important aspect of a PPVPN service for 924 some customers. QoS requirements cover scenarios involving an 925 intranet, an extranet, as well as shared access between a VPN site 926 and the Internet. 928 5.5.1 Application Level QoS Objectives 929 A customer is concerned primarily that the PPVPN service provide his 930 or her application has the QoS and level of traffic such that the 931 application performs acceptably. Pseudo-wires (e.g., SONET 932 emulation) voice and interactive video, and multimedia applications 933 are expected to require the most stringent QoS. These real-time 934 applications are sensitive to delay, delay variation, loss, 935 availability and/or reliability. Another set of applications 936 requires near real time performance. Examples are multimedia, 937 interactive video, high-performance web browsing and file transfer 938 intensive applications. Finally, best effort applications are not 939 sensitive to degradation. That is, they are elastic and can adapt to 940 conditions of degraded performance. 942 The selection of appropriate QoS and service type to meet specific 943 application requirements is particularly important to deal with 944 periods of congestion in a SP network. Sensitive applications will 945 likely select per-flow Integrated service (Intserv) with precise SLA 946 guarantees measured on a per flow basis. On the other hand, non- 947 sensitive applications will likely rely on a Differentiated service 948 (Diffserv) class-based QoS. 950 The fundamental customer application requirement is that a PPVPN 951 solution must support both the Intserv QoS model for selected 952 individual flows, and Diffserv for aggregated flows. 954 A customer application should experience consistent QoS independent 955 of the access network technology used at different sites connected 956 to the same VPN. 958 5.5.2 DSCP Transparency 959 The Diffserv Code Point (DSCP) set by a user as received by the 960 ingress CE should be capable of being relayed transparently to the 961 egress CE [See section 2.6.2 of RFC 3270 and Y.1311.1]. Although RFC 962 2475 states that interior or boundary nodes within a provider�s 963 Diffserv domain may change the DSCP, customer VPNs may have other 964 requirements, such as: 965 o Applications that use the DSCP in a manner differently than the 966 DSCP solution supported by the SP network(s); 968 Carugi et al Informational - Expires October 2003 18 970 Service requirements for Layer 3 PPVPNs April, 2003 972 o Customers using more DSCPs within their sites than the SP 973 network(s) supports; 974 o Support for a carriers' carrier service where one SP is the 975 customer of another PPVPN SP. Such an SP should be able to resell 976 VPN service to his or her VPN customers independently of the DSCP 977 mapping solution supported by the carriers� carrier SP. 979 Note that support for DSCP transparency has no implication on the 980 QoS or SLA requirements. If an SP supports DSCP transparency, then 981 that SP needs to only carry the DSCP values across its domain, but 982 may map the received DSCP to some other value for QoS support across 983 its domain. 985 5.6 Service Level Specification/Agreement 986 Most customers simply want their applications to perform well. An 987 SLA is a vehicle for customer recourse in the event that SP(s) do 988 not perform or manage a VPN service well in a measurable sense. 989 Therefore, when purchasing service under an SLA, a customer agent 990 must have access to the measures from the SP(s) that support the 991 SLA. 993 5.7 Customer Management of a VPN 994 A customer must have a means to view the topology, operational 995 state, order status, and other parameters associated with his or her 996 VPN. 998 All aspects of management information about CE devices and customer 999 attributes of a PPVPN manageable by an SP should be capable of being 1000 configured and maintained by an authenticated, authorized customer 1001 agent. 1003 A customer agent should be able to make dynamic requests for changes 1004 to traffic parameters. A customer should be able to receive real- 1005 time response from the SP network in response to these requests. 1006 One example of such as service is a "Dynamic Bandwidth management" 1007 capability, that enables real-time response to customer requests for 1008 changes of allocated bandwidth allocated to their VPN(s)[Y.1311.1]. 1010 A customer who may not be able to afford the resources to manage 1011 their own sites should be able to outsource the management of his or 1012 her VPN to the service provider(s) supporting the network. 1014 5.8 Isolation 1015 These features include traffic and routing information exchange 1016 isolation, similar to that obtained in VPNs based on Layer 1 and 1017 Layer 2 (e.g., private lines, FR, or ATM) [MPLS SEC]. 1019 5.9 Security 1020 The suite of PPVPN solutions should support a range of security 1021 related features. Higher levels of security services, like edge-to- 1022 edge encryption, authentication, or replay attack should be 1023 supported. 1025 Carugi et al Informational - Expires October 2003 19 1027 Service requirements for Layer 3 PPVPNs April, 2003 1029 Security in a PPVPN service should be as transparent as possible to 1030 the customer, with the obvious exception of support for remote or 1031 temporary user access, as detailed in section 5.11.2. 1033 PPVPN customers must be able to deploy their own internal security 1034 mechanisms in addition to those deployed by the SP, in order to 1035 secure specific applications or traffic at a granularity finer than 1036 a site-to-site basis. 1038 If a a customer desires QoS support in a L3 PPVPN, then these must 1039 be communicated to the SP either using unencrypted fields or else 1040 via an agreed to security association. For example, applications 1041 must send RSVP messages in support of Intserv either in the clear or 1042 encrypted using a key negotiated with the SP. Another case is where 1043 applications using an IPsec tunnel must copy the DSCP from the 1044 encrypted IP header to the header of the tunnel�s IP header. 1046 Security services shall apply to: 1047 o either, all VPN traffic exchanged between different sites ; 1048 o or, a subset of the VPN traffic between sites as identified by a 1049 combination of the destination IP address, the Security Profile 1050 Index (SPI) and the IPsec AH or ESP identifier. 1052 5.10 Migration Impact 1053 Often, customers are migrating from an already deployed private 1054 network toward one or more Provider Provisioned VPN solutions. A 1055 typical private network scenario is CE routers connected via real or 1056 virtual circuits. Ideally, minimal incremental cost should result 1057 during the migration period. Furthermore, if necessary, any 1058 disruption of service should also be minimized. 1060 A range of scenarios of customer migration must be supported. Full 1061 migration of all sites must be supported. Support for cases of 1062 partial migration is highly desirable [Y.1311.1], that is, legacy 1063 private network sites that belong to the PPVPN service should still 1064 have L3 reachability to the sites that migrate to the PPVPN service. 1066 5.11 Network Access 1067 Every L3 packet exchanged between the customer and the SP over the 1068 access connection must appear as it would on a private network 1069 providing an equivalent service to that offered by the PPVPN. 1071 5.11.1 Physical/Link Layer Technology 1072 PPVPNs should support a broad range of physical and link layer 1073 access technologies, such as PSTN, ISDN, xDSL, cable modem, leased 1074 line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local 1075 loop, mobile radio access, etc. The capacity and QoS achievable may 1076 be dependent on the specific access technology in use. 1078 Carugi et al Informational - Expires October 2003 20 1080 Service requirements for Layer 3 PPVPNs April, 2003 1082 5.11.2 Temporary Access 1083 The VPN service offering should allow both permanent and temporary 1084 access to one or more PPVPNs for authenticated users across a broad 1085 range of access technologies. Support for remote or temporary VPN 1086 access should include ISDN, PSTN dial-in, xDSL or access via another 1087 SP network. The customer should be able to choose from alternatives 1088 for authentication of temporary access users. Choices for access 1089 authentication are: SP-provided, third-party, or customer-provided 1090 authentication servers. 1092 A significant number of VPN users are not permanently attached to 1093 one VPN site. In order to limit access to a VPN to only authorized 1094 users, it is first necessary to authenticate them. Authentication 1095 shall apply as configured by the customer agent and/or SP where a 1096 specific user may be part of one or more VPNs. The authentication 1097 function should be used to automatically invoke all actions 1098 necessary VPN communication. 1100 A user should be able to access a PPVPN via a network having generic 1101 Internet access. 1103 Mobile users may move within a PPVPN site. Mobile users may also 1104 temporarily connect to another PPVPN site within the same VPN. 1105 Authentication should be provided for both of these cases. 1107 5.11.3 Sharing of the Access Network 1108 In a PE-based PPVPN, if the site shares the access network with 1109 other traffic (e.g., access to the Internet), then data security in 1110 the access network is the responsibility of the PPVPN customer. 1112 5.11.4 Access Connectivity 1113 Various types of physical connectivity scenarios must be supported, 1114 such as multi-homed sites, backdoor links between customer sites, 1115 devices homed to two or more SP networks. PPVPN solutions should 1116 support at least the types of physical or link-layer connectivity 1117 arrangements shown in Figure 5.1. Support for other physical 1118 connectivity scenarios with arbitrary topology is desirable. 1120 Access arrangements with multiple physical or logical paths from a 1121 CE to other CEs and PEs must support redundancy, and should support 1122 load balancing. Resiliency uses redundancy to provide connectivity 1123 between a CE site and other CE sites, and optionally, other 1124 services. Load balancing provides a means to perform traffic 1125 engineering such that capacity on redundant links is used to achieve 1126 improved performance during periods when the redundant component(s) 1127 are available. 1129 Carugi et al Informational - Expires October 2003 21 1131 Service requirements for Layer 3 PPVPNs April, 2003 1133 +---------------- +--------------- 1134 | | 1135 +------+ +------+ 1136 +---------| PE | +---------| PE | 1137 | |router| | |router| SP network 1138 | +------+ | +------+ 1139 +------+ | +------+ | 1140 | CE | | | CE | +--------------- 1141 |device| | SP network |device| +--------------- 1142 +------+ | +------+ | 1143 | +------+ | +------+ 1144 | | PE | | | PE | 1145 +---------|router| +---------|router| SP network 1146 +------+ +------+ 1147 | | 1148 +---------------- +--------------- 1149 (a) (b) 1150 +---------------- +--------------- 1151 | | 1152 +------+ +------+ +------+ +------+ 1153 | CE |-----| PE | | CE |-----| PE | 1154 |device| |router| |device| |router| SP network 1155 +------+ +------+ +------+ +------+ 1156 | | | | 1157 | Backdoor | | Backdoor +--------------- 1158 | link | SP network | link +--------------- 1159 | | | | 1160 +------+ +------+ +------+ +------+ 1161 | CE | | PE | | CE | | PE | 1162 |device|-----|router| |device|-----|router| SP network 1163 +------+ +------+ +------+ +------+ 1164 | | 1165 +---------------- +--------------- 1166 (c) (d) 1167 +---------------- +--------------- 1168 | | 1169 +------+ +------+ +------+ +------+ 1170 | CE |-----| PE | | CE |-----| PE | 1171 |device| |router| |device| |router| SP network 1172 +------+\ +------+ +------+\ +------+ 1173 | \ | | \ | 1174 |Back \ | |Back \ +--------------- 1175 |door \ | SP network |door \ +--------------- 1176 |link \ | |link \ | 1177 +------+ +------+ +------+ +------+ 1178 | CE | | PE | | CE | | PE | 1179 |device|-----|router| |device|-----|router| SP network 1180 +------+ +------+ +------+ +------+ 1181 | | 1182 +---------------- +--------------- 1183 (e) (f) 1184 Figure 5.1 Representative types of access arrangements. 1186 Carugi et al Informational - Expires October 2003 22 1188 Service requirements for Layer 3 PPVPNs April, 2003 1190 For multi-homing to a single SP, load balancing capability should be 1191 supported by the PE across the CE to PE links. For example, in case 1192 (a), load balancing should be provided by the two PEs over the two 1193 links connecting to the single CE. In case (c), load balancing 1194 should be provided by the two PEs over the two links connecting to 1195 the two CEs. 1197 In addition, the load balancing parameters (e.g., the ratio of 1198 traffic on the multiple load-balanced links, or the preferred link) 1199 should be provisionable based on customer�s requirements. The load 1200 balancing capability may also be used to achieve resiliency in the 1201 event of access connectivity failures. For example, in cases (b) a 1202 CE may connect to two different SPs via diverse access networks. 1203 Resiliency may be further enhanced as shown in case (d), where CE's 1204 connected via a "back door" connection connect to different SPs. 1205 Furthermore, arbitrary combinations of the above methods, with a few 1206 examples shown in cases (e) and (f) should be supportable by any 1207 PPVPN approach. 1209 For multi-homing to multiple SPs, load balancing capability may also 1210 be supported by the PEs in the different SPs (clearly, this is a 1211 more complex type of load balancing to realize, and requires policy 1212 and service agreements between the SPs to interoperate). 1214 5.12 Service Access 1215 Customers may also require access to other services, as described in 1216 this section. 1218 5.12.1 Internet Access 1219 Customers should be able to have L3 PPVPN and Internet access across 1220 the same access network for one or more of the customer's sites. 1222 Customers should be able to direct Internet traffic from the set of 1223 sites in the PPVPN to one or more customer sites that have 1224 firewalls, other security-oriented devices, and/or NAT that process 1225 all traffic between the Internet and the customer's VPN. 1227 L3 PPVPN Customers should be able to receive traffic from the 1228 Internet addressed to a publicly accessible resource that is not 1229 part of the VPN, such as an enterprise's public web server. 1231 As stated in section 5.3, network address translation (NAT) or 1232 similar mechanism must be provided either by the customer or the SP 1233 in order to be able to interchange traffic between devices assigned 1234 non-unique or private IP addresses and devices that have unique IP 1235 addresses. 1237 5.12.2 Hosting, Application Service Provider 1238 A customer should be able to access hosting, other application 1239 services, or other Application Service Providers (ASP) over a L3 1241 Carugi et al Informational - Expires October 2003 23 1243 Service requirements for Layer 3 PPVPNs April, 2003 1245 PPVPN service. This may require that an ASP participates in one or 1246 more VPNs with the customers that use such a service. 1248 5.12.3 Other Services 1249 In conjunction with a VPN service, a customer may also wish to have 1250 access to other services, such as: DNS, FTP, HTTP, NNTP, SMTP, LDAP, 1251 VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business, 1252 Streaming, E-commerce, Directory, Firewall, etc. The resource(s) 1253 that implement these services could be physically dedicated to each 1254 VPN. If the resource(s) are logically shared, then they need to have 1255 access separated and isolated between VPNs in a manner consistent 1256 with the PPVPN solution to meet this requirement. 1258 5.13 Hybrid VPN Service Scenarios 1259 Intranet or extranet customers have a number of reasons for wanting 1260 hybrid networks that involve more than one VPN solution type. These 1261 include migration, mergers, extranet customers with different VPN 1262 types, the need for different capabilities between different sets of 1263 sites, temporary access, different availability of VPN solutions as 1264 provided by different service providers. 1266 The framework and solution approaches should include provisions for 1267 interworking, interconnection, and/or reachability between different 1268 PPVPN solutions in such a way that does not overly complicate 1269 provisioning, management, scalability, or performance. 1271 6 Service Provider Network Requirements 1272 This section describes requirements from a service provider 1273 perspective. 1275 6.1 Scalability 1276 This section contains projections regarding PPVPN sizing projections 1277 and scalability requirements and metrics specific to particular 1278 solutions. 1280 6.1.1 Service Provider Capacity Sizing Projections 1281 This section captures projections for scaling requirements over the 1282 next several years in terms of number of VPNs, number of interfaces 1283 per VPN, number of routes per VPN, and the rate of VPN configuration 1284 changes. These numbers provide a baseline against which the 1285 scalability of specific approaches can be assessed. These values 1286 were derived from ITU-T [Y.1311.1] and inputs from service 1287 providers. 1289 A PPVPN solution should be scalable to support a very large number 1290 of VPNs per Service Provider network. The estimate is that a large 1291 service provider will require support for on the order of 10,000 1292 VPNs within four years. 1294 A PPVPN solution should be scalable to support of a wide range of 1295 number of site interfaces per VPN, depending on the size and/or 1296 structure of the customer organization. The number of site 1298 Carugi et al Informational - Expires October 2003 24 1300 Service requirements for Layer 3 PPVPNs April, 2003 1302 interfaces should range from a few site interfaces to over 50,000 1303 site interfaces per VPN. 1305 A PPVPN solution should be scalable to support of a wide range of 1306 number of routes per VPN. The number of routes per VPN may range 1307 from just a few to the number of routes exchanged between ISPs using 1308 BGP (in 2001, on the order of 100,000). Typically, the number of 1309 routes per VPN is O(2N), where N is the number of site interfaces. 1311 A PPVPN solution should support high values of the frequency of 1312 configuration setup and change, e.g. for real-time provisioning of 1313 an on-demand videoconferencing VPN. As a guideline, an estimate on 1314 the VPN frequency of change (e.g., addition/removal of sites per VPN 1315 per time unit) could be as large as 1 million per year across all 1316 service providers within the next four years. 1318 Approaches should articulate scaling and performance limits for more 1319 complex deployment scenarios, such as inter-AS(S) VPNs and carriers' 1320 carrier. Approaches should also describe other dimensions of 1321 interest, such as capacity requirements or limits, number of 1322 interworking instances supported as well as any scalability 1323 implications on management systems. 1325 6.1.2 Solution-Specific Metrics 1326 Each PPVPN solution shall document its scalability characteristics 1327 in quantitative terms. Several examples are provided below as an 1328 illustration. 1330 The number of tunnels necessary per device is one metric of 1331 interest. In a PE-based VPN, tunnels potentially from every PE to 1332 every other PE must be set up for each VPN. Or, a full mesh of 1333 tunnels between PEs can be shared across many VPNs using 1334 hierarchical tunnels. In a CE-based VPN, end-to-end tunnels between 1335 pairs of CE's in a full or partial mesh are necessary, but PEs need 1336 not be aware of these tunnels at all. Furthermore, in a CE-based 1337 VPN, the tunnels endpoints are distributed to the CEs in a 1338 particular VPN. 1340 Another metric is that of complexity. In a PE-based solution the PE 1341 is more complex in that it must maintain a VFI must for each VPN, 1342 but the CE is simpler since it needs to support no tunnels. On the 1343 other hand, in a CE-based solution, the CE is more complex since it 1344 must implement routing across a number of tunnels to other CEs in 1345 the VPN, but the PE is simpler since it has only one routing and 1346 forwarding instance. 1348 A PE-based solution should quantify the amount of state that a PE 1349 and P router must support. This should be stated in terms of the 1350 total number of VPNs and site interfaces supported by the service 1351 provider. Ideally, all VPN-specific state should be contained in the 1352 PE router, since routing and/or configuration information depends 1353 only on the VPNs whose site(s) are connected to that PE. However, 1355 Carugi et al Informational - Expires October 2003 25 1357 Service requirements for Layer 3 PPVPNs April, 2003 1359 this should be balanced against the requirements of specific 1360 services, such as multicast, which may require per VPN state in the 1361 P router. 1363 A CE-based solution should quantify the state and scaling limits. 1364 This should be stated in terms of the number of tunnels supported, 1365 how these tunnels are provisioned and maintained (e.g., key 1366 exchange), how routing occurs across these tunnels, and what the 1367 impact of changes in the network topology do to the convergence 1368 performance of such a solution. 1370 6.2 Addressing 1371 As described in section 4.4, SPs require support for public and 1372 private IP addresses, IPv4 and IPv6, for both unicast and multicast. 1373 In order to support this range of addressing schemes, SPs require 1374 the following support from PPVPN solutions. 1376 A L3 PPVPN solution must be able to assign blocks of addresses form 1377 its own public IP address space to PPVPN customer sites in such a 1378 way that advertisement of routes to other SPs and other sites 1379 aggregates efficiently. 1381 A PPVPN solution must be able to use address assignments made by a 1382 customer. These customer assigned addresses may be public, or 1383 private. 1385 In the case where private IP addresses are used, a PPVPN solution 1386 must provide a means for an SP to translate such addresses to public 1387 IP addresses for communication with other VPNs using overlapping 1388 addresses, or the Internet. 1390 6.3 Identifiers 1391 A number of identifiers may be necessary for SP use in management, 1392 control, and routing protocols. Requirements for at least the 1393 following identifiers are known. 1395 An SP domain must be uniquely identified at least within the set of 1396 all interconnected SP networks when supporting a VPN that spans 1397 multiple SPs. Ideally, this identifier should be globally unique 1398 (e.g., an AS number). 1400 An identifier for each VPN should be unique, at least within each 1401 SP's network. Ideally, the VPN identifier should be globally unique 1402 to support the case where a VPN spans multiple SPs (e.g., [RFC 1403 2685]). 1405 A CE device should have a unique identifier, at least within each 1406 SP's network. 1408 A PE device should have a unique identifier, at least within each 1409 SP's network. 1411 Carugi et al Informational - Expires October 2003 26 1413 Service requirements for Layer 3 PPVPNs April, 2003 1415 The identifier of a device interconnecting SP networks must be 1416 unique within the set of aforementioned networks. 1418 Each site interface should have a unique identifier, at least within 1419 each PE router supporting such an interface. 1421 Each tunnel should have a unique identifier, at least within each 1422 router supporting the tunnel. 1424 6.4 Discovering VPN Related Information 1425 Configuration of CE and PE devices is a significant task for a 1426 service provider. Solutions should strive to contain methods that 1427 that dynamically allows VPN information to be discovered (or 1428 learned) by the PE and/or CE to reduce configuration complexity. The 1429 following specific requirements apply to intra and inter-provider 1430 VPNs [VPN DISC]. 1432 Every device involved in a VPN shall be able to identify and 1433 authenticate itself to other devices in the VPN. After learning the 1434 VPN membership, the devices should be able to securely exchange 1435 configuration information. The VPN information must include at least 1436 the IP address of the PE and may be extensible to provide additional 1437 information. 1439 Each device in a VPN should be able to determine which other devices 1440 belong to the same VPN. Such a membership discovery scheme must 1441 prevent unauthorized access and allows authentication of the source. 1443 Distribution of VPN information should be limited to those devices 1444 involved in that VPN. 1446 In the case of a PE-based VPN, a solution should support the means 1447 for attached CEs to authenticate each other and verify that the 1448 service provider VPN is correctly configured. 1450 The mechanism should respond to VPN membership changes in a timely 1451 manner. A "timely manner" is no longer than the provisioning 1452 timeframe, typically on the order of minutes, and may be as short as 1453 the timeframe required for "rerouting," typically on the order of 1454 seconds. 1456 Dynamically creating, changing, and managing multiple VPN 1457 assignments to sites and/or customers is another aspect of 1458 membership that must be addressed in a L3 PPVPN solution. 1460 6.5 SLA and SLS Support 1461 Typically, a Service Provider offering a PPVPN service commits to 1462 specific Service Level Specifications (SLS) as part of a contract 1463 with the customer, as described in section 4.7. Such a Service Level 1464 Agreement (SLA) drives the following specific SP requirements for 1465 measuring Specific Service Level Specifications (SLS) for quality, 1466 availability, response time, and configuration intervals. 1468 Carugi et al Informational - Expires October 2003 27 1470 Service requirements for Layer 3 PPVPNs April, 2003 1472 6.6 Quality of Service (QoS) and Traffic Engineering 1473 A significant aspect of a PPVPN is support for QoS. Since an SP has 1474 control over the provisioning of resources and configuration of 1475 parameters in at least the PE and P devices, and in some cases, the 1476 CE device as well, the onus is on the service provider to provide 1477 either managed QoS access service, or edge-to-edge QoS service, as 1478 defined in section 4.6.2. 1480 Each PPVPN approach must describe the traffic engineering techniques 1481 available for a service provider to meet the QoS objectives. These 1482 descriptions of traffic engineering techniques should quantify 1483 scalability and achievable efficiency. Traffic engineering support 1484 may be on an aggregate or per-VPN basis. 1486 QoS policies must not be impacted by security mechanisms. For 1487 example, Diffserv policies must not be impacted by the use of IPSec 1488 tunnels, using the mechanisms explained in RFC 2983. 1490 As stated in RFC 2475, a mapping function from customer provided 1491 Difserv marking to marking used in a SP network should be provided 1492 for L3 PPVPN services. 1494 In the case where a customer requires DSCP transparency, as 1495 described in section 5.5.2, a L3 PPVPN service must deliver the same 1496 value of DSCP field in the IP header received from the customer to 1497 the egress demarcation of the destination. 1499 6.7 Routing 1500 The distribution of reachability and routing policy should be 1501 constrained to the sites that are members of the VPN. 1503 Optionally, the exchange of such information may use some form of 1504 authentication (e.g., MD5). 1506 Functions to isolate the SP network and customer VPNs from anomalous 1507 routing behavior from a specific set of customer sites are highly 1508 desirable. Examples of such functions are: controls for route flap 1509 dampening, filters that accept only prefixes configured for a 1510 specific CE, a maximum number of routes accepted for each CE, or a 1511 maximum rate at which route updates can be received from a CE. 1513 When VPN customers use overlapping, non-unique IP addresses, the 1514 solution must define a means to distinguish between such overlapping 1515 addresses on a per-VPN basis. 1517 Furthermore, the solution should provide an option that either 1518 allows, or prevents advertisement of VPN routes to the Internet. 1520 Ideally, the choice of a SP's IGP should not depend on the routing 1521 protocol(s) used between PE and CE routers in a PE-based VPN. 1523 Carugi et al Informational - Expires October 2003 28 1525 Service requirements for Layer 3 PPVPNs April, 2003 1527 Furthermore, it is desirable that an SP should have a choice with 1528 regards to the IGP routing protocol. 1530 The additional routing burden that a Service Provider must 1531 carry should be articulated in each specific L3 PPVPN solution. 1533 6.8 Isolation of Traffic and Routing 1534 The internal structure of a PPVPN network should not be visible to 1535 outside networks (i.e., the Internet or any connected VPN). 1537 From a high level SP perspective, a PE-based PPVPN must isolate the 1538 exchange of traffic and routing information to only those sites that 1539 are authenticated and authorized members of a VPN. 1541 In a CE-based VPN, the tunnels that connect the sites effectively 1542 meet this isolation requirement if both traffic and routing 1543 information flow over the tunnels. 1545 A PPVPN solution should provide a means for meeting PPVPN QoS SLA 1546 requirements that isolates VPN traffic from the affects of traffic 1547 offered by non-VPN customers. Also, PPVPN solutions should provide a 1548 means to isolate the effects that traffic congestion produced by 1549 sites as part of one VPN can have on another VPN. 1551 6.9 Security 1552 [Editor's Note: Some of the material in this section is generic to 1553 L2 and L3 VPNs and may be deleted if the draft proposed for [PPVPN- 1554 GR] is accepted.] 1555 This section contains requirements related to securing customer 1556 flows, providing authentication services for temporary, remote or 1557 mobile users, and the need to protect service provider resources 1558 involved in supporting a PPVPN. 1560 6.9.1 Support for Securing Customer Flows 1561 In order to meet the general requirement for providing a range of 1562 security options to a customer, each PPVPN solution must clearly 1563 spell out the configuration options that can work together and how 1564 the can do so. 1566 When a VPN solution operates over a part of the Internet it should 1567 support a configurable option to support one or more of the 1568 following standard IPsec methods for securing a flow for a specified 1569 subset of a customer�s VPN traffic: 1570 o confidentiality, so that only authorized devices can decrypt it, 1571 o integrity, to ensure that the data has not been altered, 1572 o authentication, to ensure that the sender is indeed who it claims 1573 to be, 1574 o replay attack prevention. 1576 The above functions should be capable of being applied to "data 1577 traffic" of the customer, which includes the traffic exchanged 1578 between sites, between temporary users and sites and even between 1580 Carugi et al Informational - Expires October 2003 29 1582 Service requirements for Layer 3 PPVPNs April, 2003 1584 temporary users. It should also be possible to apply these functions 1585 to "control traffic", such as routing protocol exchanges, that are 1586 not necessarily perceived by the customer but nevertheless essential 1587 to maintain his or her VPN. Note that it may be necessary to extend 1588 the IPsec protocol to support exchange of control traffic over an 1589 IPsec tunnel [IPSEC-PPVPN]. 1591 Furthermore, such security methods must be configurable between 1592 different end points, such as CE-CE, PE-PE, and CE-PE. It is also 1593 desirable to configure security on a per-route or per-VPN basis [VPN 1594 SEC]. 1596 A VPN solution may support one or more encryption schemes, including 1597 AES, 3DES. Encryption, decryption, and key management should be 1598 included in profiles as part of the security management system. 1600 6.9.2 Authentication Services 1601 A service provider must provide authentication services in support 1602 of temporary user access requirements, as described in section 1603 5.11.2. 1605 Furthermore, traffic exchanged within the scope of VPN may involve 1606 several categories of equipment that must cooperate together to 1607 provide the service [Y.1311.1]. These network elements can be CE, 1608 PE, firewalls, backbone routers, servers, management stations, etc. 1609 These network elements learn about each others identity, either via 1610 manual configuration or via discovery protocols, as described in 1611 section 6.4. When network elements must cooperate, it is necessary 1612 to authenticate peers before providing the requested service. This 1613 authentication function may also be used to control access to 1614 network resources. 1616 The peer identification and authentication function described above 1617 applies only to network elements participating in the VPN. Examples 1618 include: 1619 - traffic between a CE and a PE, 1620 - traffic between CEs belonging to the same VPN, 1621 - CE or PE routers dealing with route announcements for a VPN, 1622 - policy decision point [RFC 3198] and a network element, 1623 - management station and an SNMP agent. 1625 Each PPVPN solution should describe for a peer authentication 1626 function: where it is necessary, how it shall be implemented, how 1627 secure it must be, and the way to deploy and maintain identification 1628 and authentication information necessary to operate the service. 1630 6.9.3 Resource Protection 1631 Recall from the definitions in section 3.3, that a site can be part 1632 of an intranet with sites from the only same organization, part of 1633 an extranet involving sites from other organizations, have access to 1634 the Internet, or any combination of these scopes of communication. 1636 Carugi et al Informational - Expires October 2003 30 1638 Service requirements for Layer 3 PPVPNs April, 2003 1640 Within these contexts, a site might be subject to various attacks 1641 coming from different sources. Potential sources of attack include: 1642 - users connected to the supporting public IP backbone, 1643 - users from the Internet, 1644 - users from temporary sites belonging to the intranet and/or 1645 extranet VPN that the site is part of. 1647 Security threats and risks that a site may encounter include the 1648 following: 1649 - denial of service, for example: mail spamming, access connection 1650 congestion, TCP SYN attacks, ping attacks, etc. 1651 - intrusion attempts, which may eventually lead to denial of 1652 service (e.g. a Trojan horse attack). 1654 In order to address the above threats and risks, a SP should be able 1655 to deploy functions that control access to the site. This includes 1656 filtering functions provided by firewall, and monitoring, alerting 1657 and eventually logging all suspicious activities in order to detect 1658 potential attacks. Another way to prevent such an attack is to make 1659 sure that machines are not reachable via address hiding [MPLS SEC]. 1661 The devices in the PPVPN network must provide some means of 1662 reporting intrusion attempts to the service provider. 1664 6.10 Inter-AS (SP)VPNs 1665 The scenario for VPNs spanning multiple Autonomous Systems (AS) or 1666 Service Providers (SP) requires standardization. The scenario where 1667 multiple AS�s are involved is the most general case, and is 1668 therefore the one described here. The scenarios of concern are the 1669 CE-based and PE-based L3 VPNs defined in section 3. 1671 In each scenario, all applicable SP requirements, such as traffic 1672 and routing isolation, SLA's, management, security, provisioning, 1673 etc. must be preserved across adjacent AS�s. The solution must 1674 describe the inter-SP network interface, encapsulation method(s), 1675 routing protocol(s), and all applicable parameters [VPN IW]. 1677 An essential pre-condition for an inter-AS VPN is an agreement 1678 between the AS's involved that spells out at least trust, economic, 1679 and management responsibilities. 1681 The overall scalability of the VPN service must allow the PPVPN 1682 service to be offered across potentially hundreds of SPs, with the 1683 overall scaling parameters per SP given in section 6.1. 1685 6.10.1 Routing Protocols 1686 If the link between AS's is not trusted, routing protocols running 1687 between those AS's must support some form of authentication. For 1688 example, the TCP option for carrying an MD5 digest may be used to 1689 enhance security for BGP [RFC2385]. 1691 Carugi et al Informational - Expires October 2003 31 1693 Service requirements for Layer 3 PPVPNs April, 2003 1695 BGP must be supported as the standard inter-AS routing protocol to 1696 control the path taken by PPVPN traffic. 1698 6.10.2 Management 1699 The general requirements for managing a single AS apply to a 1700 concatenation of AS's. A minimum subset of such capabilities is the 1701 following: 1702 - Diagnostic tools (e.g., ping, traceroute) 1703 - Secured access to one AS management system by another 1704 - Configuration request and status query tools 1705 - Fault notification and trouble tracking tools 1707 6.10.3 Bandwidth and QoS Brokering 1708 When a VPN spans multiple AS's, there is a need for a brokering 1709 mechanism that requests certain SLA parameters, such as bandwidth 1710 and QoS, from the other domains and/or networks involved in 1711 transferring traffic to various sites. The essential requirement is 1712 that a solution must be able to determine whether a set of AS's can 1713 establish and guarantee uniform QoS in support of a PPVPN. 1715 The brokering mechanism can be a manual one, for example, where one 1716 provider requests from another provider a specific set of QoS 1717 parameters for traffic going to and from a specific set of sites. 1718 The mechanism could also be an automated one where a device 1719 dynamically requests and receives certain SLA/QoS parameters. For 1720 instance, in the case of a L3 PPVPN, a PE may negotiate the label 1721 for different traffic classes to reach a PE residing in a 1722 neighboring AS. Or, it might be a combination of both. 1724 In the case of an automated function, which is desirable, the 1725 functionality supported should dynamically request and reserve 1726 certain QoS parameters such as bandwidth and priority, and then to 1727 classify, mark and handle the packets as agreed in the negotiation. 1728 Observe that as traffic might traverse multiple AS's, the brokering 1729 method should also allow this. 1731 It is not desirable to perform brokering on a per VPN basis since 1732 such an approach would not scale. A solution must provide some means 1733 of aggregating QoS and bandwidth brokering requests between AS's. 1734 One method could be for SP's to make an agreement specifying the 1735 maximum amount of bandwidth for specific QoS parameters for all VPN 1736 customers using the SP network. Alternatively, such aggregation 1737 might be on a per hierarchical tunnel basis between PE routers in 1738 different AS's supporting a L3 PPVPN service. 1740 6.10.4 Security Considerations 1741 If a tunnel traverses multiple SP networks and it passes through an 1742 unsecured SP, POP, NAP, or IX, then security mechanisms must be 1743 employed. These security mechanisms include encryption, 1744 authentication and resource protection as described in section 6.9 1745 and security management of section 7.5. For example, a provider 1746 should consider use of both authentication and encryption for a 1748 Carugi et al Informational - Expires October 2003 32 1750 Service requirements for Layer 3 PPVPNs April, 2003 1752 tunnel used as part of a PPPVPN that traverses another service 1753 provider's network. 1755 6.11 PPVPN Wholesale 1756 The architecture must support the possibility of one service 1757 provider offering VPN service to another service provider. Another 1758 example is when one service provider sells PPVPN service at 1759 wholesale to another service provider, who then resells that VPN 1760 service to his or her customers. 1762 The wholesaler�s VPN must be transparent to the addressing and 1763 routing used by the reseller. 1765 Support for additional levels of hierarchy, for example three levels 1766 where a reseller can again resell the VPN service to yet another VPN 1767 provider, should be provided. This is called a hierarchical VPN 1768 scenario. 1770 The Carrier�s carrier scenario is the name used in this document for 1771 this category of PPVPN wholesale. Various Carrier�s Carrier scenarios 1772 should be supported, such as: 1773 - the customer Carriers do not operate PPVPN services for their 1774 clients; 1775 - the customer Carriers operate PPVPN services for their clients, 1776 but these services are not linked with the PPVPN service offered 1777 by the Carriers� Carrier; 1778 - the customer Carriers operate PPVPN services for their clients and 1779 these services are linked with the PPVPN service offered by the 1780 Carriers� Carrier ("Hierarchical VPNs" scenario) 1782 6.12 Tunneling Requirements 1783 Connectivity between CE sites or PE devices in the backbone should 1784 be able to use a range of tunneling technologies, such as L2TP, 1785 IPSEC, GRE, IP-in-IP, MPLS, etc. 1787 To set up tunnels between routers, every router must support static 1788 configuration for tunneling and may support a tunnel setup protocol. 1789 If employed, a tunnel establishment protocol should be capable of 1790 conveying information, such as the following: 1791 - Relevant identifiers 1792 - QoS/SLA parameters 1793 - Restoration parameters 1794 - Multiplexing identifiers 1795 - Security parameters 1797 There must be a means to monitor the following aspects of tunnels: 1798 - Statistics, such as amount of time spent in the up and down 1799 state 1800 - Count of transitions between the up and down state 1801 - Events, such as transitions between the up and down states 1803 Carugi et al Informational - Expires October 2003 33 1805 Service requirements for Layer 3 PPVPNs April, 2003 1807 The tunneling technology used by the VPN Service Provider and its 1808 associated mechanisms for tunnel establishment, multiplexing, and 1809 maintenance must meet the requirements on scaling, isolation, 1810 security, QoS, manageability, etc. 1812 6.13 Support for Access and Backbone Technologies 1813 This section describes requirements for aspects of access and 1814 backbone network technologies from a service provider point of view. 1816 Some SPs may desire that a single network infrastructure should 1817 suffice for all services, public IP, VPNs, traffic engineering, and 1818 differentiated services [L2 VPN]. 1820 6.13.1 Dedicated Access Networks 1821 Ideally, the PPVPN service should be independent of physical, link 1822 layer or even network technology of the access network. However, the 1823 characteristics of access networks must be accounted for when 1824 specifying the QoS aspects of SLAs for VPN service offerings. 1826 6.13.2 On-Demand Access Networks 1827 Service providers should be able to support temporary user access, 1828 as described in section 5.11.2 using dedicated or dial-in access 1829 network technology. 1831 PPVPN solutions must support the case where a VPN user directly 1832 accesses the VPN service through an access network connected to the 1833 service provider. They must also describe how they can support the 1834 case where one or more other service provider networks are used as 1835 access to the service provider supporting the PPVPN service. 1837 Ideally, all information necessary to identify and authenticate 1838 users for an intranet should be stored and maintained by the 1839 customer. In an extranet, one customer should be able to maintain 1840 the authentication server, or the customers involved in the extranet 1841 may choose to outsource the function to a service provider. 1843 Identification and authentication information could be made 1844 available to the service provider for controlling access, or the 1845 service provider may query a customer maintained server. 1846 Furthermore, one SP may act as access for the SP providing the VPN 1847 service. In the case where the access SP performs identification and 1848 authentication on behalf of the VPN SP, an agreement must be reached 1849 on a common specification. 1851 Support for at least the following authentication protocols is 1852 required: PAP, CHAP and EAP, since they are currently used in a wide 1853 range of equipment and services. 1855 6.13.3 Backbone Networks 1856 Ideally, the backbone interconnecting SP PE and P devices should be 1857 independent of physical and link layer technology. Nevertheless, the 1859 Carugi et al Informational - Expires October 2003 34 1861 Service requirements for Layer 3 PPVPNs April, 2003 1863 characteristics of backbone technology must be taken into account 1864 when specifying the QoS aspects of SLAs for VPN service offerings. 1866 6.14 Protection, Restoration 1867 When primary and secondary access connections are available, a PPVPN 1868 solution must provide restoration of access connectivity whenever 1869 the primary access link from a CE site to a PE fails. This 1870 restoration capability should be as automatic as possible, that is, 1871 the traffic should be directed over the secondary link soon after 1872 failure of the primary access link is detected. Furthermore, 1873 reversion to the primary link should be dynamic, if configured to do 1874 so [VPN-NEEDS]. 1876 As mentioned in Section 5.11.4 above, in the case of multi-homing, 1877 the load balancing capability may be used to achieve a degree of 1878 redundancy in the network. In the case of failure of one or more 1879 (but not all) of the multi-homed links, the load balancing 1880 parameters may be dynamically adjusted to rapidly redirect the 1881 traffic from the failed link(s) to the surviving links. Once the 1882 failed link(s) is (are) restored, the original provisioned load 1883 balancing ratio should be restored to its value prior to the 1884 failure. 1886 The Service provider should be able to deploy protection and 1887 restoration mechanisms within the service provider's backbone 1888 infrastructure to increase reliability and fault tolerance of the 1889 VPN service offering. These techniques should be scalable, and 1890 therefore should strive to not perform such function in the backbone 1891 on a per-VPN basis. 1893 Appropriate measurements and alarms that indicate how well network 1894 protection and restoration mechanisms are performing must be 1895 supported. 1897 6.15 Interoperability 1898 Service providers are interested in interoperability in at least the 1899 following scenarios: 1900 - To facilitate use of PE and managed CE devices within a single SP 1901 network 1902 - To implement PPVPN services across two or more interconnected SP 1903 networks 1904 - To achieve interworking or interconnection between customer sites 1905 using different PPVPN approaches or different implementations of 1906 the same approach 1908 Each approach must describe whether any of the above objectives can 1909 be met. If an objective can be met, the approach must describe how 1910 such interoperability could be achieved. In particular, the approach 1911 must describe the inter-solution network interface, encapsulation 1912 method(s), routing protocol(s), security, isolation, management, and 1913 all other applicable aspects of the overall VPN solution provided 1914 [VPN IW]. 1916 Carugi et al Informational - Expires October 2003 35 1918 Service requirements for Layer 3 PPVPNs April, 2003 1920 6.16 Migration Support 1921 Service providers must have a graceful means to migrate a customer 1922 with minimal service disruption on a site-by-site basis to a PPVPN 1923 approach. 1925 If PPVPN approaches can interwork or interconnect, then service 1926 providers must have a graceful means to migrate a customer with 1927 minimal service disruption on a site-by-site basis whenever changing 1928 interworking or interconnection. 1930 7 Service Provider Management Requirements 1931 A service provider must have a means to view the topology, 1932 operational state, order status, and other parameters associated 1933 with each customer's VPN. Furthermore, the service provider must 1934 have a means to view the underlying logical and physical topology, 1935 operational state, provisioning status, and other parameters 1936 associated with the equipment providing the VPN service(s) to its 1937 customers. 1939 Currently, proprietary methods are often used to manage VPNs. The 1940 additional expense associated with operators having to use multiple 1941 proprietary management methods (e.g., command line interface (CLI) 1942 languages) to access such systems is undesirable. Therefore, devices 1943 should provide standards-based interfaces wherever feasible. 1945 The remainder of this section presents detailed service provider 1946 management requirements for a Network Management System (NMS) in the 1947 traditional fault, configuration, accounting, performance, and 1948 security (FCAPS) management categories. Much of this text was 1949 adapted from ITU-T Y.1311.1. 1951 7.1 Fault management 1952 Support for fault management includes: 1953 - indication of customers impacted by failure, 1954 - fault detection (incidents reports, alarms, failure 1955 visualization), 1956 - fault localization (analysis of alarms reports, diagnostics), 1957 - incident recording or logs, creation and follow through of trouble 1958 tickets), 1959 - corrective actions (traffic, routing, resource allocation). 1961 Since PE-based VPNs rely on a common network infrastructure, the 1962 network management system must provide a means to inform the 1963 provider on the VPN customers impacted by a failure in the 1964 infrastructure. The NMS should provide pointers to the related 1965 customer configuration information to aid in fault isolation and the 1966 determination of corrective action. 1968 It is desirable to detect faults caused by configuration errors, 1969 because these may cause VPN service to fail, or not meet other 1970 requirements (e.g., traffic and routing isolation). Detection of 1972 Carugi et al Informational - Expires October 2003 36 1974 Service requirements for Layer 3 PPVPNs April, 2003 1976 such errors is inherently difficult because the problem involves 1977 more than one node and may reach across a global perspective. One 1978 approach could be a protocol that systematically checks that all 1979 constraints and consistency checks hold among tunnel configuration 1980 parameters at the various end points. 1982 A capability to verify L3 reachability within a VPN must be provided 1983 for diagnostic purposes. 1985 A capability to verify the parameter configuration of a device 1986 supporting a PPVPN must be provided for diagnostic purposes. 1988 7.2 Configuration Management 1989 Overall, The NMS must support configuration necessary to realize 1990 desired L3 reachability of a PPVPN. Toward this end, an NMS must 1991 provide configuration management to provision at least the following 1992 PPVPN components: PE,CE, hierarchical tunnels, access connections, 1993 routing, and QoS, as detailed in this section. If shared access to 1994 the Internet is provided, then this option must also be 1995 configurable. 1997 Since VPN configuration and topology are highly dependent upon a 1998 customer's organization, provisioning systems must address a broad 1999 range of customer specific requirements. The NMS must ensure that 2000 these devices and protocols are provisioned consistently and 2001 correctly. 2003 Provisioning for adding or removing sites should be as localized and 2004 automated as possible. 2006 Configuration management for VPNs, according to service templates 2007 defined by the provider must be supported. A service template 2008 contains fields which, when instantiated, yield a definite service 2009 requirement or policy. For example, a template for an IPSec tunnel 2010 would contain fields such as tunnel end points, authentication 2011 modes, encryption and authentication algorithms, preshared keys if 2012 any, and traffic filters. An SLA template would contain fields such 2013 as delay, jitter, throughput and packet loss thresholds as well as 2014 end points over which the SLA has to be satisfied. In general, a 2015 customer's service order can be regarded as a set of instantiated 2016 service templates. This set can, in turn, be regarded as the logical 2017 or service architecture of the customer's VPN. 2019 Service templates can also be used by the provider to define the 2020 service architecture of the provider's own network. For example, 2021 OSPF templates could contain fields such as the subnets that form a 2022 particular area, the area identifier and the area type. BGP service 2023 template could contain fields which when instantiated would yield a 2024 BGP policy such as for expressing a preference about an exit router 2025 for a particular destination. 2027 Carugi et al Informational - Expires October 2003 37 2029 Service requirements for Layer 3 PPVPNs April, 2003 2031 The set of service templates should be comprehensive in that they 2032 can capture all service orders in some meaningful sense. 2034 The provider should provide means for translating instantiated 2035 service templates into device configurations so that associated 2036 services can be provisioned. 2038 Finally, the approach should provide means for checking if a service 2039 order is correctly provisioned. This would represent one method of 2040 diagnosing configuration errors. Configuration errors can arise due 2041 to a variety of reasons: manual configuration, intruder attacks, 2042 conflicting service requirements. 2044 7.2.1 Configuration Management for PE-Based VPNs 2045 Requirements for configuration management unique to a PE-based VPN 2046 are as follows. 2048 o The NMS must support configuration of at least the following 2049 aspects of a L3 PE routers: intranet and extranet membership, CE 2050 routing protocol for each access connection, routing metrics, 2051 tunnels, etc. 2053 o The NMS should use identifiers for SPs, PPVPNs, PEs, CEs, 2054 hierarchical tunnels and access connections as described in section 2055 6.3. 2057 o Tunnels must be configured between PE and P devices. This 2058 requires coordination of identifiers of tunnels, hierarchical 2059 tunnels, VPNs, and any associated service information, for example, 2060 a QoS/SLA service. 2062 o Routing protocols running between PE routers and CE devices must 2063 be configured per VPN. 2065 O For multicast service, multicast routing protocols must also be 2066 configurable. 2068 o Routing protocols running between PE routers and between PE and P 2069 routers must also be configured. 2071 o The configuration of a PE-based PPVPN must be coordinated with the 2072 configuration of the underlying infrastructure, including Layer 1 2073 and 2 networks interconnecting components of a PPVPN. 2075 7.2.2 Configuration management for CE-based VPN 2076 Requirements for configuration management unique to a CE-based VPN 2077 are as follows. 2079 o Tunnels must be configured between CE devices. This requires 2080 coordination of identifiers of tunnels, VPNs, and any associated 2081 service information, for example, a QoS/SLA service. 2083 Carugi et al Informational - Expires October 2003 38 2085 Service requirements for Layer 3 PPVPNs April, 2003 2087 o Routing protocols running between PE routers and CE devices must 2088 be configured. For multicast service, multicast routing protocols 2089 must also be configurable. 2091 7.2.3 Provisioning Routing 2092 A means for a service provider to provision parameters for the IGP 2093 for a PPVPN must be provided. This includes link level metrics, 2094 capacity, QoS capability, and restoration parameters. 2096 7.2.4 Provisioning Network Access 2097 A service provider must have the means to provision network access 2098 between SP-managed PE and CE, as well as the case where the customer 2099 manages the CE. 2101 7.2.5 Provisioning Security Services 2102 When a security service is requested, an SP must have the means to 2103 provision the entities and associated parameters involved with the 2104 service. For example, for IPsec service, tunnels, options, keys, and 2105 other parameters must be provisioned at either the CE and/or PE. In 2106 the case of an intrusion detection service, the filtering and 2107 detection rules must be provisioned on a VPN basis. 2109 7.2.6 Provisioning VPN Resource Parameters 2110 A service provider must have a means to dynamically provision 2111 resources associated with VPN services. For example, in a PE-based 2112 service, the number and size of virtual switching and forwarding 2113 table instances must be provisionable. 2115 Dynamic VPN resource assignment is crucial to cope with the frequent 2116 changes requests from customer�s (e.g., sites joining or leaving a 2117 VPN), as well as to achieve scalability. The PEs should be able to 2118 dynamically assign the VPN resources. This capability is especially 2119 important for dial and wireless VPN services. 2121 If an SP supports a "Dynamic Bandwidth management" service, then the 2122 dates, times, amounts and interval required to perform requested 2123 bandwidth allocation change(s) must be traceable for accounting 2124 purposes. 2126 If an SP supports a "Dynamic Bandwidth management" service, then the 2127 provisioning system must be able to make requested changes within 2128 the ranges and bounds specified in the Service Level Agreement 2129 (SLA). Example SLA parameters are response time and probability of 2130 being able to service such a request 2132 7.2.7 Provisioning Value-Added Service Access 2133 A PPVPN service provides controlled access between a set of sites 2134 over a common backbone. However, many service providers also offer a 2135 range of value-added services, for example: Internet access, 2136 firewall services, intrusion protection, IP telephony and IP 2137 Centrex, application hosting, backup, etc. It is outside of the 2138 scope of this document to define if and how these different services 2140 Carugi et al Informational - Expires October 2003 39 2142 Service requirements for Layer 3 PPVPNs April, 2003 2144 interact with the VPN in order to solve issues such as addressing, 2145 integrity and security. However, the VPN service must be able to 2146 provide access to these various types of value-added services. 2148 A VPN service should allow the SP to supply the customer with 2149 different kinds of standard IP services like DNS, NTP and RADIUS 2150 needed for ordinary network operation and management. The provider 2151 should be able to provide IP services to multiple customers from one 2152 or many servers. 2154 A firewall function may be required to restrict access to the PPVPN 2155 from the Internet [Y.1311]. 2157 A managed firewall service must be carrier grade. For redundancy and 2158 failure recovery, a means for firewall fail-over should be provided. 2159 Managed firewall services that may be provided include dropping 2160 specified protocol types, intrusion protection, traffic-rate 2161 limiting against malicious attacks, etc. 2163 Managed firewalls must be supported on a per-VPN basis, although 2164 multiple VPNs may be supported by the same physical device (e.g., in 2165 network or PE-based solution). Managed firewalls should be provided 2166 at the major access point(s) for the PPVPN. Managed firewall 2167 services may be embedded in the CE or PE devices, or implemented in 2168 standalone devices. 2170 The NMS should allow a customer to outsource the management of an IP 2171 networking service to the SP providing the VPN or a third party. 2173 The management system should support collection of information 2174 necessary for optimal allocation of IP services in response to 2175 customer orders. 2177 Network-based firewall services must be carrier grade. For 2178 redundancy and failure recovery, a means for firewall fail-over 2179 should be provided. Network-based firewall services that may be 2180 provided include dropping specified protocol types, intrusion 2181 detection, traffic-rate limiting against malicious attacks, etc. 2183 Network-based firewalls must be supported on a per-VPN basis, 2184 although multiple VPNs may be supported by the same physical device. 2185 Network-based firewalls should be provided at the major access 2186 point(s) for the PPVPN. Network-based firewall services may be 2187 embedded in the PE equipment, or implemented in standalone 2188 equipment. 2190 Reachability to and from the Internet to sites within a VPN must be 2191 configurable by an SP. This could be controlled by configuring 2192 routing policy to control distribution of VPN routes advertised to 2193 the Internet. 2195 Carugi et al Informational - Expires October 2003 40 2197 Service requirements for Layer 3 PPVPNs April, 2003 2199 7.2.8 Provisioning Hybrid VPN Services 2200 Configuration of interworking or interconnection between PPVPN 2201 solutions should be also supported. Ensuring that security and end- 2202 to-end QoS issues are provided consistently should be addressed. 2204 7.3 Accounting 2205 Many service providers require collection of measurements regarding 2206 resource usage for accounting purposes. The NMS may need to 2207 correlate accounting information with performance and fault 2208 management information to produce billing that takes into account 2209 SLA provisions for periods of time where the SLS is not met. 2211 A PPVPN solution must describe how the following accounting 2212 functions can be provided: 2213 - measurements of resource utilization, 2214 - collection of accounting information, 2215 - storage and administration of measurements. 2217 Some providers may require near-real time reporting of measurement 2218 information, and may offer this as part of a customer network 2219 management service. 2221 If an SP supports a "Dynamic Bandwidth management" service, then the 2222 dates, times, amounts and interval required to perform requested 2223 bandwidth allocation change(s) must be traceable for monitoring and 2224 accounting purposes. 2226 Solutions should state compliance to accounting requirements, as 2227 described in section 1.7 of RFC 2975. 2229 7.4 Performance Management 2230 Performance management includes functions involved with monitoring 2231 and collecting performance data regarding devices, facilities, and 2232 services, as well as determination of conformance to Service Level 2233 Specifications (SLS), such as QoS and availability measurements. 2235 Performance management should also support analysis of important 2236 aspects of a PPVPN , such as bandwidth utilization, response time, 2237 availability, QoS statistics, and trends based on collected data. 2239 7.4.1 Performance Monitoring 2240 The NMS must monitor device behavior to evaluate performance metrics 2241 associated with a service level agreement. Different measurement 2242 techniques may be necessary depending on the service for which an 2243 SLA is provided. Example services are QoS, security, multicast, and 2244 temporary access. These techniques may be either intrusive or non- 2245 intrusive depending on the parameters being monitored. 2247 The NMS must also monitor aspects of the VPN not directly associated 2248 with an SLA, such as resource utilization, state of devices and 2249 transmission facilities, as well as control of monitoring resources 2251 Carugi et al Informational - Expires October 2003 41 2253 Service requirements for Layer 3 PPVPNs April, 2003 2255 such as probes and remote agents at network access points used by 2256 customers and mobile users. 2258 7.4.2 SLA and QoS management features 2259 The NMS should support SLAs between the SP and the various customers 2260 according to the corresponding SLSes by measurement of the 2261 indicators defined within the context of the SLA, on a regular 2262 basis. 2264 The NMS should use the QOS parameter measurement definitions, 2265 techniques, and methods as defined by the IETF IP Performance 2266 Metrics (IPPM) working group for delay, loss, and delay variation. 2268 The NMS should support allocation and measurement of end-to-end QoS 2269 requirements to QoS parameters for one or more network(s). 2271 Devices supporting PPVPN SLAs should have real-time performance 2272 measurements that have indicators and threshold crossing alerts. 2273 Such thresholds should be configurable. 2275 7.5 Security Management 2276 The security management function of the NMS must include management 2277 features to guarantee the security of devices, access connections, 2278 and protocols within the PPVPN network(s), as well as the security 2279 of customer data and control as described in section 6.9. 2281 7.5.1 Management Access Control 2282 Management access control determines the privileges that a user has 2283 for particular applications and parts of the network. Without such 2284 control, only the security of the data and control traffic is 2285 protected, leaving the devices providing the PPVPN network 2286 unprotected. Access control capabilities protect these devices to 2287 ensure that users have access to only the resources and applications 2288 to which they are authorized to use. 2290 In particular, access to the routing and switching resources managed 2291 by the SP must be tightly controlled to prevent and/or effectively 2292 mitigate a malicious attack. 2294 7.5.2 Authentication 2295 Authentication is the process of verifying that the sender is 2296 actually is who he or she says they are. The NMS must support 2297 standard methods for authenticating users attempting to access 2298 management services. 2300 Scalability is critical as the number of nomadic/mobile clients is 2301 increasing rapidly. The authentication scheme implemented for such 2302 deployments must be manageable for large numbers of users and VPN 2303 access points. 2305 Support for strong authentication schemes shall be supported to 2306 ensure the security of both VPN access point-to-VPN access point 2308 Carugi et al Informational - Expires October 2003 42 2310 Service requirements for Layer 3 PPVPNs April, 2003 2312 (PE to PE) and client-to-VPN Access point (CE-to-PE) communications. 2313 This is particularly important to prevent VPN access point spoofing. 2314 VPN Access Point Spoofing is the situation where an attacker tries 2315 to convince a PE or CE that the attacker is the VPN Access Point. 2316 If an attacker can convinces a PE or CE of that, then the device 2317 will send VPN traffic to the attacker (who could forward it on to 2318 your true access point after compromising confidentially or 2319 integrity). 2321 In other words, a non-authenticated VPN AP can be spoofed with a 2322 man-in-the-middle attack, because the endpoints never verify each 2323 other. A weakly-authenticated VPN AP may be subject to such an 2324 attack. However, strongly-authenticated VPN APs are not subject to 2325 such 2326 attacks, because the man-in-the-middle cannot authenticate as the 2327 real AP, due to the strong authentication algorithms. 2329 7.6 Network Management Techniques 2330 Each PPVPN solution approach must specify the management information 2331 bases (MIB) modules for network elements involved in PPVPN services. 2332 This is an essential requirement in network provisioning. The 2333 approach should identify any information not contained in a standard 2334 MIB related to FCAPS that is necessary to meet a generic 2335 requirement. 2337 The IP VPN Policy Information model should reuse the policy 2338 information models being developed in parallel for specific IP 2339 network capabilities [IM-REQ]. This includes the QoS Policy 2340 Information Model_[QPIM] and the IPSEC Configuration Policy Model_ 2341 [IPSECIM]. The information model should provide the OSS with 2342 adequate "hooks" to correlate service level specifications with 2343 traffic data collected from network elements. The use of policies 2344 includes rules that control corrective actions taken by OSS 2345 components responsible for monitoring the network and ensuring that 2346 it meets service requirements. 2348 Additional requirements on information models are given in reference 2349 [IM-PPVPN]. In particular, an information model must allow a service 2350 provider to change network dimensions with minimal influence on 2351 provisioning issues. The adopted model should be applicable to both 2352 small/medium size networks and large-scale PPVPN solutions. 2354 Some service providers may require systems that visually, audibly, 2355 or logically present FCAPS information to internal operators and/or 2356 customers. 2358 8 Security Considerations 2359 Security considerations occur at several levels and dimensions 2360 within Provider Provisioned VPNs, as detailed within this document. 2361 This section provides a summary with references to supporting 2362 detailed information. 2364 Carugi et al Informational - Expires October 2003 43 2366 Service requirements for Layer 3 PPVPNs April, 2003 2368 The requirements in this document separate the notion of traditional 2369 security requirements, such as integrity, confidentiality, and 2370 authentication as detailed in section 4.4 from that of isolating (or 2371 separating) the exchange of forwarded packets and exchange of 2372 routing information between specific sets of sites, as defined in 2373 sections 3.3 and 4.3. Further detail on security re quirements are 2374 given from the customer and service provider perspectives in 2375 sections 4.4 and 5.9, respectively. In an analogous manner, further 2376 detail on traffic and routing isolation requirements are given from 2377 the customer and service provider perspectives in sections 4.3 and 2378 5.8, respectively. 2380 Furthermore, requirements regarding management of security from a 2381 service provider perspective are described in section 7.5. 2383 9 Acknowledgements 2384 The authors of this document would like to acknowledge the 2385 contributions from the ITU-T people who launched the work on VPN 2386 requirements inside SG13, the authors of the original IP VPN 2387 requirements and framework document [RFC 2764], Tom Worster, Ron 2388 Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Nail Akar, 2389 Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic LeGarrec. The 2390 authors are also grateful to the helpful suggestions and direction 2391 provided by the technical advisors, Scott Bradner, Bert Wijnen and 2392 Rob Coltun. We would also like to acknowledge the insights and 2393 requirements gleaned from the many documents listed in the 2394 references section. Citations to these documents were made only 2395 where the authors believed that additional insight to the 2396 requirement could be obtained by reading the source document. 2398 10 References 2400 10.1 Normative References 2401 [PPVPN-GR] Nagaragan, A., "Generic Requirements for Provider 2402 Provisioned VPN," Work in Progress. 2403 [RFC 3377] J. Hodges, R. Morgan, �Lightweight Directory Access 2404 Protocol (v3): Technical Specification,� RFC 3377, 2405 September 2002 2406 [RFC 1918] Rekhter, Y. et al., "Address Allocation for Private 2407 Internets," RFC 1918, February 1996. 2408 [RFC 2026] Bradner, S., "The Internet Standards Process -- 2409 Revision 3", BCP 9, RFC 2026, October 1996. 2410 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2411 Requirement Levels", BCP 14, RFC 2119, March 1997 2412 [RFC 2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. 2413 Jamin, "Resource ReSerVation Protocol (RSVP) -- 2414 Version 1 Functional Specification," September 1997. 2415 [RFC 2211] J. Wroclawski, Specification of the Controlled-Load 2416 Network Element Service, RFC 2211, IETF, September 2417 1997. 2418 [RFC 2212] S. Shenker, C. Partridge, R Guerin, Specification of 2419 Guaranteed Quality of Service, RFC 2212, IETF, 2421 Carugi et al Informational - Expires October 2003 44 2423 Service requirements for Layer 3 PPVPNs April, 2003 2425 September 1997. 2426 [RFC 2251] Wahl, M. et al., "Lightweight Directory Access 2427 Protocol (v3)," RFC 2251, December 1997. 2428 [RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 2429 Weiss, "An Architecture for Differentiated 2430 Services", RFC 2475, Dec. 1998. 2431 [RFC 2597] "Assured Forwarding PHB Group", F. Baker, J. Heinanen, 2432 W. Weiss, J. Wroclawski, RFC 2597, 2433 [RFC 2661] Townsley, W. et al., "Layer Two Tunneling Protocol 2434 "L2TP"," RFC 2661, August 1999. 2435 [RFC 2685] Fox B., et al, "Virtual Private Networks Identifier", 2436 RFC 2685, September 1999. 2437 [RFC 2983] Black, D., �Differentiated Services and Tunnels�, 2438 RFC2983, October 2000 2439 [RFC 3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol 2440 Label Switching Architecture," January 2001. 2441 [RFC 3246] B. Davie et al, "An Expedited Forwarding PHB", RFC 2442 3246, March 2002. 2443 [RFC 3270] F. Le Faucheur et al, �Multi-Protocol Label Switching 2444 (MPLS) Support of Differentiated Services,� RFC 3270, 2445 May 2002 2447 10.2 Non-normative References 2448 [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work 2449 n progress. 2450 [2917bis] Muthukrishnan, K., et al., � A Core MPLS IP VPN 2451 Architecture�, work in progress 2452 [DOCSIS 1.1] Data Over Cable Service Interface Specification 2453 (DOCSIS), Cable Labs, 2454 http://www.cablemodem.com/specifications.html 2455 [FRF.13] Frame Relay Forum, "Service Level Definitions 2456 Implementation Agreement," August, 1998. 2457 [IM-PPVPN] P. Lago et al, "An Information Model for Provider 2458 Provisioned Virtual Private Networks," work in 2459 progress. 2460 [IM-REQ] M. Iyer et al, "Requirements for an IP VPN Policy 2461 Information Model," work in progress 2462 [IPSECIM] J. Jason, _"IPsec Configuration Policy Model," work 2463 in progress. 2464 [IPSEC-PPVPN] B. Gleeson, "Uses of IPsec with Provider Provisioned 2465 VPNs," work in progress. 2466 [L2 MPLS] L. Martini et al, �Transport of Layer 2 Frames Over 2467 MPLS,� work in progress. 2468 [L2 VPN] E. Rosen et al, "An Architecture for L2VPNs," work 2469 in progress. 2470 [L2 VPN] K. Kompella, R. Bonica, "Whither Layer 2 VPNs?," 2471 work in progress. 2472 [MPLS SEC] M. Behringer, "Analysis of the Security of the MPLS 2473 Architecture," work in progress 2474 [NBVPN-FR] Suzuki, M. and Sumimoto, J. (editors), "A framework 2475 for Network-based VPNs", work in progress 2476 [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for 2478 Carugi et al Informational - Expires October 2003 45 2480 Service requirements for Layer 3 PPVPNs April, 2003 2482 Provider Provisioned Virtual Private Networks ",work 2483 in progress 2484 [PPVPN-VR] H. Ould-Brahim, B. Gleeson et al. "Network based 2485 PPVPN Architecture using Virtual Routers", 2486 work in progress 2487 [QPIM] Snir, Ramberg, Strassner, Cohen and Moore,_"Policy 2488 QoS Information Model" work in progress. 2489 [RFC 2547] E. Rosen, Y. Rekhter, �BGP/MPLS VPNs,� RFC 2547,March 2490 1999. 2491 [RFC 2764] Gleeson, B., et al., "A Framework for IP based Virtual 2492 Private Networks", RFC 2764, February 2000 2493 [RFC 2975] B. Aboba et al, "Introduction to Accounting 2494 Management," October 2000. 2495 [RFC 3198] A. Westerinen et al, "Terminology for Policy-Based 2496 Management," November, 2001. 2497 [VPLS REQ] W. Augustyn et al, "Requirements for Virtual Private 2498 LAN Services (VPLS)," work in progress. 2499 [VPN DISC] M. Squire et al, "VPN Discovery Discussions and 2500 Options," work in progress. 2501 [VPN IW] H. Kurakami et al, "Provider-Provisioned VPNs 2502 Interworking," work in progress. 2503 [VPN SEC] J. De Clercq et al, "Considerations about possible 2504 security extensions to BGP/MPLS VPN," work in 2505 progress. 2506 [VPN TUNNEL] T. Worster et al, "A PPVPN Layer Separation: VPN 2507 Tunnels and Core Connectivity," work in progress 2508 [VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., 2509 "Criteria for Evaluating VPN Implementation 2510 Mechanisms", work in progress 2511 [VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment 2512 of an IP VPN service offering : a service provider 2513 perspective ", work in progress 2514 [VPN-VR] Ould-Brahim, H., Gleeson, B., et al. �Network based 2515 IP VPN Architecture using Virtual Routers�, work in 2516 progress 2517 [Y.1241] "IP Transfer Capability for the support of IP based 2518 Services", Y.1241 ITU-T Draft Recommendation, March 2519 2000 2520 [Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS 2521 architecture",Y.1311.1 ITU-T Recommendation, May 2001 2522 [Y.1311] Knightson, K. (editor), " Network based IP VPN Service 2523 - Generic Framework and Service Requirements ", Y.1311 2524 ITU-T Draft Recommendation, May 2001 2526 11 Authors' address 2528 Marco Carugi (Co-editor) 2529 Nortel Networks S.A. 2530 Parc d'activit�s de Magny-Les Jeunes Bois CHATEAUFORT 2531 78928 YVELINES Cedex 9 - FRANCE 2532 marco.carugi@nortelnetworks.com 2534 Carugi et al Informational - Expires October 2003 46 2536 Service requirements for Layer 3 PPVPNs April, 2003 2538 Dave McDysan (Co-editor) 2539 MCI 2540 22001 Loudoun County Parkway 2541 Ashburn, VA 20147, USA 2542 dave.mcdysan@mci.com 2544 Luyuan Fang 2545 AT&T 2546 200 Laurel Ave - Room C2-3B35 2547 Middletown, NJ 07748 USA 2548 Luyuanfang@att.com 2550 Ananth Nagarajan 2551 Sprint 2552 6220 Sprint Parkway, 2553 Overland Park, KS 66251, USA 2554 ananth.nagarajan@mail.sprint.com 2556 Junichi Sumimoto 2557 NTT Information Sharing Platform Labs. 2558 3-9-11, Midori-cho, 2559 Musashino-shi, Tokyo 180-8585, Japan 2560 Email: sumimoto.junichi@lab.ntt.co.jp 2562 Rick Wilder 2563 Masergy 2564 rwilder@masergy.com 2566 Full copyright statement 2568 Copyright (C) The Internet Society (1999). All Rights Reserved. 2570 This document and translations of it may be copied and furnished to 2571 others, and derivative works that comment on or otherwise explain it 2572 or assist its implementation may be prepared, copied, published and 2573 distributed, in whole or in part, without restriction of any kind, 2574 provided that the above copyright notice and this paragraph are 2575 included on all such copies and derivative works. However, this 2576 document itself may not be modified in any way, such as by removing 2577 the copyright notice or references to the Internet Society or other 2578 Internet organizations, except as needed for the purpose of 2579 developing Internet standards in which case the procedures for 2580 copyrights defined in the Internet Standards process must be 2581 followed, or as required to translate it into languages other than 2582 English. 2584 The limited permissions granted above are perpetual and will not be 2585 revoked by the Internet Society or its successors or assigns. 2587 This document and the information contained herein is provided on an 2588 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2590 Carugi et al Informational - Expires October 2003 47 2592 Service requirements for Layer 3 PPVPNs April, 2003 2594 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2595 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2596 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2597 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2599 Carugi et al Informational - Expires October 2003 48