Skip to main content

Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4111.
Author Luyuan Fang
Last updated 2020-01-21 (Latest revision 2004-11-23)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4111 (Informational)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Dr. Thomas Narten
Send notices to,,
Luyuan Fang (editor) 
   L3VPN WG                                                          
   Internet Draft                                                    
   Expires: May 2005                                  November 2004 
        Security Framework for Provider Provisioned Virtual Private 
Status of this Memo 
   By submitting this Internet-Draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed, 
   and any of which I become aware will be disclosed, in accordance 
   with RFC 3668. 
   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-
   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 
   The list of current Internet-Drafts can be accessed at 
   The list of Internet-Draft Shadow Directories can be accessed at 
   This draft addresses security aspects pertaining to Provider 
   Provisioned Virtual Private Networks (PPVPNs). We first describe 
   Expires May 2005               1 

   PPVPN Security framework November 2004 
   the security threats that are relevant in the context of PPVPNs, 
   and the defensive techniques that can be used to combat those 
   threats. We consider security issues deriving both from malicious 
   behavior of anyone and from negligent or incorrect behavior of the 
   providers. We also describe how these security attacks should be 
   detected and reported. We then discuss the possible user 
   requirements in terms of security in a PPVPN service. These user 
   requirements translate into corresponding requirements for the 
   providers. In addition, the provider may have additional 
   requirements to make its network infrastructure secure to a level 
   that can meet the PPVPN customer's expectations. Finally, we define 
   a template that may be used to analyze the security characteristics 
   of a specific PPVPN technology and describe them in a manner 
   consistent with this framework. 
Table of Contents 
   Status of this Memo...............................................1 
   Conventions used in this document.................................3 
   1. Introduction...................................................3 
   2. Terminology....................................................4 
   3. Security Reference Model.......................................5 
   4. Security Threats...............................................6 
   4.1.  Attacks on the Data Plane...................................8 
   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.............................26 
   5.5.  Use of Aggregated Infrastructure...........................26 
   5.6.  Service Provider Quality Control Processes.................27 
   5.7.  Deployment of Testable PPVPN Service.......................27 
   6. Monitoring, Detection, and Reporting of Security Attacks......27 
   7. User Security Requirements....................................28 
   7.1.  Isolation..................................................29 
   7.2.  Protection.................................................29 
   7.3.  Confidentiality............................................30 
   7.4.  CE Authentication..........................................30 
   7.5.  Integrity..................................................30 
   7.6.  Anti-Replay................................................31 
   8. Provider Security Requirements................................31 
   8.1.  Protection within the Core Network.........................31 
   8.2.  Protection on the User Access Link.........................33 
   8.3.  General Requirements for PPVPN Providers...................35 
   9. Security Evaluation of PPVPN Technologies.....................35 
   Expires May 2005             Page 2 

   PPVPN Security framework November 2004 
   9.1.  Evaluating the Template....................................35 
   9.2.  Template...................................................36 
   10.  Security Considerations.....................................38 
   11.  IANA Considerations.........................................39 
   12.  Acknowledgement.............................................39 
   13.  Normative References........................................39 
   14.  Informational References....................................40 
   Author's Addresses...............................................41 
Conventions used in this document 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   this document are to be interpreted as described in RFC2119 [RFC 
1. Introduction 
   Security is clearly an integral aspect of Provider Provisioned 
   Virtual Private Network (PPVPN) services.  
   The motivation and rationale for both Provider Provisioned Layer-2 
   VPN and Provider Provisioned Layer-3 VPN services are provided by 
   [L3VPN-FW] and [L3VPN-REQ]. 
   [L3VPN-FW] and [L3VPN-REQ] acknowledge that security is an 
   important and integral aspect of PPVPN services. Security is a 
   concern for both VPN customers and VPN Service Providers. Both will 
   benefit from a PPVPN Security Framework document that lists the 
   customer's and provider's 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. 
   In this document, we first describe the security threats that are 
   relevant in the context of PPVPNs, and the defensive techniques 
   that can be used to combat those threats. We consider security 
   issues deriving both from malicious or incorrect behavior of users 
   and other parties and from negligent or incorrect behavior of the 
   providers. An important part of security defense is the detection 
   and report of a security attack, which is also addressed in this 
   document. Any special considerations engendered by IP mobility 
   within PPVPNs are not in the scope of 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 
   Expires May 2005             Page 3 

   PPVPN Security framework November 2004 
   for the providers in order to offer the service. Furthermore, 
   providers have security requirements to protect their network 
   infrastructure, and make it secure to the level required to provide 
   the PPVPN services, in addition to other services.  
   Finally, we define a template that may be used to describe the 
   security characteristics of a specific PPVPN technology in a manner 
   consistent with the security framework described in this document. 
   It is not within the scope of this document to analyze the security 
   properties of specific technologies; instead, our intention with 
   this template is to provide a common tool, in the form of a check 
   list, that may be used in other documents dedicated to an in-depth 
   security analysis of individual PPVPN technologies to describe 
   their security characteristics in a comprehensive and coherent way, 
   and to provide a common ground for comparison between different 
   It is important to clarify that, in this document, we limit 
   ourselves to describing the users and providers' security 
   requirements that pertain to PPVPN services. It is not our 
   intention, however, to formulate precise "requirements" on each 
   specific technology in terms of defining the mechanisms and 
   techniques that must be implemented to satisfy such users and 
   providers' requirements. 
   This document is organized as follows. In Section 2, we  
   define the terminology used in the document. In section 3, we 
   define the security reference model for security in PPVPN networks, 
   which we use in the rest of the document. In Section 4, we describe 
   the security threats that are specific of PPVPNs. In Section 5, we 
   review defense techniques that may be used against those threats. 
   In Section 6, we describe how attacks may be detected and reported. 
   In Section 7, we discuss the user security requirements that apply 
   to PPVPN services. In Section 8, we describe additional security 
   requirements that the provider may have in order to guarantee the 
   security of the network infrastructure to provide PPVPN services. 
   In Section 9, we provide a template that may be used to describe 
   the security characteristics of specific PPVPN technologies. 
   Finally, in Section 10, we discuss security considerations. 
2. Terminology 
   This document uses PPVPN-specific terminology. Definitions and 
   details about PPVPN-specific terminology can be found in [PPVPN-
   term] and [L3VPN-FW]. The most important definitions are repeated 
   in this section, for other definitions the reader is referred to 
   [PPVPN-term] and [L3VPN-FW]. 
   CE: Customer Edge device. A Customer Edge device is a router or a 
   switch in the customer network interfacing with the Service 
   Provider's network. 
   Expires May 2005             Page 4 

   PPVPN Security framework November 2004 
   P: Provider Router. The Provider Router is a router in the Service 
   Provider's core network that does not have interfaces directly 
   towards the customer. A P router is used to interconnect the PE 
   routers. A P router does not need to maintain VPN state, and is 
   thus VPN unaware. 
   PE: Provider Edge device. The Provider Edge device is 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: Restricted communication between a set of sites, making use of 
   an IP backbone which is shared by traffic that is not going to or 
   coming from those sites. 
3. Security Reference Model 
   This section defines a reference model for security in PPVPN 
   A PPVPN core network is defined here as the central network 
   infrastructure (P and PE routers) over which PPVPN services are 
   delivered. A PPVPN core network consists of one or more SP 
   networks. All network elements in the core are under the 
   operational control of one or more PPVPN service providers. Even if 
   the PPVPN core is provided by several service providers, towards 
   the PPVPN users it appears as a single zone of trust. However, 
   several service providers providing together a PPVPN core still 
   need to secure themselves against the other providers. PPVPN 
   services can also be delivered over the Internet, in which case the 
   Internet forms a logical part of the PPVPN core. 
   A PPVPN user is a company, institution or residential client of the 
   PPVPN service provider.  
   A PPVPN service is a private network service made available by a 
   service provider to a PPVPN user.  The service is implemented using 
   virtual constructs built on a shared PPVPN core network.  A PPVPN 
   service interconnects sites of a PPVPN user.  
   Extranets are VPNs in which multiple sites are controlled by 
   different (legal) entities. Extranets are another example of PPVPN 
   deployment scenarios where restricted and controlled communication 
   Expires May 2005             Page 5 

   PPVPN Security framework November 2004 
   is allowed between trusted zones, often via well-defined transit 
   This document defines each PPVPN as a trusted zone, and the PPVPN 
   core as another trusted zone. A primary concern is about security 
   aspects that relate to breaches of security from the "outside" of a 
   trusted zone to the "inside" of this zone. Figure 1 depicts the 
   concept of trusted zones within the PPVPN framework.  
   +------------+                             +------------+ 
   | PPVPN      +-----------------------------+      PPVPN | 
   | user           PPVPN                             user | 
   | site       +---------------------XXX-----+       site | 
   +------------+  +------------------XXX--+  +------------+ 
                   |   PPVPN core     | |  | 
                   +------------------| |--+ 
                                      | | 
                                      | +------\ 
                                      +--------/  Internet 
   Figure 1: The PPVPN trusted zone model 
   In principle the trusted zones should be separate, however, often 
   PPVPN core networks also offer Internet access, in which case a 
   transit point (marked with "XXX" in the figure) is defined.  
   The key requirement of a "virtual private" network (VPN) is that 
   the security of the trusted zone of the VPN is not compromised by 
   sharing the core infrastructure with other VPNs.  
   Security against threats that originate within the same trusted 
   zone as their targets (for example, attacks from a user in a PPVPN 
   to other users within the same PPVPN, or attacks entirely within 
   the core network) is outside the scope of this document.  
   Also outside the scope are all aspects of network security which 
   are independent of whether a network is a PPVPN network or a 
   private network (for example, attacks from the Internet to a web-
   server inside a given PPVPN will not be considered here, unless the 
   way the PPVPN network is provisioned could make a difference to the 
   security of this server). 
4. Security Threats 
   This section discusses the various network security threats that 
   may endanger PPVPNs.  The discussion is limited to those threats 
   that are unique to PPVPNs, or that affect PPVPNs in unique ways. 

   Expires May 2005             Page 6 

   PPVPN Security framework November 2004 
   A successful attack on a particular PPVPN or on a service 
   provider's PPVPN infrastructure may cause one or more of the 
   following ill effects: 
    - Observation, modification, or deletion of PPVPN user data. 
    - Replay of PPVPN user data. 
    - Injection of non-authentic data into a PPVPN. 
    - Traffic pattern analysis on PPVPN traffic. 
    - Disruption of PPVPN connectivity. 
    - Degradation of PPVPN service quality 
   It is useful to consider that threats, whether malicious or 
   accidental, to a PPVPN may come from different categories of 
   sources.  For example they may come from: 
   - Users of other PPVPNs provided by the same PPVPN service 
   - The PPVPN service provider or persons working for it. 
   - Other persons who obtain physical access to a service provider 
   - Other persons who use social engineering methods to influence 
   behavior of service provider personnel. 
   - Users of the PPVPN itself, i.e. intra-VPN threats.  (Such threats 
   are beyond the scope of this document.) 
   - Others i.e. attackers from the Internet at large. 
   In the case of PPVPNs, some parties may be in more advantaged 
   positions that enable them to launch types of attacks not available 
   to others.  For example users of different PPVPNs provided by the 
   same service provider may be able to launch attacks that those 
   completely outside the network cannot. 
   Given that security is generally a compromise between expense and 
   risk, it is also useful to consider the likelihood of different 
   attacks occurring.  There is at least a perceived difference in the 
   likelihood of most types of attacks being successfully mounted in 
   different environments, such as: 
    - In a PPVPN contained within one service provider's network 
    - In a PPVPN transiting the public Internet  
   Most types of attacks become easier to mount and hence more likely 
   as the shared infrastructure via which VPN service is provided 
   expands from a single service provider to multiple cooperating 
   providers to the global Internet.  Attacks that may not be of 
   sufficient likeliness to warrant concern in a closely controlled 
   environment often merit defensive measures in broader, more open 
   The following sections discuss specific types of exploits that 
   threaten PPVPNs. 
   Expires May 2005             Page 7 

   PPVPN Security framework November 2004 
4.1.    Attacks on the Data Plane 
   This category encompasses attacks on the PPVPN user's data, as 
   viewed by the service provider.  Note that from the PPVPN user's 
   point of view, some of this might be control plane traffic, e.g. 
   routing protocols running from PPVPN user site to PPVPN user site 
   via an L2 PPVPN. 
4.1.1.  Unauthorized Observation of Data Traffic 
   This refers to "sniffing" VPN packets and examining their contents.  
   This can result in exposure of confidential information.  It can 
   also be a first step in other attacks (described below) in which 
   the recorded data is modified and re-inserted, or re-inserted as-
4.1.2.  Modification of Data Traffic 
   This refers to modifying the contents of packets as they traverse 
   the VPN. 
4.1.3.  Insertion of Non-Authentic Data Traffic: Spoofing and Replay 
   This refers to the insertion (or "spoofing") into the VPN of 
   packets that do not belong there, with the objective of having them 
   accepted by the recipient as legitimate.  Also included in this 
   category is the insertion of copies of once-legitimate packets that 
   have been recorded and replayed. 
4.1.4.  Unauthorized Deletion of Data Traffic 
   This refers to causing packets to be discarded as they traverse the 
   VPN.  This is a specific type of Denial of Service attack. 
4.1.5.  Unauthorized Traffic Pattern Analysis 
   This refers to "sniffing" VPN packets and examining aspects or 
   meta-aspects of them that may be visible even when the packets 
   themselves are encrypted.  An attacker might gain useful 
   information based on the amount and timing of traffic, packet 
   sizes, source and destination addresses, etc.  For most PPVPN 
   users, this type of attack is generally considered to be 
   significantly less of a concern than the other types discussed in 
   this section. 
4.1.6.  Denial of Service Attacks on the VPN 
   Denial of Service (DOS) attacks are those in which an attacker 
   attempts to disrupt or prevent the use of a service by its 
   Expires May 2005             Page 8 

   PPVPN Security framework November 2004 
   legitimate users.  Taking network devices out of service, modifying 
   their configuration, or overwhelming them with requests for service 
   are several of the possible avenues for DOS attack. 
   Overwhelming the network with requests for service, otherwise known 
   as a "resource exhaustion" DOS attack, may target any resource in 
   the network e.g. link bandwidth, packet forwarding capacity, 
   session capacity for various protocols, CPU power, and so on. 
   DOS attacks of the resource exhaustion type can be mounted against 
   the data plane of a particular PPVPN by  attempting to 
   insert(spoofing) an overwhelming quantity of non-authentic data 
   into the VPN from the outside of that VPN. Potential results might 
   be to exhaust the bandwidth available to that VPN or to overwhelm 
   the cryptographic authentication mechanisms of the VPN. 
   Data plane resource exhaustion attacks can also be mounted by 
   overwhelming the service provider's general (VPN-independent) 
   infrastructure with traffic.  These attacks on the general 
   infrastructure are not usually a PPVPN-specific issue, unless the 
   attack is mounted by another PPVPN user from a privileged position.  
   (E.g. a PPVPN user might be able to monopolize network data plane 
   resources and thus disrupt other PPVPNs.) 
4.2.    Attacks on the Control Plane 
   This category encompasses attacks on the control structures 
   operated by the PPVPN service provider. 
4.2.1.  Denial of Service Attacks on the Network Infrastructure 
   Control plane DOS attacks can be mounted specifically against the 
   mechanisms the service provider uses to provide PPVPNs e.g. IPsec, 
   MPLS, etc., or against the general infrastructure of the service 
   provider e.g. P routers or shared aspects of PE routers.  (Attacks 
   against the general infrastructure are within the scope of this 
   document only if the attack happens in relation with the VPN 
   service, otherwise is not a PPVPN-specific issue.) 
   Of special concern for PPVPNs is denial of service to one PPVPN 
   user caused by the activities of another PPVPN user.  This can 
   occur for example if one PPVPN user's activities are allowed to 
   consume excessive network resources of any sort that are also 
   needed to serve other PPVPN users. 
   The attacks described in the following sections may each have 
   denial of service as one of their effects.  Other DOS attacks are 
   also possible. 

   Expires May 2005             Page 9 

   PPVPN Security framework November 2004 
4.2.2.  Attacks on the Service Provider Equipment Via Management 
   This includes unauthorized access to service provider 
   infrastructure equipment, for example to reconfigure the equipment 
   or to extract information (statistics, topology, etc.) about one or 
   more PPVPNs. 
   This can be accomplished through malicious entering of the systems, 
   or inadvertently as a consequence of inadequate inter-VPN isolation 
   in a PPVPN user self-management interface.  (The former is not 
   necessarily a PPVPN-specific issue.) 
4.2.3.  Social Engineering Attacks on the Service Provider 
   Attacks in which the service provider network is reconfigured or 
   damaged, or in which confidential information is improperly 
   disclosed, may be mounted through manipulation of service provider 
   personnel. These types of attacks are PPVPN-specific if they affect 
   PPVPN-serving mechanisms.  It may be observed that the 
   organizational split (customer, service provider) that is inherent 
   in PPVPNs may make it easier to mount such attacks against 
   provider-provisioned VPNs than against VPNs that are customer self-
   provisioned at the IP layer. 
4.2.4.  Cross-connection of Traffic Between PPVPNs 
   This refers to the event where expected isolation between separate 
   PPVPNs is breached.  This includes cases such as: 
    - A site being connected into the "wrong" VPN 
    - Two or more VPNs being improperly merged together 
    - A point-to-point VPN connecting the wrong two points 
    - Any packet or frame being improperly delivered outside the VPN 
      it is sent in. 
   Mis-connection or cross-connection of VPNs may be caused by service 
   provider or equipment vendor error, or by the malicious action of 
   an attacker. The breach may be physical (e.g. PE-CE links mis-con 
   nected) or logical (improper device configuration). 
   Anecdotal evidence suggests that the cross-connection threat is one 
   of the largest security concerns of PPVPN users (or would-be 
4.2.5.  Attacks Against PPVPN Routing Protocols 
   This encompasses attacks against routing protocols that are run by 
   the service provider and that directly support the PPVPN service.  
   In layer 3 VPNs this typically relates to membership discovery or 
   Expires May 2005            Page 10 

   PPVPN Security framework November 2004 
   to the distribution of per-VPN routes.  In layer 2 VPNs this 
   typically relates to membership and endpoint discovery.  (Attacks 
   against the use of routing protocols for the distribution of 
   backbone (non-VPN) routes are beyond the scope of this document.)  
   Specific attacks against popular routing protocols have been widely 
   studied and described in [RPSEC]. 
4.2.6.  Attacks on Route Separation 
   "Route separation" refers here to keeping the per-VPN topology and 
   reachability information for each PPVPN separate from, and 
   unavailable to, any other PPVPN (except as specifically intended by 
   the service provider).  This concept is only a distinct security 
   concern for those layer 3 VPN types where the service provider is 
   involved with the routing within the VPN (i.e. VR, BGP-MPLS, routed 
   version of IPsec).  A breach in the route separation can reveal 
   topology and addressing information about a PPVPN.  It can also 
   cause black hole routing or unauthorized data plane cross-
   connection between PPVPNs. 
4.2.7.  Attacks on Address Space Separation 
   In Layer 3 VPNs, the IP address spaces of different VPNs need to be 
   kept separate.  In Layer 2 VPNs, the MAC address and VLAN spaces of 
   different VPNs need to be kept separate. A control plane breach in 
   this addressing separation may result in unauthorized data plane 
   cross-connection between VPNs. 
4.2.8.  Other Attacks on PPVPN Control Traffic 
   Besides routing and management protocols (covered separately in the 
   previous sections) a number of other control protocols may be 
   directly involved in delivering the PPVPN service (e.g. for 
   membership discovery and tunnel establishment in various PPVPN 
   approaches).  These include but may not be limited to: 
    - MPLS signaling (LDP, RSVP-TE) 
    - IPsec signaling (IKE) 
    - L2TP 
    - BGP-based membership discovery 
    - Database-based membership discovery (e.g. RADIUS-based) 
   Attacks might subvert or disrupt the activities of these protocols, 
   for example via impersonation or DOS attacks. 
5. Defensive Techniques for PPVPN Service Providers 
   The defensive techniques discussed in this document are intended to 
   describe methods by which some security threats can be addressed.  
   They are not intended as requirements for all PPVPN 
   Expires May 2005            Page 11 

   PPVPN Security framework November 2004 
   implementations.  The PPVPN provider should determine the 
   applicability of these techniques to the provider's specific 
   service offerings, and the PPVPN user may wish to assess the value 
   of these techniques to the user's VPN requirements. 
   The techniques discussed here include encryption, authentication, 
   filtering, firewalls, access control, isolation, aggregation, and 
   other techniques. 
   Nothing is ever 100% secure.  Defense therefore involves protecting 
   against those attacks that are most likely to occur and/or that 
   have the most dire consequences if successful.  For those attacks 
   that are protected against, absolute protection is seldom 
   achievable; more often it is sufficient just to make the cost of a 
   successful attack greater than what the adversary will be willing 
   to expend. 
   Successfully defending against an attack does not necessarily mean 
   the attack must be prevented from happening or from reaching its 
   target.  In many cases the network can instead be designed to 
   withstand the attack.  For example, the introduction of non-
   authentic packets could be defended against by preventing their 
   introduction in the first place, or by making it possible to 
   identify and eliminate them before delivery to the PPVPN user's 
   system.  The latter is frequently a much easier task. 
5.1.    Cryptographic techniques 
   PPVPN defenses against a wide variety of attacks can be enhanced by 
   the proper application of cryptographic techniques.  These are the 
   same cryptographic techniques which are applicable to general 
   network communications.  In general, these techniques can provide 
   confidentiality(encryption) of communication between devices, 
   authentication of the identities of the devices, and can ensure 
   that it will be detected if the data being communicated is changed 
   during transit. 
   Privacy is a key part (the middle name!) of any Virtual Private 
   Network.  In a PPVPN, privacy can be provided by two mechanisms: 
   traffic separation and encryption.  In this section we focus on 
   encryption, while traffic separation is addressed separately. 
   Several aspects of authentication are addressed in some detail in a 
   separate "Authentication" section. 
   Encryption adds complexity to a service, and thus it may not be a 
   standard offering within every PPVPN service. There are a few 
   reasons why encryption may not be a standard offering within every 
   PPVPN service. Encryption adds an additional computational burden 
   to the devices performing encryption and decryption.  This may 
   reduce the number of user VPN connections which can be handled on a 
   Expires May 2005            Page 12 

   PPVPN Security framework November 2004 
   device or otherwise reduce the capacity of the device, potentially 
   driving up the provider's costs.  Typically, configuring encryption 
   services on devices adds to the complexity of the device 
   configuration and adds incremental labor cost.  Packet lengths are 
   typically increased when the packets are encrypted, increasing the 
   network traffic load and adding to the likelihood of packet 
   fragmentation with its increased overhead.  (This packet length 
   increase can often be mitigated to some extent by data compression 
   techniques, but at the expense of additional computational burden.) 
   Finally, some PPVPN providers may employ enough other defensive 
   techniques, such as physical isolation or filtering/firewall 
   techniques, that they may not perceive additional benefit from 
   encryption techniques. 
   The trust model among the PPVPN user, the PPVPN provider, and other 
   parts of the network is a key element in determining the 
   applicability of encryption for any specific PPVPN implementation. 
   In particular, it determines where encryption should be applied: 
   -  If the data path between the user's site and the provider's PE 
      is not trusted, then encryption may be used on the PE-CE link. 
   -  If some part of the backbone network is not trusted, 
      particularly in implementations where traffic may travel across 
      the Internet or multiple provider networks, then the PE-PE 
      traffic may 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 at a location which is not a PPVPN customer location (for 
      example, access by a traveler) there may be a requirement for 
      encrypting the traffic between that system and an access point 
      on the PPVPN or at a customer site. If the PPVPN provider 
      provides the access point, then the customer must cooperate with 
      the provider to handle the access control services for the 
      remote users. These access control services are usually 
      implemented using encryption, as well. 
   Although CE-CE encryption provides 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, bypass encryption processing altogether, or 
   provide some means of sniffing or diverting unencrypted traffic. 
   Thus a PPVPN implementation using CE-CE encryption needs to 
   consider the trust relationship between the PPVPN user and 
   provider. PPVPN users and providers may wish to negotiate a service 
   level agreement (SLA) for CE-CE encryption which will provide an 
   acceptable demarcation of responsibilities for management of 
   encryption on the CE devices. The demarcation may also be affected 
   Expires May 2005            Page 13 

   PPVPN Security framework November 2004 
   by the capabilities of the CE devices. For example, the CE might 
   support some partitioning of management, a configuration lock-down 
   ability, or allow both parties to verify the configuration. In 
   general, the PPVPN user needs to have a fairly high level of trust 
   that the PPVPN provider will properly provision and manage the CE 
   devices, if the managed CE-CE model is used. 

5.1.1.  IPsec in PPVPNs 
   IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the 
   security protocol of choice for encryption at the IP layer (Layer 
   3), as discussed in [SECMECH].  IPsec provides robust security for 
   IP traffic between pairs of devices.  Non-IP traffic must be 
   converted to IP packets or it cannot be transported over IPsec.  
   Encapsulation is a common conversion method. 
   In the PPVPN model, IPsec can be employed to protect IP traffic 
   between PEs, between a PE and a CE, or from CE to CE.  CE-to-CE 
   IPsec may be employed in either a provider-provisioned or a user-
   provisioned model.  The user-provisioned CE-CE IPsec model is 
   outside the scope of this document, and outside the scope of the 
   PPVPN Working Group.  Likewise, encryption of data which is 
   performed within the user's site is outside the scope of this 
   document, since it is simply handled as user data by the PPVPN. 
   IPsec can also be used to protect IP traffic between a remote user 
   who is not located at a PPVPN site and the PPVPN. 
   IPsec does not itself specify an encryption algorithm.  It can use 
   a variety of encryption algorithms, with various key lengths, 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 analyzing the 
   specific encryption techniques used in the PPVPN service. 
   For many of the PPVPN provider's network control messages and some 
   PPVPN user requirements, cryptographic authentication of messages 
   Expires May 2005            Page 14 

   PPVPN Security framework November 2004 
   without encryption of the contents of the message may provide 
   acceptable security.  Using IPsec, authentication of messages is 
   provided by the Authentication Header (AH) or through the use of 
   the Encapsulating Security Protocol (ESP) with authentication only.  
   Where control messages require authentication but do not use IPsec, 
   then other cryptographic authentication methods are available.  
   Message authentication methods currently considered to be secure 
   are based on hashed message authentication codes (HMAC) [RFC2104] 
   implemented with a secure hash algorithm such as Secure Hash 
   Algorithm 1 (SHA-1) [RFC3174]. 
   One recommended mechanism to provide 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) [RFC-3602], as the IPsec ESP. 
   PPVPNs which provide differentiated services based on traffic type 
   may encounter some conflicts with IPsec encryption of traffic.  
   Since encryption hides the content of the packets, it may not be 
   possible to differentiate the encrypted traffic in the same manner 
   as unencrypted traffic.  Although DiffServ markings are copied to 
   the IPsec header and can provide some differentiation, not all 
   traffic types can be accommodated by this mechanism. 

5.1.2.  Encryption for device configuration and management 
   For configuration and management of PPVPN devices, encryption and 
   authentication of the management connection at a level comparable 
   to that provided by IPsec is desirable.   
   Several methods of transporting PPVPN device management traffic 
   offer security and confidentiality. 
   -  Secure Shell (SSH) offers protection for TELNET [STD-8] or 
      terminal-like connections to allow device configuration. 
   -  SNMP v3 [STD62] provides encrypted and authenticated protection 
      for SNMP-managed devices. 
   -  Transport Layer Security (TLS) [RFC-2246] 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, there is extensive work proceeding in several 
      organizations (OASIS, W3C, WS-I, and others) on securing device 
      management traffic within a "Web Services" framework, using a 
      wide variety of security models, and providing support for 
      multiple security token formats, multiple trust domains, 
      multiple signature formats, and multiple encryption 

   Expires May 2005            Page 15 

   PPVPN Security framework November 2004 
   -  IPsec provides the services with security and confidentiality at 
      the network layer. With regards to device management, its 
      current use is primarily focused on in-band management of user-
      managed IPsec gateway devices. 

5.1.3.  Cryptographic techniques in Layer 2 PPVPNs 
   Layer 2 PPVPNs will generally not be able to use IPsec to provide 
   encryption throughout the entire network.  They may be able to use 
   IPsec for PE-PE traffic where it is encapsulated in IP packets, but 
   IPsec will generally not be applicable for CE-PE traffic in Layer 2 
   Encryption techniques for Layer 2 links are widely available, but 
   are not within the scope of this document, nor of IETF documents in 
   general.  Layer 2 encryption could be applied to the links from CE 
   to PE, or could be applied from CE to CE, as long as the encrypted 
   Layer 2 packets can be properly handled by the intervening PE 
   devices.  In addition, the upper layer traffic transported by the 
   Layer 2 VPN can be encrypted by the user.  In this case 
   confidentiality  will be maintained; however, this is transparent 
   to the PPVPN provider and is outside the scope of this document. 
5.1.4.  End-to-end vs. hop-by-hop encryption tradeoffs in PPVPNs 
   In PPVPNs, encryption could potentially be applied to the VPN 
   traffic at several different places.  This section discusses some 
   of the tradeoffs in implementing encryption in several different 
   connection topologies among different devices within a PPVPN. 
   Encryption typically involves a pair of devices which encrypt the 
   traffic passing between them.  The devices may be directly 
   connected (over a single "hop"), or there may be intervening 
   devices which transport the encrypted traffic between the pair of 
   devices.  The extreme cases involve using encryption between every 
   adjacent pair of devices along a given path (hop-by-hop), or using 
   encryption only between the end devices along a given path (end-to-
   end).  To keep this discussion within the scope of PPVPNs, the 
   latter ("end-to-end") case considered here is CE-to-CE rather than 
   fully end-to-end. 
   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 which might 
   be present along the path between two sites in a single VPN, 
   operated by a single service provider (SP). 
   Expires May 2005            Page 16 

   PPVPN Security framework November 2004 
   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 
   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 above can also be combined, with 
   encryption running from CE to PE, then PE to PE, then PE to CE. 
   Among the four feasible configurations, key tradeoffs in 
   considering encryption include: 
   - Vulnerability to link eavesdropping - assuming 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 the 
   number of sites per VPN customer as Nce and the number of PEs 
   participating in a given VPN as Npe, how many device configurations 
   need to be created or maintained, and how do those configurations 
   - 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? 
   Expires May 2005            Page 17 

   PPVPN Security framework November 2004 
   These tradeoffs are discussed for each configuration, below: 
   1) Site-to-site (CE-to-CE) 
   Link eavesdropping  - protected on all links 
   Device compromise - vulnerable to CE compromise 
   Complexity - single administration, responsible for one device per 
        site (Nce devices), but overall configuration per VPN scales as 
   Processing load - on each of two CEs, each packet is either 
        encrypted or decrypted (2P) 
   Enhanced services - severely limited; typically only Diffserv 
        markings are visible to SP, allowing some QoS services 
   2) Provider edge-to-edge (PE-to-PE) 
   Link eavesdropping  - vulnerable on CE-PE links; protected on SP's 
        network links 
   Device compromise - vulnerable to CE or PE compromise 
   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 
   Processing load - on each of two PEs, each packet is either 
        encrypted or decrypted (2P) 
   Enhanced services - full; SP can apply any enhancements based on 
        detailed view of traffic 
   3) Access link (CE-to-PE) 
   Link eavesdropping  - protected on CE-PE link; vulnerable on SP's 
        network links 
   Device compromise - vulnerable to CE or PE compromise 
   Complexity - two administrations (customer and SP) with device 
        configuration on each side (Nce + Npe devices to configure) but 
        since there is no mesh the overall configuration scales as Nce. 
   Processing load - on each of two CEs, each packet is either 
        encrypted or decrypted, plus on each of two PEs, each packet is 
        either encrypted or decrypted (4P) 
   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) 
   Link eavesdropping  - protected on all links 
   Device compromise - vulnerable to CE or PE compromise 
   Complexity - two administrations (customer and SP) with device 
        configuration on each side (Nce + Npe devices to configure).  
   Expires May 2005            Page 18 

   PPVPN Security framework November 2004 
        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. 
   Processing load - on each of two CEs, each packet is either 
        encrypted or decrypted, plus on each of two PEs, each packet is 
        both encrypted and decrypted (6P) 
   Enhanced services - full; SP can apply any enhancements based on 
        detailed view of traffic 
   Given the tradeoffs discussed above, a few conclusions can be made: 
   - Configurations 2 and 3 are subsets of 4 that may be appropriate 
   alternatives to 4 under certain threat models; the remainder of 
   these conclusions compare 1 (CE-to-CE) vs. 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 option 1 and option 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 directly communicating. Option 4 requires configuring keys 
   on both CE and PE devices, but may 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 this comes at the cost of 
   enhanced services and at the cost of operational complexity due to 
   the Order(n**2) scaling of a larger mesh.   
   Expires May 2005            Page 19 

   PPVPN Security framework November 2004 
   This analysis of site-to-site vs. hop-by-hop encryption tradeoffs 
   does not explicitly include cases of multiple providers cooperating 
   to provide a PPVPN service, public Internet VPN connectivity, or 
   remote access VPN service, but many of the tradeoffs will be 
