Luyuan Fang (editor) AT&T Michael Behringer Cisco Fabio Chiussi Lucent Technologies Mark Duffy Quarry Technologies Provider Provisioned VPN WG Paul Hitchen BT Internet Draft Paul Knight Nortel Networks Document: draft-fang-ppvpn-security-framework-00.txt Expires: August 2003 February 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." 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. Informational - Expires May 2002 1 PPVPN Security framework February 2003 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 and meet the VPN customerÆs expectations. Finally, we define how these user requirements apply to specific PPVPN technologies, namely RFC2547 PPVPNs, Virtual Router PPVPNs, IPSec VPNs, and Layer 2 PPVPNs. 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...............................................5 3.1. Attacks on the Data Plane...................................6 3.2. Attacks on the Control Plane................................7 4. Defensive Techniques...........................................9 4.1. Cryptographic techniques...................................10 4.2. Sender Authentication......................................12 4.3. Access Control techniques..................................12 4.4. Use of Isolated Infrastructure.............................13 4.5. Use of Aggregated Infrastructure...........................13 4.6. Service Provider Quality Control Processes.................13 4.7. Deployment of Testable PPVPN Service.......................13 5. Monitoring, Detection, and Reporting of Security Attacks......13 6. User Security Requirements....................................14 6.1. Isolation..................................................15 6.2. Protection.................................................15 6.3. Confidentiality............................................16 6.4. Authentication.............................................16 6.5. Integrity..................................................16 6.6. Anti-Replay................................................16 6.7. Non-repudiation............................................16 7. Provider Security Requirements................................17 7.1. Protection within the Core Network.........................17 Expires August 2003 2 PPVPN Security framework February 2003 7.2. Protection on the User Access Link.........................19 7.3. General Requirements for PPVPN Providers...................19 8. Security Aspects of PPVPN Technologies........................19 8.1. Security Aspects of RFC2547 PPVPNs.........................20 8.2. Security Aspects of Virtual Router PPVPNs..................20 8.3. Security Aspects of IPSec VPNs.............................20 8.4. Security Aspects of Layer 2 PPVPNs.........................20 9. Security Considerations.......................................20 References........................................................20 Author's Addresses................................................21 Full Copyright Statement..........................................21 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 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. In addition, providers have security requirements to protect their network infrastructure, and make it secure so it can provide the PPVPN services. Finally, we define how these user and provider requirements apply to specific PPVPN technologies, namely RFC2547 PPVPNs, Virtual Router PPVPNs, IPSec VPNs, and Layer 2 PPVPNs. 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 Expires August 2003 3 PPVPN Security framework February 2003 techniques that must be implemented to satisfy such users and providersÆ requirements. In its current form, the body of many sections in this document is in a preliminary stage, and will be completed in future versions of this draft. Our main purpose for this first release is to solicit input and reach consensus within the working group on which security aspects should be within the scope of this draft, and which should be part of other documents. In fact, there is a clear need from providers and vendors alike to define a general framework to address the security aspects of PPVPN services, but there is also considerable debate on the most appropriate way to accomplish this. Specifically, in terms of the contents of this draft, one pressing issue is whether the mapping of the security requirements to each specific PPVPN technology should be within the scope of this document, or the specific security aspects should be treated separately in the drafts describing each technology. 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 map all these users and providersÆ requirement on 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 over which PPVPN services are delivered. All network elements in the core are under the operational control of one or more PPVPN service providers. A PPVPN user is a company, institution or residential client of the PPVPN service provider. A PPVPN network is a virtual private network provided over the PPVPN core, under administrative control of the PPVPN user. Edge network elements of a PPVPN may be maintained by the service provider. This document defines each PPVPN as a trusted zone, and the PPVPN core as another trusted zone. A primary concern is about security Expires August 2003 4 PPVPN Security framework February 2003 aspects that relate to infrictions 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. In addition, we consider security aspects that are exclusively within a trusted zone, for example within a given PPVPN, or within the core network. However, all aspects of network security which are independent of the way the network is provisioned are outside the scope of this document. For example attacks from the Internet to a server of a given PPVPN user will not be considered here, unless the way to provision the PPVPN network 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, that affect PPVPNs in unique ways, or that are perceived obstacles to PPVPN deployment. A successful attack on a particular PPVPN or on a service provider's PPVPN infrastructure would be expected to have effects of the following unhappy sorts: o Observation, modification, or deletion of PPVPN customer data. o Replay of PPVPN customer data. o Injection of non-authentic data into a PPVPN. o Traffic pattern analysis on PPVPN traffic. Expires August 2003 5 PPVPN Security framework February 2003 o Disruption of PPVPN connectivity. 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: o The PPVPN service provider or persons working for it. o Persons within the organization which is the customer with respect to a particular PPVPN. o Persons within an organization that is a separate PPVPN customer of the same service provider. o 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 other PPVPN customers of the same service provider may be able to launch attacks that those completely outside the network cannot. It is also useful to consider the likelihood of different sorts of threats occurring. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as: o In a layer 1 or layer 2 access network between a PPVPN customer and the service provider o Within one service provider's network o On the public Internet 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 customer data, as viewed by the service provider. Note that from the PPVPN customer's point of view, some of this might be control plane traffic, e.g. routing protocols running from customer site to customer site via an L2 PPVPN. 3.1.1. Insertion of non-authentic data traffic, spoofing, falsification This refers to the insertion (or ôspoofingö) into the VPN of packets that do not belong there, with the objective of having them accepted as legitimate. Included in this category is the insertion of copies of once-legitimate packets that have been recorded and replayed. 3.1.2. Denial of Service attacks on the VPN DOS attacks on the data plane could be mounted by inserting an overwhelming quantity of non-authentic data into a specific PPVPN, or by overwhelming the service providerÆs general (VPN-independent) Expires August 2003 6 PPVPN Security framework February 2003 infrastructure. This latter case is not necessarily a PPVPN- specific issue, unless the attack is mounted by another VPN with the intention of monopolizing network resources in order to prevent other VPNs from accessing those resources. 3.1.3. Unauthorized observation/modification/deletion of data traffic This refers to ôsniffingö VPN packets and examining their contents. It also includes modifying the contents of packets in flight, or causing packets in flight to be discarded. Such attacks would typically occur on links in the network but might also occur in a compromised node of the network. 3.1.4. 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. 3.1.5. Interference This refer to attacks aiming at disrupting communication exchanges between PEs or routers in the network. This includes any actions such as discarding and delaying packets and acknowledgments, flapping routing sessions, etc. Interference can also refer to actions, external to a VPN, with the purpose of disrupting the correct behavior of the VPN, such as increasing packet loss, increasing delay, and reducing throughput. 3.1.6. Impersonation This refers to a broad category of attacks where the attacker disguises itself to appear as a legitimate entity. 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 DOS attacks could 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. core routers. (The latter case is within the scope of this document only if the attack happens in relation with the VPN service, otherwise is not a PPVPN-specific issue.) Expires August 2003 7 PPVPN Security framework February 2003 Of special concern for PPVPNs is denial of service to one PPVPN customer caused by the otherwise-legitimate activities of another PPVPN customer. This can occur for example if one customer's activities are allowed to consume network resources of any sort that are also needed to serve other customers. 3.2.2. Attacks on the Service Provider Equipment Via Management Interfaces This includes unauthorized access to service provider infrastructure equipment, which access could be used to reconfigure the equipment, or to extract information (statistics, topology, etc.) about one or more PPVPNs. This could be accomplished through malicious entering of the systems, or inadvertently as a consequence of inadequate inter-VPN isolation in a customer 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: o A site being connected into the ôwrongö VPN o Two or more VPNs being merged together o A point-to-point VPN connecting the wrong two points Cross-connection of VPNs has a high likelihood of being the result of service provider or equipment vendor error rather than malicious action. Anecdotal evidence suggests that the cross-connection threat is one of the largest security concerns of PPVPN customers (or would-be customers). A related aspect specific of Layer 2 VPNs pertains to flooding, for example as a result of an ARP request, which needs to be limited to the VPN generating the ARP. 3.2.4. Attacks against PPVPN Routing Protocols This encompasses attacks against routing protocols that are run by the service provider. In layer 3 VPNs with dynamic routing this would typically relate to the distribution of per-VPN routes as well as backbone routes. In layer 2 VPNs this would typically relate only to the distribution of backbone routes. Specific attacks against popular routing protocols have been widely studied and described in [Beard]. 3.2.5. Attacks on Route separation Expires August 2003 8 PPVPN Security framework February 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 could reveal topology and addressing information about a PPVPN. It could also cause black hole routing or unintended cross-connection between PPVPNs. 3.2.6. Attacks on MAC address and VLAN separation In Layer 2 VPNs, the MAC address and VLAN space of different VPNs need to be kept separate. A breach in MAC and VLAN separation may result in cross-connection between VPNs. In fact, MAC address and VLAN spaces for different VPNs may in general overlap. MAC addresses and VLAN tags of specific VPNs need to be kept separate in the learning tables, to guarantee that a given VPNs is not prevented access to its fair share of the learning resources, and excessive flooding does not occur. 3.2.7. Spoofing (This section will be added in future version of this document.) 3.2.8. Attacks on PPVPN connectivity Loss of connectivity may be the result of several of the threats described above, rather than a threat in itself. This subsection may be removed in future version of this document. 3.2.9. Other attacks on control traffic Routing and management protocols are covered separately in the previous sections. In this section, we will address other control protocols such as MPLS signaling (LDP, RSVP TE) and IPsec (IKE). Possible attacks include the possibility of impersonation or DOS attacks on these protocols. 4. Defensive Techniques 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 Expires August 2003 9 PPVPN Security framework February 2003 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 customer system. The latter is a much easier task. 4.1. Cryptographic techniques The cryptographic 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 networks. The PPVPN operator should determine the applicability of these techniques to the operator's specific service offerings, and the PPVPN user should assess the value which these techniques add to the user's VPN requirements. There are a few reasons why encryption may not be a standard offering within every VPN. 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 by encryption, 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.) 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. However, the ability of currently available encryption techniques to reliably reduce the damage from a variety of attacks is likely to make encryption a common service offerings in PPVPNs. 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 the data being communicated is not changed during transit. IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the security protocol of choice for VPN operations at the IP layer (Layer 3), as discussed in [SECMECH]. IPsec provides robust security for IP traffic between pairs of devices. In addition, group-oriented security protocols based on the Group Domain of Expires August 2003 10 PPVPN Security framework February 2003 Interpretation [GDOI] are being developed to allow the extension of IPsec services to groups of devices. These group protocols are likely to be applicable to the development of encryption services which will offer enhanced value to multi-site VPNs. 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. The trust model between the PPVPN provider and the PPVPN user is a key element in determining the points where encryption techniques are employed. Since the entity which manages a device where encryption is applied can potentially modify the device configuration to obtain access to the unencrypted data, some PPVPN users will insist on maintaining control of the end-to-end encryption of their VPN traffic. Other PPVPN users may not trust the security of the links between their site's CE and the PPVPN provider's PE, and opt for encryption on the PE-CE link. 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, which are beyond the scope of this document. PPVPN users should be aware of the specific encryption algorithm and effective key length used by the PPVPN provider, in order to assess the level of security offered by any particular IPsec-based PPVPN service. However, in practice, almost any IPsec encryption offers enough security that it will not be directly targeted by an attacker; other weaker links in the chain of security will be attacked first. 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. Techniques using hashed message authentication codes (HMAC) [RFC2104] implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174] are preferred in this case. For configuration of PPVPN devices, some other encryption techniques offer security and privacy comparable to IPsec. Secure Shell (SSH) offers protection for terminal-like connections to allow device configuration. SNMP v3 [STD62] also provides protection for device management. 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 Expires August 2003 11 PPVPN Security framework February 2003 as the encrypted Layer 2 packets can be properly handled by the intervening PE devices. In addition, if the upper layer traffic transported by the Layer 2 VPN is encrypted, privacy will be maintained; however, this is outside the scope of this document. 4.2. Sender Authentication This category includes the techniques that have been proposed for the CEs in a 2547 network to verify they are connected to the expected VPN. Also in this category are peer authentication for control protocols (e.g. MPLS, BGP, etc.), peer authentication in the ôdata planeö (i.e. authentication of one IPsec security gateway by another), and authentication of remote access users connecting to a VPN. 4.3. Access Control techniques This includes packet-by-packet or packet-flow-by-packet-flow access control by means of filters and firewalls, as well as means of admitting a ôsessionö for a control/signalling/management protocol that is being used to implement PPVPNs. 4.3.1. Filtering (This section will be added in future version of this document.) 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. Thus, in a PPVPN, firewalls will most often 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 Expires August 2003 12 PPVPN Security framework February 2003 shared network-based services offered by the PPVPN provider. Finally, firewalls may be applied to protect PPVPN core network functions from attacks originating from the Internet or from PPVPN user sites. 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 Lists (This section will be added in future version of this document.) 4.3.4. Access Control to management interfaces (This section will be added in future version of this document.) 4.4. Use of Isolated Infrastructure Examples include running PE-based L3 VPNs on a separate backbone not connected to the Internet, CE-based IPsec VPNs that use dedicated equipment for each customer, etc. 4.5. Use of Aggregated Infrastructure The opposite of isolated infrastructure. Traffic pattern analysis may be thwarted by combining the data of multiple VPNs. 4.6. Service Provider Quality Control Processes This would refer to operational processes in place within the SP to prevent misconfigurations such as connecting a site to the wrong VPN. 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, a number of which are described in Section 3. Many of the defensive techniques described in this document and elsewhere provide significant levels of protection from a variety of threats. Expires August 2003 13 PPVPN Security framework February 2003 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 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 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. For example, events which are associated with security attacks (e.g., authentication failure, access list violations, etc.) should be recorded as an integral part of the operation of a defensive mechanism, rather than involving redundant operations. As another example, multiple attacks may be reported through a single message using a counter, rather than allowing each attack to trigger a separate message, potentially resulting in a denial-of-service attack against the monitoring system. 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 Expires August 2003 14 PPVPN Security framework February 2003 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. 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. 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. 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 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 independent networks. Expires August 2003 15 PPVPN Security framework February 2003 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 independent 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. The requirement is that a PPVPN is not more vulnerable against DoS attacks than if the same network would be provided independently. 6.2.3. Protection against spoofing It is not possible to change the sender identification (source address, source label, etc) of traffic in transit from the outside of a trusted zone. 6.3. Confidentiality This requirement means that data must be cryptographically secured in transit over the PPVPN core network to avoid eavesdropping. 6.4. Authentication (To be added in future versions of this document.) 6.5. Integrity Data in transit must be cryptographically secured such that it cannot be altered. 6.6. Anti-Replay Data in transit must be cryptographically secured such that it cannot be recorded and replayed later. 6.7. Non-repudiation Expires August 2003 16 PPVPN Security framework February 2003 The issue of non-repudiation pertains to PPVPN services, as well as any other service. However, it is typically handled at the application level, and is not therefore further discussed here. 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 network can be implemented with different types of network technologies, and each core network may use different technologies to provide the PPVPN services to the users with different level of 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 from PPVPN users and non-PPVPN users, both accidentally and maliciously, 2) how to protect the PPVPN users. 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 core may need additional security requirements, for the mere fact that most users are expecting higher security standards in a core used for delivering the PPVPN services. 7.1. Protection within the Core Network 7.1.1. Control Plane Protection - Protocol authentication within the core: Protocols authentication may be used for core protocol protection. 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 using TCP MD5 or IPSec in addition to IGP and BGP authentication. For a Layer 2 core, PE to PE authentication may be used with IPSec. With the cost of authentication coming down rapidly, the core network protocol authentication may not increase the cost of implementation for the providers significantly, but it certainly helps to improve the security of the core. - Elements protection Here we discuss means to hide the providers infrastructure nodes. Expires August 2003 17 PPVPN Security framework February 2003 A PPVPN provider may make the infrastructure routers (P and PE routers) loopbacks unreachable from the outside users and unauthorized internal users. For example, separate address space may be used for the infrastructure loopbacks. 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. 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. This helps to detach Internet access from PPVPN services. Separating control plane, data plane, and management plane separation may be implemented on the PE devices to improve the 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 by the outside users, and PEs may have links with lesser bandwidth than P routers, which makes them more vulnerable to DOS attacks. PE may be attacked by Internet users or VPN users accidentally or maliciously. 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 separately allocated based on applications, or even individual VPNs, it may help to provide better 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 may apply 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 MPLS data plane to secure the data carried over MPLS core. [Tissa] Expires August 2003 18 PPVPN Security framework February 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.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 - User data plane separation û one VPN traffic cannot be intercepted by other VPNs or any other users. - Protection against intrusion, DOS attacks and spoofing - User Authentication - Provide confidentiality, integrity, and anti-reply by using cryptography techniques to secure user data Equipment hardware/software bugs leading to breaches in security are not within the scope of this document. 8. Security Aspects of PPVPN Technologies In this section, we plan to discuss how the user and provider requirements described in Section and map to specific PPVPN Expires August 2003 19 PPVPN Security framework February 2003 technology. Whether this should be within the scope of this document is under debate, and input from the working group is solicited. 8.1. Security Aspects of RFC2547 PPVPNs 8.2. Security Aspects of Virtual Router PPVPNs 8.3. Security Aspects of IPSec VPNs 8.4. Security Aspects of Layer 2 PPVPNs 9. Security Considerations (To be added in future versions of this document.) 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. [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. [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. Expires August 2003 20 PPVPN Security framework February 2003 [Tissa] T. Senevirathne, ôSecure MPLS û Encryption and Authentication of MPLS payloads,ö draft-tsenevir-smpls-02.txt, July 2002. 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 Fabio Chiussi Lucent Technologies 101 Crawfords Corner Rd, Room 4G502 Phone: 732-949-2407 Holmdel, NJ 07733 Email: fabio@lucent.com Mark Duffy 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.night@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 Expires August 2003 21 PPVPN Security framework February 2003 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 August 2003 22