INTERNET DRAFT M. Carugi Internet Engineering Task Force Nortel Networks Document: D. McDysan draft-ietf-l3vpn-requirements-00.txt MCI April 2003 (Co-Editors) Category: Informational Expires: October 2003 Service requirements for Layer 3 Provider Provisioned Virtual Private Networks: <draft-ietf-l3vpn-requirements-00.txt > Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 ([RFC-2026]). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a product of the IETF's Provider Provisioned Virtual Private Network (ppvpn) working group. Comments should be addressed to WG's mailing list at ppvpn@ppvpn.francetelecom.com. The charter for ppvpn may be found at http://www.ietf.org/html.charters/ppvpn-charter.html Copyright (C) The Internet Society (2000). All Rights Reserved. Distribution of this memo is unlimited. Abstract This document provides requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use for the provisioning of a VPN service. This document expresses a service provider perspective, based upon past experience of IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer as well as a service provider perspective. Carugi et al 1 Service requirements for Layer 3 PPVPNs April, 2003 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 ([RFC- 2119]). Table of Contents 1 Introduction....................................................5 1.1 Scope of this document.........................................5 1.2 Outline........................................................5 2 Contributing Authors............................................6 3 Definitions.....................................................6 3.1 Virtual Private Network Components.............................6 3.2 Users, Sites, Customers and Agents.............................6 3.3 Intranets, Extranets, and VPNs 7 3.4 Networks of Customer and Provider Devices......................7 3.5 Access Networks, Tunnels, and Hierarchical Tunnels.............8 3.6 Use of Tunnels and roles of CE and PE in L3 PPVPNs.............8 3.6.1 PE-Based Layer 3 PPVPNs and Virtual Forwarding Instances..8 3.6.2 CE-Based PPVPN Tunnel Endpoints and Functions............10 3.7 Customer and Provider Network Management......................10 4 Service Requirements Common to Customers and Service Providers.11 4.1 Traffic Types.................................................11 4.2 Topology......................................................11 4.3 Isolated Exchange of Data and Routing Information.............11 4.4 Security......................................................12 4.4.1 User data security.......................................12 4.4.2 Access control...........................................12 4.4.3 Site authentication and authorization....................12 4.5 Addressing....................................................12 4.6 Quality of Service............................................13 4.6.1 QoS Standards............................................13 4.6.2 Service Models...........................................14 4.7 Service Level Specification and Agreements....................15 4.8 Management....................................................16 4.9 Interoperability..............................................16 4.10 Interworking..................................................17 5 Customer Requirements..........................................17 5.1 VPN Membership (Intranet/Extranet)............................17 5.2 Service Provider Independence.................................17 5.3 Addressing....................................................17 5.4 Routing Protocol Support......................................18 5.5 Quality of Service and Traffic Parameters.....................18 5.5.1 Application Level QoS Objectives.........................18 5.5.2 DSCP Transparency........................................18 5.6 Service Level Specification/Agreement.........................19 5.7 Customer Management of a VPN..................................19 5.8 Isolation.....................................................19 5.9 Security......................................................19 5.10 Migration Impact..............................................20 Carugi et al Informational - Expires October 2003 2 Service requirements for Layer 3 PPVPNs April, 2003 5.11 Network Access................................................20 5.11.1 Physical/Link Layer Technology...........................20 5.11.2 Temporary Access.........................................21 5.11.3 Sharing of the Access Network............................21 5.11.4 Access Connectivity......................................21 5.12 Service Access................................................23 5.12.1 Internet Access..........................................23 5.12.2 Hosting, Application Service Provider....................23 5.12.3 Other Services...........................................24 5.13 Hybrid VPN Service Scenarios..................................24 6 Service Provider Network Requirements..........................24 6.1 Scalability...................................................24 6.1.1 Service Provider Capacity Sizing Projections.............24 6.1.2 Solution-Specific Metrics................................25 6.2 Addressing....................................................26 6.3 Identifiers...................................................26 6.4 Discovering VPN Related Information...........................27 6.5 SLA and SLS Support...........................................27 6.6 Quality of Service (QoS) and Traffic Engineering..............28 6.7 Routing.......................................................28 6.8 Isolation of Traffic and Routing..............................29 6.9 Security......................................................29 6.9.1 Support for Securing Customer Flows......................29 6.9.2 Authentication Services..................................30 6.9.3 Resource Protection......................................30 6.10 Inter-AS (SP)VPNs.............................................31 6.10.1 Routing Protocols........................................31 6.10.2 Management...............................................32 6.10.3 Bandwidth and QoS Brokering..............................32 6.10.4 Security Considerations..................................32 6.11 PPVPN Wholesale...............................................33 6.12 Tunneling Requirements........................................33 6.13 Support for Access and Backbone Technologies..................34 6.13.1 Dedicated Access Networks................................34 6.13.2 On-Demand Access Networks................................34 6.13.3 Backbone Networks........................................34 6.14 Protection, Restoration.......................................35 6.15 Interoperability..............................................35 6.16 Migration Support.............................................36 7 Service Provider Management Requirements.......................36 7.1 Fault management..............................................36 7.2 Configuration Management......................................37 7.2.1 Configuration Management for PE-Based VPNs...............38 7.2.2 Configuration management for CE-based VPN................38 7.2.3 Provisioning Routing.....................................39 7.2.4 Provisioning Network Access..............................39 7.2.5 Provisioning Security Services...........................39 7.2.6 Provisioning VPN Resource Parameters.....................39 7.2.7 Provisioning Value-Added Service Access..................39 7.2.8 Provisioning Hybrid VPN Services.........................41 7.3 Accounting....................................................41 7.4 Performance Management........................................41 Carugi et al Informational - Expires October 2003 3 Service requirements for Layer 3 PPVPNs April, 2003 7.4.1 Performance Monitoring...................................41 7.4.2 SLA and QoS management features..........................42 7.5 Security Management...........................................42 7.5.1 Management Access Control................................42 7.5.2 Authentication...........................................42 7.6 Network Management Techniques.................................43 8 Security Considerations........................................43 9 Acknowledgements...............................................44 10 References.....................................................44 10.1 Normative References..........................................44 10.2 Non-normative References......................................45 11 Authors' address...............................................46 Carugi et al Informational - Expires October 2003 4 Service requirements for Layer 3 PPVPNs April, 2003 1 Introduction This section describes the scope and outline of the document. 1.1 Scope of this document This document provides requirements specific to Layer 3 Provider Provisioned Virtual Private Networks (PPVPN). Requirements that are generic to L2 and L3 VPNs are contained in [PPVPN-GR]. It identifies requirements that may apply to one or more individual approaches that a Service Provider may use for the provisioning of a Layer 3 (e.g., IP) VPN service. The content of this document makes use of the terminologies and common components for deploying Layer 3 PPVPNs defined in [PPVPN-FR]. The specification of any technical means to provide PPVPN services is outside the scope of this document. Other documents, such as the framework document [PPVPN-FR] and several sets of documents, one set per each individual technical approach providing PPVPN services, are intended to cover this aspect. This document describes requirements for two types of network-based L3 PPVPNs: aggregated routing VPNs [RFC2547bis] and virtual routers [PPVPN-VR] and one type of CE-based PPVPN [IPsec-PPVPN]. The approach followed in this document distinguishes PPVPN types as to where the endpoints of tunnels exist as detailed in the PPVPN framework document [PPVPN-FR]. Terminology regarding whether equipment faces a customer or the service provider network is used to define the various types of PPVPN solutions. This document is intended as a "checklist" of requirements that will provide a consistent way to evaluate and document how well each individual approach satisfies specific requirements. The applicability statement documents for each individual approach should document the results of this evaluation. This document provides requirements from several points of view. It begins with common customer and service provider point of view, followed by a customer perspective, and concludes with specific needs of a Service Provider (SP). These requirements provide high- level PPVPN features expected by an SP in provisioning PPVPN to make them beneficial to his or her customers. These general requirements include SP requirements for security, privacy, manageability, interoperability and scalability, including service provider projections for number, complexity, and rate of change of customer VPNs over the next several years. 1.2 Outline The outline of the rest of this document is as follows. Section 2 defines terminology. Section 3 provides common requirements that apply to both customer and service providers. Section 4 states requirements from a customer perspective. Section 5 states network requirements from a service provider perspective. Section 6 states Carugi et al Informational - Expires October 2003 5 Service requirements for Layer 3 PPVPNs April, 2003 service provider management requirements. Section 7 describes security considerations. Section 8 lists acknowledgements. Section 9 provides a list of references cited herein. Section 10 lists the authorÆs addresses. 2 Contributing Authors This document was the combined effort of the editors and the following authors who contributed to this document: Luyuan Fang Ananth Nagarajan Junichi Sumimoto Rick Wilder 3 Definitions This section provides the definition of terms and concepts used throughout the document. [Editor's Note: this section may be moved to another PPVPN RFC that defines terminology.] 3.1 Virtual Private Network Components This document uses the word ôprivateö in VPN in the sense of ownership, which is different from the use of the similar word ôprivacyö used in discussions regarding security. The term ôvirtual privateö means that the offered service retains at least some aspects of a privately owned customer network. The term "Virtual Private Network" (VPN) refers to the communication between a set of sites, making use of a shared network infrastructure. Multiple sites of a private network may therefore communicate via the public infrastructure, in order to facilitate the operation of the private network. The logical structure of the VPN, such as topology, addressing, connectivity, reachability, and access control, is equivalent to part of or all of a conventional private network using private facilities. The term ôProvider Provisioned VPNö refers to VPNs for which the service provider participates in management and provisioning of the VPN. 3.2 Users, Sites, Customers and Agents User: A user is an entity (e.g., a human being using a host, a server, or a system) that has been authorized to use a VPN service. Site: A site is a set of users that have mutual IP reachability without use of a specific service provider network. A site may consist of a set of users that are in geographic proximity. However, two geographic locations connected via another provider's network would also constitute a single site since communication between the two locations does not involve the use of the service provider offering the VPN service. Carugi et al Informational - Expires October 2003 6 Service requirements for Layer 3 PPVPNs April, 2003 Customer: A single organization, corporation, or enterprise that administratively controls a set of sites. Agent: A set of users designated by a customer who has the authorization to manage a customer's VPN service offering. 3.3 Intranets, Extranets, and VPNs Intranet: An intranet restricts communication to a set of sites that belong to one customer. An example is branch offices at different sites that require communication to a headquarters site. Extranet: An extranet allows the specification of communication between a set of sites that belong to different customers. In other words, two or more organizations have access to a specified set of each other's sites. Examples of an extranet scenario include multiple companies cooperating in joint software development, a service provider having access to information from the vendors' corporate sites, different companies, or universities participating in a consortium. An extranet often has further restrictions on reachability, for example, at the host and individual transport level. Note that an intranet or extranet can exist across a single service provider network or across multiple service providers. Virtual Private Network (VPN): The term VPN is used within this document to refer to a specific set of sites as either an intranet or an extranet that have been configured to allow communication. Note that a site is a member of at least one VPN, and may be a member of many VPNs. 3.4 Networks of Customer and Provider Devices PPVPNs are composed of the following types of devices. Customer Edge (CE) device: A CE device faces the users at a customer site. The CE has an access connection to a PE device. It may be a router or a switch that allows users at a customer site to communicate over the access network with other sites in the VPN. In a CE-based PPVPN, the service provider manages (at least partially) the CE device. Provider Edge (PE) device: A PE device faces the provider network on one side and attaches via an access connection over one or more access networks to one or more CE devices. It may be a router or a label switching-router. Note that the definitions of Customer Edge and Provider Edge do not necessarily map to the physical deployment of equipment on customer premises or a provider point of presence. Carugi et al Informational - Expires October 2003 7 Service requirements for Layer 3 PPVPNs April, 2003 Provider (P) device: A device within a provider network that interconnects PE devices, but does not have any direct attachment to CE. Service Provider (SP) network: An SP network is a set of interconnected PE and P devices administered by a single service provider. 3.5 Access Networks, Tunnels, and Hierarchical Tunnels VPNs are built between CEs using access networks, tunnels, and hierarchical tunnels. Access connection: An access connection provides connectivity between a CE and a PE. This includes dedicated physical circuits, virtual circuits, such as frame Relay or ATM, Ethernet, or IP tunnels (e.g., IPsec, L2TP). Access network: An access network provides access connections between CE and PE devices. It may be a TDM network, L2 network (e.g. FR, ATM, and Ethernet), or an IP network over which access is tunneled (e.g., using L2TP [RFC2661]). Tunnel: A tunnel between two entities is formed by encapsulating packets within another encapsulating header for purpose of transmission between those two entities in support of a VPN application. Examples of protocols commonly used for tunneling are: GRE, IPsec, IP-in-IP tunnels, and MPLS. Hierarchical Tunnel: Encapsulating one tunnel within another forms a hierarchical tunnel. The innermost tunnel protocol header defines a logical association between two entities (e.g., between CEs or PEs) [VPN TUNNEL]. Note that the tunneling protocols need not be the same at different levels in a hierarchical tunnel. 3.6 Use of Tunnels and roles of CE and PE in L3 PPVPNs This section summarizes the point where tunnels terminate and the functions implemented in the CE and PE devices that differentiate the two major categories of PPVPNs for which requirements are stated, namely PE-based and CE-based PPVPNs. See the PPVPN framework document for more detail [PPVPN-FR]. 3.6.1 PE-Based Layer 3 PPVPNs and Virtual Forwarding Instances In a PE-based layer 3 PPVPN service, a customer site receives IP layer (i.e., layer 3) service from the SP. The PE is attached via an access connection to one or more CEs. The PE performs forwarding of user data packets based on information in the IP layer header, such as an IPv4 or IPv6 destination address. The CE sees the PE as a layer 3 device such as an IPv4 or IPv6 router. Virtual Forwarding Instance (VFI): In a PE-based layer 3 VPN service, the PE contains a VFI for each L3 VPN that it serves. The VFI terminates tunnels for interconnection with other VFIs and also Carugi et al Informational - Expires October 2003 8 Service requirements for Layer 3 PPVPNs April, 2003 terminates access connections for accommodating CEs. VFI contains information regarding how to forward data received over the access connection to the CE to VFIs in other PEs supporting the same L3 VPN. The VFI includes the router information base and forwarding information base for a L3 VPN [PPVPN-FR]. A VFI enables router functions dedicated to serving a particular VPN, such as separation of forwarding and routing and support for overlapping address spaces. Routing protocols in the PEs and the CEs interact to populate the VFI. The following narrative and figures provide further explanation of the way PE devices use tunnels and hierarchical tunnels. Figure 3.1 illustrates the case where a PE uses a separate tunnel for each VPN. As shown in the figure, the tunnels provide communication between the virtual switching/forwarding instances in each of the PE devices. +----------+ +----------+ +-----+ |PE device | |PE device | +-----+ | CE | | | | | | CE | | dev | Access | +------+ | | +------+ | Access | dev | | of | conn. | |VFI of| | Tunnel | |VFI of| | conn. | of | |VPN A|----------|VPN A |==================|VPN A |----------|VPN A| +-----+ | +------+ | | +------+ | +-----+ | | | | +-----+ Access | +------+ | | +------+ | Access +-----+ |CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE | | dev |----------|VPN B |==================|VPN B |----------| dev | | of | | +------+ | | +------+ | | of | |VPN B| | | | | |VPN B| +-----+ +----------+ +----------+ +-----+ Figure 3.1 PE Usage of Separate Tunnels to Support VPNs Figure 3.2 illustrates the case where a single hierarchical tunnel is used between PE devices to support communication for VPNs. The innermost encapsulating protocol header provides the means for the PE to determine the VPN for which the packet is directed. +----------+ +----------+ +-----+ |PE device | |PE device | +-----+ | CE | | | | | | CE | | dev | Access | +------+ | | +------+ | Access | dev | | of | conn. | |VFI of| | | |VFI of| | conn. | of | |VPN A|----------|VPN A | | Hierarchical |VPN A |----------|VPN A| +-----+ | +------+\| Tunnel | +------+ | +-----+ | >==================< | +-----+ Access | +------+/| |\+------+ | Access +-----+ | CE | conn. | |VFI of| | | |VFI of| | conn. | CE | | dev |----------|VPN B | | | |VPN B |----------| dev | | of | | +------+ | | +------+ | | of | |VPN B| | | | | |VPN B| +-----+ +----------+ +----------+ +-----+ Figure 3.2 PE Usage of a Shared Hierarchical Tunnels to Support VPNs Carugi et al Informational - Expires October 2003 9 Service requirements for Layer 3 PPVPNs April, 2003 3.6.2 CE-Based PPVPN Tunnel Endpoints and Functions Figure 3.3 illustrates the CE-based L3 VPN reference model. In this configuration, typically a single level of tunnel (e.g., IPsec) terminates at pairs of CEs. Usually, a CE serves a single customer site and therefore the forwarding and routing is physically separate from all other customers. Furthermore, the PE is not aware of the membership of specific CE devices to a particular VPN. Hence, the VPN functions are implemented using provisioned configurations on the CE devices and the shared PE and P network is used to only provide the routing and forwarding that supports the tunnel endpoints on between CE devices. The tunnel topology connecting the CE devices may be a full or partial mesh, depending upon VPN customer requirements and traffic patterns. +---------+ +--------------------------------+ +---------+ | | | | | | | | | +------+ +------+ : +------+ +------+ : | | | | | | : | CE | | CE | : | | | P | | PE | : |device| |device| : +------+ Tunnel |router| |device| : | of | | of |=:================================================:=|VPN A| |VPN A| : | | +------+ +------+ : +------+ +------+ : | PE | | | : | +------+ : |device| | | : | | CE | : | | Tunnel +------+ : +------+ |device|=:================================================:=| CE | | of | : +------+ | PE | : |device| |VPN B| : | | |device| : | of | +------+ : | | +----------+ +----------+ | | : |VPN B| | : | | | Customer | | Network | +------+ : +------+ |Customer | | |management| |management| | | : | |interface| | | function | | function | | |Customer | | | | +----------+ +----------+ | |interface| | | | | | | +---------+ +--------------------------------+ +---------+ | Access | |<-------- SP network(s) ------->| | Access | | network | | | | network | Figure 3.3 Provider Provisioned CE-based L3 VPN 3.7 Customer and Provider Network Management Customer Network Management Function: A Customer network management function provides the means for a customer agent to query or configure customer specific information, or receive alarms regarding his or her VPN. Customer specific information includes data related to contact, billing, site, access network, IP address, routing protocol parameters, etc. It may also include confidential data, such as encryption keys. It may use a combination of proprietary network management system, SNMP manager, or directory service (e.g., LDAP [RFC1777] [RFC2251]). Carugi et al Informational - Expires October 2003 10 Service requirements for Layer 3 PPVPNs April, 2003 Provider Network Management Function: A provider network management function provides many of the same capabilities as a customer network management system across all customers. This would not include customer confidential information, such as keying material. The intent of giving the provider a view comparable to that of customer network management is to aid in troubleshooting and problem resolution. Such a system also provides the means to query, configure, or receive alarms regarding any infrastructure supporting the PPVPN service. It may use a combination of proprietary network management system, SNMP manager, or directory service (e.g., LDAP [RFC1777] [RFC2251]). 4 Service Requirements Common to Customers and Service Providers This section contains requirements that apply to both the customer and the provider, or are of an otherwise general nature. [Editor's Note: Some of the material in this section is generic to L2 and L3 VPNs and may be deleted if the draft proposed for [PPVPN- GR] is accepted.] 4.1 Traffic Types PPVPN services must support unicast traffic and should support multicast traffic. It is highly desirable to support L3 multicast limited in scope to an intranet or extranet. The solution should be able to support a large number of such intranet or extranet specific multicast groups in a scalable manner. 4.2 Topology A PPVPN should support arbitrary, customer agent defined inter-site connectivity, ranging, for example, from hub-and-spoke, partial mesh to full mesh topology. To the extent possible, a PPVPN service should be independent of the geographic extent of the deployment. A PPVPN should support multiple VPNs per customer site. To the extent possible, the PPVPN services should be independent of access network technology. 4.3 Isolated Exchange of Data and Routing Information A mechanism for isolating the distribution of reachability information to only those sites associated with a VPN must be provided. PPVPN solutions shall define means that prevent routers in a VPN from interaction with unauthorized entities and avoid introducing undesired routing information that could corrupt the VPN routing information base [VPN-CRIT]. A means to constrain, or isolate, the distribution of addressed data to only those VPN sites determined either by routing data and/or configuration must be provided. Carugi et al Informational - Expires October 2003 11 Service requirements for Layer 3 PPVPNs April, 2003 A single site shall be capable of being in multiple VPNs. The VPN solution must ensure that traffic is exchanged only with those sites that are in the same VPN. The internal structure of a VPN should not be advertised nor discoverable from outside that VPN. Note that isolation of forwarded data and/or exchange of reachability information to only those sites that are part of a VPN may be viewed as a form of security, for example, [Y.1311.1],[MPLS SEC]. 4.4 Security A range of security features should be supported by the suite of PPVPN solutions [VPN SEC]. Each PPVPN solution should state which security features it supports and how such features can be configured on a per customer basis. 4.4.1 User data security PPVPN solutions that support user data security should use standard methods (e.g., IPsec) to achieve confidentiality, integrity, authentication and replay attack prevention. 4.4.2 Access control A PPVPN solution may also have the ability to activate the appropriate filtering capabilities upon request of a customer [VPN- NEEDS]. A filter provides a mechanism so that access control can be invoked at the point(s) of communication between different organizations involved in an extranet. Access control can be implemented by a firewall, access control lists on routers or similar mechanisms to apply policy-based access control to transit traffic. 4.4.3 Site authentication and authorization A L3 VPN solution requires authentication and authorization of the following: - temporary and permanent access for users connecting to sites (authentication and authorization BY the site) - the site itself (authentication and authorization FOR the site) 4.5 Addressing A service provider shall accept unique IP addresses obtained by a customer or be capable of providing unique IP addresses to a customer. In the event that IP addresses are not unique, an L3 VPN service shall support overlapping customer addresses, for example non-unique private IP addresses [RFC1918]. IP addresses must be unique within the set of sites reachable from the VPNs of which a particular site is a member. Carugi et al Informational - Expires October 2003 12 Service requirements for Layer 3 PPVPNs April, 2003 A VPN solution must support IPv4 and IPv6 as both the encapsulating and encapsulated protocol. A VPN service should be capable of translating customer private IP addresses for communicating with IP systems having public addresses. FR and ATM link layer identifiers (i.e., DLCI and VPI/VCI) shall be unique only on a physical interface basis. Normally, Ethernet MAC addresses on access connections are globally unique. 4.6 Quality of Service To the extent possible, L3 VPN QoS should be independent of the access network technology. 4.6.1 QoS Standards According to the PPVPN charter, a non-goal is the development of new protocols or extension of existing ones. Therefore, with regards to QoS support, a PPPVN shall be able to support QoS in one or more of the following already standardized modes: - Best Effort (support mandatory for all PPVPN types) - Aggregate CE Interface Level QoS (i.e., ôhoseö level) - Site-to-site, or ôpipeö level QoS - Intserv (i.e., RSVP) signaled - Diffserv marked - Across packet-switched access networks Note that all cases involving QoS may require that the CE and/or PE perform shaping and/or policing. PPVPN CE should be capable of supporting integrated services (Intserv) for certain customers in support of session applications, such as switched voice or video. Intserv-capable CE devices shall support the following Internet standards: - Resource reSerVation Protocol (RSVP) [RFC 2205] - Guaranteed Quality of Service providing a strict delay bound [RFC 2212] -Controlled Load Service providing performance equivalent to that of an unloaded network [RFC 2211] PPVPN CE and PE should be capable of supporting differentiated service (diffserv). In diffserv Per Hop Behavior PHB - a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate [RFC 2475]. Diffserv- capable PPVPN CE and PE shall support the following per hop behavior (PHB) types: - Expedited Forwarding (EF) - the departure rate of an aggregate class of traffic from a router that must equal or exceed a configured rate [RFC 3246]. - Assured Forwarding (AF) - is a means for a provider DS domain to offer different levels of forwarding assurances for IP packets Carugi et al Informational - Expires October 2003 13 Service requirements for Layer 3 PPVPNs April, 2003 received from a customer DS domain. Four AF classes are defined, where each AF class is in each DS node allocated a certain amount of forwarding resources (e.g., buffer space and bandwidth) [RFC 2597]. A customer, CE, or PE device supporting a L3 VPN service may classify a packet for a particular Intserv or Diffserv service based on upon one or more of the following IP header fields: protocol ID, source port number, destination port number, destination address, or source address. For a specifiable set of Internet traffic, L3 PPVPN devices should support Random Early Detection (RED) to provide graceful degradation in the event of network congestion. The need to provide QoS will occur primarily in the access network, since that will often be the bottleneck. This is likely to occur since the backbone effectively statistically multiplexes many users, is traffic engineered, and in some cases also includes capacity for restoration and growth. There are two directions of QoS management that must be considered in any PPVPN service regarding QoS: - From the CE across the access network to the PE - From the PE across the access network to CE PPVPN CE and PE devices should be capable of supporting QoS across a subset of the access networks defined in section 5.11, such as: - ATM Virtual Connections (VCs) - Frame Relay Data Link Connection Identifiers (DLCIs) - 802.1d Prioritized Ethernet - MPLS-based access - Multilink Multiclass PPP - QoS-enabled wireless (e.g., LMDS, MMDS) - Cable modem [DOCSIS 1.1] - QoS-enabled Digital Subscriber Line (DSL) 4.6.2 Service Models A service provider must be able to offer QoS service to a customer for at least the following generic service types: managed access VPN service or an edge-to-edge QoS service. A managed access L3 PPVPN service provides QoS on the access connection between the CE and the PE. For example, diffserv would be enabled only on the CE router and the customer-facing ports of the PE router. Note that this service would not require implementation of DiffServ in the SP IP backbone. The SP may use policing for inbound traffic at the PE. The CE may perform shaping for outbound traffic. Another example of a managed access L3 VPN service is where the SP performs the packet classification and diffserv marking. An SP may provide several packet classification profiles that customers may select, or may offer a service that offers custom profiles based upon customer specific requirements. In general, more complex QoS policies should be left to the customer for implementation. Carugi et al Informational - Expires October 2003 14 Service requirements for Layer 3 PPVPNs April, 2003 An edge-to-edge QoS VPN service provides QoS from provider edge to provider edge. The provider edge may be either PE or CE depending upon the service demarcation point between the provider and the customer. Such a service may be provided across one or more provider backbones. The CE requirements for this service model are the same as the managed access VPN service. However, in this service QoS is provided from one edge of the SP network(s) to the other edge. 4.7 Service Level Specification and Agreements A Service Level Specification (SLS) may be defined per access network connection, per VPN, per VPN site, and/or per VPN route. The service provider may define objectives and the measurement interval for at least the SLS using the following Service Level Objective (SLO) parameters: O QoS and traffic parameters for the Intserv flow or Diffserv class O Availability for the site, VPN, or access connection O Duration of outage intervals per site, route or VPN O Service activation interval (e.g., time to turn up a new site) O Trouble report response time interval O Time to repair interval O Total traffic offered to the site, route or VPN O Measure of non-conforming traffic for the site, route or VPN The above list contains items from [Y.1241], as well as other items typically part of SLAs for currently deployed VPN services [FRF.13]. See RFC 3198 for generic definitions of SLS, SLA, and SLO. The provider network management system shall measure, and report as necessary, whether measured performance meets or fails to meet the above SLS objectives. The service provider and the customer may negotiate a contractual arrangement that includes a Service Level Agreement (SLA) regarding compensation if the provider does not meet an SLS performance objective. Details of such compensation are outside the scope of this document. SLS measurements for quality based on the DiffServ scheme should be based upon the following classification [Y.1311.1]: A Point-to-Point SLS, sometimes also referred to as the "Pipe" model, defines traffic parameters in conjunction with the QoS objectives for traffic exchanged between a pair of VPN sites (i.e., points). A Point-to-Point SLS is analogous to the SLS typically supported over point-to-point Frame Relay or ATM PVCs or an edge- to-edge MPLS tunnel. The set of SLS specifications to all other reachable VPN sites would define the overall Point-to-Point SLS for a specific site. A Point-to-Cloud SLS, sometimes also referred as the "Hose" model, defines traffic parameters in conjunction with the QoS objectives Carugi et al Informational - Expires October 2003 15 Service requirements for Layer 3 PPVPNs April, 2003 for traffic exchanged between a CE and a PE for traffic destined to a set (either all or a subset) of other sites in the VPN (i.e., the cloud), as applicable. In other words, a point-to-cloud SLS defines compliance in terms of all packets transmitted from a given VPN site toward the SP network on an aggregate basis (i.e., regardless of the destination VPN site of each packet). A Cloud-to-Point SLS, is the case where flows originating from multiple sources may congest the interface from the network toward a specific site, which this SLS does not cover. Traffic parameters and actions should be defined for packets to and from the demarcation between the service provider and the site. For example, policing may be defined on ingress and shaping on egress. 4.8 Management An SP and its customers must be able to manage the capabilities and characteristics of their VPN services. To the extent possible, automated operations and interoperability with standard management platforms should be supported. The ITU-T Telecommunications Management Network (TMN) model has the following generic requirements structure: O Engineer, deploy and manage the switching, routing and transmission resources supporting the service, from a network perspective (network element management); O Manage the VPNs deployed over these resources (network management); o Manage the VPN service (service management); o Manage the VPN business, mainly provisioning administrative and accounting information related to the VPN service customers (business management). Service management should include the TMN 'FCAPS' functionalities, as follows: Fault, Configuration, Accounting, Provisioning, and Security, as detailed in section 7. 4.9 Interoperability Each technical solution should support the Internet standards (in terms of compatibility and modularity). Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution should be guaranteed (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers. The technical solution must be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the PPVPN service. Carugi et al Informational - Expires October 2003 16 Service requirements for Layer 3 PPVPNs April, 2003 4.10 Interworking Interworking scenarios among different solutions providing PPVPN services is highly desirable. See the PPVPN framework document for more details on interworking scenarios [PPVPN-FR]. Interworking should be supported in a scalable manner. Interworking scenarios must consider at least traffic and routing isolation, security, QoS, access, and management aspects. This requirement is essential in the case of network migration, to ensure service continuity among sites belonging to different portions of the network. 5 Customer Requirements This section captures additional requirements from a customer perspective. 5.1 VPN Membership (Intranet/Extranet) When an extranet is formed, a customer agent from each of the organizations must approve addition of a site to an extranet VPN. The intent of this requirement is to ensure that both organizations approve extranet communication before the PPVPN allows exchange of traffic and routing information. 5.2 Service Provider Independence Customers may require VPN service that spans multiple administrative domains or service provider networks. Therefore, a VPN service must be able to span multiple AS and SP networks, but still act and appear as a single, homogenous VPN from a customer point of view. A customer might also start with a VPN provided in a single AS with a certain SLA but then ask for an expansion of the service spanning multiple ASs/SPs. In this case, as well as for all kinds of multi- AS/SP VPNs, VPN service should be able to deliver the same SLA to all sites in a VPN regardless of the AS/SP to which it homes. 5.3 Addressing A customer requires support from a L3 VPN for the following addressing IP assignment schemes: o customer assigned, non-unique, or RFC 1918 private addresses o globally unique addresses obtained by the customer o globally unique addresses statically assigned by the PPVPN service provider o on-demand, dynamically assigned IP addresses (e.g., DHCP), irrespective of whether the access is temporary (e.g., remote) or permanent (i.e., dedicated) In the case of combined L3 PPVPN service with non-unique or private addresses and Internet access, mechanisms that permit the exchange of traffic between the customer's private address space and the global unique Internet address space must be supported, for example, NAT. Carugi et al Informational - Expires October 2003 17 Service requirements for Layer 3 PPVPNs April, 2003 5.4 Routing Protocol Support There should be no restriction on the routing protocols used between CE and PE routers, or between CE routers. At least the following protocols must be supported: static routing, IGP, such as RIP, OSPF, IS-IS, and BGP [PPVPN-FR]. 5.5 Quality of Service and Traffic Parameters QoS is expected to be an important aspect of a PPVPN service for some customers. QoS requirements cover scenarios involving an intranet, an extranet, as well as shared access between a VPN site and the Internet. 5.5.1 Application Level QoS Objectives A customer is concerned primarily that the PPVPN service provide his or her application has the QoS and level of traffic such that the application performs acceptably. Pseudo-wires (e.g., SONET emulation) voice and interactive video, and multimedia applications are expected to require the most stringent QoS. These real-time applications are sensitive to delay, delay variation, loss, availability and/or reliability. Another set of applications requires near real time performance. Examples are multimedia, interactive video, high-performance web browsing and file transfer intensive applications. Finally, best effort applications are not sensitive to degradation. That is, they are elastic and can adapt to conditions of degraded performance. The selection of appropriate QoS and service type to meet specific application requirements is particularly important to deal with periods of congestion in a SP network. Sensitive applications will likely select per-flow Integrated service (Intserv) with precise SLA guarantees measured on a per flow basis. On the other hand, non- sensitive applications will likely rely on a Differentiated service (Diffserv) class-based QoS. The fundamental customer application requirement is that a PPVPN solution must support both the Intserv QoS model for selected individual flows, and Diffserv for aggregated flows. A customer application should experience consistent QoS independent of the access network technology used at different sites connected to the same VPN. 5.5.2 DSCP Transparency The Diffserv Code Point (DSCP) set by a user as received by the ingress CE should be capable of being relayed transparently to the egress CE [See section 2.6.2 of RFC 3270 and Y.1311.1]. Although RFC 2475 states that interior or boundary nodes within a providerÆs Diffserv domain may change the DSCP, customer VPNs may have other requirements, such as: o Applications that use the DSCP in a manner differently than the DSCP solution supported by the SP network(s); Carugi et al Informational - Expires October 2003 18 Service requirements for Layer 3 PPVPNs April, 2003 o Customers using more DSCPs within their sites than the SP network(s) supports; o Support for a carriers' carrier service where one SP is the customer of another PPVPN SP. Such an SP should be able to resell VPN service to his or her VPN customers independently of the DSCP mapping solution supported by the carriersÆ carrier SP. Note that support for DSCP transparency has no implication on the QoS or SLA requirements. If an SP supports DSCP transparency, then that SP needs to only carry the DSCP values across its domain, but may map the received DSCP to some other value for QoS support across its domain. 5.6 Service Level Specification/Agreement Most customers simply want their applications to perform well. An SLA is a vehicle for customer recourse in the event that SP(s) do not perform or manage a VPN service well in a measurable sense. Therefore, when purchasing service under an SLA, a customer agent must have access to the measures from the SP(s) that support the SLA. 5.7 Customer Management of a VPN A customer must have a means to view the topology, operational state, order status, and other parameters associated with his or her VPN. All aspects of management information about CE devices and customer attributes of a PPVPN manageable by an SP should be capable of being configured and maintained by an authenticated, authorized customer agent. A customer agent should be able to make dynamic requests for changes to traffic parameters. A customer should be able to receive real- time response from the SP network in response to these requests. One example of such as service is a "Dynamic Bandwidth management" capability, that enables real-time response to customer requests for changes of allocated bandwidth allocated to their VPN(s)[Y.1311.1]. A customer who may not be able to afford the resources to manage their own sites should be able to outsource the management of his or her VPN to the service provider(s) supporting the network. 5.8 Isolation These features include traffic and routing information exchange isolation, similar to that obtained in VPNs based on Layer 1 and Layer 2 (e.g., private lines, FR, or ATM) [MPLS SEC]. 5.9 Security The suite of PPVPN solutions should support a range of security related features. Higher levels of security services, like edge-to- edge encryption, authentication, or replay attack should be supported. Carugi et al Informational - Expires October 2003 19 Service requirements for Layer 3 PPVPNs April, 2003 Security in a PPVPN service should be as transparent as possible to the customer, with the obvious exception of support for remote or temporary user access, as detailed in section 5.11.2. PPVPN customers must be able to deploy their own internal security mechanisms in addition to those deployed by the SP, in order to secure specific applications or traffic at a granularity finer than a site-to-site basis. If a a customer desires QoS support in a L3 PPVPN, then these must be communicated to the SP either using unencrypted fields or else via an agreed to security association. For example, applications must send RSVP messages in support of Intserv either in the clear or encrypted using a key negotiated with the SP. Another case is where applications using an IPsec tunnel must copy the DSCP from the encrypted IP header to the header of the tunnelÆs IP header. Security services shall apply to: o either, all VPN traffic exchanged between different sites ; o or, a subset of the VPN traffic between sites as identified by a combination of the destination IP address, the Security Profile Index (SPI) and the IPsec AH or ESP identifier. 5.10 Migration Impact Often, customers are migrating from an already deployed private network toward one or more Provider Provisioned VPN solutions. A typical private network scenario is CE routers connected via real or virtual circuits. Ideally, minimal incremental cost should result during the migration period. Furthermore, if necessary, any disruption of service should also be minimized. A range of scenarios of customer migration must be supported. Full migration of all sites must be supported. Support for cases of partial migration is highly desirable [Y.1311.1], that is, legacy private network sites that belong to the PPVPN service should still have L3 reachability to the sites that migrate to the PPVPN service. 5.11 Network Access Every L3 packet exchanged between the customer and the SP over the access connection must appear as it would on a private network providing an equivalent service to that offered by the PPVPN. 5.11.1 Physical/Link Layer Technology PPVPNs should support a broad range of physical and link layer access technologies, such as PSTN, ISDN, xDSL, cable modem, leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, mobile radio access, etc. The capacity and QoS achievable may be dependent on the specific access technology in use. Carugi et al Informational - Expires October 2003 20 Service requirements for Layer 3 PPVPNs April, 2003 5.11.2 Temporary Access The VPN service offering should allow both permanent and temporary access to one or more PPVPNs for authenticated users across a broad range of access technologies. Support for remote or temporary VPN access should include ISDN, PSTN dial-in, xDSL or access via another SP network. The customer should be able to choose from alternatives for authentication of temporary access users. Choices for access authentication are: SP-provided, third-party, or customer-provided authentication servers. A significant number of VPN users are not permanently attached to one VPN site. In order to limit access to a VPN to only authorized users, it is first necessary to authenticate them. Authentication shall apply as configured by the customer agent and/or SP where a specific user may be part of one or more VPNs. The authentication function should be used to automatically invoke all actions necessary VPN communication. A user should be able to access a PPVPN via a network having generic Internet access. Mobile users may move within a PPVPN site. Mobile users may also temporarily connect to another PPVPN site within the same VPN. Authentication should be provided for both of these cases. 5.11.3 Sharing of the Access Network In a PE-based PPVPN, if the site shares the access network with other traffic (e.g., access to the Internet), then data security in the access network is the responsibility of the PPVPN customer. 5.11.4 Access Connectivity Various types of physical connectivity scenarios must be supported, such as multi-homed sites, backdoor links between customer sites, devices homed to two or more SP networks. PPVPN solutions should support at least the types of physical or link-layer connectivity arrangements shown in Figure 5.1. Support for other physical connectivity scenarios with arbitrary topology is desirable. Access arrangements with multiple physical or logical paths from a CE to other CEs and PEs must support redundancy, and should support load balancing. Resiliency uses redundancy to provide connectivity between a CE site and other CE sites, and optionally, other services. Load balancing provides a means to perform traffic engineering such that capacity on redundant links is used to achieve improved performance during periods when the redundant component(s) are available. Carugi et al Informational - Expires October 2003 21 Service requirements for Layer 3 PPVPNs April, 2003 +---------------- +--------------- | | +------+ +------+ +---------| PE | +---------| PE | | |router| | |router| SP network | +------+ | +------+ +------+ | +------+ | | CE | | | CE | +--------------- |device| | SP network |device| +--------------- +------+ | +------+ | | +------+ | +------+ | | PE | | | PE | +---------|router| +---------|router| SP network +------+ +------+ | | +---------------- +--------------- (a) (b) +---------------- +--------------- | | +------+ +------+ +------+ +------+ | CE |-----| PE | | CE |-----| PE | |device| |router| |device| |router| SP network +------+ +------+ +------+ +------+ | | | | | Backdoor | | Backdoor +--------------- | link | SP network | link +--------------- | | | | +------+ +------+ +------+ +------+ | CE | | PE | | CE | | PE | |device|-----|router| |device|-----|router| SP network +------+ +------+ +------+ +------+ | | +---------------- +--------------- (c) (d) +---------------- +--------------- | | +------+ +------+ +------+ +------+ | CE |-----| PE | | CE |-----| PE | |device| |router| |device| |router| SP network +------+\ +------+ +------+\ +------+ | \ | | \ | |Back \ | |Back \ +--------------- |door \ | SP network |door \ +--------------- |link \ | |link \ | +------+ +------+ +------+ +------+ | CE | | PE | | CE | | PE | |device|-----|router| |device|-----|router| SP network +------+ +------+ +------+ +------+ | | +---------------- +--------------- (e) (f) Figure 5.1 Representative types of access arrangements. Carugi et al Informational - Expires October 2003 22 Service requirements for Layer 3 PPVPNs April, 2003 For multi-homing to a single SP, load balancing capability should be supported by the PE across the CE to PE links. For example, in case (a), load balancing should be provided by the two PEs over the two links connecting to the single CE. In case (c), load balancing should be provided by the two PEs over the two links connecting to the two CEs. In addition, the load balancing parameters (e.g., the ratio of traffic on the multiple load-balanced links, or the preferred link) should be provisionable based on customerÆs requirements. The load balancing capability may also be used to achieve resiliency in the event of access connectivity failures. For example, in cases (b) a CE may connect to two different SPs via diverse access networks. Resiliency may be further enhanced as shown in case (d), where CE's connected via a "back door" connection connect to different SPs. Furthermore, arbitrary combinations of the above methods, with a few examples shown in cases (e) and (f) should be supportable by any PPVPN approach. For multi-homing to multiple SPs, load balancing capability may also be supported by the PEs in the different SPs (clearly, this is a more complex type of load balancing to realize, and requires policy and service agreements between the SPs to interoperate). 5.12 Service Access Customers may also require access to other services, as described in this section. 5.12.1 Internet Access Customers should be able to have L3 PPVPN and Internet access across the same access network for one or more of the customer's sites. Customers should be able to direct Internet traffic from the set of sites in the PPVPN to one or more customer sites that have firewalls, other security-oriented devices, and/or NAT that process all traffic between the Internet and the customer's VPN. L3 PPVPN Customers should be able to receive traffic from the Internet addressed to a publicly accessible resource that is not part of the VPN, such as an enterprise's public web server. As stated in section 5.3, network address translation (NAT) or similar mechanism must be provided either by the customer or the SP in order to be able to interchange traffic between devices assigned non-unique or private IP addresses and devices that have unique IP addresses. 5.12.2 Hosting, Application Service Provider A customer should be able to access hosting, other application services, or other Application Service Providers (ASP) over a L3 Carugi et al Informational - Expires October 2003 23 Service requirements for Layer 3 PPVPNs April, 2003 PPVPN service. This may require that an ASP participates in one or more VPNs with the customers that use such a service. 5.12.3 Other Services In conjunction with a VPN service, a customer may also wish to have access to other services, such as: DNS, FTP, HTTP, NNTP, SMTP, LDAP, VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business, Streaming, E-commerce, Directory, Firewall, etc. The resource(s) that implement these services could be physically dedicated to each VPN. If the resource(s) are logically shared, then they need to have access separated and isolated between VPNs in a manner consistent with the PPVPN solution to meet this requirement. 5.13 Hybrid VPN Service Scenarios Intranet or extranet customers have a number of reasons for wanting hybrid networks that involve more than one VPN solution type. These include migration, mergers, extranet customers with different VPN types, the need for different capabilities between different sets of sites, temporary access, different availability of VPN solutions as provided by different service providers. The framework and solution approaches should include provisions for interworking, interconnection, and/or reachability between different PPVPN solutions in such a way that does not overly complicate provisioning, management, scalability, or performance. 6 Service Provider Network Requirements This section describes requirements from a service provider perspective. 6.1 Scalability This section contains projections regarding PPVPN sizing projections and scalability requirements and metrics specific to particular solutions. 6.1.1 Service Provider Capacity Sizing Projections This section captures projections for scaling requirements over the next several years in terms of number of VPNs, number of interfaces per VPN, number of routes per VPN, and the rate of VPN configuration changes. These numbers provide a baseline against which the scalability of specific approaches can be assessed. These values were derived from ITU-T [Y.1311.1] and inputs from service providers. A PPVPN solution should be scalable to support a very large number of VPNs per Service Provider network. The estimate is that a large service provider will require support for on the order of 10,000 VPNs within four years. A PPVPN solution should be scalable to support of a wide range of number of site interfaces per VPN, depending on the size and/or structure of the customer organization. The number of site Carugi et al Informational - Expires October 2003 24 Service requirements for Layer 3 PPVPNs April, 2003 interfaces should range from a few site interfaces to over 50,000 site interfaces per VPN. A PPVPN solution should be scalable to support of a wide range of number of routes per VPN. The number of routes per VPN may range from just a few to the number of routes exchanged between ISPs using BGP (in 2001, on the order of 100,000). Typically, the number of routes per VPN is O(2N), where N is the number of site interfaces. A PPVPN solution should support high values of the frequency of configuration setup and change, e.g. for real-time provisioning of an on-demand videoconferencing VPN. As a guideline, an estimate on the VPN frequency of change (e.g., addition/removal of sites per VPN per time unit) could be as large as 1 million per year across all service providers within the next four years. Approaches should articulate scaling and performance limits for more complex deployment scenarios, such as inter-AS(S) VPNs and carriers' carrier. Approaches should also describe other dimensions of interest, such as capacity requirements or limits, number of interworking instances supported as well as any scalability implications on management systems. 6.1.2 Solution-Specific Metrics Each PPVPN solution shall document its scalability characteristics in quantitative terms. Several examples are provided below as an illustration. The number of tunnels necessary per device is one metric of interest. In a PE-based VPN, tunnels potentially from every PE to every other PE must be set up for each VPN. Or, a full mesh of tunnels between PEs can be shared across many VPNs using hierarchical tunnels. In a CE-based VPN, end-to-end tunnels between pairs of CE's in a full or partial mesh are necessary, but PEs need not be aware of these tunnels at all. Furthermore, in a CE-based VPN, the tunnels endpoints are distributed to the CEs in a particular VPN. Another metric is that of complexity. In a PE-based solution the PE is more complex in that it must maintain a VFI must for each VPN, but the CE is simpler since it needs to support no tunnels. On the other hand, in a CE-based solution, the CE is more complex since it must implement routing across a number of tunnels to other CEs in the VPN, but the PE is simpler since it has only one routing and forwarding instance. A PE-based solution should quantify the amount of state that a PE and P router must support. This should be stated in terms of the total number of VPNs and site interfaces supported by the service provider. Ideally, all VPN-specific state should be contained in the PE router, since routing and/or configuration information depends only on the VPNs whose site(s) are connected to that PE. However, Carugi et al Informational - Expires October 2003 25 Service requirements for Layer 3 PPVPNs April, 2003 this should be balanced against the requirements of specific services, such as multicast, which may require per VPN state in the P router. A CE-based solution should quantify the state and scaling limits. This should be stated in terms of the number of tunnels supported, how these tunnels are provisioned and maintained (e.g., key exchange), how routing occurs across these tunnels, and what the impact of changes in the network topology do to the convergence performance of such a solution. 6.2 Addressing As described in section 4.4, SPs require support for public and private IP addresses, IPv4 and IPv6, for both unicast and multicast. In order to support this range of addressing schemes, SPs require the following support from PPVPN solutions. A L3 PPVPN solution must be able to assign blocks of addresses form its own public IP address space to PPVPN customer sites in such a way that advertisement of routes to other SPs and other sites aggregates efficiently. A PPVPN solution must be able to use address assignments made by a customer. These customer assigned addresses may be public, or private. In the case where private IP addresses are used, a PPVPN solution must provide a means for an SP to translate such addresses to public IP addresses for communication with other VPNs using overlapping addresses, or the Internet. 6.3 Identifiers A number of identifiers may be necessary for SP use in management, control, and routing protocols. Requirements for at least the following identifiers are known. An SP domain must be uniquely identified at least within the set of all interconnected SP networks when supporting a VPN that spans multiple SPs. Ideally, this identifier should be globally unique (e.g., an AS number). An identifier for each VPN should be unique, at least within each SP's network. Ideally, the VPN identifier should be globally unique to support the case where a VPN spans multiple SPs (e.g., [RFC 2685]). A CE device should have a unique identifier, at least within each SP's network. A PE device should have a unique identifier, at least within each SP's network. Carugi et al Informational - Expires October 2003 26 Service requirements for Layer 3 PPVPNs April, 2003 The identifier of a device interconnecting SP networks must be unique within the set of aforementioned networks. Each site interface should have a unique identifier, at least within each PE router supporting such an interface. Each tunnel should have a unique identifier, at least within each router supporting the tunnel. 6.4 Discovering VPN Related Information Configuration of CE and PE devices is a significant task for a service provider. Solutions should strive to contain methods that that dynamically allows VPN information to be discovered (or learned) by the PE and/or CE to reduce configuration complexity. The following specific requirements apply to intra and inter-provider VPNs [VPN DISC]. Every device involved in a VPN shall be able to identify and authenticate itself to other devices in the VPN. After learning the VPN membership, the devices should be able to securely exchange configuration information. The VPN information must include at least the IP address of the PE and may be extensible to provide additional information. Each device in a VPN should be able to determine which other devices belong to the same VPN. Such a membership discovery scheme must prevent unauthorized access and allows authentication of the source. Distribution of VPN information should be limited to those devices involved in that VPN. In the case of a PE-based VPN, a solution should support the means for attached CEs to authenticate each other and verify that the service provider VPN is correctly configured. The mechanism should respond to VPN membership changes in a timely manner. A "timely manner" is no longer than the provisioning timeframe, typically on the order of minutes, and may be as short as the timeframe required for "rerouting," typically on the order of seconds. Dynamically creating, changing, and managing multiple VPN assignments to sites and/or customers is another aspect of membership that must be addressed in a L3 PPVPN solution. 6.5 SLA and SLS Support Typically, a Service Provider offering a PPVPN service commits to specific Service Level Specifications (SLS) as part of a contract with the customer, as described in section 4.7. Such a Service Level Agreement (SLA) drives the following specific SP requirements for measuring Specific Service Level Specifications (SLS) for quality, availability, response time, and configuration intervals. Carugi et al Informational - Expires October 2003 27 Service requirements for Layer 3 PPVPNs April, 2003 6.6 Quality of Service (QoS) and Traffic Engineering A significant aspect of a PPVPN is support for QoS. Since an SP has control over the provisioning of resources and configuration of parameters in at least the PE and P devices, and in some cases, the CE device as well, the onus is on the service provider to provide either managed QoS access service, or edge-to-edge QoS service, as defined in section 4.6.2. Each PPVPN approach must describe the traffic engineering techniques available for a service provider to meet the QoS objectives. These descriptions of traffic engineering techniques should quantify scalability and achievable efficiency. Traffic engineering support may be on an aggregate or per-VPN basis. QoS policies must not be impacted by security mechanisms. For example, Diffserv policies must not be impacted by the use of IPSec tunnels, using the mechanisms explained in RFC 2983. As stated in RFC 2475, a mapping function from customer provided Difserv marking to marking used in a SP network should be provided for L3 PPVPN services. In the case where a customer requires DSCP transparency, as described in section 5.5.2, a L3 PPVPN service must deliver the same value of DSCP field in the IP header received from the customer to the egress demarcation of the destination. 6.7 Routing The distribution of reachability and routing policy should be constrained to the sites that are members of the VPN. Optionally, the exchange of such information may use some form of authentication (e.g., MD5). Functions to isolate the SP network and customer VPNs from anomalous routing behavior from a specific set of customer sites are highly desirable. Examples of such functions are: controls for route flap dampening, filters that accept only prefixes configured for a specific CE, a maximum number of routes accepted for each CE, or a maximum rate at which route updates can be received from a CE. When VPN customers use overlapping, non-unique IP addresses, the solution must define a means to distinguish between such overlapping addresses on a per-VPN basis. Furthermore, the solution should provide an option that either allows, or prevents advertisement of VPN routes to the Internet. Ideally, the choice of a SP's IGP should not depend on the routing protocol(s) used between PE and CE routers in a PE-based VPN. Carugi et al Informational - Expires October 2003 28 Service requirements for Layer 3 PPVPNs April, 2003 Furthermore, it is desirable that an SP should have a choice with regards to the IGP routing protocol. The additional routing burden that a Service Provider must carry should be articulated in each specific L3 PPVPN solution. 6.8 Isolation of Traffic and Routing The internal structure of a PPVPN network should not be visible to outside networks (i.e., the Internet or any connected VPN). From a high level SP perspective, a PE-based PPVPN must isolate the exchange of traffic and routing information to only those sites that are authenticated and authorized members of a VPN. In a CE-based VPN, the tunnels that connect the sites effectively meet this isolation requirement if both traffic and routing information flow over the tunnels. A PPVPN solution should provide a means for meeting PPVPN QoS SLA requirements that isolates VPN traffic from the affects of traffic offered by non-VPN customers. Also, PPVPN solutions should provide a means to isolate the effects that traffic congestion produced by sites as part of one VPN can have on another VPN. 6.9 Security [Editor's Note: Some of the material in this section is generic to L2 and L3 VPNs and may be deleted if the draft proposed for [PPVPN- GR] is accepted.] This section contains requirements related to securing customer flows, providing authentication services for temporary, remote or mobile users, and the need to protect service provider resources involved in supporting a PPVPN. 6.9.1 Support for Securing Customer Flows In order to meet the general requirement for providing a range of security options to a customer, each PPVPN solution must clearly spell out the configuration options that can work together and how the can do so. When a VPN solution operates over a part of the Internet it should support a configurable option to support one or more of the following standard IPsec methods for securing a flow for a specified subset of a customerÆs VPN traffic: o confidentiality, so that only authorized devices can decrypt it, o integrity, to ensure that the data has not been altered, o authentication, to ensure that the sender is indeed who it claims to be, o replay attack prevention. The above functions should be capable of being applied to "data traffic" of the customer, which includes the traffic exchanged between sites, between temporary users and sites and even between Carugi et al Informational - Expires October 2003 29 Service requirements for Layer 3 PPVPNs April, 2003 temporary users. It should also be possible to apply these functions to "control traffic", such as routing protocol exchanges, that are not necessarily perceived by the customer but nevertheless essential to maintain his or her VPN. Note that it may be necessary to extend the IPsec protocol to support exchange of control traffic over an IPsec tunnel [IPSEC-PPVPN]. Furthermore, such security methods must be configurable between different end points, such as CE-CE, PE-PE, and CE-PE. It is also desirable to configure security on a per-route or per-VPN basis [VPN SEC]. A VPN solution may support one or more encryption schemes, including AES, 3DES. Encryption, decryption, and key management should be included in profiles as part of the security management system. 6.9.2 Authentication Services A service provider must provide authentication services in support of temporary user access requirements, as described in section 5.11.2. Furthermore, traffic exchanged within the scope of VPN may involve several categories of equipment that must cooperate together to provide the service [Y.1311.1]. These network elements can be CE, PE, firewalls, backbone routers, servers, management stations, etc. These network elements learn about each others identity, either via manual configuration or via discovery protocols, as described in section 6.4. When network elements must cooperate, it is necessary to authenticate peers before providing the requested service. This authentication function may also be used to control access to network resources. The peer identification and authentication function described above applies only to network elements participating in the VPN. Examples include: - traffic between a CE and a PE, - traffic between CEs belonging to the same VPN, - CE or PE routers dealing with route announcements for a VPN, - policy decision point [RFC 3198] and a network element, - management station and an SNMP agent. Each PPVPN solution should describe for a peer authentication function: where it is necessary, how it shall be implemented, how secure it must be, and the way to deploy and maintain identification and authentication information necessary to operate the service. 6.9.3 Resource Protection Recall from the definitions in section 3.3, that a site can be part of an intranet with sites from the only same organization, part of an extranet involving sites from other organizations, have access to the Internet, or any combination of these scopes of communication. Carugi et al Informational - Expires October 2003 30 Service requirements for Layer 3 PPVPNs April, 2003 Within these contexts, a site might be subject to various attacks coming from different sources. Potential sources of attack include: - users connected to the supporting public IP backbone, - users from the Internet, - users from temporary sites belonging to the intranet and/or extranet VPN that the site is part of. Security threats and risks that a site may encounter include the following: - denial of service, for example: mail spamming, access connection congestion, TCP SYN attacks, ping attacks, etc. - intrusion attempts, which may eventually lead to denial of service (e.g. a Trojan horse attack). In order to address the above threats and risks, a SP should be able to deploy functions that control access to the site. This includes filtering functions provided by firewall, and monitoring, alerting and eventually logging all suspicious activities in order to detect potential attacks. Another way to prevent such an attack is to make sure that machines are not reachable via address hiding [MPLS SEC]. The devices in the PPVPN network must provide some means of reporting intrusion attempts to the service provider. 6.10 Inter-AS (SP)VPNs The scenario for VPNs spanning multiple Autonomous Systems (AS) or Service Providers (SP) requires standardization. The scenario where multiple ASÆs are involved is the most general case, and is therefore the one described here. The scenarios of concern are the CE-based and PE-based L3 VPNs defined in section 3. In each scenario, all applicable SP requirements, such as traffic and routing isolation, SLA's, management, security, provisioning, etc. must be preserved across adjacent ASÆs. The solution must describe the inter-SP network interface, encapsulation method(s), routing protocol(s), and all applicable parameters [VPN IW]. An essential pre-condition for an inter-AS VPN is an agreement between the AS's involved that spells out at least trust, economic, and management responsibilities. The overall scalability of the VPN service must allow the PPVPN service to be offered across potentially hundreds of SPs, with the overall scaling parameters per SP given in section 6.1. 6.10.1 Routing Protocols If the link between AS's is not trusted, routing protocols running between those AS's must support some form of authentication. For example, the TCP option for carrying an MD5 digest may be used to enhance security for BGP [RFC2385]. Carugi et al Informational - Expires October 2003 31 Service requirements for Layer 3 PPVPNs April, 2003 BGP must be supported as the standard inter-AS routing protocol to control the path taken by PPVPN traffic. 6.10.2 Management The general requirements for managing a single AS apply to a concatenation of AS's. A minimum subset of such capabilities is the following: - Diagnostic tools (e.g., ping, traceroute) - Secured access to one AS management system by another - Configuration request and status query tools - Fault notification and trouble tracking tools 6.10.3 Bandwidth and QoS Brokering When a VPN spans multiple AS's, there is a need for a brokering mechanism that requests certain SLA parameters, such as bandwidth and QoS, from the other domains and/or networks involved in transferring traffic to various sites. The essential requirement is that a solution must be able to determine whether a set of AS's can establish and guarantee uniform QoS in support of a PPVPN. The brokering mechanism can be a manual one, for example, where one provider requests from another provider a specific set of QoS parameters for traffic going to and from a specific set of sites. The mechanism could also be an automated one where a device dynamically requests and receives certain SLA/QoS parameters. For instance, in the case of a L3 PPVPN, a PE may negotiate the label for different traffic classes to reach a PE residing in a neighboring AS. Or, it might be a combination of both. In the case of an automated function, which is desirable, the functionality supported should dynamically request and reserve certain QoS parameters such as bandwidth and priority, and then to classify, mark and handle the packets as agreed in the negotiation. Observe that as traffic might traverse multiple AS's, the brokering method should also allow this. It is not desirable to perform brokering on a per VPN basis since such an approach would not scale. A solution must provide some means of aggregating QoS and bandwidth brokering requests between AS's. One method could be for SP's to make an agreement specifying the maximum amount of bandwidth for specific QoS parameters for all VPN customers using the SP network. Alternatively, such aggregation might be on a per hierarchical tunnel basis between PE routers in different AS's supporting a L3 PPVPN service. 6.10.4 Security Considerations If a tunnel traverses multiple SP networks and it passes through an unsecured SP, POP, NAP, or IX, then security mechanisms must be employed. These security mechanisms include encryption, authentication and resource protection as described in section 6.9 and security management of section 7.5. For example, a provider should consider use of both authentication and encryption for a Carugi et al Informational - Expires October 2003 32 Service requirements for Layer 3 PPVPNs April, 2003 tunnel used as part of a PPPVPN that traverses another service provider's network. 6.11 PPVPN Wholesale The architecture must support the possibility of one service provider offering VPN service to another service provider. Another example is when one service provider sells PPVPN service at wholesale to another service provider, who then resells that VPN service to his or her customers. The wholesalerÆs VPN must be transparent to the addressing and routing used by the reseller. Support for additional levels of hierarchy, for example three levels where a reseller can again resell the VPN service to yet another VPN provider, should be provided. This is called a hierarchical VPN scenario. The CarrierÆs carrier scenario is the name used in this document for this category of PPVPN wholesale. Various CarrierÆs Carrier scenarios should be supported, such as: - the customer Carriers do not operate PPVPN services for their clients; - the customer Carriers operate PPVPN services for their clients, but these services are not linked with the PPVPN service offered by the CarriersÆ Carrier; - the customer Carriers operate PPVPN services for their clients and these services are linked with the PPVPN service offered by the CarriersÆ Carrier ("Hierarchical VPNs" scenario) 6.12 Tunneling Requirements Connectivity between CE sites or PE devices in the backbone should be able to use a range of tunneling technologies, such as L2TP, IPSEC, GRE, IP-in-IP, MPLS, etc. To set up tunnels between routers, every router must support static configuration for tunneling and may support a tunnel setup protocol. If employed, a tunnel establishment protocol should be capable of conveying information, such as the following: - Relevant identifiers - QoS/SLA parameters - Restoration parameters - Multiplexing identifiers - Security parameters There must be a means to monitor the following aspects of tunnels: - Statistics, such as amount of time spent in the up and down state - Count of transitions between the up and down state - Events, such as transitions between the up and down states Carugi et al Informational - Expires October 2003 33 Service requirements for Layer 3 PPVPNs April, 2003 The tunneling technology used by the VPN Service Provider and its associated mechanisms for tunnel establishment, multiplexing, and maintenance must meet the requirements on scaling, isolation, security, QoS, manageability, etc. 6.13 Support for Access and Backbone Technologies This section describes requirements for aspects of access and backbone network technologies from a service provider point of view. Some SPs may desire that a single network infrastructure should suffice for all services, public IP, VPNs, traffic engineering, and differentiated services [L2 VPN]. 6.13.1 Dedicated Access Networks Ideally, the PPVPN service should be independent of physical, link layer or even network technology of the access network. However, the characteristics of access networks must be accounted for when specifying the QoS aspects of SLAs for VPN service offerings. 6.13.2 On-Demand Access Networks Service providers should be able to support temporary user access, as described in section 5.11.2 using dedicated or dial-in access network technology. PPVPN solutions must support the case where a VPN user directly accesses the VPN service through an access network connected to the service provider. They must also describe how they can support the case where one or more other service provider networks are used as access to the service provider supporting the PPVPN service. Ideally, all information necessary to identify and authenticate users for an intranet should be stored and maintained by the customer. In an extranet, one customer should be able to maintain the authentication server, or the customers involved in the extranet may choose to outsource the function to a service provider. Identification and authentication information could be made available to the service provider for controlling access, or the service provider may query a customer maintained server. Furthermore, one SP may act as access for the SP providing the VPN service. In the case where the access SP performs identification and authentication on behalf of the VPN SP, an agreement must be reached on a common specification. Support for at least the following authentication protocols is required: PAP, CHAP and EAP, since they are currently used in a wide range of equipment and services. 6.13.3 Backbone Networks Ideally, the backbone interconnecting SP PE and P devices should be independent of physical and link layer technology. Nevertheless, the Carugi et al Informational - Expires October 2003 34 Service requirements for Layer 3 PPVPNs April, 2003 characteristics of backbone technology must be taken into account when specifying the QoS aspects of SLAs for VPN service offerings. 6.14 Protection, Restoration When primary and secondary access connections are available, a PPVPN solution must provide restoration of access connectivity whenever the primary access link from a CE site to a PE fails. This restoration capability should be as automatic as possible, that is, the traffic should be directed over the secondary link soon after failure of the primary access link is detected. Furthermore, reversion to the primary link should be dynamic, if configured to do so [VPN-NEEDS]. As mentioned in Section 5.11.4 above, in the case of multi-homing, the load balancing capability may be used to achieve a degree of redundancy in the network. In the case of failure of one or more (but not all) of the multi-homed links, the load balancing parameters may be dynamically adjusted to rapidly redirect the traffic from the failed link(s) to the surviving links. Once the failed link(s) is (are) restored, the original provisioned load balancing ratio should be restored to its value prior to the failure. The Service provider should be able to deploy protection and restoration mechanisms within the service provider's backbone infrastructure to increase reliability and fault tolerance of the VPN service offering. These techniques should be scalable, and therefore should strive to not perform such function in the backbone on a per-VPN basis. Appropriate measurements and alarms that indicate how well network protection and restoration mechanisms are performing must be supported. 6.15 Interoperability Service providers are interested in interoperability in at least the following scenarios: - To facilitate use of PE and managed CE devices within a single SP network - To implement PPVPN services across two or more interconnected SP networks - To achieve interworking or interconnection between customer sites using different PPVPN approaches or different implementations of the same approach Each approach must describe whether any of the above objectives can be met. If an objective can be met, the approach must describe how such interoperability could be achieved. In particular, the approach must describe the inter-solution network interface, encapsulation method(s), routing protocol(s), security, isolation, management, and all other applicable aspects of the overall VPN solution provided [VPN IW]. Carugi et al Informational - Expires October 2003 35 Service requirements for Layer 3 PPVPNs April, 2003 6.16 Migration Support Service providers must have a graceful means to migrate a customer with minimal service disruption on a site-by-site basis to a PPVPN approach. If PPVPN approaches can interwork or interconnect, then service providers must have a graceful means to migrate a customer with minimal service disruption on a site-by-site basis whenever changing interworking or interconnection. 7 Service Provider Management Requirements A service provider must have a means to view the topology, operational state, order status, and other parameters associated with each customer's VPN. Furthermore, the service provider must have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the VPN service(s) to its customers. Currently, proprietary methods are often used to manage VPNs. The additional expense associated with operators having to use multiple proprietary management methods (e.g., command line interface (CLI) languages) to access such systems is undesirable. Therefore, devices should provide standards-based interfaces wherever feasible. The remainder of this section presents detailed service provider management requirements for a Network Management System (NMS) in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories. Much of this text was adapted from ITU-T Y.1311.1. 7.1 Fault management Support for fault management includes: - indication of customers impacted by failure, - fault detection (incidents reports, alarms, failure visualization), - fault localization (analysis of alarms reports, diagnostics), - incident recording or logs, creation and follow through of trouble tickets), - corrective actions (traffic, routing, resource allocation). Since PE-based VPNs rely on a common network infrastructure, the network management system must provide a means to inform the provider on the VPN customers impacted by a failure in the infrastructure. The NMS should provide pointers to the related customer configuration information to aid in fault isolation and the determination of corrective action. It is desirable to detect faults caused by configuration errors, because these may cause VPN service to fail, or not meet other requirements (e.g., traffic and routing isolation). Detection of Carugi et al Informational - Expires October 2003 36 Service requirements for Layer 3 PPVPNs April, 2003 such errors is inherently difficult because the problem involves more than one node and may reach across a global perspective. One approach could be a protocol that systematically checks that all constraints and consistency checks hold among tunnel configuration parameters at the various end points. A capability to verify L3 reachability within a VPN must be provided for diagnostic purposes. A capability to verify the parameter configuration of a device supporting a PPVPN must be provided for diagnostic purposes. 7.2 Configuration Management Overall, The NMS must support configuration necessary to realize desired L3 reachability of a PPVPN. Toward this end, an NMS must provide configuration management to provision at least the following PPVPN components: PE,CE, hierarchical tunnels, access connections, routing, and QoS, as detailed in this section. If shared access to the Internet is provided, then this option must also be configurable. Since VPN configuration and topology are highly dependent upon a customer's organization, provisioning systems must address a broad range of customer specific requirements. The NMS must ensure that these devices and protocols are provisioned consistently and correctly. Provisioning for adding or removing sites should be as localized and automated as possible. Configuration management for VPNs, according to service templates defined by the provider must be supported. A service template contains fields which, when instantiated, yield a definite service requirement or policy. For example, a template for an IPSec tunnel would contain fields such as tunnel end points, authentication modes, encryption and authentication algorithms, preshared keys if any, and traffic filters. An SLA template would contain fields such as delay, jitter, throughput and packet loss thresholds as well as end points over which the SLA has to be satisfied. In general, a customer's service order can be regarded as a set of instantiated service templates. This set can, in turn, be regarded as the logical or service architecture of the customer's VPN. Service templates can also be used by the provider to define the service architecture of the provider's own network. For example, OSPF templates could contain fields such as the subnets that form a particular area, the area identifier and the area type. BGP service template could contain fields which when instantiated would yield a BGP policy such as for expressing a preference about an exit router for a particular destination. Carugi et al Informational - Expires October 2003 37 Service requirements for Layer 3 PPVPNs April, 2003 The set of service templates should be comprehensive in that they can capture all service orders in some meaningful sense. The provider should provide means for translating instantiated service templates into device configurations so that associated services can be provisioned. Finally, the approach should provide means for checking if a service order is correctly provisioned. This would represent one method of diagnosing configuration errors. Configuration errors can arise due to a variety of reasons: manual configuration, intruder attacks, conflicting service requirements. 7.2.1 Configuration Management for PE-Based VPNs Requirements for configuration management unique to a PE-based VPN are as follows. o The NMS must support configuration of at least the following aspects of a L3 PE routers: intranet and extranet membership, CE routing protocol for each access connection, routing metrics, tunnels, etc. o The NMS should use identifiers for SPs, PPVPNs, PEs, CEs, hierarchical tunnels and access connections as described in section 6.3. o Tunnels must be configured between PE and P devices. This requires coordination of identifiers of tunnels, hierarchical tunnels, VPNs, and any associated service information, for example, a QoS/SLA service. o Routing protocols running between PE routers and CE devices must be configured per VPN. O For multicast service, multicast routing protocols must also be configurable. o Routing protocols running between PE routers and between PE and P routers must also be configured. o The configuration of a PE-based PPVPN must be coordinated with the configuration of the underlying infrastructure, including Layer 1 and 2 networks interconnecting components of a PPVPN. 7.2.2 Configuration management for CE-based VPN Requirements for configuration management unique to a CE-based VPN are as follows. o Tunnels must be configured between CE devices. This requires coordination of identifiers of tunnels, VPNs, and any associated service information, for example, a QoS/SLA service. Carugi et al Informational - Expires October 2003 38 Service requirements for Layer 3 PPVPNs April, 2003 o Routing protocols running between PE routers and CE devices must be configured. For multicast service, multicast routing protocols must also be configurable. 7.2.3 Provisioning Routing A means for a service provider to provision parameters for the IGP for a PPVPN must be provided. This includes link level metrics, capacity, QoS capability, and restoration parameters. 7.2.4 Provisioning Network Access A service provider must have the means to provision network access between SP-managed PE and CE, as well as the case where the customer manages the CE. 7.2.5 Provisioning Security Services When a security service is requested, an SP must have the means to provision the entities and associated parameters involved with the service. For example, for IPsec service, tunnels, options, keys, and other parameters must be provisioned at either the CE and/or PE. In the case of an intrusion detection service, the filtering and detection rules must be provisioned on a VPN basis. 7.2.6 Provisioning VPN Resource Parameters A service provider must have a means to dynamically provision resources associated with VPN services. For example, in a PE-based service, the number and size of virtual switching and forwarding table instances must be provisionable. Dynamic VPN resource assignment is crucial to cope with the frequent changes requests from customerÆs (e.g., sites joining or leaving a VPN), as well as to achieve scalability. The PEs should be able to dynamically assign the VPN resources. This capability is especially important for dial and wireless VPN services. If an SP supports a "Dynamic Bandwidth management" service, then the dates, times, amounts and interval required to perform requested bandwidth allocation change(s) must be traceable for accounting purposes. If an SP supports a "Dynamic Bandwidth management" service, then the provisioning system must be able to make requested changes within the ranges and bounds specified in the Service Level Agreement (SLA). Example SLA parameters are response time and probability of being able to service such a request 7.2.7 Provisioning Value-Added Service Access A PPVPN service provides controlled access between a set of sites over a common backbone. However, many service providers also offer a range of value-added services, for example: Internet access, firewall services, intrusion protection, IP telephony and IP Centrex, application hosting, backup, etc. It is outside of the scope of this document to define if and how these different services Carugi et al Informational - Expires October 2003 39 Service requirements for Layer 3 PPVPNs April, 2003 interact with the VPN in order to solve issues such as addressing, integrity and security. However, the VPN service must be able to provide access to these various types of value-added services. A VPN service should allow the SP to supply the customer with different kinds of standard IP services like DNS, NTP and RADIUS needed for ordinary network operation and management. The provider should be able to provide IP services to multiple customers from one or many servers. A firewall function may be required to restrict access to the PPVPN from the Internet [Y.1311]. A managed firewall service must be carrier grade. For redundancy and failure recovery, a means for firewall fail-over should be provided. Managed firewall services that may be provided include dropping specified protocol types, intrusion protection, traffic-rate limiting against malicious attacks, etc. Managed firewalls must be supported on a per-VPN basis, although multiple VPNs may be supported by the same physical device (e.g., in network or PE-based solution). Managed firewalls should be provided at the major access point(s) for the PPVPN. Managed firewall services may be embedded in the CE or PE devices, or implemented in standalone devices. The NMS should allow a customer to outsource the management of an IP networking service to the SP providing the VPN or a third party. The management system should support collection of information necessary for optimal allocation of IP services in response to customer orders. Network-based firewall services must be carrier grade. For redundancy and failure recovery, a means for firewall fail-over should be provided. Network-based firewall services that may be provided include dropping specified protocol types, intrusion detection, traffic-rate limiting against malicious attacks, etc. Network-based firewalls must be supported on a per-VPN basis, although multiple VPNs may be supported by the same physical device. Network-based firewalls should be provided at the major access point(s) for the PPVPN. Network-based firewall services may be embedded in the PE equipment, or implemented in standalone equipment. Reachability to and from the Internet to sites within a VPN must be configurable by an SP. This could be controlled by configuring routing policy to control distribution of VPN routes advertised to the Internet. Carugi et al Informational - Expires October 2003 40 Service requirements for Layer 3 PPVPNs April, 2003 7.2.8 Provisioning Hybrid VPN Services Configuration of interworking or interconnection between PPVPN solutions should be also supported. Ensuring that security and end- to-end QoS issues are provided consistently should be addressed. 7.3 Accounting Many service providers require collection of measurements regarding resource usage for accounting purposes. The NMS may need to correlate accounting information with performance and fault management information to produce billing that takes into account SLA provisions for periods of time where the SLS is not met. A PPVPN solution must describe how the following accounting functions can be provided: - measurements of resource utilization, - collection of accounting information, - storage and administration of measurements. Some providers may require near-real time reporting of measurement information, and may offer this as part of a customer network management service. If an SP supports a "Dynamic Bandwidth management" service, then the dates, times, amounts and interval required to perform requested bandwidth allocation change(s) must be traceable for monitoring and accounting purposes. Solutions should state compliance to accounting requirements, as described in section 1.7 of RFC 2975. 7.4 Performance Management Performance management includes functions involved with monitoring and collecting performance data regarding devices, facilities, and services, as well as determination of conformance to Service Level Specifications (SLS), such as QoS and availability measurements. Performance management should also support analysis of important aspects of a PPVPN , such as bandwidth utilization, response time, availability, QoS statistics, and trends based on collected data. 7.4.1 Performance Monitoring The NMS must monitor device behavior to evaluate performance metrics associated with a service level agreement. Different measurement techniques may be necessary depending on the service for which an SLA is provided. Example services are QoS, security, multicast, and temporary access. These techniques may be either intrusive or non- intrusive depending on the parameters being monitored. The NMS must also monitor aspects of the VPN not directly associated with an SLA, such as resource utilization, state of devices and transmission facilities, as well as control of monitoring resources Carugi et al Informational - Expires October 2003 41 Service requirements for Layer 3 PPVPNs April, 2003 such as probes and remote agents at network access points used by customers and mobile users. 7.4.2 SLA and QoS management features The NMS should support SLAs between the SP and the various customers according to the corresponding SLSes by measurement of the indicators defined within the context of the SLA, on a regular basis. The NMS should use the QOS parameter measurement definitions, techniques, and methods as defined by the IETF IP Performance Metrics (IPPM) working group for delay, loss, and delay variation. The NMS should support allocation and measurement of end-to-end QoS requirements to QoS parameters for one or more network(s). Devices supporting PPVPN SLAs should have real-time performance measurements that have indicators and threshold crossing alerts. Such thresholds should be configurable. 7.5 Security Management The security management function of the NMS must include management features to guarantee the security of devices, access connections, and protocols within the PPVPN network(s), as well as the security of customer data and control as described in section 6.9. 7.5.1 Management Access Control Management access control determines the privileges that a user has for particular applications and parts of the network. Without such control, only the security of the data and control traffic is protected, leaving the devices providing the PPVPN network unprotected. Access control capabilities protect these devices to ensure that users have access to only the resources and applications to which they are authorized to use. In particular, access to the routing and switching resources managed by the SP must be tightly controlled to prevent and/or effectively mitigate a malicious attack. 7.5.2 Authentication Authentication is the process of verifying that the sender is actually is who he or she says they are. The NMS must support standard methods for authenticating users attempting to access management services. Scalability is critical as the number of nomadic/mobile clients is increasing rapidly. The authentication scheme implemented for such deployments must be manageable for large numbers of users and VPN access points. Support for strong authentication schemes shall be supported to ensure the security of both VPN access point-to-VPN access point Carugi et al Informational - Expires October 2003 42 Service requirements for Layer 3 PPVPNs April, 2003 (PE to PE) and client-to-VPN Access point (CE-to-PE) communications. This is particularly important to prevent VPN access point spoofing. VPN Access Point Spoofing is the situation where an attacker tries to convince a PE or CE that the attacker is the VPN Access Point. If an attacker can convinces a PE or CE of that, then the device will send VPN traffic to the attacker (who could forward it on to your true access point after compromising confidentially or integrity). In other words, a non-authenticated VPN AP can be spoofed with a man-in-the-middle attack, because the endpoints never verify each other. A weakly-authenticated VPN AP may be subject to such an attack. However, strongly-authenticated VPN APs are not subject to such attacks, because the man-in-the-middle cannot authenticate as the real AP, due to the strong authentication algorithms. 7.6 Network Management Techniques Each PPVPN solution approach must specify the management information bases (MIB) modules for network elements involved in PPVPN services. This is an essential requirement in network provisioning. The approach should identify any information not contained in a standard MIB related to FCAPS that is necessary to meet a generic requirement. The IP VPN Policy Information model should reuse the policy information models being developed in parallel for specific IP network capabilities [IM-REQ]. This includes the QoS Policy Information Model_[QPIM] and the IPSEC Configuration Policy Model_ [IPSECIM]. The information model should provide the OSS with adequate "hooks" to correlate service level specifications with traffic data collected from network elements. The use of policies includes rules that control corrective actions taken by OSS components responsible for monitoring the network and ensuring that it meets service requirements. Additional requirements on information models are given in reference [IM-PPVPN]. In particular, an information model must allow a service provider to change network dimensions with minimal influence on provisioning issues. The adopted model should be applicable to both small/medium size networks and large-scale PPVPN solutions. Some service providers may require systems that visually, audibly, or logically present FCAPS information to internal operators and/or customers. 8 Security Considerations Security considerations occur at several levels and dimensions within Provider Provisioned VPNs, as detailed within this document. This section provides a summary with references to supporting detailed information. Carugi et al Informational - Expires October 2003 43 Service requirements for Layer 3 PPVPNs April, 2003 The requirements in this document separate the notion of traditional security requirements, such as integrity, confidentiality, and authentication as detailed in section 4.4 from that of isolating (or separating) the exchange of forwarded packets and exchange of routing information between specific sets of sites, as defined in sections 3.3 and 4.3. Further detail on security re quirements are given from the customer and service provider perspectives in sections 4.4 and 5.9, respectively. In an analogous manner, further detail on traffic and routing isolation requirements are given from the customer and service provider perspectives in sections 4.3 and 5.8, respectively. Furthermore, requirements regarding management of security from a service provider perspective are described in section 7.5. 9 Acknowledgements The authors of this document would like to acknowledge the contributions from the ITU-T people who launched the work on VPN requirements inside SG13, the authors of the original IP VPN requirements and framework document [RFC 2764], Tom Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic LeGarrec. The authors are also grateful to the helpful suggestions and direction provided by the technical advisors, Scott Bradner, Bert Wijnen and Rob Coltun. We would also like to acknowledge the insights and requirements gleaned from the many documents listed in the references section. Citations to these documents were made only where the authors believed that additional insight to the requirement could be obtained by reading the source document. 10 References 10.1 Normative References [PPVPN-GR] Nagaragan, A., "Generic Requirements for Provider Provisioned VPN," Work in Progress. [RFC 3377] J. Hodges, R. Morgan, ôLightweight Directory Access Protocol (v3): Technical Specification,ö RFC 3377, September 2002 [RFC 1918] Rekhter, Y. et al., "Address Allocation for Private Internets," RFC 1918, February 1996. [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC 2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification," September 1997. [RFC 2211] J. Wroclawski, Specification of the Controlled-Load Network Element Service, RFC 2211, IETF, September 1997. [RFC 2212] S. Shenker, C. Partridge, R Guerin, Specification of Guaranteed Quality of Service, RFC 2212, IETF, Carugi et al Informational - Expires October 2003 44 Service requirements for Layer 3 PPVPNs April, 2003 September 1997. [RFC 2251] Wahl, M. et al., "Lightweight Directory Access Protocol (v3)," RFC 2251, December 1997. [RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", RFC 2475, Dec. 1998. [RFC 2597] "Assured Forwarding PHB Group", F. Baker, J. Heinanen, W. Weiss, J. Wroclawski, RFC 2597, [RFC 2661] Townsley, W. et al., "Layer Two Tunneling Protocol "L2TP"," RFC 2661, August 1999. [RFC 2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [RFC 2983] Black, D., ôDifferentiated Services and Tunnelsö, RFC2983, October 2000 [RFC 3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture," January 2001. [RFC 3246] B. Davie et al, "An Expedited Forwarding PHB", RFC 3246, March 2002. [RFC 3270] F. Le Faucheur et al, ôMulti-Protocol Label Switching (MPLS) Support of Differentiated Services,ö RFC 3270, May 2002 10.2 Non-normative References [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work n progress. [2917bis] Muthukrishnan, K., et al., ô A Core MPLS IP VPN Architectureö, work in progress [DOCSIS 1.1] Data Over Cable Service Interface Specification (DOCSIS), Cable Labs, http://www.cablemodem.com/specifications.html [FRF.13] Frame Relay Forum, "Service Level Definitions Implementation Agreement," August, 1998. [IM-PPVPN] P. Lago et al, "An Information Model for Provider Provisioned Virtual Private Networks," work in progress. [IM-REQ] M. Iyer et al, "Requirements for an IP VPN Policy Information Model," work in progress [IPSECIM] J. Jason, _"IPsec Configuration Policy Model," work in progress. [IPSEC-PPVPN] B. Gleeson, "Uses of IPsec with Provider Provisioned VPNs," work in progress. [L2 MPLS] L. Martini et al, ôTransport of Layer 2 Frames Over MPLS,ö work in progress. [L2 VPN] E. Rosen et al, "An Architecture for L2VPNs," work in progress. [L2 VPN] K. Kompella, R. Bonica, "Whither Layer 2 VPNs?," work in progress. [MPLS SEC] M. Behringer, "Analysis of the Security of the MPLS Architecture," work in progress [NBVPN-FR] Suzuki, M. and Sumimoto, J. (editors), "A framework for Network-based VPNs", work in progress [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Carugi et al Informational - Expires October 2003 45 Service requirements for Layer 3 PPVPNs April, 2003 Provider Provisioned Virtual Private Networks ",work in progress [PPVPN-VR] H. Ould-Brahim, B. Gleeson et al. "Network based PPVPN Architecture using Virtual Routers", work in progress [QPIM] Snir, Ramberg, Strassner, Cohen and Moore,_"Policy QoS Information Model" work in progress. [RFC 2547] E. Rosen, Y. Rekhter, ôBGP/MPLS VPNs,ö RFC 2547,March 1999. [RFC 2764] Gleeson, B., et al., "A Framework for IP based Virtual Private Networks", RFC 2764, February 2000 [RFC 2975] B. Aboba et al, "Introduction to Accounting Management," October 2000. [RFC 3198] A. Westerinen et al, "Terminology for Policy-Based Management," November, 2001. [VPLS REQ] W. Augustyn et al, "Requirements for Virtual Private LAN Services (VPLS)," work in progress. [VPN DISC] M. Squire et al, "VPN Discovery Discussions and Options," work in progress. [VPN IW] H. Kurakami et al, "Provider-Provisioned VPNs Interworking," work in progress. [VPN SEC] J. De Clercq et al, "Considerations about possible security extensions to BGP/MPLS VPN," work in progress. [VPN TUNNEL] T. Worster et al, "A PPVPN Layer Separation: VPN Tunnels and Core Connectivity," work in progress [VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., "Criteria for Evaluating VPN Implementation Mechanisms", work in progress [VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment of an IP VPN service offering : a service provider perspective ", work in progress [VPN-VR] Ould-Brahim, H., Gleeson, B., et al. ôNetwork based IP VPN Architecture using Virtual Routersö, work in progress [Y.1241] "IP Transfer Capability for the support of IP based Services", Y.1241 ITU-T Draft Recommendation, March 2000 [Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS architecture",Y.1311.1 ITU-T Recommendation, May 2001 [Y.1311] Knightson, K. (editor), " Network based IP VPN Service - Generic Framework and Service Requirements ", Y.1311 ITU-T Draft Recommendation, May 2001 11 Authors' address Marco Carugi (Co-editor) Nortel Networks S.A. Parc d'activits de Magny-Les Jeunes Bois CHATEAUFORT 78928 YVELINES Cedex 9 - FRANCE marco.carugi@nortelnetworks.com Carugi et al Informational - Expires October 2003 46 Service requirements for Layer 3 PPVPNs April, 2003 Dave McDysan (Co-editor) MCI 22001 Loudoun County Parkway Ashburn, VA 20147, USA dave.mcdysan@mci.com Luyuan Fang AT&T 200 Laurel Ave - Room C2-3B35 Middletown, NJ 07748 USA Luyuanfang@att.com Ananth Nagarajan Sprint 6220 Sprint Parkway, Overland Park, KS 66251, USA ananth.nagarajan@mail.sprint.com Junichi Sumimoto NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: sumimoto.junichi@lab.ntt.co.jp Rick Wilder Masergy rwilder@masergy.com Full copyright statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Carugi et al Informational - Expires October 2003 47 Service requirements for Layer 3 PPVPNs April, 2003 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Carugi et al Informational - Expires October 2003 48
Datatracker
Report a datatracker bug
draft-ietf-l3vpn-requirements-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4031.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |