Network Working Group L. Fang, Ed. Request for Comments: 4111 AT&T Labs. Category: Informational July 2005 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis document addresses security aspects pertaining to Provider- Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. 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, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. 1. Introduction ................................................. 2 2. Terminology .................................................. 4 3. Security Reference Model ..................................... 4 4. Security Threats ............................................. 6 4.1. Attacks on the Data Plane .............................. 7 4.2. Attacks on the Control Plane ........................... 9 5. Defensive Techniques for PPVPN Service Providers ............. 11 5.1. Cryptographic Techniques ............................... 12 5.2. Authentication ......................................... 20 5.3. Access Control Techniques .............................. 22 5.4. Use of Isolated Infrastructure ......................... 27
5.5. Use of Aggregated Infrastructure ....................... 27 5.6. Service Provider Quality Control Processes ............. 28 5.7. Deployment of Testable PPVPN Service ................... 28 6. Monitoring, Detection, and Reporting of Security Attacks ..... 28 7. User Security Requirements ................................... 29 7.1. Isolation .............................................. 30 7.2. Protection ............................................. 30 7.3. Confidentiality ........................................ 31 7.4. CE Authentication ...................................... 31 7.5. Integrity .............................................. 31 7.6. Anti-replay ............................................ 32 8. Provider Security Requirements ............................... 32 8.1. Protection within the Core Network ..................... 32 8.2. Protection on the User Access Link ..................... 34 8.3. General Requirements for PPVPN Providers ............... 36 9. Security Evaluation of PPVPN Technologies .................... 37 9.1. Evaluating the Template ................................ 37 9.2. Template ............................................... 37 10. Security Considerations ...................................... 40 11. Contributors ................................................. 41 12. Acknowledgement .............................................. 42 13. Normative References ......................................... 42 14. Informative References ....................................... 43 RFC4110] and [RFC4031]. These documents acknowledge that security is an important and integral aspect of PPVPN services, for both VPN customers and VPN service providers. Both will benefit from a PPVPN Security Framework document that lists the customer and provider security requirements related to PPVPN services, and that can be used to assess how much a particular technology protects against security threats and fulfills the security requirements. First, we 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. Special considerations engendered by IP mobility within PPVPNs are not in the scope of this document. Then, we discuss the possible user and provider security requirements for a PPVPN service. Users expectations must be met for the security characteristics of a VPN service. These user requirements translate into corresponding requirements for the providers offering the service. Furthermore, providers have security requirements to protect their network infrastructure, securing it 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 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 is to provide a common tool, in the form of a checklist, 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, thereby providing a common ground for comparison between different technologies. It is important to clarify that this document is limited to describing users' and providers' security requirements that pertain to PPVPN services. It is not the intention to formulate precise "requirements" on each specific technology by defining the mechanisms and techniques that must be implemented to satisfy such users' and providers' requirements. This document is organized as follows. Section 2 defines the terminology used in the document. Section 3 defines the security reference model for security in PPVPN networks. Section 4 describes the security threats that are specific of PPVPNs. Section 5 reviews defense techniques that may be used against those threats. Section 6 describes how attacks may be detected and reported. Section 7 discusses the user security requirements that apply to PPVPN services. Section 8 describes additional security requirements on the provider to guarantee the security of the network infrastructure providing PPVPN services. In Section 9, we provide a template that may be used to describe the security characteristics of specific PPVPN technologies. Finally, Section 10 discusses security considerations.
RFC4026] and [RFC4110]. The most important definitions are repeated in this section; for other definitions, the reader is referred to [RFC4026] and [RFC4110]. CE: Customer Edge device, a router or a switch in the customer network interfacing with the service provider's network. P: Provider Router. The Provider Router is a router in the service provider's core network that does not have interfaces directly toward the customer. A P router is used to interconnect the PE routers. A P router does not have to maintain VPN state and is thus VPN unaware. PE: Provider Edge device, the equipment in the service provider's network that interfaces with the equipment in the customer's network. PPVPN: Provider-Provisioned Virtual Private Network, a VPN that is configured and managed by the service provider (and thus not by the customer itself). SP: Service Provider. VPN: Virtual Private Network, which restricts communication between a set of sites using an IP backbone shared by traffic that is not going to or coming from those sites.
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 wherein 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 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, PPVPN core networks often offer Internet access, in which case a transit point (marked "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 that 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 provisioning of the PPVPN network could make a difference to the security of this server.
same service provider may be able to launch attacks that those who are 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. 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, or - in a PPVPN transiting the public Internet. Most types of attacks become easier to mount, and hence more likely, as the shared infrastructure that provides VPN service expands from a single service provider to multiple cooperating providers, and then to the global Internet. Attacks that may not be sufficiently likely 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.
the insertion of copies of once-legitimate packets that have been recorded and replayed.
VPNs than against VPNs that are self-provisioned by the customer at the IP layer. RFC3889].
black hole routing or unauthorized data plane cross-connection between PPVPNs.
Successful defense against an attack does not necessarily mean that 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.
In particular, it determines where encryption should be applied, as follows. - 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 be 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 that is not at 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 by using encryption, as well. Although CE-CE encryption provides confidentiality 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, to bypass encryption processing altogether, or to provide some means of sniffing or diverting unencrypted traffic. Thus, a PPVPN implementation using CE-CE encryption has 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 that 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 or a configuration lock-down ability, or it might allow both parties to verify the configuration. In general, if the managed CE-CE model is used, the PPVPN user has to have a fairly high level of trust that the PPVPN provider will properly provision and manage the CE devices.
RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the security protocol of choice for encryption at the IP layer (Layer 3), as discussed in [RFC3631]. 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, data encryption that is performed within the user's site is outside the scope of this document, as it is simply handled as user data by the PPVPN. IPsec can also be used to protect IP traffic between a remote user and the PPVPN. IPsec does not itself specify an encryption algorithm. It can use a variety of encryption algorithms with various key lengths, such as AES encryption. 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 confidentiality rather than to analyze 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. With IPsec, authentication of messages is provided by the Authentication Header (AH) or by the Encapsulating Security Protocol (ESP) with authentication only. Where control messages require authentication but do not use IPsec, other cryptographic authentication methods are available. Message authentication methods currently considered to be secure are based on hashed message authentication codes (HMAC) [RFC2104] implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174].
One recommended mechanism for providing a combination confidentiality, data origin authentication, and connectionless integrity is the use of AES in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV) [RFC3602], as the IPsec ESP. PPVPNs that provide differentiated services based on traffic type may encounter some conflicts with IPsec encryption of traffic. As 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. STD8] or terminal-like connections to allow device configuration. - SNMP v3 [STD62] provides encrypted and authenticated protection for SNMP-managed devices. - Transport Layer Security (TLS) [RFC2246] and the closely-related Secure Sockets Layer (SSL) are widely used for securing HTTP-based communication, and thus can provide support for most XML- and SOAP-based device management approaches. - As of 2004, extensive work is proceeding in several organizations (OASIS, W3C, WS-I, and others) on securing device management traffic within a "Web Services" framework. This work uses a wide variety of security models and supports multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. - IPsec provides the services with security and confidentiality at the network layer. With regard to device management, its current use is primarily focused on in-band management of user-managed IPsec gateway devices.
Figure 2 depicts a simplified PPVPN topology, showing the Customer Edge (CE) devices, the Provider Edge (PE) devices, and a variable number (three are shown) of Provider core (P) devices that might be present along the path between two sites in a single VPN, operated by a single service provider (SP). Site_1---CE---PE---P---P---P---PE---CE---Site_2 Figure 2: Simplified PPVPN topology
Within this simplified topology and assuming that P devices are not to be involved with encryption, there are four basic feasible configurations for implementing encryption on connections among the devices: 1) Site-to-site (CE-to-CE): Encryption can be configured between the two CE devices, so that traffic will be encrypted throughout the SP's network. 2) Provider edge-to-edge (PE-to-PE): Encryption can be configured between the two PE devices. Unencrypted traffic is received at one PE from the customer's CE; then it is encrypted for transmission through the SP's network to the other PE, where it is decrypted and sent to the other CE. 3) Access link (CE-to-PE): Encryption can be configured between the CE and PE, on each side (or on only one side). 4) Configurations 2) and 3) can be combined, with encryption running from CE to PE, then from PE to PE, and then from PE to CE. Among the four feasible configurations, key tradeoffs in considering encryption include the following: - Vulnerability to link eavesdropping: Assuming that an attacker can observe the data in transit on the links, would it be protected by encryption? - Vulnerability to device compromise: Assuming an attacker can get access to a device (or freely alter its configuration), would the data be protected? - Complexity of device configuration and management: Given Nce, the number of sites per VPN customer, and Npe, the number of PEs participating in a given VPN, how many device configurations have to be created or maintained and how do those configurations scale? - Processing load on devices: How many encryption or decryption operations must be done, given P packets? This influences considerations of device capacity and perhaps end-to-end delay. - Ability of SP to provide enhanced services (QoS, firewall, intrusion detection, etc.): Can the SP inspect the data in order to provide these services? These tradeoffs are discussed below for each configuration.
1) Site-to-site (CE-to-CE) Configurations o Link eavesdropping: Protected on all links. o Device compromise: Vulnerable to CE compromise. o Complexity: Single administration, responsible for one device per site (Nce devices), but overall configuration per VPN scales as Nce**2. o Processing load: on each of two CEs, each packet is either encrypted or decrypted (2P). o Enhanced services: Severely limited; typically only DiffServ markings are visible to SP, allowing some QoS services. 2) Provider edge-to-edge (PE-to-PE) Configurations o Link eavesdropping: Vulnerable on CE-PE links; protected on SP's network links. o Device compromise: Vulnerable to CE or PE compromise. o Complexity: Single administration; Npe devices to configure. (Multiple sites may share a PE device, so Npe is typically much less than Nce.) Scalability of the overall configuration depends on the PPVPN type: If the encryption is separate per VPN context, it scales as Npe**2 per customer VPN. If the encryption is per PE, it scales as Npe**2 for all customer VPNs combined. o Processing load: On each of two PEs, each packet is either encrypted or decrypted (2P). o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic. 3) Access link (CE-to-PE) Configuration o Link eavesdropping: Protected on CE-PE link; vulnerable on SP's network links. o Device compromise: Vulnerable to CE or PE compromise. o Complexity: Two administrations (customer and SP) with device configuration on each side (Nce + Npe devices to configure), but as there is no mesh, the overall configuration scales as Nce.
o Processing load: On each of two CEs, each packet is either encrypted or decrypted. On each of two PEs, each packet is either encrypted or decrypted (4P). o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic. 4) Combined Access link and PE-to-PE (essentially hop-by-hop). o Link eavesdropping: Protected on all links. o Device compromise: Vulnerable to CE or PE compromise. o Complexity: Two administrations (customer and SP), with device configuration on each side (Nce + Npe devices to configure). Scalability of the overall configuration depends on the PPVPN type. If the encryption is separate per VPN context, it scales as Npe**2 per customer VPN. If the encryption is per-PE, it scales as Npe**2 for all customer VPNs combined. o Processing load: On each of two CEs, each packet is either encrypted or decrypted. On each of two PEs, each packet is both encrypted and decrypted (6P). o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic. Given the tradeoffs discussed above, a few conclusions can be reached. - Configurations 2 and 3, which are subsets of 4, may be appropriate alternatives to 4 under certain threat models. The remainder of these conclusions compare 1 (CE-to-CE) with 4 (combined access links and PE-to-PE). - If protection from link eavesdropping is most important, then configurations 1 and 4 are equivalent. - If protection from device compromise is most important and the threat is to the CE devices, both cases are equivalent; if the threat is to the PE devices, configuration 1 is best. - If reducing complexity is most important and the size of the network is very small, configuration 1 is the best. Otherwise, the comparison between options 1 and 4 is relatively complex , based on a number of issues such as, how close the CE to CE communication is to a full mesh, and what tools are used for key management. Option 1 requires configuring keys for each CE-CE
pair that is communicating directly. Option 4 requires configuring keys on both CE and PE devices but may offer benefit from the fact that the number of PEs is generally much smaller than the number of CEs. Also, under some PPVPN approaches, the scaling of 4 is further improved by sharing the same PE-PE mesh across all VPN contexts. The scaling characteristics of 4 may be increased or decreased in any given situation if the CE devices are simpler to configure than the PE devices, or vice versa. Furthermore, with option 4, the impact of operational error may be significantly increased. - If the overall processing load is a key factor, then 1 is best. - If the availability of enhanced services support from the SP is most important, then 4 is best. As a quick overall conclusion, CE-to-CE encryption provides greater protection against device compromise, but it comes at the cost of enhanced services and with additional operational complexity due to the Order(n**2) scaling of the mesh. This analysis of site-to-site vs. hop-by-hop encryption tradeoffs does not explicitly include cases where multiple providers cooperate to provide a PPVPN service, public Internet VPN connectivity, or remote access VPN service, but many of the tradeoffs will be similar.
RFC2865] and DIAMETER [RFC3588]. 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 [RFC2661] 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 any of several possible locations in the network. The user-managed case is of limited interest within the PPVPN security framework, and it 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 have to be
referenced in a secure manner by the PPVPN provider. This can be accomplished through 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 it 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.
- Statefulness: Because it receives both sides of a conversation, a firewall may be able to obtain a significant amount of information concerning that conversation and to use this information to control access. A filter can maintain some limited state information on a unidirectional flow of packets, but it cannot determine the state of the bi-directional conversation as precisely as a firewall can.
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 that 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 that are part of a DoS or DDoS attack, or packets that are trying to access forbidden resources (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 also be counted and/or logged, of course. - 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 that match a particular filter may be limited to a specified bandwidth. Packets and/or bytes would be counted and forwarded normally up to the specified limit. Excess packets may be discarded or marked (for example, by setting a "discard eligible" bit in the IP ToS field or the MPLS EXP field). - Forward and Copy It is useful in some cases not only to forward some set of packets normally, but also to 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 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 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 on 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. A key consideration with the use of packet filters is that they can provide few options for filtering packets carrying encrypted data. Because the data itself is not accessible, only packet header information or other unencrypted fields can be used for filtering.
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. Another consideration with the use of firewalls is that they can provide few options for handling packets carrying encrypted data. As the data itself is not accessible, only packet header information, other unencrypted fields, or analysis of the flow of encrypted packets can be used for making decisions on accepting or rejecting encrypted traffic.
also, in some cases, thwart traffic pattern analysis by combining the data from multiple VPNs.
Monitoring systems used to detect security attacks in PPVPNs will typically operate by collecting information from 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 notifications). 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. 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 allow 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. 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.
RFC1918], without interfering with other PPVPNs that use PPVPN services from the same service provider(s). When Internet access is provided (e.g., by the same service provider that is offering PPVPN service), NAT functionality may be needed. In layer-2 VPNs, the same requirement exists for the layer 2 addressing schemes, such as MAC addresses.
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. 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 it will improve the security of the core. If the core is dedicated to VPN services and there are no interconnects to third parties, then it 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 by 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 should be taken for loop prevention. This prevents the backbone addresses from being exposed through trace route; however, it 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, by using MPLS label switching for all traffic within the core and possibly by making the Internet a VPN within the PPVPN core itself. This helps detach Internet access from PPVPN services. PE devices may implement separate control plane, data plane, and management plane functionality in terms of hardware and software, to improve security. This may help limit the problems when one particular area is attacked, and it may allow each plane to implement additional security measurement separately. PEs are often more vulnerable to attack than P routers, since, by their very nature, PEs cannot be made unreachable to outside users. 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 8.2.3).
In the PE, using separate routing processes for Internet and PPVPN service may help 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 on individual VPNs, it may help 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. Providing PPVPN services introduces new security requirements for VPN services. Similar consideration apply to L2 VPN services.
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 it supports VPN and Internet services on the same physical interfaces through different logical interfaces.
Section 7. Depending on the technologies used, these requirements may include the following. - 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. - Access Authentication. - Techniques highlighted through this document identify methodologies for the protection of PPVPN resources and infrastructure. Hardware or software bugs in equipment that lead to security breaches are outside the scope of this document.
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, or 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, or 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, or 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, or 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, or 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, or c. in the Internet used as PPVPN backbone. 14. The control protocol(s) used for each of the following functions provides 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, 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. 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 toward 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, that the approach provides for each.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security Mechanisms for the Internet", RFC 3631, December 2003. [RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 3889, October 2004. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC4031] Carugi, M. and D. McDysan, Eds., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005. [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", RFC 4110, July 2005.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.