5.2.    Authentication 
   In order to prevent security issues from some Denial-of-Service 
   attacks or from malicious misconfiguration, it is critical that 
   devices in the PPVPN should only accept connections or control 
   messages from valid sources.  Authentication refers to methods to 
   ensure that message sources are properly identified by the PPVPN 
   devices with which they communicate.  This section focuses on 
   identifying the scenarios in which sender authentication is 
   required, and recommends authentication mechanisms for these 
   Cryptographic techniques (authentication and encryption) do not 
   protect against some types of denial of service attacks, 
   specifically resource exhaustion attacks based on CPU or bandwidth 
   exhaustion. In fact, the processing required to decrypt and/or 
   check authentication may in some cases increase the effect of these 
   resource exhaustion attacks. Cryptographic techniques may however, 
   be useful against resource exhaustion attacks based on exhaustion 
   of state information (e.g., TCP SYN attacks). 

5.2.1.  VPN Member Authentication 
   This category includes techniques for the CEs to verify they are 
   connected to the expected VPN.  It includes techniques for CE-PE 
   authentication, to verify that each specific CE and PE is actually 
   communicating with its expected peer. 

5.2.2.  Management System Authentication 
   Management system authentication includes the authentication of a 
   PE to a centrally-managed directory server, when directory-based 
   "auto-discovery" is used.  It also includes authentication of a CE 
   to its PPVPN configuration server, when a configuration server 
   system is used. 

