INTERNET DRAFT M. Carugi Internet Engineering Task Force France Telecom Document: D. McDysan draft-ietf-ppvpn-requirements-00.txt WorldCom February 2001 (Co-Editors) Category: Informational L. Fang Expires: August 2001 AT&T F. Johansson Telia Ananth Nagarajan Sprint J. Sumimoto NTT R. Wilder Zephion Networks Service requirements for Provider Provisioned Virtual Private Networks : 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 nbvpn@bbo.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 Carugi et al 1 Service requirements for PPVPNs February, 2001 This document provides requirements for Provider Provisioned Virtual Private Networks (PPVPNs). It identifes 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. 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 ........................................................6 2 Definitions......................................................6 2.1 Provider Provisioned Virtual Private Network ...................6 2.2 Customers, Sites, Users, and Subscribers .......................6 2.3 Intranets and Extranets ........................................7 2.4 Layered VPN Services ...........................................7 2.5 Layer 2 VPN Service ............................................7 2.6 Layer 3 VPN Service ............................................8 2.7 Customer Equipment (CE) Based ..................................8 2.7.1 Reference Model.............................................8 2.8 Network Based ..................................................9 2.8.1 Reference Model............................................10 2.9 VPN Tunnels ...................................................12 3 General Requirements............................................12 3.1 Topology ......................................................12 3.2 Exchange of Data and Routing Information ......................13 3.3 Addressing ....................................................13 3.4 Security ......................................................13 3.4.1 User data security.........................................13 3.4.2 Routing data security......................................13 3.4.3 Access control.............................................13 3.4.4 VPN isolation..............................................14 3.5 Management ....................................................14 3.6 Interoperability (TEXT MAINLY DERIVED FROM [Y.1311.1]) ........14 4 Customer Requirements...........................................14 4.1 VPN Membership (Intranet/Extranet) ............................14 4.2 Service Provider Independence .................................15 4.3 Addressing ....................................................15 4.4 Traffic Types .................................................15 4.5 Routing Protocol Support ......................................15 4.6 SLA/SLS .......................................................15 4.7 Management ....................................................16 Carugi et al Informational - Expires August 2001 2 Service requirements for PPVPNs February, 2001 4.8 Security/Integrity [Y.1311.1] .................................17 4.9 Migration Impact ..............................................18 4.10 Network Access ................................................18 4.10.1 Physical/Link Layer Technology.............................18 4.10.2 Remote Access..............................................18 4.10.3 Sharing of the Access Network..............................18 4.10.4 Access Connectivity Multi-homing, Backdoor, Shortcut.......18 4.11 Service Access ................................................20 4.11.1 Internet Access............................................20 4.11.2 Hosting, Application Service Provider......................21 4.11.3 Other Services.............................................21 4.12 Hybrid VPN Scenarios ..........................................21 5 Service Provider Requirements...................................21 5.1 Scalability ...................................................22 5.2 Addressing ....................................................23 5.3 Identifiers ...................................................24 5.4 Learning VPN Membership .......................................24 5.5 Service Level Agreements and Specifications ...................24 5.6 QoS ...........................................................26 5.6.1 A Service Deployment Perspective...........................26 5.6.2 A Standards-Based Approach.................................27 5.6.3 Diffserv-Specific Requirements.............................29 5.7 Resource Control ..............................................29 5.8 Inter-AS (SP)VPNs .............................................29 5.8.1 Routing Protocols..........................................30 5.8.2 Management.................................................30 5.8.3 Bandwidth and Qos Brokering................................30 5.8.4 Security Considerations....................................31 5.9 Isolation (Traffic, Processing Resources) .....................31 5.10 Tunneling Mechanism Independence and Selection ...............31 5.11 Backbone Technology Independence .............................32 5.12 Protection, Restoration ......................................32 5.13 PPVPN Wholesale ..............................................33 5.14 Management ...................................................33 5.14.1 Configuration Management..................................34 5.14.2 Service monitoring........................................36 5.14.3 VPN management solutions..................................39 5.15 Migration Support .............................................40 5.16 Isolation, Security, Authentication and Identification .......40 5.16.1 VPN isolation.............................................40 5.16.2 VPN user identification...................................41 5.16.3 VPN user authentication...................................42 5.16.4 Securing the flow.........................................42 5.16.5 Peer identification.......................................42 5.16.6 Peer authentication.......................................43 5.16.7 Site protection...........................................43 5.17 Provisioning Routing [Y.1311.1] ..............................44 5.18 Provisioning Network Access ..................................44 5.19 Provisioning Security Services ...............................44 5.20 Provisioning VPN Parameters ..................................44 5.21 Provisioning Value-Added Service Access ......................44 Carugi et al Informational - Expires August 2001 3 Service requirements for PPVPNs February, 2001 5.21.1 IP Networking Services....................................45 5.21.2 Internet access...........................................45 5.22 Provisioning Hybrid VPN Services .............................45 5.23 Interoperability .............................................45 6 Security Considerations.........................................45 7 Acknowledgements................................................46 8 References......................................................46 9 Authors" address................................................47 Carugi et al Informational - Expires August 2001 4 Service requirements for PPVPNs February, 2001 1 Introduction NOTE: EDITOR"S NOTES, ISSUES AND AREAS REQUIRING FURTHER WORK ARE INDICATED IN ALL CAPS. 1.1 Scope of this document This document provides requirements for Provider Provisioned Virtual Private Networks (ppvpn). It identifies requirements that may apply to one or more individual approaches that a Service Provider may use for the provisioning of a VPN service. The document states requirements from a general point of view, as well as from a customer and service provider point of view. The content of this document makes use of the terminologies and common components for deploying 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. The charter of the PPVPN working group defines at least three types of PPVPNs: BGP-VPNs (e.g. RFC 2547), virtual routers and port-based VPNs (i.e., where the SP provides a Layer 2 interface, such as Frame Relay or ATM, to the VPN customer, while using IP-based mechanisms in the provider infrastructure to improve scalability and configurability over traditional L2 networks). The approach followed in this document distinguishes PPVPN types as to where the endpoints of tunnels exist and whether the service provided is layer 2 or layer 3. Terminology regarding whether equipment faces a customer or the service provider network is used to define the various types of PPVPN solutions. This requirements document summarizes the reference model from framework document [PPVPN-FR]for the convenience of readers. This document does not map requirements to each individual approach. Rather, it"s intended use is as a "checklist" of requirements that will provide a consistent way to evaluate and document how well each individual approach satisfies a specific requirement. The relevant documents for each individual approach should document the results of this evaluation. This document first provides general requirements, followed by requirements from a customer perspective, and concludes with requirements from a Service Provider (SP) perspective. These requirements provide high level PPVPN features expected by a SP in provisioning PPVPN to make them beneficial to his customers. These general requirements include SP requirements for security, privacy, manageability, interoperability and scalability, including SP" s projections for number, complexity, and rate of change of customer VPNs over the next several years. Carugi et al Informational - Expires August 2001 5 Service requirements for PPVPNs February, 2001 1.2 Outline The outline of the rest of this document is as follows. Section 2 defines terminology and summarizes the ppvpn reference model. Section 3 provides general requirements. Section 4 states requirements from a customer perspective. Section 5 states requirements from a service provider perspective. Section 6 describes security considerations. Section 7 lists acknowledgements. Section 8 provides a list of references cited herein. Section 9 lists the author"s addresses. 2 Definitions NOTE: DEFINITIONS IN THIS SECTION WERE TAKEN FROM PREVIOUS TEXT, THE FRAMEWORK DOCUMENT AND THE NOTES CAPTURED BY THE DESIGN TEAM. 2.1 Provider Provisioned Virtual Private Network 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 interconnection of customer sites, making use of a shared network infrastructure. Multiple sites of a private network may therefore be interconnected via the public infrastructure, in order to facilitate the operation of the private network. The logical structure of the VPN, such as addressing, 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. The taxonomy of PPVPN types has two principal dimensions: whether the service provided to the customer is layer 2 or layer 3, and whether the tunnels that provide the service either terminate on Customer facing Equipment (CE), or on "Network-based" Provider Edge (PE) equipment. Note that the definitions of Customer Equipment and Provider Edge do not necessarily map to the physical deployment of equipment on customer premises or a provider point of presence. 2.2 Customers, Sites, Users, and Subscribers THE FOLLOWING ARE TENTATIVE DEFINITIONS TAKEN FROM [VPN- NEEDS](ALIGNMENT OF THE DOCUMENT TO THESE TENTATIVE DEFINITIONS HAS NOT BEEN RIGOROUSLY PURSUED) Customer = subscriber. Subscriber : A subscriber (or a customer) is a legal representative who has the (legal) ability to subscribe to a service offering. User : A user is an entity (a human being or a process, from a general perspective) who has been named by a subscriber and Carugi et al Informational - Expires August 2001 6 Service requirements for PPVPNs February, 2001 appropriately identified by a service provider, so that he might benefit from a service according to his associated rights and duties. The definition of site is taken from [RFC 2547], as follows: From the perspective of a particular backbone network, a set of IP systems constitutes a site if those systems have mutual IP interconnectivity, and communication between them occurs without use of the backbone. In general, a site will consist of a set of systems which are in geographic proximity. However, this is not universally true; two geographic locations connected via a leased line, over which OSPF is running, will constitute a single site, because communication between the two locations does not involve the use of the backbone. 2.3 Intranets and Extranets An intranet defines connectivity between sites in the same organization. This is the simplest and most common scenario. In this scenario, a VPN is formed between different sites belonging to the same organization. For example, this scenario could be envisioned as one where different branch offices are interconnected and/or also connect to the headquarters. This is the minimum/mandatory scenario that needs to be supported by any VPN architecture. All other service deployment scenarios require certain modifications/extensions to the basic intranet architecture. An extranet defines connectivity between sites across multiple organizations. In an extranet scenario, two or more organizations have access to a limited number 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 and universities participating in a consortium, etc. An extranet can exist across a single service provider backbone or across multiple backbones or autonomous systems. The main difference between an extranet and an intranet is the existence of some kind of an access control mechanism at the interconnection between different organizations. This access control can be implemented by a firewall, access lists on routers or similar mechanisms to apply policy-based access control to transit traffic. The access control mechanism may be achieved using separate devices or may be integrated into the PE device. 2.4 Layered VPN Services A PPVPN must provide a layer 2 VPN service, a layer 3 VPN service, or both to a set of customer sites. 2.5 Layer 2 VPN Service In a layer 2 VPN service, a customer site receives datalink layer (i.e., layer 2) service from the SP. The CE and PE are adjacent to each other at the datalink layer and not at the IP layer. A PE performs forwarding of customer data packets based on information in Carugi et al Informational - Expires August 2001 7 Service requirements for PPVPNs February, 2001 the packets" datalink layer headers, such as a frame relay DLCI or 802.1q VLAN tag. That is, the CE sees the PE as a layer 2 device such as a FR switch or an Ethernet VLAN switch. Initial protocol proposals have been made to define how an IP- controlled MPLS network could provide a layer 2 VPN service. See [L2 VPN] and [L2 MPLS] for more information. 2.6 Layer 3 VPN Service In a layer 3 VPN service, a customer site receives IP layer (i.e., layer 3) service from the SP. The CE and PE are adjacent to each other at the datalink layer and the IP layer. The PE performs forwarding of customer 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. 2.7 Customer Equipment (CE) Based In a CE-based VPN, the tunnels terminate at the CE, as detailed in the reference model described below. The CE faces the network at customer site, but may or may not be located on the customer premises. The PE may optionally distinguish between packets that belong to the PPVPN based upon the VPN tunnel, and not based on the user data packet header. The provider may or may not manage the customer equipment. Examples of a CE-based layer 3 VPN service are a SP managed IPsec router, or a customer-managed router tunneled over an ISP network. Examples of a CE-based layer 2 VPN service are a managed router connected, or a customer-managed router connected via layer 2 connections. The above CE-based "customer-managed router" scenarios are outside of the PPVPN WG charter. 2.7.1 Reference Model Figure 2.1 shows the reference model for SP managed CE-based VPN. The entities in the reference model are described below. NOTE: MANY OF THESE TERMS AND DEFINITIONS OVERLAP WITH THE NEXT SECTION ON NETWORK-BASED VPNS. o Customer edge (CE) device: This device is provisioned and possibly managed as well by the service provider. For example, it may support IPsec. o Provider edge (PE) router: It is a router without any VPN specific functionality. o SP networks: IP network + CE management function. Carugi et al Informational - Expires August 2001 8 Service requirements for PPVPNs February, 2001 o Access network (See section 4.10) o Tunnel: A tunnel is a connection between CE routers. (See section 2.9) o Device for customer management (See section 3.5) o Device for network management (See section 5.14) +---------+ +-----------------------------------+ +---------+ | | | | | | | | | +------+ +------+ : +------+ +------+ : | | | | | | : | CE | | CE | : | | VPN | PE | | PE | : |device| |device| : +------+ Tunnel |router| |router| : | of | | of |=:===================================================:=|VPN A| |VPN A| : | | +------+ +------+ : +------+ +------+ : | PE | | | : | +------+ : |router| VPN | | : | | CE | : | | Tunnel +------+ : +------+ |device|=:===================================================:=| CE | | of | : +------+ | PE | : |device| |VPN B| : | | | | |router| : | of | +------+ : | | +------+-----+ +------+----+ | | : |VPN B| | : | | | Device for | |Device for | +------+ : +------+ |Customer | | | customer | | network | | | : | |interface| | | management | |management | | |Customer | | | | +------------+ +-----------+ | |interface| | | | | | | +---------+ +-----------------------------------+ +---------+ | Access | |<---------- SP network(s) -------->| | Access | | network | | | | network | Figure 2.1: Reference model for SP managed CE-based VPN 2.8 Network Based In a Network-based VPN, the tunnels terminate at the PE, as detailed in the reference model described below. The PE faces the service provider network, but may or may not be located in a service provider point of presence. The PE distinguishes between packets that belong to the PPVPN based on information in the user data packet at L1, L2, and/or L3. The service provider always manages the PE equipment. The term "Network-Based VPN" is also defined by the ITU-T in Y.1311.1, as follows. "A network-based IP VPN provides a layer-3 service to customers. A customer site may be connected to the Service Provider network-based IP VPN, and the IP VPN takes care of routing packets to the correct customer destination. With a network- based IP VPN the Provider edge routers are responsible for learning Carugi et al Informational - Expires August 2001 9 Service requirements for PPVPNs February, 2001 and distributing among themselves the customer layer-3 reachability information." An example of a Network-based layer 2 VPN is provision of a FR or ATM service over an MPLS-based, IP controlled service provider backbone [L2 VPN], [L2 MPLS]. Examples of a Network-based layer 3 VPN are the BGP/MPLS VPN [RFC 2547] or virtual routers [2917bis], [VPN-VR]. 2.8.1 Reference Model Figure 2.2 shows the reference model for network-based VPN and Figure 2.3 shows relationship between entities in the reference model. The entities in the reference model are described below. ? Customer edge (CE) device: A CE device is a device on the customer site which has an access connection to a PE router. It may be a router, host, or switch located at the edge of a user site. ? P Router: A router within a provider network which is used to interconnect PE routers, but which does not have any VPN state and does not have any direct attachment to CE devices. ? Provider Edge (PE) router: A PE router is attached via an access connection to one or more CE devices. In the context of supporting VPNs, a PE router implements one or more VFIs and maintains per-VPN state. (Note that access connections are terminated by VFIs from the functional point of view.) ? SP networks: An SP network is a network administered by a single service provider. ? Access connection: An access connection represents an isolated L2 connectivity between a CE device and a PE router. This includes dedicated physical circuits, logical circuits (such as Frame Relay and ATM), plus IP tunnels (eg, using IPsec, L2TP). ? Access network: An access network provides access connections between CE devices and PE routers. It may be a TDM network, L2 network (e.g. FR, ATM, and Ethernet), or IP network over which access is tunneled (eg using L2TP [RFC2661]). ? VPN Tunnel: A VPN tunnel is a logical link between two entities which is created by encapsulating packets within an encapsulating header for purpose of transmission between those two entities for support of VPNs. VFIs are typically interconnected via (per-VPN) tunnels. This is illustrated in figure 2.3. Another example of a tunnel is a connection between PE routers. Carugi et al Informational - Expires August 2001 10 Service requirements for PPVPNs February, 2001 Multiple tunnels at one level may be hierarchically multiplexed into a single tunnel at another level. For example, multiple per-VPN tunnels may be multiplexed into a single PE to PE tunnel. +---------+ +-----------------------------------+ +---------+ | | | | | | | | | +------+ +------+ : +------+ +------+ : | | | | | | : | CE | | CE | : | | VPN | PE | VPN | PE | : |device| |device| : +------+ Tunnel : |router| :Tunnel |router| : | of | | of |-:--| |========:===| |===:=======| |--:-|VPN A| |VPN A| : | | : +------+ : +------+ : +------+ +------+ : | PE | : : | | : | +------+ : |router| Network interface | | : | | CE | : | | : +------+ : +------+ |device|-:--| |================:==============| |--:-| CE | | of | : +------+ VPN Tunnel | PE | : |device| |VPN B| : | | | | |router| : | of | +------+ : | | +------+-----+ +------+----+ | | : |VPN B| | : | | | Device for | |Device for | +------+ : +------+ |Customer | | | customer | | network | | | : | |interface| | | management | |management | | |Customer | | | | +------------+ +-----------+ | |interface| | | | | | | +---------+ +-----------------------------------+ +---------+ | Access | |<---------- SP network(s) -------->| | Access | | network | | single or multiple SP domains | | network | Figure 2.2: Reference model for network-based VPN. +----------+ +----------+ +-----+ |PE router | |PE router | +-----+ | CE | | | +-------------+ | | | CE | | dev | Access | +------+ | : : | +------+ | Access | dev | | of | conn. | |VFI of| | : VPN Tunnel : | |VFI of| | conn. | of | |VPN A|----------|VPN A |---------------------|VPN A |----------|VPN A| +-----+ | +------+ | : : | +------+ | +-----+ | | : : | | +-----+ Access | +------+ | : : | +------+ | Access +-----+ | CE | conn. | |VFI of| | : VPN Tunnel : | |VFI of| | conn. | CE | | dev |----------|VPN B |---------------------|VPN B |----------| dev | | of | | +------+ | : : | +------+ | | of | |VPN B| | | +-------------+ | | |VPN B| +-----+ +----------+ +----------+ +-----+ Figure 2.3: Relationship between entities in reference model. ? VPN Forwarding Instance (VFI): A VFI is a logical entity that resides in a PE, that includes the router information base and Carugi et al Informational - Expires August 2001 11 Service requirements for PPVPNs February, 2001 forwarding information base for a VPN. A VFI enables router functions dedicated to serving a particular VPN. In general a VFI terminates tunnels for interconnection with other VFIs and also terminates access connections for accommodating CEs. The interaction between routing and VFIs is discussed in section 5.4. ? Customer and Network Management Functions: Customer and network management functions may use a combination of proprietary network management system, SNMP manager, or directory service (eg, LDAP [RFC1777] [RFC2251]). 2.9 VPN Tunnels In a L3 PPVPN, a number of IP tunneling protocols are available, however, in this document, three different tunneling mechanisms; MPLS, GRE, and IPsec are considered to support VPN. In a L2 PPVPN, a number of layer 2 tunnel types are available, the main ones being FR, ATM, MPLS. In a network-based PPVPN, a tunnel enables the forwarding of packets between a specified set of CE devices via PEs accommodating them. In a CE-based PPVPN, a tunnel exists between CE devices. Since detailed PPVPN functions depend on the specifics on a tunnel, this section gives an overview of tunneling protocols. When MPLS is used for the tunneling mechanism, LSPs implement tunnels and the multiplexing is supported by the two-layer label stacking of the MPLS. In this case, the nested tunnels identified by the bottom label in the stack are multiplexed into a tunnel identified by the top label. This enables high-speed packet forwarding, because the forwarding processing does not refer to the bottom label. When GRE is used for the tunneling mechanism and the key field extension is supported, the nested VPN tunnels are identified by the key field. Note that if the key field is not present, there is no means available to nest tunnels. When IPsec is used for the tunneling mechanism, they are identified by the SPI field. Note that when the tunnel is provided by GRE or IPsec, it may pass through another tunneling mechanism (e.g., an IPsec tunnel over an MPLS network). 3 General Requirements 3.1 Topology The VPN service offering should support arbitrary user defined inter- site connectivity, ranging, for example, from hub-and-spoke, partial mesh to full mesh topology. An approach should support multiple VPNs per customer site. Carugi et al Informational - Expires August 2001 12 Service requirements for PPVPNs February, 2001 To the extent possible, the PPVPN services should independent of the access network technology. 3.2 Exchange of Data and Routing Information A mechanism for distributing reachability information between only those sites across a PPVPN must be provided. A mechanism to exchange reachability information with equipment at customer sites within a PPVPN must be provided. A means to constrain the distribution of addressed data to only those sites determined either by routing data and/or configuration must be provided. 3.3 Addressing The VPN service offering should satisfy the following addressing requirements: - support of customer VPN address overlapping - IP addresses have to be unique only within a given VPN, but not across VPNs. As direct consequence, the customer having deployed its own private numbering scheme on every location, this IP numbering scheme must be controlled; - he solution should be able (easily extendable) to enable a SP having an IPv4 or an IPv6 backbone to provide both IPv4 and IPv6 VPNs to its customers. - minimization of the usage of IP addresses (e.g., for mobile users)should be pursued; - support of NAT capabilities (NEEDS FURTHER DETAIL) 3.4 Security CURRENT STRUCTURE OF 3.4 FOLLOWS THAT IN [VPN-CRIT]. ALIGN WITH FRAMEWORK DRAFT AND PLANNED DRAFT ON IPSEC VPNS. THE ADOPTED STRUCTURE SHOULD BE THEN ALSO ALIGNED WITH SECURITY SECTIONS IN CHAPTER 4 AND 5. 3.4.1 User data security PPVPN solutions that support user data security should use standard means to achieve confidentiality, integrity, origin authentication. 3.4.2 Routing data security PPVPN solutions shall define means that [VPN-CRIT]: - prevent routers of a VPN from interaction with unauthorized entities, - prevent routes to VPN destinations from leaking to undesired entities, - avoid introducing undesired routing information to taint the VPN routing information base.. 3.4.3 Access control Carugi et al Informational - Expires August 2001 13 Service requirements for PPVPNs February, 2001 3.4.4 VPN isolation 3.4.5 Site authentication and authorization 3.5 Management The management activity of VPN services evolves in the TMN model. Then it will have to comply with the following requirements : - engineer, deploy and manage the switching and transmission resources supporting the service, from a network perspective (network element management); - manage the VPNs deployed over these resources (network management); - manage the VPN service (service management) ; - manage the VPN business, mainly provisioning administrative and accounting information related to the VPN service customers (business management). The service management itself should at least include the global activation of the TMN FCAPS functionalities. In particular, the following aspects should be considered: - the specification and the establishment of SLAs between the SP and the various customers, according to the corresponding SLSes ; - the measurement of the indicators which have been defined within the context of the above-mentioned SLAs, on a regular basis; - the management of the users which have been identified, so that they may benefit from the VPN(s) deployed accordingly. 3.6 Interoperability (TEXT MAINLY DERIVED FROM [Y.1311.1]) 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 should 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. Service interworking among different solutions providing PPVPN services should be also supported (in an as much as possible scalable manner). Security and end-to-end QoS issues should be addressed. 4 Customer Requirements 4.1 VPN Membership (Intranet/Extranet) - Multiple VPNs per customer site Carugi et al Informational - Expires August 2001 14 Service requirements for PPVPNs February, 2001 4.2 Service Provider Independence As customers might ask a provider for a VPN service that spans multiple administrative domains or even beyond the provider"s network, the service should be able to span multiple AS and SP but still act and appear as a single, homogenous VPN to the customer. 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 AS/SP. 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. It is undesirable that a VPN that spans multiple AS/SP can only be provisioned with a SLA that only guarantees the least common QoS and SLA parameters. This is of course also dependent on support agreements between the service providers 4.3 Addressing A variety of customer IP numbering schemes should be supported : - private ; - globally unique : the subscriber has deployed a globally unique IP numbering scheme composed of public IP addresses which have been delivered by the IANA or one of its representatives; - no scheme : the subscriber has deployed no IP numbering scheme, and has made no specific request either : in this case, the IP VPN service offering should be able to address this need, whatever the corresponding provisioning may be (i.e. private and/or public) ; - on-demand : a dynamic IP address allocation mechanism whenever requested by the user, and whatever the access may be, i.e. either permanent or temporary. 4.4 Traffic Types The IP VPN service offering should handle any kind of customer IP traffic - namely multicast and unicast; it might also have the ability to activate the appropriate filtering capabilities whenever required, and whatever the filter may be, upon request of the customer [VPN-NEEDS]. It is highly desirable to support 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.5 Routing Protocol Support There should be no restriction on the routing protocols used between CE and PE routers, or between CE routers. 4.6 SLA/SLS Every access link must support the specified SLA. From an application point of view, we may at least distinguish between: - SLAs/SLSes for applications which are sensitive either to delay, jitter, throughput or reliability (or a combination of the above- Carugi et al Informational - Expires August 2001 15 Service requirements for PPVPNs February, 2001 mentioned criteria)(e.g. real-time applications, such as Voice over IP) ; SLAs/SLSes for applications which are not that sensitive, i.e. they can accept an affordable degradation when being transmitted, even from a user perspective (e.g. transactional applications). The negotiation of appropriate QoS parameters according to the specific application requirements is particularly important to deal with SP network congestion periods (sensitive applications would probably negotiate precise guarantees measured on a regular basis, not-sensitive applications will probably rely on a per Class-of- Service differentiation). According to the DiffServ scheme of QoS support in IP-based networks, a mapping function (from customer DifServ to SP"s backbone DiffServ)should be provided at the edge of the SP network. Support of DSCP transparency[Y.1311.1]: the SP offering the VPN service should be able to set the IP DS field at the egress of the SP backbone to the same value as it was on the ingress of the SP backbone. A rationale for the support of this feature is the following. It is stated [RFC2475] that the codepoints of the DS field of IP packets may be changed within a DS domain by DS interior or DS boundary nodes, but that may not be sufficient in conjunction with the provisioning of IP VPNs, which may have specific requirements. In particular: - VPN customers using applications with internal CoS solutions should have the possibility to utilize the solutions independent of the DSCP solution supported by the SP infrastructure ; - VPN customers supporting more DSCPs than the SP should have the possibility to use these classes within their physical private network sites ; - carriers" carrier service scenarios should enable a customer SP to offer the VPN service to his VPN customers regardless of the DSCP solution supported by the SP identified as carriers" carrier SP. A customer expects to have consistent QoS independent of the access network technology used at interfaces at different sites connected to the same PPVPN. 4.7 Management This section describes the requirements for the customer management in association with the provision of 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 and authenticated, authorized customer agent. Dynamic Bandwidth management should allow real-time response to customer requests for changes of allocated bandwidth (control plane should be flexible to accommodate real time changes) [Y.1311.1]. Carugi et al Informational - Expires August 2001 16 Service requirements for PPVPNs February, 2001 4.8 Security/Integrity [Y.1311.1] Security mechanisms deployed to support the VPN service offer should be as transparent as possible for the customer excepted maybe for remote customers accessing the VPN through ISDN, PSTN, xDSL or Internet for which AAA services may have to be deployed. Users of an IP VPN should be able and allowed to deploy their own internal security mechanisms, in addition to those deployed by the SP, in order to secure specific applications or internal VPN traffic. Those internal security services should ideally have to conform to SP requirements especially when Quality of Service SLAs have been contracted between the customer and the SP. In such a case, the security solution deployed by the customer should not hide information used by the SP to set up QoS features. Generally, the constraint for the SP, in accordance with the privacy feature of the VPN, is to ensure, as far as possible, that internal security mechanisms which could be deployed within a VPN have a good chance to be transparently supported by the VPN service offer. The VPN will generally be secured according to the customer"s requirements in order to enforce the privacy characteristic of his VPN. This implies that the SP shall in particular ensure that : - every equipment (e.g. router) involved in the set up of a VPN shall be able to identify and authenticate each other so that the traffic exchanged within the scope of a VPN can be routed. Depending on the nature of this traffic and the nature of the equipment involved to process it, this identification and authentication could have to be achieved between CEs and/or between CEs and PE/P routers; - privacy services shall be provided and integrated as a service element by the Provider. Confidentiality and integrity services shall apply to : - either, all VPN traffic exchanged above the backbone between the different sites ; - or, some limited VPN traffic identified by a combination of source and/or destination IP addresses and/ or protocols and/or applications ; - administration traffic since this latter can contain sensitive information related to VPN configuration, users, security, accounting ; - isolation of each VPN shall be strictly ensured and the operator shall at least have some visibility on intrusion attempts in order to stop those intrusions; - in the same way, access to the various equipment deployed to support the IP VPN service shall be strongly secured in order to prevent unauthorized users to access the IP VPN resources. In particular, the access to the (switching) resources which are managed by the SP will have to be secured to prevent any kind of malicious attack, that may well come from any kind of hacker (internet users or else). Carugi et al Informational - Expires August 2001 17 Service requirements for PPVPNs February, 2001 4.9 Migration Impact VPN service customers having already deployed their own private internetwork (whatever the technology) should not suffer from migration considerations (whatever they are), when evolving from the above-mentioned internetwork towards one or more Provider Provisioned VPNs. This migration should be as smooth as possible, both from an economical and technical perspectives [VPN-NEEDS]. Migration should be also allowed without heavy disruption of service. Flexible scenarios of customer migration should be allowed, from full migration of all sites to partial migration (e.g. for a given VPN, the migration of some sites to a PPVPN service should still ensure service continuity with the other legacy VPN sites)[Y.1311.1]. 4.10 Network Access Every packet transmitted to or from the customer must have the usual format without VPN-aware encapsulation. 4.10.1 Physical/Link Layer Technology Since a VPN service offering will have to consider the connection of sites which may belong to an enterprise (or a set of enterprises), there should be no kind of limitation in terms of link-layer-based access technology, such as PSTN, ISDN, xDSL, cable modem, leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, mobile radio access, etc. (a wide range of bandwidth should be supported, according to the specific technology in use) [Y.1311.1]. To the extent possible, the architecture for IP-layer QoS should be independent of the access network technology. 4.10.2 Remote Access The VPN service offering should allow both permanent and temporary access (to one or several IP VPNs) for its users (again, with no limitation in the type of access technology which may be used as the IP transportation technology). 4.10.3 Sharing of the Access Network 4.10.4 Access Connectivity Multi-homing, Backdoor, Shortcut The following types of physical connectivity scenarios must be supported, such as multi-homed sites, backdoor links among customer sites, etc. Support for additional physical connectivity scenarios is desirable. A CE device is usually accommodated by a single PE router. However, four types of double-homing arrangements, shown in Figure 4.1, should be supported. Carugi et al Informational - Expires August 2001 18 Service requirements for PPVPNs February, 2001 +---------------- +--------------- +------+ +------+ +---------| PE | +---------| PE | | |router| | |router| SP network | +------+ | +------+ +------+ | +------+ | | CE | | | CE | +--------------- |device| | SP network |device| +--------------- +------+ | +------+ | | +------+ | +------+ | | PE | | | PE | +---------|router| +---------|router| SP network +------+ +------+ +---------------- +--------------- This type includes a CE device connected to a PE router via two access lines. (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 4.1: Representative types of double-homing arrangements. Carugi et al Informational - Expires August 2001 19 Service requirements for PPVPNs February, 2001 For multi-homing to 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 (i.e., the ratio of traffic on the multiple load-balanced links) may be provisionable based on customer"s requirements. The load balancing capability may also be used to achieve a degree of redundancy. 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). 4.11 Service Access 4.11.1 Internet Access VPN service can be coupled with Internet access per customer site, namely Internet access could be provided for all or part of the customer"s sites. Various options of the Internet access service should be supported [VPN-NEEDS]: - traffic from or to the Internet could be processed by the customer"s IP VPNs ; - traffic from or to the Internet could be rejected (via appropriate filtering capabilities) by the customer"s IP VPNs ; access from the Internet to some of the customer Web-based servers installed in one of his VPN sites (specific security issues need to be addressed). In case of combined VPN service and Internet access, support of mechanisms that prevent from compromising the traffic exchange between the customer private address space and the global unique Internet address space should be supported, such as NAT. This scenario of providing simultaneous access to the global Internet from any site that belongs to any VPN can be achieved in a number of ways, again, depending on the VPN mechanism used. For example, if the PE device is composed of virtual routers, then it is possible to access the Internet by means of a dedicated "global" virtual router within the PE device. As previously mentioned, a network address translation (NAT) or similar mechanism may then be required (either at the CE or within the PE device) in order to be able to distinguish private VPN addresses from global Internet addresses. If the PE device does not employ virtual routers, non-VPN (Internet) traffic may be directed by means of a default route to an Internet Gateway. This default route is distributed to all sites Carugi et al Informational - Expires August 2001 20 Service requirements for PPVPNs February, 2001 within a VPN to provide Internet access to all the sites. Traffic from the Internet to particular sites within VPNs has to be handled properly by ISPs, by distributing to the Internet routes leading to sites within VPNs. The internal structure of the VPN would be invisible to the Internet. A firewall function may be required to restrict access to the VPN from the Internet [Y.1311]. 4.11.2 Hosting, Application Service Provider TBD. 4.11.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. 4.12 Hybrid VPN Scenarios NEED COMMENTS - ALL 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, remote access, different availability of VPN solutions as provided by different service providers. The framework and solution approaches should include provisions for interworking, interconnection, or reachability between different VPN solutions in such a way that does not overly complicate provisioning, management, scalability, or performance. 5 Service Provider Requirements THIS INTRODUCTION TEXT REFERS TO A "NETWORK-BASED VPN" SERVICE: APPROPRIATE ADAPTATION TO PPVPN IS NEEDED. The following are some of the customer and provider motivations for a network-based VPN service offering: - Scalability - In a network-based VPN, edge-to-edge tunnels (PE-to- PE) need to be established versus end-to-end tunnels between customer sites, as in the CE-based VPNs. Therefore, fewer tunnels need to be maintained and scalability problems of VC-based VPNs (e.g. ATM, FR VPNs) are eliminated. - Outsourcing and manageability - Network-based VPNs allow customers who may not be able to afford the resources to manage their own sites to outsource the VPN management to the SP. For the SP himself, on the other hand, this presents a revenue opportunity. - Value-added services - Customers seeking value-added services such as multicast, web hosting, flexible SLA management and flexible billing may benefit from network-based VPNs. Similarly, a SP can attract more customers by providing such value-added services. Carugi et al Informational - Expires August 2001 21 Service requirements for PPVPNs February, 2001 Security in terms of isolation and authentication - Security similar to that obtained in VC-based VPNs can be easily provided in network- based VPNs. Higher levels of security like edge-to-edge encryption can be provided based on customer demand. The following are some of the generic issues that need to be addressed in a network-based VPN offering: - VPN membership - The PE device needs to determine which other nodes have members belonging to a particular VPN. In addition to this, a PE router that advertises membership to a particular VPN should be authorized to do so after appropriate verification. Dynamically creating and changing VPN interconnections and managing them is another aspect of membership that needs to be addressed in a network- based VPN solution. A VPN identification mechanism is essential in order to be able to identify traffic belonging to different VPNs, which may have the same IP addresses. - Route distribution - The distribution of reachability information within a VPN should be done in a secure and constrained manner. Different VPN customers may use the same non-unique IP addresses, and these need to be distinguished on a per-VPN basis. Since a SP"s network will be shared by multiple VPN customers, care should be taken to preserve isolation between different customers. In addition to this, customers wishing to access the Internet must be distinguished from those who desire secure access to their own VPNs. - Interworking across multiple AS"s - In an extranet scenario, a VPN can span across multiple provider boundaries or autonomous systems. Care should be taken that security and SLAs are maintained across multiple autonomous system boundaries. - QoS mechanisms and management - One of the main features of the network-based VPN is the opportunity for the SP to provide flexible QoS mechanisms and SLAs across its backbone, since the SP will have complete control over the VPN traffic across its backbone. This opportunity also presents its challenges of providing a simple and efficient QoS mechanism, which is flexible and easily manageable. QoS management systems based on Web-based interfaces to policy servers and policy-based QoS control are highly desirable features of any VPN solution. The interworking of policies across multiple vendor equipment, as well as the accurate translation of QoS requirements to network parameters is another major challenge. - Security - It should be noted that network-based VPNs can provide security by means of authentication and isolation across the SP"s network. However, encryption in network-based VPNs does not provide end-to-end security since the access links are not under the SP"s control. However, if encryption across the backbone is a customer requirement, it needs to be provided. 5.1 Scalability Scalable routing capabilities should be supported by the service : - the amount of routing and/or scheduling state in a P router independent of the total number of VPNs supported by the SP and of Carugi et al Informational - Expires August 2001 22 Service requirements for PPVPNs February, 2001 the number of VPN sites. This should be balanced against the requirements of specific services, such as multicast, - the amount of routing (and/or configuration) information on PE may depend only on the VPNs whose site(s) are connected to that PE. The content of this chapter tries to express the common understanding among several VPN service Service Providers about scaling requirements over the next several years(which time interval to be considered ?) in terms of projections for number, complexity, and rate of change (THE DIMENSIONS TAKEN INTO CONSIDERATION BELOW HAVE BEEN DEFINED INSIDE ITU-T [Y.1311.1], THE NUMERICAL ASSUMPTIONS REPRESENT A REVISED VERSION OF THOSE PRODUCED THERE). The main dimensions characterizing the scalability of a Provider Provisioned VPN service offering can be quantitatively expressed as the number of supported VPNs to be deployed by the SP, the number of supported terminations (permanent and temporary access)per VPN, the number of routes to be managed per VPN. From that perspective, the technical specification of a Provider Provisioned VPN service offering should consider the following numerical assumptions : - support of a very large number, on the order of 1,000,000, of VPNs per Service Provider network ; - support of a wide range of number of site interfaces per VPN (depending on size or structure of the customer organization): ranging from a few site interfaces to 50,000 site interfaces per VPN per customer - support of a wide range of number of routes per VPN : ranging from few to 200,000 routes per VPN (this number may be limited by the choice of the routing protocol between CE and PE). Typically, the number of routes I O(2N), where N is the number of site interfaces. - more than one VPN per site should be possible Numerical assumptions on VPN frequency of change (e.g. addition/removal of sites per VPN per time unit) could be as many as 1 million per year across all SPs within the next 5 years. High values of the frequency of configuration setup and change should be supported, e.g. for real-time provisioning of an on-demand videoconferencing VPN.. Numerical assumptions for complex deployment scenarios, such as Inter-AS (SP) VPNs and carriers" carrier, should be also provided. Which other dimensions of interest ? (bandwidth , private vs SP network scaling) Also need to consider scalability of management systems. 5.2 Addressing Support should be also provided for an IP numbering scheme outsourcing feature, which may consist for the service provider in managing the IP numbering scheme which has been deployed by or Carugi et al Informational - Expires August 2001 23 Service requirements for PPVPNs February, 2001 allocated to the subscriber, including the multicast addressing scheme. Such a feature could increase the network flexibility in case of growth and the rate of provisioning, and it could even allow cost- effective IP numbering resource optimization. 5.3 Identifiers A number of identifiers may be necessary for use in management, control, and routing protocols. Requirements for at least the following identifiers are known. FURTHER INPUTS ON THE USAGE OF A SPECIFIC IDENTIFIER IS NECESSARY. REQUIRES COORDINATION WITH FRAMEWORK DOCUMENT. IF IDENTIFIERS ARE USED, THEN FUNCTIONAL CONTENT, DESCRIPTIONS REGARDING THEIR USAGE, AS WELL AS SCOPE MUST ALSO BE PROVIDED. A SP must be uniquely identified at least within allthe interconnected networks of SPs. (In practice, it should be globally unique.) This is necessary when a single VPN spans multiple SPs. A identifier for each PPVPN should be unique, at least within each SP"s network. 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. The identifier of a device interconnecting SP networks must be unique within the set of aforementioned networks. Each logical port should have a unique identifier, at least within each PE router containing the logical port. Here, a logicalport represents a terminating point of an access link accommodating a user site. Each tunnel should have a unique identifier, at least within each router supporting the tunnel. 5.4 Learning VPN Membership The VPN service should support a mechanism that dynamically allows VPN information to be learned PE and CE. This mechanism could be used for different purposes, primarily for service scalability purposes. 5.5 Service Level Agreements and Specifications The Service Provider offering the VPN service has to commit in some specific service quality guarantees which will be part of the contract signed with the customer. The agreement will constitute the Service Level Agreement (SLA) and its corresponding technical Service Level Specification (SLS) for that particular VPN service offer. Carugi et al Informational - Expires August 2001 24 Service requirements for PPVPNs February, 2001 A range of (measurable) SLAs/SLSes should be provided on a per-VPN basis to address the various VPN customer needs. A list of SLAs is provided below (general SLA requirements for IP-based networks are more fully described in [Y.1241], part of them being applicable for VPNs). NEED TO REVIEW LIST AND IDENTIFY HOW AND WHERE THE REQUIREMENTS FOR THE IMPORTANT ITEMS WILL BE DETAILED. Service Level Agreements, per VPN and/or per VPN site, and/or per VPN route should include: o Service Level Objectives comprising some or all of: o IP Transfer Capability o QoS parameters o Availability o Reliability o Delivery confirmation o Mobility and Portability support o Security o Bandwidth o Priority o Authentication o Protocols supported o Flexibility - scaling and connectivity o Life of the SLA o Service monitoring objectives o QoS monitoring - comparison against objectives o Flow tracking o Reports as necessary o Financial compensation objectives o Billing option o Penalties o Pricing o Early termination charges According to the DiffServ scheme of QoS support in IP-based networks, a mapping function (from customer DiffServ to SP"s backbone DiffServ)should be provided at the edge of the SP network. SLSes based on the DiffServ scheme should be provided according to the following classification [Y.1311.1]: - Point-to-Point SLSes (also referred as the "Pipe" model) : the traffic parameters as well as the QoS commitment are specified on the basis of traffic exchanged between the CE at a pair of VPN sites. "Point-to-Point" SLSes are analogous to the SLSes typically supported over Layer 2 technologies, such as Frame Relay and ATM. A VPN SLS which defines compliance to the traffic contract by separate measurement of the packets transmitted from a given VPN site towards each remote destination VPN site is an example of "Point-to-Point" SLS. Carugi et al Informational - Expires August 2001 25 Service requirements for PPVPNs February, 2001 - Point-to-Cloud SLSes (also referred as the "Hose" model) : the traffic parameters as well as the QoS commitment are specified on the basis of traffic exchanged between a CE and a PE (as opposed to on the basis of traffic exchanged between CEs). A VPN SLS which defines compliance to the traffic contract by measurement of all the packets transmitted from a given VPN site towards the SP VPN backbone on an aggregate basis (i.e. regardless of the destination VPN site of each packet) is an example of "Point-to-Cloud" SLS. - Point-to-Multisite SLSes : the traffic parameters as well as the QoS commitment are specified on the basis of traffic exchanged between a VPN site and a subset of the other VPN sites. 5.6 QoS Quality of Service (QoS) is expected to be an important aspect of a PPVPN service for some customers. QoS requirements cover scenarios involving a intranet (i.e., a VPN composed of sites from a single customer), an extranet (i.e., a VPN composed of sites from multiple customers), as well as shared access between a VPN and the Internet. NOTE: THE FOLLOWING SUBSECTIONS WERE PROVIDED BY DIFFERENT SERVICE PROVIDER AUTHORS, AND HAVE NOT BEEN ALIGNED. MAILING LIST DISCUSSION IS SOLICITED TO FINALIZE THESE REQUIREMENTS. 5.6.1 A Service Deployment Perspective From a service deployment perspective, we may distinguish among : - Provider-managed CE-based VPNs : Quality of Service may be offered based on simple classification based on prioritization, without guarantees, or based on hard guarantees requiring more complex mechanisms to be met. QoS can be envisioned to be of two basic types : 1. Managed access VPN service The managed access VPN service provides traffic prioritization or service differentiation on the access circuit within the customer"s own Internet/intranet traffic. Service differentiation will be enabled only on the CE router and the customer ports of the PE router. This service does not require implementation of DiffServ in the core or Traffic Policing at the edge of the core network. For the sake of simplicity, three different traffic classes are defined: Real-Time (RT), Non-Real-Time (NRT), and Best Effort (BE). Real-time class ensures that mission critical applications will be given prioritized quality of service for delay sensitive applications. NRT class refers to "better-effort" and is well suited for non-real time applications with higher throughput requirements than a best-effort service. The managed access service"s customer will provide the packet classification requirements to the service provider. It is recommended that the SP provides several packet classification profiles to customers. Changes can be made on the profiles depending Carugi et al Informational - Expires August 2001 26 Service requirements for PPVPNs February, 2001 on additional customer requirements. More granular policies should be left to the customer for implementation. 2. Full-QoS VPN service The Full-QoS VPN service provides an end-to-end differentiated QoS to the VPN customer. The CE router requirements for this model are the same as the managed-access service. In the QoS VPN architecture, DiffServ is enabled throughout the core allowing service differentiation among all customers" traffic as opposed to the managed access service where differentiation is within a customer"s own traffic and only for the access link. In this model, the VPN customer receives a service where a CIR (Committed Information Rate) is specified for both RT and NRT traffic. RT traffic up to CIR_RT is guaranteed low delay, delay jitter, and packet loss rates. NRT traffic up to CIR_NRT is offered low loss rates and moderate delay and delay jitter. - Network-based VPN services: In this service the Provider Edge (PE) device performs aggregation of traffic from various CE sites. It should have the ability to support QoS mechanisms based on the underlying network technology (MPLS/ATM etc). Based on the customer profiles and QoS requirements, as obtained from the policy systems, DiffServ and/or ATM QoS (if the underlying network protocol is ATM) classification may be applied to incoming packets at the PE. Classification could be based on one (a combination) of a variety of factors like protocol ID, TCP or UDP port number, byte, destination address, source address, Differentiated Services byte etc. A variety of queueing mechanisms like Weighted Fair Queueing, Weighted Round Robin, Class-based Queuing, Random Early Detection (RED)etc. could be supported. In addition, shaping and policing may be used to monitor and control incoming and outgoing traffic at the PE. Each packet"s CoS/QoS attributes may be marked as desired either as a DiffServ Code Points (DSCP) or an ATM QoS class. At the PE router, the DSCPs may be used to define service classes. As for CE-based VPNs, three classes may be used for differentiation of Real-Time (RT), Committed Non-Real-Time (CNRT), and Best-Effort (BE) traffic. Once classified, packets are queued and scheduled for transmission. 5.6.2 A Standards-Based Approach 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 Carugi et al Informational - Expires August 2001 27 Service requirements for PPVPNs February, 2001 Note that all cases involving QoS may require that the CE and/or PE perform shaping and/or policing. QoS may be provided on an aggregate level for all PPVPN flows entering and leaving an interface. QoS in this case applies to packet sent to all destinations, section 5.5 calls this the "point- to-cloud," or "hose" SLS/SLA model. Note that the flows originating from multiple sources may congest the interface from the network toward the customer interface. Alternatively, QoS may be provided on a point-to-point basis for a specific set of flows, which section 5.5 calls the "pipe" SLS/SLA model. A layer 2 VPN naturally provides this type of QoS. Finally, as defined in section 5.5, there may be a one point to many point SLA/SLS model. How this would map to QoS is to be determined. PPVPN CE should be capable of supporting integrated services (Intserv) for certain customers in support of session types of applications, such as switched voice or video. Intserv-capable CE 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 2598]. - Assured Forwarding (AF) - is a means for a provider DS domain to offer different levels of forwarding assurances for IP packets 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 (buffer space and bandwidth) [RFC 2597]. It is believed that 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 Carugi et al Informational - Expires August 2001 28 Service requirements for PPVPNs February, 2001 PPVPN CE and PE equipment should be capable of supporting QoS across the following types of QoS-aware packet-switched access networks: - ATM Virtual Connections (VCs) - Prioritized Frame Relay - 802.1d Prioritized Ethernet - MPLS-based access - Multilink Multiclass PPP 5.6.3 Diffserv-Specific Requirements In case of usage of IPSEC tunnels, appropriate mechanisms should be supported in order to not compromise the DiffServ policies across the SP network ([RFC2983] elaborates on this topic). More sophisticated QoS requirements should be also supported when needed, such as Guaranteed Bandwidth tunnels (e.g. edge-to-edge MPLS tunnels in a Network-based VPN). NOTE THAT FOLLOWING TEXT IS CURRENTLY DUPLICATED IN CUSTOMER REQUIREMENTS According to the DiffServ scheme of QoS support in IP-based networks, a mapping function (from customer DifServ to SP"s backbone DiffServ)should be provided at the edge of the SP network. Support of DSCP transparency [Y.1311.1]: the SP offering the VPN service should be able to set the IP DS field at the egress of the SP backbone to the same value as it was on the ingress of the SP backbone. A rationale for the support of this feature is the following : it is stated [RFC2745] that the codepoints of the DS field may be changed within a DS domain by DS interior or DS boundary nodes. That may not be sufficient in conjunction with the provisioning of IP VPNs, which may have specific requirements : - VPN customers using applications with internal CoS solutions should have the possibility to utilize the solutions independent of the DSCP solution supported by the SP" infrastructure ; - VPN customers supporting more DSCPs than the SP should have the possibility to use these classes within their physical private network sites ; - Carriers" Carrier service scenarios should enable a SP to offer the VPN service to his VPN customers regardless of the DSCP solution supported by the SP identified as Carriers" Carrier SP. 5.7 Resource Control The Service provider should be able to deploy techniques to increase efficiency in terms of network resource utilization, such as Traffic Engineering, and this could possibly done - whenever adequate and acceptable in terms of scalability impact - on a per-VPN basis. 5.8 Inter-AS (SP)VPNs The scenario for VPNs spanning multiple Autonomous Systems (AS)or Service Providers (SP) is a complex one that requires a large degree of standardization. The scenarios where multiple AS"s are involved Carugi et al Informational - Expires August 2001 29 Service requirements for PPVPNs February, 2001 is the most general case, and is therefore the one described here. The scenarios of concern are the CE-based and network-based L2 and L3 VPNs defined in section 2. In each scenario, all applicable SP requirements, such as traffic and routing isolation, QoS, management, security, provisioning, etc. must be preserved across PEs in adjacent AS"s. An essential pre-condition for an inter-AS VPN is an agreement between the service providers 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 5.1. 5.8.1 Routing Protocols If the link between AS"s or SP"s is not trusted, routing protocols run between those AS"s or SP"s should support some form of authentication. For example, TCP option for carrying an MD5 digest may be used to enhance security for BGP [RFC2385]. AS"s/SP"s may specify the AS-path by use of standardrouting protocols. 5.8.2 Management 5.8.3 Bandwidth and Qos Brokering As a VPN should be able to span multiple AS and Service Providers, there is a need for some kind of mechanism that requests certain SLA/QoS parameters from the other domains and/or networks involved in transferring traffic to various sites. This mechanism can be a manual one, e.g. where one provider requests a specific set of QoS parameters for traffic going to and from a specific set of sites from another provider and receives a number of ATM VCs. The mechanism could also be a more automated one where the network itself dynamically requests and receives certain SLA/QoS parameters, for instance negotiates which label to use for different traffic classes for a set of sites 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 be for instance to dynamically request and reserve certain QoS parameters such as bandwidth and priority, and then to classify, mark and handle the packets as agreed upon. Observe that as traffic might traverse multiple AS the brokering method should also allow this. It is not necessary to perform this kind of brokering on a per VPN basis. Another method might be to make an agreement on a per Service Provider basis specifying the maximum amount of bandwidth and other QoS parameters a service provider might use as a total for all it"s customers usage of the other providers network. Or, it might be on a Carugi et al Informational - Expires August 2001 30 Service requirements for PPVPNs February, 2001 per VPN tunnel basis. The essential is the ability to establish and guarantee uniform QoS across several AS/SP. 5.8.4 Security Considerations If a tunnel traverses multiple SP networks and it passes through an unsecure SP, POP, NAP, or IX, then security mechanisms must be employed. 5.9 Isolation (Traffic, Processing Resources) Routers must isolation VPNs from one another, both with respect to forwarding and with respect to the distribution of routing information. For example, assume that a network contains three routers (A, B, and C) and supports three VPNs (A, B and C). Assume also that each router dedicates one access port to each of the three VPNs. Each router must maintain four forwarding tables, a general table and one table that supports each of the three VPNs. When a CE submits a datagram the the network, the PE should forward that datagram according to policy defined by the forwarding table that the CE maintains for that VPN. If that forwarding table does not contain a relevant entry, the CE should execute one of the following procedures, depending upon its configuration: 1) discard the datagram 2) attempt to forward the datagram based upon information obtained from the general routing table. The PE MUST NOT forward the datagram based upon information obtain from any other VPNs forwarding table. Likewise, routers must isolate VPNs from one another with respect to the distribution of routing information. In the network described above, assume that Router A is connected directly to CE A which is a member of VPN A. Router A may distribute routing information concerning CE A to Routers B and C. Routers B and C may install this information in the forwarding table that supports VPN A, but not any of the other forwarding tables. 5.10 Tunneling Mechanism Independence and Selection Connectivity between CE sites and SP PE to PE nodes in the backbone should not be limited in terms of tunneling technology, such as L2TP, IPSEC, GRE, MPLS, etc. [Y.1311.1] A variety of tunneling technologies should be supported inside the SP network between (a pair of) PEs, including MPLS, IPSEC, GRE, IP in IP. The tunneling technology used by the VPN Service Provider and its associated mechanisms for tunnel establishment, multiplexing, maintenance should fit the various requirements of the specific VPN Carugi et al Informational - Expires August 2001 31 Service requirements for PPVPNs February, 2001 service offering, such as scaling, security, manageability and QoS related ones. To set up tunnels between PE routers, every PE router must support static configuration for tunneling and may support a tunnel setup protocol. NEED FURTHER INPUTS ON TUNNEL ESTABLISHMENT AND MONITORING REQUIREMENTS. The tunnel establishment protocol must convey information regarding: - Relevant identifiers - QoS/SLA - Restoration - Multiplexing 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 5.11 Backbone Technology Independence Considering the physical and link layer technology to be used by the SP"s backbone which will support the IP VPNs, the VPN service offering should not depend on that. Nevertheless, the engineering characteristics of such an IP backbone will have to be taken into account when specifying the IP VPN service offering. 5.12 Protection, Restoration From the access perspective, it should be possible to provide a back- up capability whenever the primary access link from a site to one of the IP VPN(s) fails to be operational. This back-up capability should obviously be as dynamic as possible, i.e. the back-up link should be dynamically established as soon as the primary access link fails to be operational, and should become dynamically idle as soon as the primary access link comes back up [VPN-NEEDS]. The Service provider should be able to deploy techniques to increase reliability and fault tolerance of the VPN service offering, such as network protection and restoration mechanisms, and this could possibly done - whenever adequate and acceptable in terms of scalability impact - on a per-VPN basis. Adequate performance indicators should be provided to qualify such capabilities. Appropriate indicators in relation with network protection and restoration mechanisms should be provided from the service user perspective. As mentioned in Section 4.10.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 Carugi et al Informational - Expires August 2001 32 Service requirements for PPVPNs February, 2001 not all) of the multi-homing 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. 5.13 PPVPN Wholesale The architecture must support the possibility of one service provider offering VPN service to another service provider. This may be useful, for example, when one service provider sells PPVPN service at wholesale to another service provider, who then resells VPN service to his 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. - -The Carrier"s carrier scenarios belong to 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) 5.14 Management FOLLOWING TEXT IS FROM Y.1311.1 Setting up the VPN and managing the deployed devices requires to take care of three main aspects : - connectivity : configuring, provisioning and managing the devices, especially when topology can change - network monitoring (particularly performance and capacity monitoring) in order to meter resources usage and to anticipate scalability problems - security : authentication, authorization and overall policies (including security risks introduced by policy inconsistency). In order to facilitate the service management, a logical view of the network indicating VPN topology above the backbone topology is useful. It can be used for provisioning and verification of connectivity, verification of configuration/privacy, fault management and performance management. The specification of a management information base (MIB) describing the detailed configuration of network elements involved in the Carugi et al Informational - Expires August 2001 33 Service requirements for PPVPNs February, 2001 provisioning of VPN services is a key requirement in network provisioning. The general topic of MIBs for PPVN services will be handled within the framework document. ADDITIONAL TEXT NEEDED TO MAKE THE FOLLOWING AN EXHAUSTIVE LIST A management system should satisfy the following requirements: - Control, SLA measurement and accounting on a per customer basis, - Policy for "CE-to-PE" and "PE-to-PE", - Access to VPN parameters (e.g., security keys, location of tunnel initiation/termination points, application-to-DSCP mappings, QoS parameters, etc.) from a secured centralized location, - Access to customer directory services, - New policy and billing implemented in near real time, - Flexibility in terms of service scenarios to be managed, such as customer site connectivity, topologies, deployment scenarios, types of customer IP traffic (v4/v6, unicast/mcast,...). FOLLOWING TEXT FOR ALL 5.14.1, 5.14.2 SECTIONS IS FROM ITU Y.1311.1 Both the SP and its customers should be able to manage the capabilities and characteristics of their VPN services. Automated operations and interoperability with standard management platforms should be pursued. 5.14.1 Configuration Management Following the VPN growth, configuration management for VPNs,according to service templates defined by the provider must be supported. VPN configuration management is needed for basic components such as PE and CE, for example to provision VPN tunnels and access network/links. The management system could centralize such a process to guarantee coherence of parameters and accelerate deployment by automating configuration. As VPN configuration and topology highly depends on the customer"s organization, provisioning templates have to apply to the customer"s specific requirements (remote accesses, security policy, QoS). The management system could rely on centralized information to get all needed parameters for optimal adaptation of templates to specific needs. Such a system may increase the network reactivity in case of failure or policy violation. It can reduce provisioning delay in case of current VPN configuration requested by the customer (add, modify, delete), which can be a very heavy task in terms of routing tables update. In a multi-domain environment, the end-to-end QoS depends on the QoS provided by each domain. In case of a VPN spanning accross two domains, QoS provisioning may reach its limit and such a problem seems difficult to solve. Carugi et al Informational - Expires August 2001 34 Service requirements for PPVPNs February, 2001 Conformance between configured results and customer specific requirements should be verified. This topic is covered in sections 5.14.1.3 and 5.14.1.4. 5.14.1.1 Configuration Management for Network-Based VPNs Concrete requirements on configuration management for Network-based VPN are described as follows. o The configuration of PE routers must be supported. Their management information includes IP routing information and access control policy information for intranet and extranet membership. o Systematic alignment of related identifiers and mapping of these identifiers according to configuration are important when configuring PPVPNs. Identifiers for SPs, PPVPNs, PEs, CEs, VPN tunnels and identifiers for logical ports as mentioned in Section 5.3 must be configurable to realize desired L2 connectivity and/or L3 reachability of the NBVPN. NOTE: ALIGNMENT WITH SEC. 5.3 IS NEEDED o Tunnel information must be configured. It includes the identifiers of tunnels, identifiers of logical links, tunnel states, and QoS/SLA information for QoS/SLA service. o Routing protocols running between PE routers and CE devices must be configured per VPN. For multicast service, multicast routing protocols must also be supported. o Routing protocols running between PE routers must be configured. For multicast service, multicast routing protocols must also be supported. o The configuration of network-based PPVPN must be coordinated with the configuration of the underlying infrastructure, including Layer 1 and 2 networks interconnecting components of PPVPN. 5.14.1.2 Configuration management for CE-based VPN NOTE: TO BE WRITTEN 5.14.1.2 Verification of L2 Connectivity and L3 Reachability It is desirable that a capability to verify the L2 connectivity or L3 reachability between CE at user sites within a VPN is provided. If a logical view of a VPN is provided and the result of this verification is shown in this view, the operator can understand the result easily. NOTE:ABOVE TEXT REQUIRES MORE REVIEW/ POSSIBLE REVISION. 5.14.1.3 Verification of configuration and privacy It is desirable that a capability to verify the configuration and privacy of a VPN is provided. Privacy here means that the VPN cannot be accessed from outside of this VPN. If a logical view of a VPN is Carugi et al Informational - Expires August 2001 35 Service requirements for PPVPNs February, 2001 provided and the result of this verification is shown in this view, the operator can understand the result easily. NOTE:ABOVE TEXT REQUIRES MORE REVIEW/ POSSIBLE REVISION. 5.14.2 Service monitoring Network monitoring in the VPN perspective includes the classical items such as fault management, service-level management and accounting. 5.14.2.1 Fault management As VPNs rely on a common network infrastructure, the network management system should provide means to inform the provider on the consequences of a device failure for the VPNs it supported. The NM should provide a logical view of the network indicating VPN topology above the backbone topology. It should provide pointers to the related configuration and customer"s requirement information so as to ease fault isolation and take corrective action as impact on traffic engineering and security considerations may be important. To summarize, fault management includes : - customers information of failures, - faults detection (incidents reports, alarms, failures visualization, SLA violation), - faults localization (analysis of alarms reports, diagnosis), - incidents recording, logs,(creation and following of the trouble ticket), - corrective actions (traffic, routing, resources ...). It is desirable to detect faults cause by configuration errors, because these may cause VPN service to fail, or not meet other requirements (e.g., traffic isolation). Detection of such errors is inherently difficult because the problem involves more than one node and may reach across a global perspective. On approach could be a protocol that systematically checks that all constraints and consistency checks hold between tunnel configuration parameters at the various end points. 5.14.2.2 Performance management The performance management system should be able to monitor network behaviour in order to evaluate performance metrics that form part of the service-level agreements. Multiple different VPN services are subscribed by the customers and the system should be able to deploy specific measurement techniques depending on the activated service components (security, multicast, remote access). These techniques may be either intrusive or non-intrusive depending on the parameters or service being considered. QoS deployment and SLA monitoring may be coupled by monitoring policies that : - describe QoS mechanisms and the associated metrics that should be activated Carugi et al Informational - Expires August 2001 36 Service requirements for PPVPNs February, 2001 - control monitoring resources such as probes and remote agents Remote agents may be a key to the network monitoring as it allows the collection of statistics directly at the network access points used by customers and mobile users. A logical view of the network indicating the VPN topology helps operators to understand the result of the performance management activities. To summarize, performance management includes : - real-time performance measurements (indicators and thresholds initialization and modification, data collection), - real-time monitoring (resources utilization), VPN status (up/down), - analysis (bandwidth, response time, availability, packet loss), - statistics and trends based on collected metrics. Additionally, the performance management system should have a "Dynamic Bandwidth management" capability : - Dynamic Bandwidth management should allow real-time response to customer requests for changes of allocated bandwidth (control plane should be flexible to accommodate real time changes) (*) - Performances (e.g. bandwidth allocation) should be traceable (*): Dynamic bandwidth allocation would normally occur within the ranges and bounds specified in the Service Level Agreement (SLA), possibly using internal SP mechanisms to check appropriate allocation. 5.14.2.3 Accounting Being able to associate service profiles to customers and to the resources providing these services may facilitate accounting, which can be a key feature of subscribed services. The accounting system has to be able to sort among the huge amount of usage information and correlate this information to performance and fault management information to produce billing according to the real provided service. It should be noted that accounting requirements may conflict with security requirements. To summarize, accounting process includes : - measurements of resources utilization, - production of accounting information, - measurement storage (files creation and administration), - quotas control per customer (current consumption update, consumption authorizations checking). 5.14.2.4 Security management features The security management system of a VPN solution must include management features to guarantee the security of network connections, the privacy and integrity of data, as described in section 5.16. 5.14.2.5 Access Control TEXT OF THIS CHAPTER SHOULD BE REVISED TO JUST INDICATE SUPPORT OF SECURITY MANAGEMENT FEATURES FOR ACCESS CONTROL (AUTHENTICATION, DATA PRIVACY). TEXT CURRENTLY PROVIDED BELOW IS A DESCRIPTION OF SECURITY Carugi et al Informational - Expires August 2001 37 Service requirements for PPVPNs February, 2001 FEATURES, SO IT HAS A MORE APPROPRIATE LOCATION IN SECURITY SECTION 5.16 (REDUNDANCY WITH THIS SECTION HAS ALSO TO BE CHECKED). Access control dictates the amount of freedom a VPN user has, and controls the access of other users to applications and different parts of the network. A VPN without access control only protects the security of the transported data but not the network. Access control capabilities protect the entire network to ensure that VPN users have complete access to the applications, but only to these resources. In case of negotiated customer bandwidth, the access control at network level should ensure that each customer doesn"t violate his contract. 5.14.2.5.1 Authentication Authentication is the process of verifying that the sender is actually who he says he is. Support for strong authentication schemes is particularly important to ensure the privacy of both VPN access point-to-VPN access point (PE to PE) and client-to-VPN Access point (CE-to-PE) communications. This is particularly important to prevent VPN access point spoofing ( e.g. PE fake to enter a specific or a set of VPNs) in the presence of auto-discovery mechanisms. Nomadic access implying dynamic evolution of PEs serving a specific VPN is another situation which requires such authentication schemes in the presence of autodiscovery mechanisms. A variety of authentication methods are available to meet the needs of particular VPN deployments, including username/password authentication, RADIUS or TACACS servers, LDAP directory servers, X.509 digital certificates, smart cards, ... Scalability is critical when the number of nomadic/mobile clients is increasing. The authentication scheme implemented for such deployments must be both manageable and easily deployed for large numbers of users and VPN access points. 5.14.2.5.2 Data privacy A VPN solution should protect the privacy of the data being transmitted. Here data means both user and control information. Data privacy could be provided by encryption or by other mechanisms, e.g. data separation. It may support multiple encryption algorithms and encryption schemes, including DES, 3DES, and the IPSec standards. Encryption, decryption, and key management could be included in profiles that may be inforced by a policy-based management system. It should be possible to activate encryption on specific services. 5.14.2.6 SLA and QoS management features The management system should support : - specification and the establishment of SLAs between the SP and the various customers, according to the corresponding SLSes ; Carugi et al Informational - Expires August 2001 38 Service requirements for PPVPNs February, 2001 measurement of the indicators which have been defined within the context of the above-mentioned SLAs, on a regular basis. FOLLOWING TEXT (SECTION 5.14.3) MAY BE MORE APPROPRIATE FOR FRAMEWORK AS A POTENTIAL SOLUTION - - NEED COMMENTS AND INPUT - - NARAIN, IF YOU HAVE TIME LOOK TO SEE IF LIST IN 5.14.3 IS CORRECT, SHOULD BE AUGMENTED. 5.14.3 VPN management solutions The following options are available for deploying management systems for the VPN offering: 1. Use a call center model for customer control, 2. Deploy proprietary or custom-made management solutions, 3. Deploy a standards-based, policy-based VPN management solution The third option is more scaleable and interoperable and are beneficial to both the customer and the provider. The following chapter describes this option. 5.14.3.1 Policy-based management model This model contains four functional areas: configuration; network element; policy engine; and billing. The configuration and billing functional areas provide the customer with a "window" into the provider"s network. Customers can see the level of service that they have and alter it accordingly. The other functional areas view the customer configurations as parameters which must be satisfied. This is the first option where the customer can view and configure the network in near real time. The network is configured by either defining policy in a customer owned directory service or by configuring the service by using a web browser. The web browser sends information directly to the policy engine, which is the service control point of the system. The policy engine can also access policy information through LDAP connections to the customer directory service. Policy-based management provides the ability to specify rules to govern the behavior of a service. The function of the policy engine involves retrieving and interpreting policy, detecting conflicts, sending the policy to the Policy Enforcement Points (PEP), being aware of network health, SLA requirements, and tracking how customers are currently using the network. The policy engine communicates policy to the PEP by using COPS (Common Open Policy System) and information is communicated back using traditional management protocols (e.g., SNMP). Policy is described by using the Policy Core Schema. Carugi et al Informational - Expires August 2001 39 Service requirements for PPVPNs February, 2001 The billing system receives notifications of the changes made by the customer through the policy engine. The customer may view current service parameters at any time by coupling the billing system with the HTTP server. Deploying a policy-based system satisfies the following customer management requirements: - Customer control via a web-based service or a directory enabled service, - Flexible administrational policy to any number of elements, - Fully automated to satisfy non-real time requests based on the current network condition. 5.15 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. 5.16 Isolation, Security, Authentication and Identification SECTION 5.16 COMES FROM [Y.1311.1] The following security functions (described hereafter) should be considered in a PPVPN service offering: - isolation ; - user identification ; - user authentication ; - security of the flow ; - peer identification ; - peer authentication ; - site protection. 5.16.1 VPN isolation From the SP perspective and at a high level of description, the VPN isolation function consists in ensuring that all traffic exchanged within the scope of a VPN remains unknown and protected from other users of the backbone and insensitive with regard to traffic transported over the supporting backbone. From this perspective the SP shall ensure, when deploying the service, that it conforms to the following characteristics : - only a set of pre-defined users can access the VPN, - QoS SLA shall be guaranteed whatever the state of the traffic experienced in the supporting IP backbone and especially when this traffic is generated by other customers within or outside the scope of the VPN service, - IP connectivity shall be deployed in such a way that only recorded VPN sites and registered remote users can exchange traffic within the Carugi et al Informational - Expires August 2001 40 Service requirements for PPVPNs February, 2001 VPN. This may lead peer equipment to identify/authenticate each other at different level of the VPN service, - traffic exchanged might be secured thanks to encryption and/or authentication functions, - VPN management functions shall not impact other VPN or IP services. This isolation function is achieved by application of a combination of functions related to architecture, quality of service, security and administration functional domains. This set of functions, correctly deployed, constitutes a generic function called "VPN isolation". This function is nevertheless classified within the security domain due to the strong implication of security features in the realization of such a global isolation function. 5.16.2 VPN user identification Among VPN users can be found travelling people who are not permanently attached to one of the sites of the VPN. In order to control the access of those users to the VPN it is necessary to identify them. This identification shall apply within the various deployment context which have been identified (intranet, extranet, sub-vpn), keeping in mind that some of these users can have an access to several distinct VPNs. This identification function can be used to automate or trigger all technical actions which are necessary to establish the communication with the VPN he wants to connect to. Two main identification contexts have to be considered : - identification in case of "mobility", whatever it is an intra-site or inter-site mobility, - identification when the user tries to reach his IP VPN from a public or private access point through a NAS/BAS server or even from a network having an Internet access to which he has a temporary access. This function can be implemented by the VPN SP in totality or partially. Roaming capabilities could probably have to be set-up between the Provider and the customer who might well decide to perform the VPN user identification in case he would not accept to outsource the identification/authentication service. In fact this identification will be used by the access SP who needs to identify the user to provide the IP connectivity and by the VPN user identification service in order to accept the VPN connection. The two mechanisms can be linked. In this case the access Provider and the VPN SP resources have to cooperate and an agreement has to be reached on common identification specification. All information necessary to identify the users will have to be stored and should ideally be maintained by the customer. This information should be made available to the access Provider for controlling the IP access. Carugi et al Informational - Expires August 2001 41 Service requirements for PPVPNs February, 2001 5.16.3 VPN user authentication The scope of this authentication function is the same than above and concerns users in a remote access situation. This authentication function will consist in ensuring, with a good level of confidence, that the declared user is the one is claiming to be. Various authentication protocols might be used for that purpose depending on the level of security wished by the customer but at least PAP, CHAP and challenged mechanisms should be supported since they are currently widely used in a large range of equipment and services. This authentication function may be executed completely or partially by the VPN SP. In the latter case the authentication phase can be relayed to the customer access point according to the terms of the contract. 5.16.4 Securing the flow Within the present context which consist in deploying a VPN over a public IP backbone (which is part of the Internet), the sole routing functions are not sufficient to secure the flows of a given customer. As a matter of fact, even if the flows are correctly routed between the sites (including remote users), the corresponding traffic might be intercepted and consequently read or altered. Securing the flows should be enforced at the network layer to ensure the two main characteristics : - privacy of the traffic, so that only authorized equipment decrypt it, - integrity, to protect recipients from alteration which could have been introduced during the transport. These two functions shall apply to what is called here the "data traffic" of the customer which includes the traffic exchanged between sites, between remote users and sites and even between remote users. But it shall also apply to "control traffic", which is not necessarily perceived by the customer but nevertheless essential to maintain his VPN. Even if it is strongly recommended to deploy those functions in an operational context, these functions shall not be considered as mandatory and should be activated only if requested by the customer. In the same kind of idea, those functions should be as flexible as possible so that they can be deployed independently from each other and applied to some part of the traffic (security level may differ depending the traffic which is considered, performance considerations may also lead to secure a sub-set of the traffic). 5.16.5 Peer identification Traffic exchanged within the scope of VPN may involve several categories of equipment that need to cooperate together to provide the service. These network elements can be CE, firewalls, backbone routers, servers, management stations, etc. Carugi et al Informational - Expires August 2001 42 Service requirements for PPVPNs February, 2001 Each time two network elements need to cooperate, it is necessary for the peer to proceed to an identification (enforced by an authentication if needed, see below) before accepting to process the received traffic or to provide the requested service. This identification can be used as a trigger to adapt the way the service will be provided but in most cases to control the access to the network resources. This peer identification function is intended here to apply only to network elements participating in the VPN setup. Are excluded here all identification needs related to users" applications. Examples of such peer identification could apply to : - traffic between a CE and a SP access point (P/PE access point), - traffic between CEs belonging to the same VPN, - routers dealing with route announcement (these routers could be a CE and P/PE router or two CEs exchanging routing information), - policy server and a network element, - management station and an SNMP agent, etc. This identification function shall not be considered as an atomic function since it is rather distributed and probably implemented differently depending on network elements which are considered. But globally, the VPN service shall provide a peer identification function in defining where it is necessary, how it shall be implemented, how secured it shall be and the way to deploy and maintain identification information necessary to operate the service. 5.16.6 Peer authentication This function is the prolongation, in security terms, of the above function. It aims at authenticating the peer following the same philosophy adopted for user identification and authentication. 5.16.7 Site protection A site might be involved in various ways within the scope of a VPN. It can be part of a VPN deployed to support an Intranet (in that case he is inter-connected with sites belonging to the same company), part of an IP VPN deployed between different companies to support an Extranet, or both. Within this context, a site might be subject to various attacks coming from different sources. These potential sources are : - users connected to the supporting public IP backbone, since by definition a IP VPN is built over a public and shared IP infrastructure, - users from the Internet, if the backbone offers an Internet access, - users from remote sites belonging to the VPN the site is part of. Risks that a site may encounter are the following: Carugi et al Informational - Expires August 2001 43 Service requirements for PPVPNs February, 2001 - service denial (when a hacker acts in such a way that a service cannot be used. Mail spamming and access line overloading for instance) ; - viruses ; - intrusions. In order to prevent those risks the VPN SP shall deploy functions that control access to the site, thanks to the deployment of filtering functions provided by firewall for instance but also in monitoring, alerting and eventually logging all suspicious activities in order to detect all possible attacks. 5.17 Provisioning Routing [Y.1311.1] Filtering of VPN routing information in the PE-to-PE and CE-to-PE configurations should be supported. A variety of routing protocols should be supported at the edge and the core level of the Service Provider network : - there should be no restriction on the routing protocols used between CE and PE routers ; - the choice of SP"s IGP must not depend on the routing protocol(s) used between PE and CE routers. Furthermore, that choice should be flexible, not limited to a single routing protocol. 5.18 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. 5.19 Provisioning Security Services Deployment scenarios with application of security should be provided (managed CE-based VPNs, L2 VPNs, L3 VPNs) 5.20 Provisioning VPN Parameters Need to have a means to dynamically provision resources associated with implementations of VPN services (e.g., virtual routing instances, table space, etc.). The dynamic nature of the VPN resource assignment is crucial to cope with the frequent changes from the customer side (e.g., users joining and leaving the VPN), and achieve scalability. The PEs should be able to dynamically assign the VPN resources. This capability is especially important for dial and wireless VPN services. 5.21 Provisioning Value-Added Service Access A VPN service is from a business point of view quite simple, only providing access between different sites over a common backbone. Other market drivers for the SP business is various kinds of services, and when these are provided through the VPN service itself, we might regard them as value added services. Examples of these kinds of services is for instance Internet access, firewall services, virus screening, IP telephony and IP centrex, application hosting, backup, etc. It is out of this documents scope to define if and how these Carugi et al Informational - Expires August 2001 44 Service requirements for PPVPNs February, 2001 different services 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. 5.21.1 IP Networking 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. The VPN service offering should allow the outsourcing of IP services. The management system could rely on centralized information to get all needed parameters for optimal adaptation of IP services to specific needs. This could also allow cost-effective optimization by offering services at a large range of customers. 5.21.2 Internet access Network-based firewall services must be carrier grade. For redundancy and failure recovery, means for firewall fall-over should be provided. Network-based firewall services that may be provided include virus scanning, traffic-rate limiting against malicious attacks, etc. Network-based firewalls must be supported on a per-VPN basis (although multiple VPNs may be grouped into the same firewall). Network-based firewalls should be provided at the major access point(s) for the PPVPN. Network-based firewall services can be embedded in the PE equipment, or can be standalone equipment. 5.22 Provisioning Hybrid VPN Services Service interworking between the identified solutions for PPVPN services and other solutions providing VPN services (e.g. VC-based VPNs) should be also supported. Security and end-to-end QoS issues should be addressed. 5.23 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 6 Security Considerations TBD Carugi et al Informational - Expires August 2001 45 Service requirements for PPVPNs February, 2001 7 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 framewbork document [RFC 2764], Tom Worster, Ron Bonica, and Sanjai Narain. 8 References [RFC1777] Yeong, W. et al., "Lightweight Directory Access Protocol," RFC 1777, March 1995. [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-2251] Wahl, M. et al., "Lightweight Directory Access Protocol (v3)," RFC 2251, December 1997. [RFC-2661] Townsley, W. et al., "Layer Two Tunneling Protocol "L2TP"," RFC 2661, August 1999. [RFC-2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs," RFC 2547,March 1999. [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work in progress. [RFC-2764] Gleeson, B., et al., "A Framework for IP based Virtual Private Networks", RFC 2764, February 2000 [2917bis] Muthukrishnan, K., et al., " A Core MPLS IP VPN Architecture", work in progress [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider Provisioned Virtual Private Networks ",work in progress [NBVPN-FR] Suzuki, M. and Sumimoto, J. (editors), "A framework for Network-based VPNs", 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 Draft Recommendation, November 2000 (http://nbvpn.francetelecom.com/ituRelated.html) [Y.1311] Jamoussi, B. (editor), " Network based IP VPN Service - Generic Framework and Service Requirements ", Y.1311 ITU- T Draft Recommendation, November 2000 (http://nbvpn.francetelecom.com/ituRelated.html) Carugi et al Informational - Expires August 2001 46 Service requirements for PPVPNs February, 2001 [L2 VPN] K. Kompella et al, "MPLS-based Layer 2 VPNs," work in progress [L2 MPLS] L. Martini et al, "Transport of Layer 2 Frames Over MPLS," work in progress. [RFC 2205] [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, September 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 2598] "An Expedited Forwarding PHB", V.Jacobson, K.Nichols, K.Poduri, RFC 2598 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, October 2000 NOTE: LIST OF REFERENCES MAY NOT BE COMPLETE, AND NOT ALL REFERENCES LISTED ARE CURRENTLY CITED. 9 Authors" address Marco Carugi (Co-editor) France Telecom Research and Development Technopole Anticipa - - 2, av. Pierre Marzin 22307 Lannion cedex, France Phone : + 33 2 96 05 36 17 Fax : + 33 2 96 05 18 52Email : marco.carugi@francetelecom.fr Dave McDysan (Co-editor) WorldCom 22001 Loudoun County Parkway Ashburn, VA 20147, USA dave.mcdysan@wcom.com Luyuan Fang AT&T 200 Laurel Ave - Room C2-3B35 Middletown, NJ 07748 USA Luyuanfan@att.com Fredrik Johansson Telia Research 5E-123 86 Farsta, Sweden frederik.xz.johansson@trab.se Ananth Nagarajan Sprint Carugi et al Informational - Expires August 2001 47 Service requirements for PPVPNs February, 2001 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 Zephion Networks rwilder@bbo.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 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 August 2001 48