Luyuan Fang (editor) AT&T Michael Behringer Cisco Ross Callon Juniper Fabio Chiussi Lucent Technologies Jeremy De Clercq Alcatel Mark Duffy Quarry Technologies L3VPN WG Paul Hitchen BT Internet Draft Paul Knight Nortel Networks Document: draft-ietf-l3vpn-security-framework-00.txt Expires: March 2004 September 2003 Security Framework 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 RFC2026. 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." Expires March 2004 1 PPVPN Security framework September 2003 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. Abstract This draft addresses security aspects pertaining to Provider Provisioned Virtual Private Networks (PPVPNs). We first describe the security threats that are relevant in the context of PPVPNs, and the defensive techniques that can be used to combat those threats. We consider security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. We also describe how these security attacks should be detected and reported. We then discuss the possible user requirements in terms of security in a PPVPN service. These user requirements translate into corresponding requirements for the providers. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, we define a template that may be used to analyze the security characteristics of a specific PPVPN technology and describe them in a manner consistent with this framework. Table of Contents Status of this Memo................................................1 Abstract...........................................................2 Conventions used in this document..................................3 1. Introduction...................................................3 2. Security Reference Model.......................................4 3. Security Threats...............................................6 3.1. Attacks on the Data Plane...................................7 3.2. Attacks on the Control Plane................................8 4. Defensive Techniques for PPVPN Service Providers..............10 4.1. Cryptographic techniques...................................11 4.2. Authentication.............................................15 4.3. Access Control techniques..................................17 4.4. Use of Isolated Infrastructure.............................20 4.5. Use of Aggregated Infrastructure...........................21 4.6. Service Provider Quality Control Processes.................21 4.7. Deployment of Testable PPVPN Service.......................22 5. Monitoring, Detection, and Reporting of Security Attacks......22 6. User Security Requirements....................................23 6.1. Isolation..................................................23 6.2. Protection.................................................24 Expires January 2004 Page 2 PPVPN Security framework September 2003 6.3. Confidentiality............................................25 6.4. CE Authentication..........................................25 6.5. Integrity..................................................25 6.6. Anti-Replay................................................25 7. Provider Security Requirements................................25 7.1. Protection within the Core Network.........................26 7.2. Protection on the User Access Link.........................28 7.3. General Requirements for PPVPN Providers...................29 8. Security Evaluation of PPVPN Technologies.....................30 8.1. Evaluating the Template....................................30 8.2. Template...................................................31 9. Security Considerations.......................................33 References........................................................33 Author's Addresses................................................34 Full Copyright Statement..........................................35 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 [1]. 1. Introduction Security is clearly an integral aspect of Provider Provisioned Virtual Private Network (PPVPN) services. In this document, we first describe the security threats that are relevant in the context of PPVPNs, and the defensive techniques that can be used to combat those threats. We consider security issues deriving both from malicious or incorrect behavior of users and other parties and from negligent or incorrect behavior of the providers. An important part of security defense is the detection and report of a security attack, which is also addressed in this document. We then discuss the possible user and provider security requirements in a PPVPN service. The users have expectations that need to be met on the security characteristics of a VPN service. These user requirements translate into corresponding requirements for the providers in order to offer the service. Furthermore, providers have security requirements to protect their network infrastructure, and make it secure to the level required to provide the PPVPN services, in addition to other services. Finally, we define a template that may be used to describe the security characteristics of a specific PPVPN technology in a manner Expires January 2004 Page 3 PPVPN Security framework September 2003 consistent with the security framework described in this document. It is not within the scope of this document to analyze the security properties of specific technologies; instead, our intention with this template is to provide a common tool, in the form of a check list, that may be used in other documents dedicated to an in-depth security analysis of individual PPVPN technologies to describe their security characteristics in a comprehensive and coherent way, and to provide a common ground for comparison between different technologies. It is important to clarify that, in this document, we limit ourselves to describing the users and providers' security requirements that pertain to PPVPN services. It is not our intention, however, to formulate precise "requirements" on each specific technology in terms of defining the mechanisms and techniques that must be implemented to satisfy such users and providers' requirements. This document is organized as follows. In Section 2, we define the security reference model for security in PPVPN networks, which we use in the rest of the document. In Section 3, we describe the security threats that are specific of PPVPNs. In Section 4, we review defense techniques that may be used against those threats. In Section 5, we describe how attacks may be detected and reported. In Section 6, we discuss the user security requirements that apply to PPVPN services. In Section 7, we describe additional security requirements that the provider may have in order to guarantee the security of the network infrastructure to provide PPVPN services. Finally, in Section 8, we provide a template that may be used to describe the security characteristics of specific PPVPN technologies. 2. Security Reference Model This section defines the terminology used in this document, and a reference model for security in PPVPN networks. A PPVPN core network is defined here as the central network infrastructure (P and PE routers) over which PPVPN services are delivered. A PPVPN core network consists of one or more SP networks. All network elements in the core are under the operational control of one or more PPVPN service providers. Even if the PPVPN core is provided by several service providers, towards the PPVPN users it appears as a single zone of trust. However, several service providers providing together a PPVPN core still need to secure themselves against the other providers. PPVPN services can also be delivered over the Internet, in which case the Internet forms a logical part of the PPVPN core. Expires January 2004 Page 4 PPVPN Security framework September 2003 A PPVPN user is a company, institution or residential client of the PPVPN service provider. A PPVPN service is a private network service made available by a service provider to a PPVPN user. The service is implemented using virtual constructs built on a shared PPVPN core network. A PPVPN service interconnects sites of a PPVPN user. Extranets are VPNs in which multiple sites are controlled by different (legal) entities. Extranets are another example of PPVPN deployment scenarios where restricted and controlled communication is allowed between trusted zones, often via well-defined transit points. This document defines each PPVPN as a trusted zone, and the PPVPN core as another trusted zone. A primary concern is about security aspects that relate to breaches of security from the "outside" of a trusted zone to the "inside" of this zone. Figure 1 depicts the concept of trusted zones within the PPVPN framework. +------------+ +------------+ | PPVPN +-----------------------------+ PPVPN | | user PPVPN user | | site +---------------------XXX-----+ site | +------------+ +------------------XXX--+ +------------+ | PPVPN core | | | +------------------| |--+ | | | +------\ +--------/ Internet Figure 1: The PPVPN trusted zone model In principle the trusted zones should be separate, however, often PPVPN core networks also offer Internet access, in which case a transit point (marked with "XXX" in the figure) is defined. The key requirement of a "virtual private" network (VPN) is that the security of the trusted zone of the VPN is not compromised by sharing the core infrastructure with other VPNs. Security against threats that originate within the same trusted zone as their targets (for example, attacks from a user in a PPVPN to other users within the same PPVPN, or attacks entirely within the core network) is outside the scope of this document. Also outside the scope are all aspects of network security which are independent of whether a network is a PPVPN network or a private network (for example, attacks from the Internet to a web- server inside a given PPVPN will not be considered here, unless the Expires January 2004 Page 5 PPVPN Security framework September 2003 way the PPVPN network is provisioned could make a difference to the security of this server). 3. Security Threats This section discusses the various network security threats that may endanger PPVPNs. The discussion is limited to those threats that are unique to PPVPNs, or that affect PPVPNs in unique ways. A successful attack on a particular PPVPN or on a service provider's PPVPN infrastructure may cause one or more of the following ill effects: - Observation, modification, or deletion of PPVPN user data. - Replay of PPVPN user data. - Injection of non-authentic data into a PPVPN. - Traffic pattern analysis on PPVPN traffic. - Disruption of PPVPN connectivity. - Degradation of PPVPN service quality It is useful to consider that threats, whether malicious or accidental, to a PPVPN may come from different categories of sources. For example they may come from: - Users of other PPVPNs provided by the same PPVPN service provider. - The PPVPN service provider or persons working for it. - Other persons who obtain physical access to a service provider site. - Users of the PPVPN itself, i.e. intra-VPN threats. (Such threats are beyond the scope of this document.) - Others i.e. attackers from the Internet at large. In the case of PPVPNs, some parties may be in more advantaged positions that enable them to launch types of attacks not available to others. For example users of different PPVPNs provided by the same service provider may be able to launch attacks that those completely outside the network cannot. Given that security is generally a compromise between expense and risk, it is also useful to consider the likelihood of different attacks occurring. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as: - In a PPVPN contained within one service provider's network - In a PPVPN transiting the public Internet Most types of attacks become easier to mount and hence more likely as the shared infrastructure via which VPN service is provided expands from a single service provider to multiple cooperating Expires January 2004 Page 6 PPVPN Security framework September 2003 providers to the global Internet. Attacks that may not be of sufficient likeliness to warrant concern in a closely controlled environment often merit defensive measures in broader, more open environments. The following sections discuss specific types of exploits that threaten PPVPNs. 3.1. Attacks on the Data Plane This category encompasses attacks on the PPVPN user's data, as viewed by the service provider. Note that from the PPVPN user's point of view, some of this might be control plane traffic, e.g. routing protocols running from PPVPN user site to PPVPN user site via an L2 PPVPN. 3.1.1. Unauthorized Observation of Data Traffic This refers to "sniffing" VPN packets and examining their contents. This can result in exposure of confidential information. It can also be a first step in other attacks (described below) in which the recorded data is modified and re-inserted, or re-inserted as- is. 3.1.2. Modification of Data Traffic This refers to modifying the contents of packets as they traverse the VPN. 3.1.3. Insertion of Non-Authentic Data Traffic: Spoofing and Replay This refers to the insertion (or "spoofing") into the VPN of packets that do not belong there, with the objective of having them accepted by the recipient as legitimate. Also included in this category is the insertion of copies of once-legitimate packets that have been recorded and replayed. 3.1.4. Unauthorized Deletion of Data Traffic This refers to causing packets to be discarded as they traverse the VPN. This is a specific type of Denial of Service attack. 3.1.5. Unauthorized Traffic Pattern Analysis This refers to "sniffing" VPN packets and examining aspects or meta-aspects of them that may be visible even when the packets themselves are encrypted. An attacker might gain useful information based on the amount and timing of traffic, packet sizes, source and destination addresses, etc. For most PPVPN users, this type of attack is generally considered to be Expires January 2004 Page 7 PPVPN Security framework September 2003 significantly less of a concern than the other types discussed in this section. 3.1.6. Denial of Service Attacks on the VPN Denial of Service (DOS) attacks are those in which an attacker attempts to disrupt or prevent the use of a service by its legitimate users. Taking network devices out of service, modifying their configuration, or overwhelming them with requests for service are several of the possible avenues for DOS attack. Overwhelming the network with requests for service, otherwise known as a "resource exhaustion" DOS attack, may target any resource in the network e.g. link bandwidth, packet forwarding capacity, session capacity for various protocols, CPU power, and so on. DOS attacks of the resource exhaustion type can be mounted against the data plane of a particular PPVPN by inserting an overwhelming quantity of non-authentic data into the VPN. Data plane resource exhaustion attacks can also be mounted by overwhelming the service provider's general (VPN-independent) infrastructure with traffic. These attacks on the general infrastructure are not usually a PPVPN-specific issue, unless the attack is mounted by another PPVPN user from a privileged position. (E.g. a PPVPN user might be able to monopolize network data plane resources and thus disrupt other PPVPNs.) 3.2. Attacks on the Control Plane This category encompasses attacks on the control structures operated by the PPVPN service provider. 3.2.1. Denial of Service Attacks on the Network Infrastructure Control plane DOS attacks can be mounted specifically against the mechanisms the service provider uses to provide PPVPNs e.g. IPsec, MPLS, etc., or against the general infrastructure of the service provider e.g. P routers or shared aspects of PE routers. (Attacks against the general infrastructure are within the scope of this document only if the attack happens in relation with the VPN service, otherwise is not a PPVPN-specific issue.) Of special concern for PPVPNs is denial of service to one PPVPN user caused by the activities of another PPVPN user. This can occur for example if one PPVPN user's activities are allowed to consume excessive network resources of any sort that are also needed to serve other PPVPN users. Expires January 2004 Page 8 PPVPN Security framework September 2003 The attacks described in the following sections may each have denial of service as one of their effects. Other DOS attacks are also possible. 3.2.2. Attacks on the Service Provider Equipment Via Management Interfaces This includes unauthorized access to service provider infrastructure equipment, which access can be used to reconfigure the equipment, or to extract information (statistics, topology, etc.) about one or more PPVPNs. This can be accomplished through malicious entering of the systems, or inadvertently as a consequence of inadequate inter-VPN isolation in a PPVPN user self-management interface. (The former is not necessarily a PPVPN-specific issue.) 3.2.3. Cross-connection of Traffic Between PPVPNs This refers to the event where expected isolation between separate PPVPNs is breached. This includes cases such as: - A site being connected into the "wrong" VPN - Two or more VPNs being improperly merged together - A point-to-point VPN connecting the wrong two points - Any packet or frame being improperly delivered outside the VPN it is sent in. Mis-connection or cross-connection of VPNs may be caused by service provider or equipment vendor error, or by the malicious action of an attacker. Anecdotal evidence suggests that the cross-connection threat is one of the largest security concerns of PPVPN users (or would-be users). 3.2.4. Attacks Against PPVPN Routing Protocols This encompasses attacks against routing protocols that are run by the service provider and that directly support the PPVPN service. In layer 3 VPNs this typically relates to membership discovery or to the distribution of per-VPN routes. In layer 2 VPNs this typically relates to membership and endpoint discovery. (Attacks against the use of routing protocols for the distribution of backbone (non-VPN) routes are beyond the scope of this document.) Specific attacks against popular routing protocols have been widely studied and described in [Beard]. 3.2.5. Attacks on Route Separation Expires January 2004 Page 9 PPVPN Security framework September 2003 "Route separation" refers here to keeping the per-VPN topology and reachability information for each PPVPN separate from, and unavailable to, any other PPVPN (except as specifically intended by the service provider). This concept is only a distinct security concern for those layer 3 VPN types where the service provider is involved with the routing within the VPN (i.e. VR, BGP-MPLS, routed version of IPsec). A breach in the route separation can reveal topology and addressing information about a PPVPN. It can also cause black hole routing or unauthorized data plane cross- connection between PPVPNs. 3.2.6. Attacks on Address Space Separation In Layer 3 VPNs, the IP address spaces of different VPNs need to be kept separate. In Layer 2 VPNs, the MAC address and VLAN spaces of different VPNs need to be kept separate. A control plane breach in this addressing separation may result in unauthorized data plane cross-connection between VPNs. 3.2.7. Other Attacks on PPVPN Control Traffic Besides routing and management protocols (covered separately in the previous sections) a number of other control protocols may be directly involved in delivering the PPVPN service (e.g. for membership discovery and tunnel establishment in various PPVPN approaches). These include but may not be limited to: - MPLS signaling (LDP, RSVP-TE) - IPsec signaling (IKE) - L2TP - BGP-based membership discovery - Database-based membership discovery (e.g. RADIUS-based) Attacks might subvert or disrupt the activities of these protocols, for example via impersonation or DOS attacks. 4. Defensive Techniques for PPVPN Service Providers The defensive techniques discussed in this document are intended to describe methods by which some security threats can be addressed. They are not intended as requirements for all PPVPN implementations. The PPVPN provider should determine the applicability of these techniques to the provider's specific service offerings, and the PPVPN user may wish to assess the value of these techniques to the user's VPN requirements. The techniques discussed here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and other techniques. Expires January 2004 Page 10 PPVPN Security framework September 2003 Nothing is ever 100% secure. Defense therefore involves protecting against those attacks that are most likely to occur and/or that have the most dire consequences if successful. For those attacks that are protected against, absolute protection is seldom achievable; more often it is sufficient just to make the cost of a successful attack greater than what the adversary will be willing to expend. Successfully defending against an attack does not necessarily mean the attack must be prevented from happening or from reaching its target. In many cases the network can instead be designed to withstand the attack. For example, the introduction of non- authentic packets could be defended against by preventing their introduction in the first place, or by making it possible to identify and eliminate them before delivery to the PPVPN user's system. The latter is frequently a much easier task. 4.1. Cryptographic techniques PPVPN defenses against a wide variety of attacks can be enhanced by the proper application of cryptographic techniques. These are the same cryptographic techniques which are applicable to general network communications. In general, these techniques can provide privacy (encryption) of communication between devices, authentication of the identities of the devices, and can ensure that it will be detected if the data being communicated is changed during transit. Privacy is a key part (the middle name!) of any Virtual Private Network. In a PPVPN, privacy can be provided by two mechanisms: traffic separation and encryption. In this section we focus on encryption, while traffic separation is addressed separately. Several aspects of authentication are addressed in some detail in a separate "Authentication" section. Encryption adds complexity to a service, and thus it may not be a standard offering within every PPVPN service. There are a few reasons why encryption may not be a standard offering within every PPVPN service. Encryption adds an additional computational burden to the devices performing encryption and decryption. This may reduce the number of user VPN connections which can be handled on a device or otherwise reduce the capacity of the device, potentially driving up the provider's costs. Typically, configuring encryption services on devices adds to the complexity of the device configuration and adds incremental labor cost. Packet lengths are typically increased when the packets are encrypted, increasing the network traffic load and adding to the likelihood of packet fragmentation with its increased overhead. (This packet length increase can often be mitigated to some extent by data compression techniques, but at the expense of additional computational burden. Expires January 2004 Page 11 PPVPN Security framework September 2003 Finally, some PPVPN providers may employ enough other defensive techniques, such as physical isolation or filtering/firewall techniques, that they may not perceive additional benefit from encryption techniques. The trust model among the PPVPN user, the PPVPN provider, and other parts of the network is a key element in determining the applicability of encryption for any specific PPVPN implementation. In particular, it determines where encryption should be applied: - If the data path between the user's site and the provider's PE is not trusted, then encryption may be used on the PE-CE link. - If some part of the backbone network is not trusted, particularly in implementations where traffic may travel across the Internet or multiple provider networks, then the PE-PE traffic may encrypted. - If the PPVPN user does not trust any zone outside of its premises, it may require end-to-end or CE-CE encryption service. This service fits within the scope of this PPVPN security framework when the CE is provisioned by the PPVPN provider. - If the PPVPN user requires remote access to a PPVPN from a system at a location which is not a PPVPN customer location (for example, access by a traveler) there may be a requirement for encrypting the traffic between that system and an access point on the PPVPN or at a customer site. If the PPVPN provider provides the access point, then the customer must cooperate with the provider to handle the access control services for the remote users. These access control services are usually implemented using encryption, as well. Although CE-CE encryption provides privacy against third-party interception, if the PPVPN provider has complete management control over the CE (encryption) devices, then it may be possible for the provider to gain access to the user's VPN traffic or internal network. Encryption devices can potentially be configured to use null encryption, bypass encryption processing altogether, or provide some means of sniffing or diverting unencrypted traffic. Thus a PPVPN implementation using CE-CE encryption needs to consider the trust relationship between the PPVPN user and provider. PPVPN users and providers may wish to negotiate a service level agreement (SLA) for CE-CE encryption which will provide an acceptable demarcation of responsibilities for management of encryption on the CE devices. The demarcation may also be affected by the capabilities of the CE devices. For example, the CE might support some partitioning of management, a configuration lock-down ability, or allow both parties to verify the configuration. In general, the PPVPN user needs to have a fairly high level of trust that the PPVPN provider will properly provision and manage the CE devices, if the managed CE-CE model is used. Expires January 2004 Page 12 PPVPN Security framework September 2003 4.1.1. IPsec in PPVPNs IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the security protocol of choice for encryption at the IP layer (Layer 3), as discussed in [SECMECH]. IPsec provides robust security for IP traffic between pairs of devices. Non-IP traffic must be converted to IP packets or it cannot be transported over IPsec. Encapsulation is a common conversion method. In the PPVPN model, IPsec can be employed to protect IP traffic between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec may be employed in either a provider-provisioned or a user- provisioned model. The user-provisioned CE-CE IPsec model is outside the scope of this document, and outside the scope of the PPVPN Working Group. Likewise, encryption of data which is performed within the user's site is outside the scope of this document, since it is simply handled as user data by the PPVPN. IPSec can also be used to protect IP traffic between a remote user who is not located at a PPVPN site and the PPVPN. IPsec does not itself specify an encryption algorithm. It can use a variety of encryption algorithms, with various key lengths. There are trade-offs between key length, computational burden, and the level of security of the encryption. A full discussion of these trade-offs is beyond the scope of this document. In order to assess the level of security offered by a particular IPsec-based PPVPN service, some PPVPN users may wish to know the specific encryption algorithm and effective key length used by the PPVPN provider. However, in practice, any currently recommended IPsec encryption offers enough security to substantially reduce the likelihood of being directly targeted by an attacker; other weaker links in the chain of security are likely to be attacked first. PPVPN users may wish to use a Service Level Agreement (SLA) specifying the Service Provider's responsibility for ensuring data privacy, rather than analyzing the specific encryption techniques used in the PPVPN service. For many of the PPVPN provider's network control messages and some PPVPN user requirements, cryptographic authentication of messages without encryption of the contents of the message may provide acceptable security. Using IPsec, authentication of messages is provided by the Authentication Header (AH) or through the use of the Encapsulating Security Protocol (ESP) with authentication only. Where control messages require authentication but do not use IPsec, then other cryptographic authentication methods are available. Message authentication methods currently considered to be secure are based on hashed message authentication codes (HMAC) [RFC2104] Expires January 2004 Page 13 PPVPN Security framework September 2003 implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174]. PPVPNs which provide differentiated services based on traffic type may encounter some conflicts with IPsec encryption of traffic. Since encryption hides the content of the packets, it may not be possible to differentiate the encrypted traffic in the same manner as unencrypted traffic. Although DiffServ markings are copied to the IPsec header and can provide some differentiation, not all traffic types can be accommodated by this mechanism. 4.1.2. Encryption for device configuration and management For configuration and management of PPVPN devices, encryption and authentication of the management connection at a level comparable to that provided by IPsec is desirable. Several methods of transporting PPVPN device management traffic offer security and privacy. - Secure Shell (SSH) offers protection for TELNET [STD-8] or terminal-like connections to allow device configuration. - SNMP v3 [STD62] provides encrypted and authenticated protection for SNMP-managed devices. - Transport Layer Security (TLS) (also known as Secure Sockets Layer or SSL) [RFC-2246] is probably the emerging standard for securing HTTP-based communication, and thus can provide support for most XML- and SOAP-based device management approaches. - IPsec provides security and privacy services at the network layer. With regards to device management, its current use is primarily focused on in-band management of user-managed IPSec gateway devices. 4.1.3. Cryptographic techniques in Layer 2 PPVPNs Layer 2 PPVPNs will generally not be able to use IPsec to provide encryption throughout the entire network. They may be able to use IPsec for PE-PE traffic where it is encapsulated in IP packets, but IPsec will generally not be applicable for CE-PE traffic in Layer 2 PPVPNs. Encryption techniques for Layer 2 links are widely available, but are not within the scope of this document, nor of IETF documents in general. Layer 2 encryption could be applied to the links from CE to PE, or could be applied from CE to CE, as long as the encrypted Layer 2 packets can be properly handled by the intervening PE devices. In addition, the upper layer traffic transported by the Layer 2 VPN can be encrypted by the user. In this case privacy will be maintained; however, this is transparent to the PPVPN provider and is outside the scope of this document. Expires January 2004 Page 14 PPVPN Security framework September 2003 4.2. Authentication In order to prevent security issues from some Denial-of-Service attacks or from malicious misconfiguration, it is critical that devices in the PPVPN should only accept connections or control messages from valid sources. Authentication refers to methods to ensure that message sources are properly identified by the PPVPN devices with which they communicate. This section focuses on identifying the scenarios in which sender authentication is required, and recommends authentication mechanisms for these scenarios. Cryptographic techniques (authentication and encryption) do not protect against some types of denial of service attacks, specifically resource exhaustion attacks based on CPU or bandwidth exhaustion. In fact, the processing required to decrypt and/or check authentication may in some cases increase the effect of these resource exhaustion attacks. Cryptographic techniques may however, be useful against resource exhaustion attacks based on exhaustion of state information (e.g., TCP SYN attacks). 4.2.1. VPN Member Authentication This category includes techniques for the CEs to verify they are connected to the expected VPN. It includes techniques for CE-PE authentication, to verify that each specific CE and PE is actually communicating with its expected peer. 4.2.2. Management System Authentication Management system authentication includes the authentication of a PE to a centrally-managed directory server, when directory-based "auto-discovery" is used. It also includes authentication of a CE to its PPVPN configuration server, when a configuration server system is used. 4.2.3. Peer-to-peer Authentication Peer-to-peer authentication includes peer authentication for network control protocols (e.g. LDP, BGP, etc.), and other peer authentication (i.e. authentication of one IPsec security gateway by another). 4.2.4. Authenticating Remote Access VPN members This section describes methods for authentication of remote access users connecting to a VPN. Expires January 2004 Page 15 PPVPN Security framework September 2003 Effective authentication of individual connections is a key requirement for enabling remote access to a PPVPN from an arbitrary Internet address (for instance, by a traveler). There are several widely used standards-based protocols to support remote access authentication. These include RADIUS [ref] and DIAMETER [ref]. Digital certificate systems also provide authentication. In addition there has been extensive development and deployment of mechanisms for securely transporting individual remote access connections within tunneling protocols, including L2TP [ref] and IPsec. Remote access involves connection to a gateway device, which provides access to the PPVPN. The gateway device may be managed by the user at a user site, or by the PPVPN provider at several possible locations in the network. The user-managed case is of limited interest within the PPVPN security framework, and is not considered at this time. When a PPVPN provider manages authentication at the remote access gateway, this implies that authentication databases, which are usually extremely confidential user-managed systems, will need to be referenced in a secure manner by the PPVPN provider. This can be accomplished by the use of proxy authentication services, which accept an encrypted authentication credential from the remote access user, pass it to the PPVPN user's authentication system, and receive a yes/no response as to whether the user has been authenticated. Thus the PPVPN provider does not have access to the actual authentication database, but can use it on behalf of the PPVPN user to provide remote access authentication. Specific cryptographic techniques for handling authentication are described in the following sections. 4.2.5. Cryptographic techniques for authenticating identity Cryptographic techniques offer several mechanisms for authenticating the identity of devices or individuals. These include the use of shared secret keys, one-time keys generated by accessory devices or software, user-ID and password pairs, and a range of public-private key systems. Another approach is to use a hierarchical Certificate Authority system to provide digital certificates. This section describes or provides references to the specific cryptographic approaches for authenticating identity. These approaches provide secure mechanisms for most of the authentication scenarios required in operating a PPVPN. Expires January 2004 Page 16 PPVPN Security framework September 2003 4.3. Access Control techniques Access control techniques include packet-by-packet or packet-flow- by-packet-flow access control by means of filters and firewalls, as well as by means of admitting a "session" for a control/signaling/management protocol that is being used to implement PPVPNs. Enforcement of access control by isolated infrastructure addresses is discussed in another section of this document. In this document, we distinguish between filtering and firewalls based primarily on the direction of traffic flow. We define filtering as being applicable to unidirectional traffic, while a firewall can analyze and control both sides of a conversation. There are two significant corollaries of this definition: - Routing or traffic flow symmetry: A firewall typically requires routing symmetry, which is usually enforced by locating a firewall where the network topology assures that both sides of a conversation will pass through the firewall. A filter can operate upon traffic flowing in one direction, without considering traffic in the reverse direction. - Statefulness: Since it receives both sides of a conversation, a firewall may be able to interpret a significant amount of information concerning the state of that conversation, and use this information to control access. A filter can maintain some limited state information on a unidirectional flow of packets, but cannot determine the state of the bi-directional conversation as precisely as a firewall. 4.3.1. Filtering It is relatively common for routers to filter data packets. That is, routers can look for particular values in certain fields of the IP or higher level (e.g., TCP or UDP) headers. Packets which match the criteria associated with a particular filter may either be discarded or given special treatment. In discussing filters, it is useful to separate the Filter Characteristics which may be used to determine whether a packet matches a filter from the Packet Actions which are applied to those packets which match a particular filter. o Filter Characteristics Filter characteristics are used to determine whether a particular packet or set of packets matches a particular filter. In many cases filter characteristics may be stateless. A stateless filter is one which determines whether a particular packet matches a filter based solely on the filter definition, normal forwarding Expires January 2004 Page 17 PPVPN Security framework September 2003 information (such as the next hop for a packet), and the characteristics of that individual packet. Typically stateless filters may consider the incoming and outgoing logical or physical interface, information in the IP header, and information in higher layer headers such as the TCP or UDP header. Information in the IP header to be considered may for example include source and destination IP address, Protocol field, Fragment Offset, and TOS field. Filters also may consider fields in the TCP or UDP header such as the Port fields as well as the SYN field in the TCP header. Stateful filtering maintains packet-specific state information, to aid in determining whether a filter has been met. For example, a device might apply stateless filters to the first fragment of a fragmented IP packet. If the filter matches, then the data unit ID may be remembered and other fragments of the same packet may then be considered to match the same filter. Stateful filtering is more commonly done in firewalls, although firewall technology may be added to routers. o Actions based on Filter Results If a packet, or a series of packets, match a specific filter, then there are a variety of actions which may be taken based on that filter match. Examples of such actions include: - Discard In many cases filters may be set to catch certain undesirable packets. Examples may include packets with forged or invalid source addresses, packets which are part of a DOS or DDOS attack, or packets which are trying to access resources which are not permitted (such as network management packets from an unauthorized source). Where such filters are activated, it is common to silently discard the packet or set of packets matching the filter. The discarded packets may of course also be counted and/or logged. - Set CoS A filter may be used to set the Class of Service associated with the packet. - Count packets and/or bytes - Rate Limit In some cases the set of packets which match a particular filter may be limited to a specified bandwidth. In this case packets and/or bytes would be counted, and would be forwarded normally up to the specified limit. Excess packets may be discarded, or may be marked (for example by setting a "discard eligible" bit in the IP ToS field or the MPLS EXP field). Expires January 2004 Page 18 PPVPN Security framework September 2003 - Forward and Copy It is useful in some cases to forward some set of packets normally, but to also send a copy to a specified other address or interface. For example, this may be used to implement a lawful intercept capability, or to feed selected packets to an Intrusion Detection System. o Other Issues related to Use of Packet Filters There may be a very wide variation in the performance impact of filtering. This may occur both due to differences between implementations, and also due to differences between types or numbers of filters deployed. For filtering to be useful, the performance of the equipment has to be acceptable in the presence of filters. The precise definition of "acceptable" may vary from service provider to service provider, and may depend upon the intended use of the filters. For example, for some uses a filter may be turned on all the time in order to set CoS, to prevent an attack, or to mitigate the effect of a possible future attack. In this case it is likely that the service provider will want the filter to have minimal or no impact on performance. In other cases, a filter may be turned on only in response to a major attack (such as a major DDOS attack). In this case a greater performance impact may be acceptable to some service providers. 4.3.2. Firewalls Firewalls provide a mechanism for control over traffic passing between different trusted zones in the PPVPN model, or between a trusted zone and an untrusted zone. Firewalls typically provide much more functionality than filters, since they may be able to apply detailed analysis and logical functions to flows, and not just to individual packets. They may offer a variety of complex services, such as threshold-driven denial-of-service attack protection, virus scanning, acting as a TCP connection proxy, etc. As with other access control techniques, the value of firewalls depends on a clear understanding of the topologies of the PPVPN core network, the user networks, and the threat model. Their effectiveness depends on a topology with a clearly defined inside (secure) and outside (not secure). Within the PPVPN framework, traffic typically is not allowed to pass between the various user VPNs. This inter-VPN isolation is usually not performed by a firewall, but is a part of the basic VPN mechanism. An exception to the total isolation of VPNs is the case of "extranets", which allow specific external access to a user's Expires January 2004 Page 19 PPVPN Security framework September 2003 VPN, potentially from another VPN. Firewalls can be used to provide the services required for secure extranet implementation. In a PPVPN, firewalls can be applied between the public Internet and user VPNs, in cases where Internet access services are offered by the provider to the VPN user sites. In addition, firewalls may be applied between VPN user sites and any shared network-based services offered by the PPVPN provider. Firewalls may be applied to help protect PPVPN core network functions from attacks originating from the Internet or from PPVPN user sites, but typically other defensive techniques will be used for this purpose. Where firewalls are employed as a service to protect user VPN sites from the Internet, different VPN users, and even different sites of a single VPN user, may have varying firewall requirements. The overall PPVPN logical and physical topology, along with the capabilities of the devices implementing the firewall services, will have a significant effect on the feasibility and manageability of such varied firewall service offerings. 4.3.3. Access Control to management interfaces Most of the security issues related to management interfaces can be addressed through the use of authentication techniques as described in the section on authentication. However, additional security may be provided by controlling access to management interfaces in other ways. Management interfaces, especially console ports on PPVPN devices, may be configured so they are only accessible out-of-band, through a system which is physically and/or logically separated from the rest of the PPVPN infrastructure. Where management interfaces are accessible in-band within the PPVPN domain, filtering or firewalling techniques can be used to restrict unauthorized in-band traffic from having access to management interfaces. Depending on device capabilities, these filtering or firewalling techniques can be configured either on other devices through which the traffic might pass, or on the individual PPVPN devices themselves. 4.4. Use of Isolated Infrastructure One way to protect the infrastructure used for support of VPNs is to separate the resources for support of VPNs from the resources used for other purposes (such as support of Internet services). In some cases this may make use of physically separate equipment for VPN services, or even a physically separate network. Expires January 2004 Page 20 PPVPN Security framework September 2003 For example, PE-based L3 VPNs may be run on a separate backbone not connected to the Internet, or may make use of separate edge routers from those used to support Internet service. Private IP addresses (local to the provider and non-routable over the Internet) are sometimes used to provide additional separation. It is common for CE-based L3VPNs to make use of CE devices which are dedicated to one specific VPN. In many or most cases CE-based VPNs may make use of normal Internet services to interconnect CE devices. 4.5. Use of Aggregated Infrastructure In general it is not feasible to use a completely separate set of resources for support of each VPN. In fact, one of the main reasons for VPN services is to allow sharing of resources between multiple users, including multiple VPNs. Thus even if VPN services make use of a separate network from Internet services, nonetheless there will still be multiple VPN users sharing the same network resources. In some cases VPN services will share the use of network resources with Internet services or other services. It is therefore important for VPN services to provide protection between resource utilization by different VPNs. Thus a well-behaved VPN user should be protected from possible misbehavior by other VPNs. This requires that limits are placed on the amount of resources which can be used by any one VPN. For example, both control traffic and user data traffic may be rate limited. In some cases or in some parts of the network where a sufficiently large number of queues are available each VPN (and optionally each VPN and CoS within the VPN) may make use of a separate queue. Control- plane resources such as link bandwidth as well as CPU and memory resources may be reserved on a per-VPN basis. The techniques which are used to provision resource protection between multiple VPNs served by the same infrastructure can also be used to protect VPN services from Internet services. In general the use of aggregated infrastructure allows the service provider to benefit from stochastic multiplexing of multiple bursty flows, and also may in some cases thwart traffic pattern analysis by combining the data from multiple VPNs. 4.6. Service Provider Quality Control Processes Deployment of provider-provisioned VPN services in general requires a relatively large amount of configuration by the service provider. For example, the service provider needs to configure which VPN each site belongs to, as well as QoS and SLA guarantees. This large Expires January 2004 Page 21 PPVPN Security framework September 2003 amount of required configuration leads to the possibility of misconfiguration. It is important for the service provider to have operational processes in place to reduce the potential impact of misconfiguration. CE to CE authentication may also be used to detect misconfiguration when it occurs. 4.7. Deployment of Testable PPVPN Service. This refers to solutions that can be readily tested to make sure they are configured correctly. E.g. for a point-point VPN, checking that the intended connectivity is working pretty much ensures that there is not connectivity to some unintended site. 5. Monitoring, Detection, and Reporting of Security Attacks A PPVPN service may be subject to attacks from a variety of security threats. Many threats are described in another part of this document. Many of the defensive techniques described in this document and elsewhere provide significant levels of protection from a variety of threats. However, in addition to silently employing defensive techniques to protect against attacks, PPVPN services can also add value for both providers and customers by implementing security monitoring systems which detect and report on any security attacks which occur, regardless of whether the attacks are effective. Attackers often begin by probing and analyzing defenses, so systems which can detect and properly report these early stages of attacks can provide significant benefits. Information concerning attack incidents, especially if available quickly, can be useful in defending against further attacks. It can be used to help identify attackers and/or their specific targets at an early stage. This knowledge about attackers and targets can be used to further strengthen defenses against specific attacks or attackers, or improve the defensive services for specific targets on an as-needed basis. Information collected on attacks may also be useful in identifying and developing defenses against novel attack types. Monitoring systems used to detect security attacks in PPVPNs will typically operate by collecting information from the Provider Edge (PE), Customer Edge (CE), and/or Provider backbone (P) devices. Security monitoring systems should have the ability to actively retrieve information from devices (e.g., SNMP get) or to passively receive reports from devices (e.g., SNMP traps). The specific information exchanged will depend on the capabilities of the devices and on the type of VPN technology. Particular care should Expires January 2004 Page 22 PPVPN Security framework September 2003 be given to securing the communications channel between the monitoring systems and the PPVPN devices. The CE, PE, and P devices should employ efficient methods to acquire and communicate the information needed by the security monitoring systems. It is important that the communication method between PPVPN devices and security monitoring systems be designed so that it will not disrupt network operations. As an example, multiple attack events may be reported through a single message, rather than allowing each attack event to trigger a separate message, which might result in a flood of messages, essentially becoming a denial-of-service attack against the monitoring system or the network. The mechanisms for reporting security attacks should be flexible enough to meet the needs of VPN service providers, VPN customers, and regulatory agencies, if applicable. The specific reports will depend on the capabilities of the devices, the security monitoring system, the type of VPN, and the service level agreements between the provider and customer. 6. User Security Requirements This section defines a list of security related requirements that the users of PPVPN services may have for their PPVPN service. Typically, these user requirements translate into requirement for the provider in offering the service. The following sections detail various requirements that ensure the security of a given trusted zone. Since in real life there are various levels of security, a PPVPN may fulfill any number or all of these security requirements. Specifically this document does not state that a PPVPN must fulfill all of these requirements to be secure. As mentioned in the Introduction, it is not within the scope of this document to define the specific requirements that each VPN technology must fulfill in order to be secure. 6.1. Isolation A virtual private network usually defines the "private" as being isolated from other PPVPNs and the Internet. More specifically, isolation has several components: 6.1.1. Address Separation Within a PPVPN service, a given PPVPN can use the full Internet address range, including private address ranges [RFC1918], without interfering with other PPVPNs that use the same PPVPN service. When using Internet access through the PPVPN core a NAT functionality can be implemented. Expires January 2004 Page 23 PPVPN Security framework September 2003 In layer 2 VPNs the same requirement exists for the layer 2 addressing schemes, such as MAC addresses. 6.1.2. Routing Separation A PPVPN core must maintain routing separation between the trusted zones. This means that routing information must not leak from any trusted zone to any other trusted zone, unless this is specifically engineered this way, for example for Internet access. In layer 2 VPNs the switching information must be kept separate between the trusted zones, such that switching information of one PPVPN does not influence other PPVPNs or the PPVPN core. 6.1.3. Traffic Separation Traffic from a given trusted zone must never leave this zone, and traffic from another zone must never enter this zone. Exceptions are where this is specifically engineered that way, for example for extranet purposes or Internet access. 6.2. Protection The perception of a completely separated, "private" network is that it has defined entry points, and only over those is can be attacked or intruded. By sharing a common core a PPVPN appears to lose some of this clear interfaces to parts outside the trusted zone. Thus one of the key security requirements of PPVPN services is that they offer the same level of protection as private networks. 6.2.1. Protection against intrusion An intrusion is defined here as the penetration of a trusted zone from outside this zone. This could be from the Internet, another PPVPN, or the core network itself. The fact that a network is "virtual" must not expose it to additional threats over private networks. Specifically, it must not add new interfaces to other parts outside the trusted zone. Intrusions from known interfaces such as Internet gateways are outside the scope of this document. 6.2.2. Protection against Denial of Service attacks A denial of service attack aims at making services or devices un- available to legitimate users. In the framework of this document only those DoS attacks are considered which are a consequence of providing the network in a virtual way. DoS attacks over the standard interfaces into a trusted zone are not considered here. Expires January 2004 Page 24 PPVPN Security framework September 2003 The requirement is that a PPVPN is not more vulnerable against DoS attacks than if the same network would be private. 6.2.3. Protection against spoofing It is not possible to change the sender identification (source address, source label, etc) of traffic in transit, such that by this spoofing the integrity of a PPVPN gets violated. For example, if two CEs are connected to the same PE, it must not be possible for one CE to send crafted packets that make the PE believe those packets are coming from the other CE, thus inserting them into the wrong PPVPN. 6.3. Confidentiality This requirement means that data must be cryptographically secured in transit over the PPVPN core network to avoid eavesdropping. 6.4. CE Authentication Where CE authentication is provided it is not possible for an outsider to install a CE and pretend to belong to a specific PPVPN, to which this CE does not belong in reality. 6.5. Integrity Data in transit must be secured in a manner such that it cannot be altered, or that any alteration may be detected at the receiver. 6.6. Anti-Replay Anti-replay means that data in transit cannot be recorded and replayed later. To protect against anti-replay attacks the data must be cryptographically secured. Note: Even private networks do not necessarily meet the requirements of confidentiality, integrity and anti-reply. Thus when comparing private to "virtually private" PPVPN services these requirements are only applicable if the comparable private service also included these services. 7. Provider Security Requirements In this section, we discuss additional security requirements that the provider may have in order to secure its network infrastructure as it provides PPVPN services. The PPVPN service provider requirements defined here are the requirements for the PPVPN core in the reference model. The core Expires January 2004 Page 25 PPVPN Security framework September 2003 network can be implemented with different types of network technologies, and each core network may use different technologies to provide the PPVPN services to users with different levels of offered security. Therefore, a PPVPN service provider may fulfill any number of the security requirements listed in this section. This document does not state that a PPVPN must fulfill all of these requirements to be secure. These requirements are focused on: 1) how to protect the PPVPN core from various attacks outside the core including PPVPN users and non-PPVPN alike, both accidentally and maliciously, 2) how to protect the PPVPN user VPNs and sites themselves. Note that a PPVPN core is not more vulnerable against attacks than a core that does not provide PPVPNs. However providing PPVPN services over such a core may need lead to additional security requirements, for the mere fact that most users are expecting higher security standards in a core delivering PPVPN services. 7.1. Protection within the Core Network 7.1.1. Control Plane Protection - Protocol authentication within the core: PPVPN technologies and infrastructure must support mechanisms for authentication of the control plane. For an IP core, IGP and BGP sessions may be authenticated by using TCP MD5 or IPSec. If an MPLS core is used, LDP sessions may be authenticated by use TCP MD5, in addition, IGP and BGP authentication should also be considered. For a core providing Layer 2 services, PE to PE authentication may also be used via IPSec. With the cost of authentication coming down rapidly, the application of control plane authentication may not increase the cost of implementation for providers significantly, and will help to improve the security of the core. If the core is dedicated to VPN services and without any interconnects to third parties then this may reduce the requirement for authentication of the core control plane. - Elements protection Here we discuss means to hide the provider's infrastructure nodes. A PPVPN provider may make the infrastructure routers (P and PE routers) unreachable from outside users and unauthorized internal users. For example, separate address space may be used for the infrastructure loopbacks. Expires January 2004 Page 26 PPVPN Security framework September 2003 Normal TTL propagation may be altered to make the backbone look like one hop from the outside, but caution needs to be taken for loop prevention. This prevents the backbone addresses to be exposed through trace route, however this must also be assessed against operational requirements for end to end fault tracing. An Internet backbone core may be re-engineered to make Internet routing an edge function, for example, using MPLS label switching for all traffic within the core and possibly make the Internet a VPN within the PPVPN core itself. This helps to detach Internet access from PPVPN services. Separating control plane, data plane, and management plane functionality in terms of hardware and software may be implemented on the PE devices to improve security. This may help to limit the problems when attacked in one particular area, and may allow each plane to implement additional security measurement separately. PEs are often more vulnerable to attack than P routers, since PEs cannot be made unreachable to outside users by their very nature. Access to core trunk resources can be controlled on a per user basis by the application of inbound rate-limiting/shaping, this can be further enhanced on a per Class of Service basis (see section 7.2.3) In the PE, using separate routing processes for Internet and PPVPN service may help to improve the PPVPN security and better protect VPN customers. Furthermore, if the resources, such as CPU and Memory, may be further separated based on applications, or even individual VPNs, it may help to provide improved security and reliability to individual VPN customers. Many of these were not particular issues when an IP core was designed to support Internet services only. When providing PPVPN services, new requirements are introduced to satisfy the security needs for VPN services. Similar consideration apply to L2 VPN services. 7.1.2. Data Plane Protection PPVPN using IPSec technologies provide VPN users with encryption of secure user data. In today's MPLS, ATM, or Frame Relay networks, encryption is not provided as a basic feature. Mechanisms can be used to secure the MPLS data plane to secure the data carried over MPLS core. Additionally, if the core is dedicated to VPN services and without any external interconnects to third party networks then there is no obvious need for encryption of the user data plane. Expires January 2004 Page 27 PPVPN Security framework September 2003 IPSec / L3 PPVPN technologies inter-working, or IPSec /L2 PPVPN technologies inter-working may be used to provide PPVPN users end- to-end PPVPN services. 7.2. Protection on the User Access Link Peer / Neighbor protocol authentication may be used to enhance security. For example, BGP MD5 authentication may be used to enhance security on PE-CE links using eBGP. In the case of Inter- provider connection, authentication / encryption mechanisms between ASes, such as IPSec, may be used. WAN link address space separation for VPN and non-VPN users may be implemented to improve security in order to protect VPN customers if multiple services are provided on the same PE platform. Firewall / Filtering: access control mechanisms can be used to filter out any packets destined for the service provider's infrastructure prefix or eliminate routes identified as illegitimate routes. Rate limiting may be applied to the user interface/logical interfaces against DDOS bandwidth attack. This is very helpful when the PE device is supporting both VPN services and Internet Services, especially when supporting VPN and Internet Services on the same physical interfaces through different logical interfaces. 7.2.1 Link Authentication Authentication mechanisms can be employed to validate site access to the PPVPN network via fixed or logical (e.g. L2TP, IPSec) connections. Where the user wishes to hold the 'secret' associated to acceptance of the access and site into the VPN, then PPVPN based solutions require the flexibility for either direct authentication by the PE itself or interaction with a customer PPVPN authentication server. Mechanisms are required in the latter case to ensure that the interaction between the PE and the customer authentication server is controlled e.g. limiting it simply to an exchange in relation to the authentication phase and with other attributes e.g. RADIUS optionally being filtered. 7.2.2 Access Routing Mechanisms may be used to provide control at a routing protocol level e.g. RIP, OSPF, BGP between the CE and PE. Per neighbor and per VPN routing policies may be established to enhance security and reduce the impact of a malicious or non-malicious attack on the PE, in particular the following mechanisms should be considered: - Limiting the number of prefixes that may be advertised on a per access basis into the PE. Appropriate action may be taken should Expires January 2004 Page 28 PPVPN Security framework September 2003 a limit be exceeded e.g. the PE shutting down the peer session to the CE - Applying route dampening at the PE on received routing updates - Definition of a per VPN prefix limit after which additional prefixes will not be added to the VPN routing table. In the case of Inter-provider connection, access protection, link authentication, and routing policies as described above may be applied. Both inbound and outbound firewall/filtering mechanism between ASes may be applied. Proper security procedures must be implemented in Inter-provider VPN interconnection to protect the providers' network infrastructure and their customer VPNs. This may be custom designed for each Inter-Provider VPN peering connection, and must be agreed by both providers. 7.2.3 Access QoS PPVPN providers offering QoS enabled services require mechanisms to ensure that individual accesses are validated against their subscribed QOS profile and as such gain access to core resources that match their service profile. Mechanisms such as per Class of service rate limiting/traffic shaping on ingress to the PPVPN core are one option in providing this level of control. Such mechanisms may require the per Class of Service profile to be enforced either by marking, remarking or discard of traffic outside of profile. 7.2.4 Customer VPN monitoring tools End users requiring visibility of VPN specific statistics on the core e.g. routing table, interface status, QoS statistics, impose requirements for mechanisms at the PE to both validate the incoming user and limit the views available to that particular users VPN. Mechanisms should also be considered to ensure that such access cannot be used a means of a DOS attack (either malicious or accidental) on the PE itself. This could be accomplished through either separation of these resources within the PE itself or via the capability to rate-limit on a per VPN basis such traffic. 7.3. General Requirements for PPVPN Providers The PPVPN providers must support the users security requirements as listed in Section 6. Depending on the technologies used, these requirements may include: - User control plane separation û routing isolation - User address space separation û supporting overlapping addresses from different VPNs Expires January 2004 Page 29 PPVPN Security framework September 2003 - User data plane separation û one VPN traffic cannot be intercepted by other VPNs or any other users. - Protection against intrusion, DOS attacks and spoofing - Access Authentication - Techniques highlighted through this document identify methodologies for the protection of PPVPN resources and infrastructure. By following these approaches a secure VPN service can be delivered without the absolute need for cryptographic techniques Equipment hardware/software bugs leading to breaches in security are not within the scope of this document. 8. Security Evaluation of PPVPN Technologies This section presents a brief template that may be used to evaluate and summarize how a given PPVPN approach (solution) measures up against the PPVPN Security Framework. An evaluation of a given PPVPN approach using this template should appear in the applicability statement for each PPVPN approach. 8.1. Evaluating the Template The first part of the template is in the form of a list of security assertions. For each assertion the approach is assessed and one or more of the following ratings is assigned: - The requirement is not applicable to the VPN approach because ... (fill in reason) - The base VPN approach completely addresses the requirement by ... (fill in technique) - The base VPN approach partially addresses the requirement by ... (fill in technique and extent to which it addresses the requirement) - An optional extension to the VPN approach completely addresses the requirement by ... (fill in technique) - An optional extension to the VPN approach partially addresses the requirement by ... (fill in technique and extent to which it addresses the requirement) - In the VPN approach, the requirement is addressed in a way that is beyond the scope of the VPN approach. (Explain) (One example of this would be a VPN approach in which some aspect, say membership discovery, is done via configuration. The Expires January 2004 Page 30 PPVPN Security framework September 2003 protection afforded to the configuration would be beyond the scope of the VPN approach.) - The VPN approach does not meet the requirement. 8.2. Template The following assertions solicit responses of the types listed in the previous section. 1. The approach provides complete IP address space separation for each L3 VPN. 2. The approach provides complete L2 address space separation for each L2 VPN. 3. The approach provides complete VLAN ID space separation for each L2 VPN. 4. The approach provides complete IP route separation for each L3 VPN. 5. The approach provides complete L2 forwarding separation for each L2 VPN. 6. The approach provides a means to prevent improper cross- connection of sites in separate VPNs. 7. The approach provides a means to detect improper cross- connection of sites in separate VPNs. 8. The approach protects against the introduction of unauthorized packets into each VPN. a. In the CE-PE link b. In a single- or multi- provider PPVPN backbone c. In the Internet used as PPVPN backbone 9. The approach provides confidentiality (secrecy) protection for PPVPN user data. a. In the CE-PE link b. In a single- or multi- provider PPVPN backbone c. In the Internet used as PPVPN backbone 10. The approach provides sender authentication for PPVPN user data. a. In the CE-PE link b. In a single- or multi- provider PPVPN backbone Expires January 2004 Page 31 PPVPN Security framework September 2003 c. In the Internet used as PPVPN backbone 11. The approach provides integrity protection for PPVPN user data. a. In the CE-PE link b. In a single- or multi- provider PPVPN backbone c. In the Internet used as PPVPN backbone 12. The approach provides protection against replay attacks for PPVPN user data. a. In the CE-PE link b. In a single- or multi- provider PPVPN backbone c. In the Internet used as PPVPN backbone 13. The approach provides protection against unauthorized traffic pattern analysis for PPVPN user data. a. In the CE-PE link b. In a single- or multi- provider PPVPN backbone c. In the Internet used as PPVPN backbone 14. The control protocol(s) used for each of the following functions provide for message integrity and peer authentication: a. VPN membership discovery b. Tunnel establishment c. VPN topology and reachability advertisement i. PE-PE ii. PE-CE d. VPN provisioning and management e. VPN monitoring and attack detection and reporting f. Other VPN-specific control protocols, if any. (list) The following questions solicit free-form answers. 15. Describe the protection, if any, the approach provides against PPVPN-specific DOS attacks (i.e. Inter-trusted-zone DOS attacks): a. Protection of the service provider infrastructure against Data Plane or Control Plane DOS attacks originated in a private (PPVPN user) network and aimed at PPVPN mechanisms. b. Protection of the service provider infrastructure against Data Plane or Control Plane DOS attacks originated in the Internet and aimed at PPVPN mechanisms. c. Protection of PPVPN users against Data Plane or Control Plane DOS attacks originated from the Internet or from other PPVPN users and aimed at PPVPN mechanisms. Expires January 2004 Page 32 PPVPN Security framework September 2003 16. Describe the protection, if any, the approach provides against unstable or malicious operation of a PPVPN user network: a. Protection against high levels of, or malicious design of, routing traffic from PPVPN user networks to the service provider network. b. Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network. c. Protection against worms and probes originated in the PPVPN user networks, sent towards the service provider network. 17. Is the approach subject to any approach-specific vulnerabilities not specifically addressed by this template? If so describe the defense or mitigation, if any, the approach provides for each. 9. Security Considerations There are no further security considerations in addition to what discussed in the previous sections. References [Beard] D. Beard and Y. Yang, "Known Threats to Routing Protocols," draft-beard-rpsec-routing-threats-00.txt, Oct. 2002. [GDOI] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of Interpretation," draft-ietf-msec-gdoi-07.txt, December 2002. [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," February 1997. [RFC-2246] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol," November 1998. [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header," November 1998. [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)," November 1998. [RFC2407] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP," November 1998. Expires January 2004 Page 33 PPVPN Security framework September 2003 [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap," November 1998. [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 1 (SHA1)," September 2001. [SECMECH] S. Bellovin, C. Kaufman, J. Schiller, "Security Mechanisms for the Internet," draft-iab-secmech-02.txt, January 2003. [STD62] "Simple Network Management Protocol, Version 3," RFCs 3411- 3418, December 2002. [STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification", STD 8, May 1983. Author's Addresses Luyuan Fang AT&T 200 Laurel Avenue, Room C2-3B35 Phone: 732-420-1921 Middletown, NJ 07748 Email: luyuanfang@att.com Michael Behringer Cisco Avda de la Vega 15 Phone: 34-639-659-822 28100 Alcobendas, Madrid Email: mbehring@cisco.com Spain Ross Callon Juniper Networks 10 Technology Park Drive Phone: 978-692-6724 Westford, MA 01886 Email: rcallon@juniper.net Fabio Chiussi Lucent Technologies 101 Crawfords Corner Rd, Room 4G502 Phone: 732-949-2407 Holmdel, NJ 07733 Email: fabio@lucent.com Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen E-mail: Belgium jeremy.de_clercq@alcatel.be Mark Duffy Expires January 2004 Page 34 PPVPN Security framework September 2003 Quarry Technologies 8 New England Executive Park Phone: 781-359-5052 Burlington, MA 01803 Email: mduffy@quarrytech.com Paul Hitchen BT BT Adastral Park Martlesham Heath Phone: 44-1473-606-344 Ipswich IP53RE Email: paul.hitchen@bt.com UK Paul Knight Nortel Networks 600 Technology Park Drive Phone: 978-288-6414 Billerica, MA 01821 Email: paul.knight@nortelnetworks.com Full Copyright Statement "Copyright (C) The Internet Society (date). 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 in 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. Expires January 2004 Page 35