5.2.3.  Peer-to-peer Authentication 
   Peer-to-peer authentication includes peer authentication for 
   network control protocols (e.g. LDP, BGP, etc.), and other peer 
   authentication (i.e. authentication of one IPsec security gateway 
   by another). 

   Expires May 2005            Page 20 

   PPVPN Security framework November 2004 
5.2.4.  Authenticating Remote Access VPN members 
   This section describes methods for authentication of remote access 
   users connecting to a VPN. 
   Effective authentication of individual connections is a key 
   requirement for enabling remote access to a PPVPN from an arbitrary 
   Internet address (for instance, by a traveler).  
   There are several widely used standards-based protocols to support 
   remote access authentication.  These include RADIUS [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 several 
   possible locations in the network. The user-managed case is of 
   limited interest within the PPVPN security framework, and is not 
   considered at this time.  
   When a PPVPN provider manages authentication at the remote access 
   gateway, this implies that authentication databases, which are 
   usually extremely confidential user-managed systems, will need to 
   be referenced in a secure manner by the PPVPN provider. This can be 
   accomplished by the use of proxy authentication services, which 
   accept an encrypted authentication credential from the remote 
   access user, pass it to the PPVPN user's authentication system, and 
   receive a yes/no response as to whether the user has been 
   authenticated.  Thus the PPVPN provider does not have access to the 
   actual authentication database, but can use it on behalf of the 
   PPVPN user to provide remote access authentication. 
   Specific cryptographic techniques for handling authentication are 
   described in the following sections. 

5.2.5.  Cryptographic techniques for authenticating identity 
   Cryptographic techniques offer several mechanisms for 
   authenticating the identity of devices or individuals. These 
   include the use of shared secret keys, one-time keys generated by 
   accessory devices or software, user-ID and password pairs, and a 
   range of public-private key systems. Another approach is to use a 
   hierarchical Certificate Authority system to provide digital 
   Expires May 2005            Page 21 

   PPVPN Security framework November 2004 
   This section describes or provides references to the specific 
   cryptographic approaches for authenticating identity.  These 
   approaches provide secure mechanisms for most of the authentication 
   scenarios required in operating a PPVPN. 
5.3.    Access Control techniques 
   Access control techniques include packet-by-packet or packet-flow-
   by-packet-flow access control by means of filters and firewalls, as 
   well as by means of admitting a "session" for a 
   control/signaling/management protocol that is being used to 
   implement PPVPNs. Enforcement of access control by isolated 
   infrastructure addresses is discussed in another section of this 
   In this document, we distinguish between filtering and firewalls 
   based primarily on the direction of traffic flow.  We define 
   filtering as being applicable to unidirectional traffic, while a 
   firewall can analyze and control both sides of a conversation.   
   There are two significant corollaries of this definition: 
   - Routing or traffic flow symmetry: A firewall typically requires 
   routing symmetry, which is usually enforced by locating a firewall 
   where the network topology assures that both sides of a 
   conversation will pass through the firewall.  A filter can operate 
   upon traffic flowing in one direction, without considering traffic 
   in the reverse direction. 
   - Statefulness: Since it receives both sides of a conversation, a 
   firewall may be able to interpret a significant amount of 
   information concerning the state of that conversation, and use this 
   information to control access.  A filter can maintain some limited 
   state information on a unidirectional flow of packets, but cannot 
   determine the state of the bi-directional conversation as precisely 
   as a firewall. 
5.3.1.  Filtering 
   It is relatively common for routers to filter data packets. That 
   is, routers can look for particular values in certain fields of the 
   IP or higher level (e.g., TCP or UDP) headers. Packets which match 
   the criteria associated with a particular filter may either be 
   discarded or given special treatment.  
   In discussing filters, it is useful to separate the Filter 
   Characteristics which may be used to determine whether a packet 
   matches a filter from the Packet Actions which are applied to those 
   packets which match a particular filter.  
   o Filter Characteristics 

   Expires May 2005            Page 22 

   PPVPN Security framework November 2004 
   Filter characteristics are used to determine whether a particular 
   packet or set of packets matches a particular filter.  
   In many cases filter characteristics may be stateless. A stateless 
   filter is one which determines whether a particular packet matches 
   a filter based solely on the filter definition, normal forwarding 
   information (such as the next hop for a packet), and the 
   characteristics of that individual packet. Typically stateless 
   filters may consider the incoming and outgoing logical or physical 
   interface, information in the IP header, and information in higher 
   layer headers such as the TCP or UDP header. Information in the IP 
   header to be considered may for example include source and 
   destination IP address, Protocol field, Fragment Offset, and TOS 
   field. Filters also may consider fields in the TCP or UDP header 
   such as the Port fields as well as the SYN field in the TCP header.  
   Stateful filtering maintains packet-specific state information, to 
   aid in determining whether a filter has been met. For example, a 
   device might apply stateless filters to the first fragment of a 
   fragmented IP packet. If the filter matches, then the data unit ID 
   may be remembered and other fragments of the same packet may then 
   be considered to match the same filter. Stateful filtering is more 
   commonly done in firewalls, although firewall technology may be 
   added to routers. 
   o Actions based on Filter Results 
   If a packet, or a series of packets, match a specific filter, then 
   there are a variety of actions which may be taken based on that 
   filter match. Examples of such actions include: 
     - Discard 
   In many cases filters may be set to catch certain undesirable 
   packets. Examples may include packets with forged or invalid source 
   addresses, packets which are part of a DOS or DDOS attack, or 
   packets which are trying to access resources which are not 
   permitted (such as network management packets from an unauthorized 
   source). Where such filters are activated, it is common to silently 
   discard the packet or set of packets matching the filter. The 
   discarded packets may of course also be counted and/or logged.  
     - Set CoS 
   A filter may be used to set the Class of Service associated with 
   the packet.  
     - Count packets and/or bytes 
     - Rate Limit 
   Expires May 2005            Page 23 

   PPVPN Security framework November 2004 
   In some cases the set of packets which match a particular filter 
   may be limited to a specified bandwidth. In this case packets 
   and/or bytes would be counted, and would be forwarded normally up 
   to the specified limit. Excess packets may be discarded, or may be 
   marked (for example by setting a "discard eligible" bit in the IP 
   ToS field or the MPLS EXP field).  
     - Forward and Copy 
   It is useful in some cases to forward some set of packets normally, 
   but to also send a copy to a specified other address or interface. 
   For example, this may be used to implement a lawful intercept 
   capability, or to feed selected packets to an Intrusion Detection 
   o Other Issues related to Use of Packet Filters 
   There may be a very wide variation in the performance impact of 
   filtering. This may occur both due to differences between 
   implementations, and also due to differences between types or 
   numbers of filters deployed. For filtering to be useful, the 
   performance of the equipment has to be acceptable in the presence 
   of filters.  
   The precise definition of "acceptable" may vary from service 
   provider to service provider, and may depend upon the intended use 
   of the filters. For example, for some uses a filter may be turned 
   on all the time in order to set CoS, to prevent an attack, or to 
   mitigate the effect of a possible future attack. In this case it is 
   likely that the service provider will want the filter to have 
   minimal or no impact on performance. In other cases, a filter may 
   be turned on only in response to a major attack (such as a major 
   DDOS attack). In this case a greater performance impact may be 
   acceptable to some service providers.  
   A key consideration with the use of packet filters is that they can 
   provide few options for filtering packets carrying encrypted data.  
   Since the data itself is not accessible, only packet header 
   information or other unencrypted fields can be used for filtering. 
5.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. 
   Expires May 2005            Page 24 

   PPVPN Security framework November 2004 
   As with other access control techniques, the value of firewalls 
   depends on a clear understanding of the topologies of the PPVPN 
   core network, the user networks, and the threat model.  Their 
   effectiveness depends on a topology with a clearly defined inside 
   (secure) and outside (not secure). 
   Within the PPVPN framework, traffic typically is not allowed to 
   pass between the various user VPNs.  This inter-VPN isolation is 
   usually not performed by a firewall, but is a part of the basic VPN 
   mechanism.  An exception to the total isolation of VPNs is the case 
   of "extranets", which allow specific external access to a user's 
   VPN, potentially from another VPN.  Firewalls can be used to 
   provide the services required for secure extranet implementation. 
   In a PPVPN, firewalls can be applied between the public Internet 
   and user VPNs, in cases where Internet access services are offered 
   by the provider to the VPN user sites.  In addition, firewalls may 
   be applied between VPN user sites and any shared network-based 
   services offered by the PPVPN provider.   
   Firewalls may be applied to help protect PPVPN core network 
   functions from attacks originating from the Internet or from PPVPN 
   user sites, but typically other defensive techniques will be used 
   for this purpose. 
   Where firewalls are employed as a service to protect user VPN sites 
   from the Internet, different VPN users, and even different sites of 
   a single VPN user, may have varying firewall requirements.  The 
   overall PPVPN logical and physical topology, along with the 
   capabilities of the devices implementing the firewall services, 
   will have a significant effect on the feasibility and manageability 
   of such varied firewall service offerings. 
   Another consideration with the use of firewalls is that they can 
   provide few options for handling packets carrying encrypted data.  
   Since 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. 
5.3.3.  Access Control to management interfaces 
   Most of the security issues related to management interfaces can be 
   addressed through the use of authentication techniques as described 
   in the section on authentication.  However, additional security may 
   be provided by controlling access to management interfaces in other 
   Management interfaces, especially console ports on PPVPN devices, 
   may be configured so they are only accessible out-of-band, through 
   Expires May 2005            Page 25 

   PPVPN Security framework November 2004 
   a system which is physically and/or logically separated from the 
   rest of the PPVPN infrastructure. 
   Where management interfaces are accessible in-band within the PPVPN 
   domain, filtering or firewalling techniques can be used to restrict 
   unauthorized in-band traffic from having access to management 
   interfaces.  Depending on device capabilities, these filtering or 
   firewalling techniques can be configured either on other devices 
   through which the traffic might pass, or on the individual PPVPN 
   devices themselves. 
5.4.    Use of Isolated Infrastructure 
   One way to protect the infrastructure used for support of VPNs is 
   to separate the resources for support of VPNs from the resources 
   used for other purposes (such as support of Internet services). In 
   some cases this may make use of physically separate equipment for 
   VPN services, or even a physically separate network.  
   For example, PE-based L3 VPNs may be run on a separate backbone not 
   connected to the Internet, or may make use of separate edge routers 
   from those used to support Internet service. Private IP addresses 
   (local to the provider and non-routable over the Internet) are 
   sometimes used to provide additional separation. 
   It is common for CE-based L3VPNs to make use of CE devices which 
   are dedicated to one specific VPN. In many or most cases CE-based 
   VPNs may make use of normal Internet services to interconnect CE 
5.5.    Use of Aggregated Infrastructure 
   In general it is not feasible to use a completely separate set of 
   resources for support of each VPN. In fact, one of the main reasons 
   for VPN services is to allow sharing of resources between multiple 
   users, including multiple VPNs. Thus even if VPN services make use 
   of a separate network from Internet services, nonetheless there 
   will still be multiple VPN users sharing the same network 
   resources. In some cases VPN services will share the use of network 
   resources with Internet services or other services.  
   It is therefore important for VPN services to provide protection 
   between resource utilization by different VPNs. Thus a well-behaved 
   VPN user should be protected from possible misbehavior by other 
   VPNs. This requires that limits are placed on the amount of 
   resources which can be used by any one VPN. For example, both 
   control traffic and user data traffic may be rate limited. In some 
   cases or in some parts of the network where a sufficiently large 
   number of queues are available each VPN (and optionally each VPN 
   and CoS within the VPN) may make use of a separate queue. Control-

   Expires May 2005            Page 26 

   PPVPN Security framework November 2004 
   plane resources such as link bandwidth as well as CPU and memory 
   resources may be reserved on a per-VPN basis.  
   The techniques which are used to provision resource protection 
   between multiple VPNs served by the same infrastructure can also be 
   used to protect VPN services from Internet services.  
   In general the use of aggregated infrastructure allows the service 
   provider to benefit from stochastic multiplexing of multiple bursty 
   flows, and also may in some cases thwart traffic pattern analysis 
   by combining the data from multiple VPNs.  
5.6.    Service Provider Quality Control Processes 
   Deployment of provider-provisioned VPN services in general requires 
   a relatively large amount of configuration by the service provider. 
   For example, the service provider needs to configure which VPN each 
   site belongs to, as well as QoS and SLA guarantees. This large 
   amount of required configuration leads to the possibility of 
   It is important for the service provider to have operational 
   processes in place to reduce the potential impact of 
   misconfiguration. CE to CE authentication may also be used to 
   detect misconfiguration when it occurs.  
5.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. 
6. Monitoring, Detection, and Reporting of Security Attacks 
   A PPVPN service may be subject to attacks from a variety of 
   security threats.  Many threats are described in another part of 
   this document.  Many of the defensive techniques described in this 
   document and elsewhere provide significant levels of protection 
   from a variety of threats.  However, in addition to silently 
   employing defensive techniques to protect against attacks, PPVPN 
   services can also add value for both providers and customers by 
   implementing security monitoring systems which detect and report on 
   any security attacks which occur, regardless of whether the attacks 
   are effective. 
   Attackers often begin by probing and analyzing defenses, so systems 
   which can detect and properly report these early stages of attacks 
   can provide significant benefits. 
   Expires May 2005            Page 27 

   PPVPN Security framework November 2004 
   Information concerning attack incidents, especially if available 
   quickly, can be useful in defending against further attacks.  It 
   can be used to help identify attackers and/or their specific 
   targets at an early stage.  This knowledge about attackers and 
   targets can be used to further strengthen defenses against specific 
   attacks or attackers, or improve the defensive services for 
   specific targets on an as-needed basis.  Information collected on 
   attacks may also be useful in identifying and developing defenses 
   against novel attack types. 
   Monitoring systems used to detect security attacks in PPVPNs will 
   typically operate by collecting information from the Provider Edge 
   (PE), Customer Edge (CE), and/or Provider backbone (P) devices.  
   Security monitoring systems should have the ability to actively 
   retrieve information from devices (e.g., SNMP get) or to passively 
   receive reports from devices (e.g., SNMP  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 allowing each attack event to trigger a separate 
   message, which might result in a flood of messages, essentially 
   becoming a denial-of-service attack against the monitoring system 
   or the network. 
   The mechanisms for reporting security attacks should be flexible 
   enough to meet the needs of VPN service providers, VPN customers, 
   and regulatory agencies, if applicable.  The specific reports will 
   depend on the capabilities of the devices, the security monitoring 
   system, the type of VPN, and the service level agreements between 
   the provider and customer. 
7. User Security Requirements 
   This section defines a list of security related requirements that 
   the users of PPVPN services may have for their PPVPN service. 
   Typically, these user requirements translate into requirement for 
   the provider in offering the service.   
   The following sections detail various requirements that ensure the 
   security of a given trusted zone. Since in real life there are 
   various levels of security, a PPVPN may fulfill any number or all 
   of these security requirements. Specifically this document does not 
   Expires May 2005            Page 28 

   PPVPN Security framework November 2004 
   state that a PPVPN must fulfill all of these requirements to be 
   secure. As mentioned in the Introduction, it is not within the 
   scope of this document to define the specific requirements that 
   each VPN technology must fulfill in order to be secure.  
7.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:  
7.1.1.  Address Separation 
     A given PPVPN can use the full Internet address range, 
     including private address ranges [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, a NAT functionality may be needed. 
   In layer 2 VPNs the same requirement exists for the layer 2 
   addressing schemes, such as MAC addresses. 
7.1.2.  Routing Separation 
   A PPVPN core must maintain routing separation between the trusted 
   zones. This means that routing information must not leak from any 
   trusted zone to any other trusted zone, unless this is specifically 
   engineered this way, for example for Internet access.  
   In layer 2 VPNs the switching information must be kept separate 
   between the trusted zones, such that switching information of one 
   PPVPN does not influence other PPVPNs or the PPVPN core. 
7.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. 
7.2.    Protection 
   The perception is that  a completely separated "private" network 
   has defined entry points, and is only subject to attack or 
   intrusion over those entry points. 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 

   Expires May 2005            Page 29 

   PPVPN Security framework November 2004 
   services is that they offer the same level of protection as private 
7.2.1.  Protection against intrusion 
   An intrusion is defined here as the penetration of a trusted zone 
   from outside this zone. This could be from the Internet, another 
   PPVPN, or the core network itself.  
   The fact that a network is "virtual" must not expose it to 
   additional threats over private networks. Specifically, it must not 
   add new interfaces to other parts outside the trusted zone. 
   Intrusions from known interfaces such as Internet gateways are 
   outside the scope of this document. 
7.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 private.  
7.2.3.  Protection against spoofing 
   It is not possible to change the sender identification (source 
   address, source label, etc) of traffic in transit, such that by 
   this spoofing the integrity of a PPVPN gets violated. For example, 
   if two CEs are connected to the same PE, it must not be possible 
   for one CE to send crafted packets that make the PE believe those 
   packets are coming from the other CE, thus inserting them into the 
   wrong PPVPN. 
7.3.    Confidentiality 
   This requirement means that data must be cryptographically secured 
   in transit over the PPVPN core network to avoid eavesdropping. 
7.4.    CE Authentication 
   Where CE authentication is provided it is not possible for an 
   outsider to install a CE and pretend to belong to a specific PPVPN, 
   to which this CE does not belong in reality. 
7.5.    Integrity 

   Expires May 2005            Page 30 

   PPVPN Security framework November 2004 
   Data in transit must be secured in a manner such that it cannot be 
   altered, or that any alteration may be detected at the receiver. 
7.6.    Anti-Replay 
   Anti-replay means that data in transit cannot be recorded and 
   replayed later. To protect against anti-replay attacks the data 
   must be cryptographically secured. 
   Note: Even private networks do not necessarily meet the 
   requirements of confidentiality, integrity and anti-reply. Thus 
   when comparing private to "virtually private" PPVPN services these 
   requirements are only applicable if the comparable private service 
   also included these services. However, the fact that VPNs operate 
   over a shared infrastructure may make some of these requirements 
   more important in a VPN environment when compared with a private 
   network environment. 
8. 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 users with different levels of 
   offered security. Therefore, a PPVPN service provider may fulfill 
   any number of the security requirements listed in this section. 
   This document does not state that a PPVPN must fulfill all of these 
   requirements to be secure.   
   These requirements are focused on: 1) how to protect the PPVPN core 
   from various attacks outside the core including PPVPN users and 
   non-PPVPN alike, both accidentally and maliciously, 2) how to 
   protect the PPVPN user VPNs and sites themselves. Note that a PPVPN 
   core is not more vulnerable against attacks than a core that does 
   not provide PPVPNs. However providing PPVPN services over such a 
   core may need lead to additional security requirements, for the 
   mere fact that most users are expecting higher security standards 
   in a core delivering PPVPN services. 
8.1.    Protection within the Core Network 
8.1.1.  Control Plane Protection 
   - Protocol authentication within the core:  
   Expires May 2005            Page 31 

   PPVPN Security framework November 2004 
   PPVPN technologies and infrastructure must support mechanisms for 
   authentication of the control plane. For an IP core, IGP and BGP 
   sessions may be authenticated by using TCP MD5 or IPsec. If an MPLS 
   core is used, LDP sessions may be authenticated by use TCP MD5, in 
   addition, IGP and BGP authentication should also be considered. For 
   a core providing Layer 2 services, PE to PE authentication may also 
   be used via IPsec. 
   With the cost of authentication coming down rapidly, the 
   application of control plane authentication may not increase the 
   cost of implementation for providers significantly, and will help 
   to improve the security of the core. If the core is dedicated to 
   VPN services and without any interconnects to third parties then 
   this may reduce the requirement for authentication of the core 
   control plane. 
   - Elements protection 
   Here we discuss means to hide the provider's infrastructure nodes.  
   A PPVPN provider may make the infrastructure routers (P and PE 
   routers) unreachable from outside users and unauthorized internal 
   users. For example, separate address space may be used for the 
   infrastructure loopbacks.  
   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 from being 
   exposed through trace route, however this must also be assessed 
   against operational requirements for end to end fault tracing.  
   An Internet backbone core may be re-engineered to make Internet 
   routing an edge function, for example, using MPLS label switching 
   for all traffic within the core and possibly make the Internet a 
   VPN within the PPVPN core itself. This helps to detach Internet 
   access from PPVPN services. 
   Separating control plane, data plane, and management plane 
   functionality in terms of hardware and software may be implemented 
   on the PE devices to improve security. This may help to limit the 
   problems when attacked in one particular area, and may allow each 
   plane to implement additional security measurement separately. 
   PEs are often more vulnerable to attack than P routers, since PEs 
   cannot be made unreachable to outside users by their very nature. 
   Access to core trunk resources can be controlled on a per user 
   basis by the application of inbound rate-limiting/shaping, this can 
   be further enhanced on a per Class of Service basis (see section 
   Expires May 2005            Page 32 

   PPVPN Security framework November 2004 
   In the PE, using separate routing processes for Internet and PPVPN 
   service may help to improve the PPVPN security and better protect 
   VPN customers. Furthermore, if the resources, such as CPU and 
   Memory, may be further separated based on applications, or even 
   individual VPNs, it may help to provide improved security and 
   reliability to individual VPN customers. 
   Many of these were not particular issues when an IP core was 
   designed to support Internet services only. When providing PPVPN 
   services, new requirements are introduced to satisfy the security 
   needs for VPN services. Similar consideration apply to L2 VPN 
8.1.2.  Data Plane Protection 
   PPVPN using IPsec technologies provide VPN users with encryption of 
   secure user data. 
   In today's MPLS, ATM, or Frame Relay networks, encryption is not 
   provided as a basic feature. Mechanisms can be used to secure the 
   MPLS data plane to secure the data carried over MPLS core. 
   Additionally, if the core is dedicated to VPN services and without 
   any external interconnects to third party networks then there is no 
   obvious need for encryption of the user data plane.  
   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.  
8.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 
   Expires May 2005            Page 33 

   PPVPN Security framework November 2004 
   Services, especially when supporting VPN and Internet Services on 
   the same physical interfaces through different logical interfaces. 
   8.2.1 Link Authentication 
   Authentication mechanisms can be employed to validate site access 
   to the PPVPN network via fixed or logical (e.g. L2TP, IPsec) 
   connections. Where the user wishes to hold the 'secret' associated 
   to acceptance of the access and site into the VPN, then PPVPN based 
   solutions require the flexibility for either direct authentication 
   by the PE itself or interaction with a customer PPVPN 
   authentication server. Mechanisms are required in the latter case 
   to ensure that the interaction between the PE and the customer 
   authentication server is controlled e.g. limiting it simply to an 
   exchange in relation to the authentication phase and with other 
   attributes e.g. RADIUS optionally being filtered. 
   8.2.2 Access Routing 
   Mechanisms may be used to provide control at a routing protocol 
   level e.g. RIP, OSPF, BGP between the CE and PE. Per neighbor and 
   per VPN routing policies may be established to enhance security and 
   reduce the impact of a malicious or non-malicious attack on the PE, 
   in particular the following mechanisms should be considered: 
    - Limiting the number of prefixes that may be advertised on a per 
       access basis into the PE. Appropriate action may be taken should 
       a limit be exceeded e.g. the PE shutting down the peer session 
       to the CE  
    - Applying route dampening at the PE on received routing updates 
    - Definition of a per VPN prefix limit after which additional 
       prefixes will not be added to the VPN routing table. 
   In the case of Inter-provider connection, access protection, link 
   authentication, and routing policies as described above may be 
   applied. Both inbound and outbound firewall/filtering mechanism 
   between ASes may be applied. Proper security procedures must be 
   implemented in Inter-provider VPN interconnection to protect the 
   providers' network infrastructure and their customer VPNs. This may 
   be custom designed for each Inter-Provider VPN peering connection, 
   and must be agreed by both providers. 
   8.2.3 Access QoS 
   PPVPN providers offering QoS enabled services require mechanisms to 
   ensure that individual accesses are validated against their 
   subscribed QOS profile and as such gain access to core resources 
   that match their service profile.  Mechanisms such as per Class of 
   service rate limiting/traffic shaping on ingress to the PPVPN core 
   are one option in providing this level of control.  Such mechanisms 

   Expires May 2005            Page 34 

   PPVPN Security framework November 2004 
   may require the per Class of Service profile to be enforced either 
   by marking, remarking or discard of traffic outside of profile. 
   8.2.4 Customer VPN monitoring tools  
   End users requiring visibility of VPN specific statistics on the 
   core e.g. routing table, interface status, QoS statistics, impose 
   requirements for mechanisms at the PE to both validate the incoming 
   user and limit the views available to that particular users VPN.  
   Mechanisms should also be considered to ensure that such access 
   cannot be used a means of a DOS attack (either malicious or 
   accidental) on the PE itself. This could be accomplished through 
   either separation of these resources within the PE itself or via 
   the capability to rate-limit on a per VPN basis such traffic. 
8.3.    General Requirements for PPVPN Providers 
   The PPVPN providers must support the users' security requirements 
   as listed in Section 7. 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 
   - Access Authentication 
   - Techniques highlighted through this document identify 
      methodologies for the protection of PPVPN resources and 
   Equipment hardware/software bugs leading to breaches in security 
   are not within the scope of this document. 
9. Security Evaluation of PPVPN Technologies 
   This section presents a brief template that may be used to evaluate 
   and summarize how a given PPVPN approach (solution) measures up 
   against the PPVPN Security Framework.  An evaluation of a given 
   PPVPN approach using this template should appear in the 
   applicability statement for each PPVPN approach. 
9.1.    Evaluating the Template 

   Expires May 2005            Page 35 

   PPVPN Security framework November 2004 
   The first part of the template is in the form of a list of security 
   assertions.  For each assertion the approach is assessed and one or 
   more of the following ratings is assigned: 
   - The requirement is not applicable to the VPN approach because ...  
      (fill in reason) 
   - The base VPN approach completely addresses the requirement by ...  
      (fill in technique) 
   - The base VPN approach partially addresses the requirement by ...  
      (fill in technique and extent to which it addresses the 
   - An optional extension to the VPN approach completely addresses 
      the requirement by ...  (fill in technique) 
   - An optional extension to the VPN approach partially addresses the 
      requirement by ...  (fill in technique and extent to which it 
      addresses the requirement) 
   - In the VPN approach, the requirement is addressed in a way that 
      is beyond the scope of the VPN approach.  (Explain)  (One 
      example of this would be a VPN approach in which some aspect, 
      say membership discovery, is done via configuration.  The 
      protection afforded to the configuration would be beyond the 
      scope of the VPN approach.) 
   - The VPN approach does not meet the requirement. 
9.2.    Template 
   The following assertions solicit responses of the types listed in 
   the previous section. 
   1. The approach provides complete IP address space separation for 
      each L3 VPN. 
   2. The approach provides complete L2 address space separation for 
      each L2 VPN. 
   3. The approach provides complete VLAN ID space separation for each 
      L2 VPN. 
   4. The approach provides complete IP route separation for each L3 
   5. The approach provides complete L2 forwarding separation for each 
      L2 VPN. 
   Expires May 2005            Page 36 

   PPVPN Security framework November 2004 
   6. The approach provides a means to prevent improper cross-
      connection of sites in separate VPNs. 
   7. The approach provides a means to detect improper cross-
      connection of sites in separate VPNs. 
   8. The approach protects against the introduction of unauthorized 
      packets into each VPN. 
       a. In the CE-PE link 
       b. In a single- or multi- provider PPVPN backbone 
       c. In the Internet used as PPVPN backbone 
   9. The approach provides confidentiality (secrecy) protection for 
      PPVPN user data. 
       a. In the CE-PE link 
       b. In a single- or multi- provider PPVPN backbone 
       c. In the Internet used as PPVPN backbone 
   10. The approach provides sender authentication for PPVPN user 
       a. In the CE-PE link 
       b. In a single- or multi- provider PPVPN backbone 
       c. In the Internet used as PPVPN backbone 
   11. The approach provides integrity protection for PPVPN user data. 
       a. In the CE-PE link 
       b. In a single- or multi- provider PPVPN backbone 
       c. In the Internet used as PPVPN backbone 
   12. The approach provides protection against replay attacks for 
      PPVPN user data. 
       a. In the CE-PE link 
       b. In a single- or multi- provider PPVPN backbone 
       c. In the Internet used as PPVPN backbone 
   13. The approach provides protection against unauthorized traffic 
      pattern analysis for PPVPN user data. 
       a. In the CE-PE link 
       b. In a single- or multi- provider PPVPN backbone 
       c. In the Internet used as PPVPN backbone 
   14. The control protocol(s) used for each of the following 
      functions provide for message integrity and peer authentication: 
       a. VPN membership discovery 
   Expires May 2005            Page 37 

   PPVPN Security framework November 2004 
       b. Tunnel establishment 
       c. VPN topology and reachability advertisement 
          i.  PE-PE 
          ii. PE-CE 
       d. VPN provisioning and management 
       e. VPN monitoring and attack detection and reporting 
       f. Other VPN-specific control protocols, if any.  (list) 
   The following questions solicit free-form answers. 
   15. Describe the protection, if any, the approach provides against 
      PPVPN-specific DOS attacks (i.e. Inter-trusted-zone DOS 
      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 towards the service provider network. 
   17. Is the approach subject to any approach-specific 
      vulnerabilities not specifically addressed by this template?  If 
      so describe the defense or mitigation, if any, the approach 
      provides for each. 
10.     Security Considerations 
   Security considerations constitute the sole subject of this memo 
   and hence are discussed throughout.  Here we recap what has been 
   presented and explain at a very high level the role of each type of 
   consideration in an overall secure PPVPN system. 
   Expires May 2005            Page 38 

   PPVPN Security framework November 2004 
   The document describes a number of potential security threats.  
   Some of these threats have already been observed occurring in 
   running networks; others are largely theoretical at this time.  DOS 
   attacks and intrusion  
   attacks from the Internet against service provider infrastructure 
   have been seen to occur.  DOS "attacks" (typically not malicious) 
   have also been seen in which CE equipment overwhelms PE equipment 
   with high quantities or rates of packet traffic or routing 
   information.  Operational/provisioning errors are cited by service 
   providers as one of their prime concerns. 
   The document describes a variety of defensive techniques that may 
   be used to counter the suspected threats.  All of the techniques 
   presented involve mature and widely implemented technologies that 
   are practical to implement. 
   The document describes the importance of detecting, monitoring, and  
   reporting attacks, both successful and unsuccessful.  These 
   activities are essential for "understanding one's enemy", 
   mobilizing new defenses, and obtaining metrics about how secure the 
   PPVPN service is.  As such they are vital components of any 
   complete PPVPN security system. 
   The document evaluates PPVPN security requirements from a customer  
   perspective as well as from a service provider perspective.  These 
   sections re-evaluate the identified threats from the perspectives 
   of the various stakeholders and are meant to assist equipment 
   vendors and service providers, who must ultimately decide what 
   threats to protect against in any given equipment or service 
   Finally, the document includes a template for use by authors of 
   PPVPN technical solutions for evaluating how those solutions 
   measure up against the security considerations presented in this 
11.     IANA Considerations 
   This document has no actions for IANA. 
12.     Acknowledgement 
   The authors would also like to acknowledge the helpful comments and 
   suggestions from Paul Hoffman, Eric Gray, Ron Bonica, Chris Chase, 
   Jerry Ash, Stewart Bryant.  
13.     Normative References 
   Expires May 2005            Page 39 

   PPVPN Security framework November 2004 
   [RFC2246] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", 
   RFC 2246, January 1999. 
   [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 
   Internet Protocol," November 1998. 
   [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header," 
   [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. 
   [RFC2661] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer 
   Two Tunneling Protocol", RFC 2661, June 1999. 
   [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson, 
   "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, 
   June 2000. 
   [RFC3588]  P. Calhoun, J. Loughney, J. Arkko, E. Guttman, G. Zorn. 
   "Diameter Base Protocol", RFC 3588, September 2003. 
   [RFC3602] S. Frankel, R. Glenn, S. Kelley, "The AES-CBC Cipher 
   Algorithm and its Use with IPsec," RFC 3602, September 2003. 
   [STD62] "Simple Network Management Protocol, Version 3," RFCs 3411-
   3418, December 2002. 
   [STD8] J. Postel and J. Reynolds, "TELNET Protocol Specification", 
   STD 8, May 1983. 
14.     Informational References 
   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 
   Requirement Levels", BCP 14, RFC 2119, March 1997 
   [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 
   for Message Authentication," February 1997. 
   [RFC2411] R. Thayer, N. Doraswamy, R. Glenn,  "IP Security Document 
   Roadmap," November 1998. 
   Expires May 2005            Page 40 

   PPVPN Security framework November 2004 
   [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 
   1 (SHA1)," September 2001. 
   [RFC8631] S. Bellovin, C. Kaufman, J. Schiller, "Security 
   Mechanisms for the Internet," December 2003. 
   [L3VPN-FW]  R. Callon and M. Suzuki, "A Framework for Layer 3 
   Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn-
   framework-00.txt, March 2003. 
   [L3VPN-REQ]M. Carugi and D. McDysan, "Service requirements for 
   Layer 3 Virtual Private Networksö, draft-ietf-l3vpn-requirements-
   01.txt, June 2004. 
   [RPSEC] A. Barbir, S. Murphy, and Y. Yang, "Generic Threats to 
   Routing Protocols," draft-ietf-rpsec-routing-threats-07.txt, 
   October 2004. 
15.     Author's Addresses 
   Luyuan Fang                           
   200 Laurel Avenue, Room C2-3B35      Phone: 732-420-1921 
   Middletown, NJ 07748                 Email: 
   Michael Behringer 
   Village d'Entreprises Green Side,    Phone: +33.49723-2652    
   400, Avenue Roumanille, Bat. T 3     Email: 
   06410 Biot, Sophia Antipolis 
   Ross Callon 
   Juniper Networks 
   10 Technology Park Drive             Phone: 978-692-6724 
   Westford, MA  01886                  Email: 
   Fabio Chiussi                      Phone: 508-624-0000 x203 
   Invento Networks                   Email: 
   377 Simarano Drive 
   Marlborough, Massachusetts 01752 
   Jeremy De Clercq  
   Fr. Wellesplein 1, 2018 Antwerpen    E-mail: 
   Expires May 2005            Page 41 

   PPVPN Security framework November 2004 
   Mark Duffy 
   Quarry Technologies 
   8 New England Executive Park         Phone: 781-359-5052 
   Burlington, MA 01803                 Email: 
   Paul Hitchen 
   BT Adastral Park 
   Martlesham Heath                     Phone: 44-1473-606-344 
   Ipswich IP53RE                       Email: 
   Paul Knight 
   Nortel Networks 
   600 Technology Park Drive    Phone: 978-288-6414 
   Billerica, MA 01821          Email: 
   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 
   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- 
   Copyright (C) The Internet Society (2004).  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 
   This document and the information contained herein are provided on 
   Expires May 2005            Page 42 

   PPVPN Security framework November 2004 

   Expires May 2005            Page 43