Internet DRAFT - draft-fang-ppvpn-security-framework

draft-fang-ppvpn-security-framework





                                                                        
                                                                        
                                                            Luyuan Fang 
                                                               (editor) 
                                                                   AT&T 
                                                                        
                                                      Michael Behringer 
                                                                  Cisco 
                                                                        
                                                            Ross Callon 
                                                                Juniper 
                                                                        
                                                          Fabio Chiussi 
                                                    Lucent Technologies 
                                                                        
                                                       Jeremy De Clercq 
                                                                Alcatel 
                                                                        
                                                             Mark Duffy 
                                                    Quarry Technologies 
                                                                        
   Provider Provisioned VPN WG                             Paul Hitchen 
                                                                     BT 
                                                                        
   Internet Draft                                           Paul Knight 
                                                        Nortel Networks 
   Document:                                                            
   draft-fang-ppvpn-security-framework-01.txt 
   Expires: January 2004                                      July 2003 
    
                                      
   Security Framework for Provider Provisioned Virtual Private Networks 
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026. 
    
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress." 
    

     
                         Expires January 2004                        1 




                       PPVPN Security framework              July 2003 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   This draft addresses security aspects pertaining to Provider 
   Provisioned Virtual Private Networks (PPVPNs). We first describe the 
   security threats that are relevant in the context of PPVPNs, and the 
   defensive techniques that can be used to combat those threats. We 
   consider security issues deriving both from malicious behavior of 
   anyone and from negligent or incorrect behavior of the providers. We 
   also describe how these security attacks should be detected and 
   reported. We then discuss the possible user requirements in terms of 
   security in a PPVPN service. These user requirements translate into 
   corresponding requirements for the providers. In addition, the 
   provider may have additional requirements to make its network 
   infrastructure secure and meet the VPN customerĂs expectations. 
   Finally, we define a template that may be used to analyze the 
   security characteristics of a specific PPVPN technology and describe 
   them in a manner consistent with this framework. 
 
Table of Contents 
    
   Status of this Memo................................................1 
   Abstract...........................................................2 
   Conventions used in this document..................................3 
   1. Introduction...................................................3 
   2. Security Reference Model.......................................4 
   3. Security Threats...............................................5 
   3.1.  Attacks on the Data Plane...................................7 
   3.2.  Attacks on the Control Plane................................8 
   4. Defensive Techniques...........................................9 
   4.1.  Cryptographic techniques...................................10 
   4.2.  Authentication.............................................13 
   4.3.  Access Control techniques..................................14 
   4.4.  Use of Isolated Infrastructure.............................17 
   4.5.  Use of Aggregated Infrastructure...........................18 
   4.6.  Service Provider Quality Control Processes.................18 
   4.7.  Deployment of Testable PPVPN Service.......................19 
   5. Monitoring, Detection, and Reporting of Security Attacks......19 
   6. User Security Requirements....................................20 
   6.1.  Isolation..................................................20 
   6.2.  Protection.................................................21 
   6.3.  Confidentiality............................................22 
   6.4.  CE Authentication..........................................22 
     
                         Expires January 2004                        2 







                       PPVPN Security framework              July 2003 
    
   6.5.  Integrity..................................................22 
   6.6.  Anti-Replay................................................22 
   6.7.  Non-repudiation............................................22 
   7. Provider Security Requirements................................22 
   7.1.  Protection within the Core Network.........................23 
   7.2.  Protection on the User Access Link.........................24 
   7.3.  General Requirements for PPVPN Providers...................26 
   8. Security Evaluation of PPVPN Technologies.....................26 
   8.1.  Evaluating the Template....................................26 
   8.2.  Template...................................................27 
   9. Security Considerations.......................................29 
   References........................................................29 
   Author's Addresses................................................30 
   Full Copyright Statement..........................................31 
    
Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 [1]. 
    
    
1. Introduction 
    
   Security is clearly an integral aspect of Provider Provisioned 
   Virtual Private Network (PPVPN) services.  
    
   In this document, we first describe the security threats that are 
   relevant in the context of PPVPNs, and the defensive techniques that 
   can be used to combat those threats. We consider security issues 
   deriving both from malicious behavior of users and other parties and 
   from negligent or incorrect behavior of the providers. An important 
   part of security defense is the detection and report of a security 
   attack, which is also addressed in this document.  
    
   We then discuss the possible user and provider security requirements 
   in a PPVPN service. The users have expectations that need to be met 
   on the security characteristics of a VPN service. These user 
   requirements translate into corresponding requirements for the 
   providers in order to offer the service. In addition, providers have 
   security requirements to protect their network infrastructure, and 
   make it secure so it can provide the PPVPN services.  
    
   Finally, we define 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 
     
                         Expires January 2004                        3 






                       PPVPN Security framework              July 2003 
    
   list, that may be used in other documents dedicated to an in-depth 
   security analysis of individual PPVPN technologies to describe their 
   security characteristics in a comprehensive and coherent way, and to 
   provide a common ground for comparison between different 
   technologies. 
    
   It is important to clarify that, in this document, we limit 
   ourselves to describing the users and providersĂ security 
   requirements that pertain to PPVPN services. It is not our 
   intention, however, to formulate precise ˘requirements÷ on each 
   specific technology in terms of defining the mechanisms and 
   techniques that must be implemented to satisfy such users and 
   providersĂ requirements. 
    
   This document is organized as follows. In Section 2, we define the 
   security reference model for security in PPVPN networks, which we 
   use in the rest of the document. In Section 3, we describe the 
   security threats that are specific of PPVPNs. In Section 4, we 
   review defense techniques that may be used against those threats. In 
   Section 5, we describe how attacks may be detected and reported. In 
   Section 6, we discuss the user security requirements that apply to 
   PPVPN services. In Section 7, we describe additional security 
   requirements that the provider may have in order to guarantee the 
   security of the network infrastructure to provide PPVPN services. 
   Finally, in Section 8, we provide a template that may be used to 
   describe the security characteristics of specific PPVPN 
   technologies. 
 
2. Security Reference Model 
    
   This section defines the terminology used in this document, and a 
   reference model for security in PPVPN networks.  
    
   A PPVPN core network is defined here as the central network 
   infrastructure over which PPVPN services are delivered. All network 
   elements in the core are under the operational control of one or 
   more PPVPN service 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 January 2004                        4 




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


     
                         Expires January 2004                        5 




                       PPVPN Security framework              July 2003 
    
   A successful attack on a particular PPVPN or on a service provider's 
   PPVPN infrastructure would be expected to have effects of the 
   following unhappy sorts: 
    
    - 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: 
    
    - The PPVPN service provider or persons working for it. 
    - Other persons who obtain physical access to a service provider 
      site. 
    - Persons within the organization which is the PPVPN user with 
      respect to a particular PPVPN. 
    - Persons within an organization that is a separate PPVPN user of 
      the same service provider. 
    - Others i.e. attackers from the Internet at large. 
    
   In the case of PPVPNs, some parties may be in more advantaged 
   positions that enable them to launch types of attacks not available 
   to others.  For example other PPVPN users of the same service 
   provider may be able to launch attacks that those completely outside 
   the network cannot. 
    
   It is also useful to consider the likelihood of different sorts of 
   threats occurring.  There is at least a perceived difference in the 
   likelihood of most types of attacks being successfully mounted in 
   different environments, such as: 
    
    - In a TDM or ATM access network between a PPVPN user and the 
      service provider 
    - In an Ethernet access network 
    - In a PPVPN contained within one service provider's network 
    - In a PPVPN transiting the public Internet  
    
   Most types of threats become easier to mount and hence more likely 
   as the access link via which VPN service is provided changes from a 
   point-to-point layer 2 circuit to an Ethernet, or as the shared 
   infrastructure via which VPN service is provided expands from a 
   single service provider to multiple cooperating providers to the 
   global Internet.  Threats that may not be of sufficient likeliness 
   to warrant concern in a closely controlled environment often require 
   defensive measures in broader, more open environments. 
    

     
                         Expires January 2004                        6 




                       PPVPN Security framework              July 2003 
    
   The following sections discuss specific types of exploits that 
   threaten PPVPNs. 
    
3.1.    Attacks on the Data Plane 
    
   This category encompasses attacks on the PPVPN user's data, as 
   viewed by the service provider.  Note that from the PPVPN user's 
   point of view, some of this might be control plane traffic, e.g. 
   routing protocols running from PPVPN user site to PPVPN user site 
   via an L2 PPVPN. 
    
3.1.1.  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 
   as legitimate.  Included in this category is the insertion of copies 
   of once-legitimate packets that have been recorded and replayed. 
    
3.1.2.  Denial of Service Attacks on the VPN 
    
   DOS attacks on the data plane could be mounted by inserting an 
   overwhelming quantity of non-authentic data into a specific PPVPN. 
    
   DOS attacks could also be mounted by overwhelming the service 
   provider's general (VPN-independent) infrastructure with traffic, or 
   by interfering with its operation e.g. by disrupting control 
   protocols or general packet flow.  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 resources and 
   thus prevent other PPVPNs from accessing those resources.) 
    
3.1.3.  Unauthorized Observation/Modification/Deletion of Data Traffic 
    
   This refers to "sniffing" VPN packets and examining their contents.  
   It also includes modifying the contents of packets in flight, or 
   causing packets in flight to be discarded.  Such attacks would 
   typically occur on links in the network but might also occur in a 
   compromised node of the network. 
    
3.1.4.  Traffic Pattern Analysis 
    
   This refers to "sniffing" VPN packets and examining aspects or meta-
   aspects of them that may be visible even when the packets themselves 
   are encrypted.  An attacker might gain useful information based on 
   the amount and timing of traffic, packet sizes, source and 
   destination addresses, etc. 
 
3.1.5.  Impersonation 
    

     
                         Expires January 2004                        7 




                       PPVPN Security framework              July 2003 
    
   This refers to a broad category of attacks where the attacker 
   disguises itself to appear as a legitimate entity.  
    
3.2.    Attacks on the Control Plane 
    
   This category encompasses attacks on the control structures operated 
   by the PPVPN service provider. 
    
3.2.1.  Denial of Service Attacks on the Network Infrastructure 
    
   DOS attacks could be mounted specifically against the mechanisms the 
   service provider uses to provide PPVPNs e.g. IPsec, MPLS, etc., or 
   against the general infrastructure of the service provider e.g. core 
   routers.  (The latter case is within the scope of this document only 
   if the attack happens in relation with the VPN service, otherwise is 
   not a PPVPN-specific issue.) 
    
   Of special concern for PPVPNs is denial of service to one PPVPN user 
   caused by the otherwise-legitimate 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. 
    
3.2.2.  Attacks on the Service Provider Equipment Via Management 
 Interfaces 
    
   This includes unauthorized access to service provider infrastructure 
   equipment, which access could be used to reconfigure the equipment, 
   or to extract information (statistics, topology, etc.) about one or 
   more PPVPNs. 
    
   This could be accomplished through malicious entering of the 
   systems, or inadvertently as a consequence of inadequate inter-VPN 
   isolation in a PPVPN user self-management interface.  (The former is 
   not necessarily a PPVPN-specific issue.) 
    
3.2.3.  Cross-connection of Traffic Between PPVPNs 
 
   This refers to the event where expected isolation between separate 
   PPVPNs is breached.  This includes cases such as: 
    
    - A site being connected into the "wrong" VPN 
    - Two or more VPNs being improperly merged together 
    - A point-to-point VPN connecting the wrong two points 
    - Any packet or frame being improperly delivered outside the VPN it 
      is sent in. 
    
   Mis-connection or cross-connection of VPNs has a high likelihood of 
   being the result of service provider or equipment vendor error 
   rather than malicious action. 
    
     
                         Expires January 2004                        8 




                       PPVPN Security framework              July 2003 
    
   Anecdotal evidence suggests that the cross-connection threat is one 
   of the largest security concerns of PPVPN users (or would-be users). 
 
3.2.4.  Attacks Against PPVPN Routing Protocols 
    
   This encompasses attacks against routing protocols that are run by 
   the service provider.  In layer 3 VPNs with dynamic routing this 
   would typically relate to the distribution of per-VPN routes as well 
   as backbone routes.  In layer 2 VPNs this would typically relate 
   only to the distribution of backbone routes.  Specific attacks 
   against popular routing protocols have been widely studied and 
   described in [Beard]. 
    
3.2.5.  Attacks on Route Separation 
    
   "Route separation" refers here to keeping the per-VPN topology and 
   reachability information for each PPVPN separate from, and 
   unavailable to, any other PPVPN (except as specifically intended by 
   the service provider).  This concept is only a distinct security 
   concern for those layer 3 VPN types where the service provider is 
   involved with the routing within the VPN (i.e. VR, BGP-MPLS, routed 
   version of IPsec).  A breach in the route separation could reveal 
   topology and addressing information about a PPVPN.  It could also 
   cause black hole routing or unintended cross-connection between 
   PPVPNs. 
    
3.2.6.  Attacks on 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 breach in this addressing 
   separation may result in cross-connection between VPNs. 
    
3.2.7.  Other Attacks on PPVPN Control Traffic 
    
   Besides routing and management protocols (covered separately in the 
   previous sections) a number of other control protocols are used for 
   membership discovery and tunnel establishment in various PPVPN 
   approaches.  These include but may not be limited to: 
    
    - MPLS signaling (LDP, RSVP-TE) 
    - IPsec signaling (IKE) 
    - L2TP 
    - BGP-based membership discovery 
    - Database-based membership discovery (e.g. RADIUS-based) 
    
   Attacks might subvert or disrupt the activities of these protocols, 
   for example via impersonation or DOS attacks. 
    
4. Defensive Techniques 
    
     
                         Expires January 2004                        9 




                       PPVPN Security framework              July 2003 
    
   The defensive techniques discussed in this document are intended to 
   describe methods by which some security threats can be addressed.  
   They are not intended as requirements for all PPVPN implementations.  
   The PPVPN provider should determine the applicability of these 
   techniques to the provider's specific service offerings, and the 
   PPVPN user should assess the value which these techniques add to the 
   user's VPN requirements. 
    
   Nothing is ever 100% secure.  Defense therefore involves protecting 
   against those attacks that are most likely to occur and/or that have 
   the most dire consequences if successful.  For those attacks that 
   are protected against, absolute protection is seldom achievable; 
   more often it is sufficient just to make the cost of a successful 
   attack greater than what the adversary will be willing to expend. 
    
   Successfully defending against an attack does not necessarily mean 
   the attack must be prevented from happening or from reaching its 
   target.  In many cases the network can instead be designed to 
   withstand the attack.  For example, the introduction of non-
   authentic packets could be defended against by preventing their 
   introduction in the first place, or by making it possible to 
   identify and eliminate them before delivery to the PPVPN user's 
   system.  The latter is frequently a much easier task. 
    
4.1.    Cryptographic techniques 
    
   PPVPN defenses against a wide variety of attacks can be enhanced by 
   the proper application of cryptographic techniques.  These are the 
   same cryptographic techniques which are applicable to general 
   network communications.  In general, these techniques can provide 
   privacy (encryption) of communication between devices, 
   authentication of the identities of the devices, and can ensure that 
   the data being communicated is not 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.   
    
   There are a few reasons why encryption may not be a standard 
   offering within every PPVPN service.  Encryption adds an additional 
   computational burden to the devices performing encryption and 
   decryption.  This may reduce the number of user VPN connections 
   which can be handled on a device, or otherwise reduce the capacity 
   of the device, potentially driving up the provider's costs.  
   Typically, configuring encryption services on devices adds to the 
   complexity of the device configuration and adds incremental labor 
   cost.  Packet lengths are typically increased when the packets are 
   encrypted, increasing the network traffic load and adding to the 
   likelihood of packet fragmentation with its increased overhead.  
   (This packet length increase can often be mitigated to some extent 
     
                         Expires January 2004                       10 




                       PPVPN Security framework              July 2003 
    
   by data compression techniques, but at the expense of additional 
   computational burden.)  Finally, some PPVPN providers may employ 
   enough other defensive techniques, such as physical isolation or 
   filtering/firewall techniques, that they may not perceive additional 
   benefit from encryption techniques.  However, the ability of 
   currently available encryption techniques to reliably reduce the 
   damage from a variety of attacks is likely to make encryption a 
   common service offerings in PPVPNs. 
    
   The trust model between the PPVPN provider and the PPVPN user is a 
   key element in determining which party manages the encryption keying 
   material and the physical devices that perform the encryption.  The 
   parts of the network that are not considered to be secure usually 
   determine the points where encryption techniques are employed.  
   Since the party which manages a device where encryption is applied 
   can potentially modify the device configuration to obtain access to 
   the unencrypted data, some PPVPN users will insist on maintaining 
   control of the end-to-end encryption of their VPN traffic.  Other 
   PPVPN users may not trust the security of the links between their 
   site's CE and the PPVPN provider's PE, and opt for encryption on the 
   PE-CE link. 

4.1.1.  IPsec in PPVPNs 
 
   IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the 
   security protocol of choice for VPN operations at the IP layer 
   (Layer 3), as discussed in [SECMECH].  IPsec provides robust 
   security for IP traffic between pairs of devices.  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 
   currently outside the scope of this document, and outside the scope 
   of the PPVPN Working Group.   
    
   IPsec does not itself specify an encryption algorithm.  It can use a 
   variety of encryption algorithms, with various key lengths.  There 
   are trade-offs between key length, computational burden, and the 
   level of security of the encryption.  A full discussion of these 
   trade-offs is beyond the scope of this document.  In order to assess 
   the level of security offered by a particular IPsec-based PPVPN 
   service, some PPVPN users may wish to know the specific encryption 
   algorithm and effective key length used by the PPVPN provider.  
   However, in practice, any currently recommended IPsec encryption 
   offers enough security to substantially reduce the likelihood of 
   being directly targeted by an attacker; other weaker links in the 
   chain of security are likely to be attacked first.  PPVPN users may 
     
                         Expires January 2004                       11 





                       PPVPN Security framework              July 2003 
    
   wish to use a Service Level Agreement (SLA) specifying the Service 
   Provider's responsibility for ensuring data privacy, rather than 
   analyzing the specific encryption techniques used in the PPVPN 
   service. 
    
   For many of the PPVPN provider's network control messages and some 
   PPVPN user requirements, cryptographic authentication of messages 
   without encryption of the contents of the message may provide 
   acceptable security.  Using IPsec, authentication of messages is 
   provided by the Authentication Header (AH) or through the use of the 
   Encapsulating Security Protocol (ESP) with authentication only.  
   Where control messages require authentication but do not use IPsec, 
   then other cryptographic authentication methods are available.  
   Message authentication methods currently considered to be secure are 
   based on  hashed message authentication codes (HMAC) [RFC2104] 
   implemented with a secure hash algorithm such as Secure Hash 
   Algorithm 1 (SHA-1) [RFC3174]. 

4.1.2.  Encryption for device configuration and management 
 
   For configuration and management of PPVPN devices, encryption and 
   authentication of the management connection at a level comparable to 
   that provided by IPsec is desirable.  However, IPsec is not 
   currently available for this purpose on all existing PPVPN devices.   
    
   Some other methods of transporting PPVPN device management traffic 
   offer security and privacy comparable to IPsec. 
   -  Secure Shell (SSH) offers protection for TELNET [STD-8] or 
   terminal-like connections to allow device configuration. 
   -  SNMP v3 [STD62] also provides encrypted and authenticated 
   protection for SNMP-managed devices. 
   -  Transport Layer Security (TLS) (also known as Secure Sockets 
   Layer or SSL) [RFC-2246] is probably the emerging standard for 
   securing HTTP-based communication, and thus can provide support for 
   most XML- and SOAP-based device management approaches. 

4.1.3.  Cryptographic techniques in Layer 2 PPVPNs 
 
   Layer 2 PPVPNs will generally not be able to use IPsec to provide 
   encryption throughout the entire network.  They may be able to use 
   IPsec for PE-PE traffic where it is encapsulated in IP packets, but 
   IPsec will generally not be applicable for CE-PE traffic in Layer 2 
   PPVPNs.   
    
   Encryption techniques for Layer 2 links are widely available, but 
   are not within the scope of this document, nor of IETF documents in 
   general.  Layer 2 encryption could be applied to the links from CE 
   to PE, or could be applied from CE to CE, as long as the encrypted 
   Layer 2 packets can be properly handled by the intervening PE 
   devices.  In addition, the upper layer traffic transported by the 
     
                         Expires January 2004                       12 





                       PPVPN Security framework              July 2003 
    
   Layer 2 VPN can be encrypted by the user.  In this case privacy will 
   be maintained; however, this is transparent to the PPVPN provider 
   and is outside the scope of this document. 
    
4.2.    Authentication 
    
   In order to prevent security issues from some Denial-of-Service 
   attacks or from malicious misconfiguration, it is critical that 
   devices in the PPVPN should only accept connections or control 
   messages from valid sources.  Authentication refers to methods to 
   ensure that message sources are properly identified by the PPVPN 
   devices with which they communicate.  This section focuses on 
   identifying the scenarios in which sender authentication is 
   required, and recommends authentication mechanisms for these 
   scenarios. 
    
   Cryptographic techniques (authentication and encryption) do not 
   protect against some types of denial of service attacks, 
   specifically those 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 DOS attacks. Cryptographic 
   techniques may however, be useful against DOS attacks based on 
   exhaustion of state information (e.g., TCP SYN attacks). 

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

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

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

4.2.4.  Authenticating Remote Access VPN members 
 

     
                         Expires January 2004                       13 






                       PPVPN Security framework              July 2003 
    
   This section describes methods for authentication of remote access 
   users connecting to a VPN. 

4.2.5.  Cryptographic techniques for authenticating identity 
    
   Cryptographic techniques offer several mechanisms for authenticating 
   the identity of devices or individuals.  These include the use of 
   shared secret keys, one-time keys generated by accessory devices or 
   software, user-ID and password pairs, and a range of public-private 
   key systems.  Digital certificates using a hierarchical Certificate 
   Authority system are among the most useful systems, but they require 
   significant investment in infrastructure, and have not been 
   universally deployed. 
    
   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. 
    
4.3.    Access Control techniques 
    
   This includes packet-by-packet or packet-flow-by-packet-flow access 
   control by means of filters and firewalls, as well as means of 
   admitting a "session" for a control/signaling/management protocol 
   that is being used to implement PPVPNs. 
    
4.3.1.  Filtering 
 
   It is relatively common for routers to filter data packets. That is, 
   routers can look for particular values in certain fields of the IP 
   or higher level (e.g., TCP or UDP) headers. Packets which match the 
   criteria associated with a particular filter may either be discarded 
   or given special treatment.  
    
   In discussing filters, it is useful to separate the Filter 
   Characteristics which may be used to determine whether a packet 
   matches a filter from the Packet Actions which are applied to those 
   packets which match a particular filter.  
    
   o Filter Characteristics 
    
   Filter characteristics are used to determine whether a particular 
   packet or set of packets matches a particular filter.  
    
   In many cases filter characteristics may be stateless. A stateless 
   filter is one which determines whether a particular packet matches a 
   filter based solely on the filter definition, normal forwarding 
   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 
     
                         Expires January 2004                       14 





                       PPVPN Security framework              July 2003 
    
   interface, information in the IP header, and information in higher 
   layer headers such as the TCP or UDP header. Information in the IP 
   header to be considered may for example include source and 
   destination IP address, Protocol field, Fragment Offset, and TOS 
   field. Filters also may consider fields in the TCP or UDP header 
   such as the Port fields as well as the SYN field in the TCP header.  
    
   Stateful filtering maintains packet-specific state information, to 
   aid in determining whether a filter has been met. For example, a 
   device might apply stateless filters to the first fragment of a 
   fragmented IP packet. If the filter matches, then the data unit ID 
   may be remembered, and other fragments of the same packet may then 
   be considered to match the same filter. Stateful filtering is more 
   commonly done in firewalls, although firewall technology may be 
   added to routers. 
    
   o Actions based on Filter Results 
    
   If a packet, or a series of packets, match a specific filter, then 
   there are a variety of actions which may be taken based on that 
   filter match. Examples of such actions include: 
    
     - Discard 
    
   In many cases filters may be set to catch certain undesirable 
   packets. Examples may include packets with forged or invalid source 
   addresses, packets which are part of a DOS or DDOS attack, or 
   packets which are trying to access resources which are not permitted 
   (such as network management packets from an unauthorized source). 
   Where such filters are activated, it is common to silently discard 
   the packet or set of packets matching the filter. The discarded 
   packets may of course also be counted and/or logged.  
    
     - Set CoS 
    
   A filter may be used to set the Class of Service associated with the 
   packet.  
    
     - Count packets and/or bytes 
    
     - Rate Limit 
    
   In some cases the set of packets which match a particular filter may 
   be limited to a specified bandwidth. In this case packets and/or 
   bytes would be counted, and would be forwarded normally up to the 
   specified limit. Excess packets may be discarded, or may be marked 
   (for example by setting a "discard eligible" bit in the IP ToS field 
   or the MPLS EXP field).  
    
     - Forward and Copy 
    
     
                         Expires January 2004                       15 




                       PPVPN Security framework              July 2003 
    
   It is useful in some cases to forward some set of packets normally, 
   but to also send a copy to a specified other address or interface. 
   For example, this may be used to implement a lawful intercept 
   capability, or to feed selected packets to an Intrusion Detection 
   System.  
    
   o Other Issues related to Use of Packet Filters 
     
   There may be a very wide variation in the performance impact of 
   filtering. This may occur both due to differences between 
   implementations, and also due to differences between types or 
   numbers of filters deployed. For filtering to be useful, the 
   performance of the equipment has to be acceptable in the presence of 
   filters.  
    
   The precise definition of "acceptable" may vary from service 
   provider to service provider, and may depend upon the intended use 
   of the filters. For example, for some uses a filter may be turned on 
   all the time in order to set CoS, to prevent an attack, or to 
   mitigate the effect of a possible future attack. In this case it is 
   likely that the service provider will want the filter to have 
   minimal or no impact on performance. In other cases, a filter may be 
   turned on only in response to a major attack (such as a major DDOS 
   attack). In this case a greater performance impact may be acceptable 
   to some service providers.  
    
4.3.2.  Firewalls 
    
   Firewalls provide a mechanism for control over traffic passing 
   between different trusted zones in the PPVPN model, or between a 
   trusted zone and an untrusted zone.  Firewalls typically provide 
   much more functionality than filters, since they may be able to 
   apply detailed analysis and logical functions to flows, and not just 
   to individual packets.  They may offer a variety of complex 
   services, such as threshold-driven denial-of-service attack 
   protection, virus scanning, acting as a TCP connection proxy, etc. 
    
   As with other access control techniques, the value of firewalls 
   depends on a clear understanding of the topologies of the PPVPN core 
   network, the user networks, and the threat model.  Their 
   effectiveness depends on a topology with a clearly defined inside 
   (secure) and outside (not secure). 
    
   Within the PPVPN framework, traffic typically is not allowed to pass 
   between the various user VPNs.  This inter-VPN isolation is usually 
   not performed by a firewall, but is a part of the basic VPN 
   mechanism.  An exception to the total isolation of VPNs is the case 
   of "extranets", which allow specific external access to a user's 
   VPN, potentially from another VPN.  Firewalls can be used to provide 
   the services required for secure extranet implementation. 
    
     
                         Expires January 2004                       16 




                       PPVPN Security framework              July 2003 
    
   In a PPVPN, firewalls can be applied between the public Internet and 
   user VPNs, in cases where Internet access services are offered by 
   the provider to the VPN user sites.  In addition, firewalls may be 
   applied between VPN user sites and any shared network-based services 
   offered by the PPVPN provider.   
    
   Firewalls may be applied to help protect PPVPN core network 
   functions from attacks originating from the Internet or from PPVPN 
   user sites, but typically other defensive techniques will be used 
   for this purpose. 
    
   Where firewalls are employed as a service to protect user VPN sites 
   from the Internet, different VPN users, and even different sites of 
   a single VPN user, may have varying firewall requirements.  The 
   overall PPVPN logical and physical topology, along with the 
   capabilities of the devices implementing the firewall services, will 
   have a significant effect on the feasibility and manageability of 
   such varied firewall service offerings. 
    
4.3.3.  Access Control to management interfaces 
    
   Most of the security issues related to management interfaces can be 
   addressed through the use of authentication techniques as described 
   in the section on authentication.  However, additional security may 
   be provided by controlling access to management interfaces in other 
   ways. 
    
   Management interfaces, especially console ports on PPVPN devices, 
   may be configured so they are only accessible out-of-band, through a 
   system which is physically and/or logically separated from the rest 
   of the PPVPN infrastructure. 
    
   Where management interfaces are accessible in-band within the PPVPN 
   domain, filtering or firewalling techniques can be used to restrict 
   unauthorized in-band traffic from having access to management 
   interfaces.  Depending on device capabilities, these filtering or 
   firewalling techniques can be configured either on other devices 
   through which the traffic might pass, or on the individual PPVPN 
   devices themselves. 
    
4.4.    Use of Isolated Infrastructure 
    
   One way to protect the infrastructure used for support of VPNs is to 
   separate the resources for support of VPNs from the resources used 
   for other purposes (such as support of Internet services). In some 
   cases this may make use of a 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.  
     
                         Expires January 2004                       17 




                       PPVPN Security framework              July 2003 
    
    
   It is common for CE-based L3VPNs to make use of CE devices which are 
   dedicated to one specific VPN. In many or most cases CE-based VPNs 
   may make use of normal Internet services to interconnect CE devices.  
    
4.5.    Use of Aggregated Infrastructure 
    
   In general it is not feasible to use a completely separate set of 
   resources for support of each VPN. In fact, one of the main reasons 
   for VPN services is to allow sharing of resources between multiple 
   users, including multiple VPNs. Thus even if VPN services make use 
   of a separate network from Internet services, nonetheless there will 
   still be multiple VPN users sharing the same network resources. In 
   some cases VPN services will share the use of network resources with 
   Internet services or other services.  
    
   It is therefore important for VPN services to provide protection 
   between resource utilization by different VPNs. Thus a well-behaved 
   VPN user should be protected from possible misbehavior by other 
   VPNs. This requires that limits are placed on the amount of 
   resources which can be used by any one VPN. For example, both 
   control traffic and user data traffic may be rate limited. In some 
   cases or in some parts of the network where a sufficiently large 
   number of queues are available each VPN (and optionally each VPN and 
   CoS within the VPN) may make use of a separate queue. Control-plane 
   resources such as link bandwidth as well as CPU and memory resources 
   may be reserved on a per-VPN basis.  
    
   The techniques which are used to provision resource protection 
   between multiple VPNs served by the same infrastructure can also be 
   used to protect VPN services from Internet services.  
    
   In general the use of aggregated infrastructure allows the service 
   provider to benefit from stochastic multiplexing of multiple bursty 
   flows, and also may in some cases thwart traffic pattern analysis by 
   combining the data from multiple VPNs.  
    
4.6.    Service Provider Quality Control Processes 
    
   Deployment of provider-provisioned VPN services in general requires 
   a relatively large amount of configuration by the service provider. 
   For example, the service provider needs to configure which VPN each 
   site belongs to, as well as QoS and SLA guarantees. This large 
   amount of required configuration leads to the possibility of 
   misconfiguration.  
    
   It is important for the service provider to have operational 
   processes in place to reduce the potential impact of 
   misconfiguration. CE to CE authentication may also be used to detect 
   misconfiguration when it occurs.  
    
     
                         Expires January 2004                       18 




                       PPVPN Security framework              July 2003 
    
4.7.    Deployment of Testable PPVPN Service.   
    
   This refers to solutions that can be readily tested to make sure 
   they are configured correctly.  E.g. for a point-point VPN, checking 
   that the intended connectivity is working pretty much ensures that 
   there is not connectivity to some unintended site. 
    
 
5. Monitoring, Detection, and Reporting of Security Attacks 
    
   A PPVPN service may be subject to attacks from a variety of security 
   threats.  Many threats are described in another part of this 
   document.  Many of the defensive techniques described in this 
   document and elsewhere provide significant levels of protection from 
   a variety of threats.  However, in addition to silently employing 
   defensive techniques to protect against attacks, PPVPN services can 
   also add value for both providers and customers by implementing 
   security monitoring systems which detect and report on any security 
   attacks which occur, regardless of whether the attacks are 
   effective. 
    
   Attackers often begin by probing and analyzing defenses, so systems 
   which can detect and properly report these early stages of attacks 
   can provide significant benefits. 
    
   Information concerning attack incidents, especially if available 
   quickly, can be useful in defending against further attacks.  It can 
   be used to help identify attackers and/or their specific targets at 
   an early stage.  This knowledge about attackers and targets can be 
   used to further strengthen defenses against specific attacks or 
   attackers, or improve the defensive services for specific targets on 
   an as-needed basis.  Information collected on attacks may also be 
   useful in identifying and developing defenses against novel attack 
   types. 
    
   Monitoring systems used to detect security attacks in PPVPNs will 
   typically operate by collecting information from the Provider Edge 
   (PE), Customer Edge (CE), and/or Provider backbone (P) devices.  
   Security monitoring systems should have the ability to actively 
   retrieve information from devices (e.g., SNMP get) or to passively 
   receive reports from devices (e.g., SNMP traps).  The specific 
   information exchanged will depend on the capabilities of the devices 
   and on the type of VPN technology.  Particular care should 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 
     
                         Expires January 2004                       19 




                       PPVPN Security framework              July 2003 
    
   events may be reported through a single message, rather than 
   allowing each attack event to trigger a separate message, which 
   might result in a flood of messages, essentially becoming a denial-
   of-service attack against the monitoring system or the network. 
    
   The mechanisms for reporting security attacks should be flexible 
   enough to meet the needs of VPN service providers, VPN customers, 
   and regulatory agencies, if applicable.  The specific reports will 
   depend on the capabilities of the devices, the security monitoring 
   system, the type of VPN, and the service level agreements between 
   the provider and customer. 
 
    
6. User Security Requirements 
    
   This section defines a list of security related requirements that 
   the users of PPVPN services may have for their PPVPN service. 
   Typically, these user requirements translate into requirement for 
   the provider in offering the service.   
    
   The following sections detail various requirements that ensure the 
   security of a given trusted zone. Since in real life there are 
   various levels of security, a PPVPN may fulfill any number or all of 
   these security requirements. Specifically this document does not 
   state that a PPVPN must fulfill all of these requirements to be 
   secure. As mentioned in the Introduction, it is not within the scope 
   of this document to define the specific requirements that each VPN 
   technology must fulfill in order to be secure.  
    
6.1.    Isolation 
    
   A virtual private network usually defines the "private" as being 
   isolated from other PPVPNs and the Internet. More specifically, 
   isolation has several components:  
    
6.1.1.  Address Separation 
    
   Within a PPVPN service, a given PPVPN can use the full Internet 
   address range, including private address ranges [RFC1918], without 
   interfering with other PPVPNs that use the same PPVPN service. When 
   using Internet access through the PPVPN core a NAT functionality can 
   be implemented.  
    
   In layer 2 VPNs the same requirement exists for the layer 2 
   addressing schemes, such as MAC addresses. 
    
6.1.2.  Routing Separation 
    
   A PPVPN core must maintain routing separation between the trusted 
   zones. This means that routing information must not leak from any 

     
                         Expires January 2004                       20 




                       PPVPN Security framework              July 2003 
    
   trusted zone to any other trusted zone, unless this is specifically 
   engineered this way, for example for Internet access.  
    
   In layer 2 VPNs the switching information must be kept separate 
   between the trusted zones, such that switching information of one 
   PPVPN does not influence other PPVPNs or the PPVPN core. 
    
6.1.3.  Traffic Separation 
    
   Traffic from a given trusted zone must never leave this zone, and 
   traffic from another zone must never enter this zone. Exceptions are 
   where this is specifically engineered that way, for example for 
   extranet purposes or Internet access. 
    
6.2.    Protection 
    
   The perception of a completely separated network is that it has 
   defined entry points, and only over those is can be attacked or 
   intruded. By sharing a common core a PPVPN appears to lose some of 
   this clear interfaces to parts outside the trusted zone. Thus one of 
   the key security requirements of PPVPN services is that they offer 
   the same level of protection as independent networks. 
    
6.2.1.  Protection against intrusion 
    
   An intrusion is defined here as the penetration of a trusted zone 
   from outside this zone. This could be from the Internet, another 
   PPVPN, or the core network itself.  
    
   The fact that a network is "virtual" must not expose it to 
   additional threats over independent networks. Specifically, it must 
   not add new interfaces to other parts outside the trusted zone. 
   Intrusions from known interfaces such as Internet gateways are 
   outside the scope of this document.  
    
6.2.2.  Protection against Denial of Service attacks 
    
   A denial of service attack aims at making services or devices un-
   available to legitimate users. In the framework of this document 
   only those DoS attacks are considered which are a consequence of 
   providing the network in a virtual way. DoS attacks over the 
   standard interfaces into a trusted zone are not considered here.  
    
   The requirement is that a PPVPN is not more vulnerable against DoS 
   attacks than if the same network would be provided independently.  
    
6.2.3.  Protection against spoofing 
    
   It is not possible to change the sender identification (source 
   address, source label, etc) of traffic in transit, such that by this 
   spoofing the integrity of a PPVPN gets violated. For example, if two 
     
                         Expires January 2004                       21 




                       PPVPN Security framework              July 2003 
    
   CEs are connected to the same PE, it must not be possible for one CE 
   to send crafted packets that make the PE believe those packets are 
   coming from the other CE, thus inserting them into the wrong PPVPN. 
    
6.3.    Confidentiality 
    
   This requirement means that data must be cryptographically secured 
   in transit over the PPVPN core network to avoid eavesdropping. 
    
6.4.    CE Authentication 
    
   It is not possible for an outsider to install a CE and pretend to 
   belong to a specific PPVPN, to which this CE does not belong in 
   reality. 
    
6.5.    Integrity 
    
   Data in transit must be cryptographically secured such that it 
   cannot be altered. 
    
6.6.    Anti-Replay 
    
   Data in transit must be cryptographically secured such that it 
   cannot be recorded and replayed later. 
    
6.7.    Non-repudiation 
    
   The issue of non-repudiation pertains to PPVPN services, as well as 
   any other service. However, it is typically handled at the 
   application level, and is not therefore within the scope of this 
   document. 
    
7. Provider Security Requirements 
    
   In this section, we discuss additional security requirements that 
   the provider may have in order to secure its network infrastructure 
   as it provides PPVPN services. 
    
   The PPVPN service provider requirements defined here are the 
   requirements for the PPVPN core in the reference model.  The core 
   network can be implemented with different types of network 
   technologies, and each core network may use different technologies 
   to provide the PPVPN services to 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 
     
                         Expires January 2004                       22 




                       PPVPN Security framework              July 2003 
    
   the PPVPN user VPNs and sites themselves. Note that a PPVPN core is 
   not more vulnerable against attacks than a core that does not 
   provide PPVPNs. However providing PPVPN services over such a core 
   may need lead to additional security requirements, for the mere fact 
   that most users are expecting higher security standards in a core 
   delivering PPVPN services. 
    
7.1.    Protection within the Core Network 
    
7.1.1.  Control Plane Protection 
    
   - Protocol authentication within the core:  
    
   PPVPN technologies and infrastructure must support mechanisms for 
   authentication of the control plane. For an IP core, IGP and BGP 
   sessions may be authenticated by using TCP MD5 or IPSec. If an MPLS 
   core is used, LDP sessions may be authenticated by use TCP MD5, in 
   addition IGP and BGP authentication should also be considered. For a 
   core providing Layer 2 services, PE to PE authentication may also be 
   used via IPSec. 
    
   With the cost of authentication coming down rapidly, the application 
   of control plane authentication may not increase the cost of 
   implementation for providers significantly, and will help to improve 
   the security of the core. If the core is dedicated to VPN services                                      rd   and without any interconnects to 3  parties then this may reduce the 
   requirement for authentication of the core control plane. 
    
 
   - Elements protection 
    
   Here we discuss means to hide the providers 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 to be exposed 
   through trace route, however this must also be assessed against 
   operational requirements for end to end fault tracing.  
    
   An Internet backbone core may be re-engineered to make Internet 
   routing an edge function, for example, using MPLS label switching 
   for all traffic within the core and possibly make the Internet a VPN 
   within the PPVPN core itself. This helps to detach Internet access 
   from PPVPN services. 
    

     
                         Expires January 2004                       23 



                       PPVPN Security framework              July 2003 
    
   Separating control plane, data plane, and management plane 
   functionality in terms of hardware and software may be implemented 
   on the PE devices to improve security. This may help to limit the 
   problems when attacked in one particular area, and may allow each 
   plane to implement additional security measurement separately. 
    
   PEs are often more vulnerable to attack than P routers, since PEs 
   cannot be made unreachable to outside users by their very nature. 
   Access to core trunk resources can be controlled on a per user basis 
   by the application of inbound rate-limiting/shaping, this can be 
   further enhanced on a per Class of Service basis (see section 7.2.3)  
    
    
   In the PE, using separate routing processes for Internet and PPVPN 
   service may help to improve the PPVPN security and better protect 
   VPN customers. Furthermore, if the resources, such as CPU and 
   Memory, may be further separated based on applications, or even 
   individual VPNs, it may help to provide improved security and 
   reliability to individual VPN customers. 
    
   Many of these were not particular issues when an IP core was 
   designed to support Internet services only. When providing PPVPN 
   services, new requirements are introduced to satisfy the security 
   needs for VPN services. Similar consideration apply to L2 VPN 
   services. 
       
7.1.2.  Data Plane Protection 
    
   PPVPN using IPSec technologies provide VPN users with encryption of 
   secure user data. 
    
   In todayĂs MPLS, ATM, or Frame Relay networks, encryption is not 
   provided as a basic feature. Mechanisms can be used to secure the 
   MPLS data plane to secure the data carried over MPLS core. 
   Additionally, if the core is dedicated to VPN services and without                                  rd   any external interconnects to 3  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.  
    
    
7.2.    Protection on the User Access Link 
 
   Peer / Neighbor protocol authentication may be used to enhance 
   security. For example, BGP MD5 authentication may be used to enhance 
   security on PE-CE links using eBGP. In the case of Inter-provider 
   connection, authentication / encryption mechanisms between ASes, 
   such as IPSec, may be used. 
    
     
                         Expires January 2004                       24 



                       PPVPN Security framework              July 2003 
    
   WAN link address space separation for VPN and non-VPN users may be 
   implemented to improve security in order to protect VPN customers if 
   multiple services are provided on the same PE platform. 
    
   Firewall / Filtering: access control mechanisms can be used to 
   filter out any packets destined for the service providerĂs 
   infrastructure prefix or eliminate routes identified as illegitimate 
   routes. 
    
   Rate limiting may be applied to the user interface/logical 
   interfaces against DDOS bandwidth attack. This is very helpful when 
   the PE device is supporting both VPN services and Internet Services, 
   especially when supporting VPN and Internet Services on the same 
   physical interfaces through different logical interfaces. 
 
   7.2.1 Link Authentication 
    
   Authentication mechanisms can be employed to validate site access to 
   the PPVPN network via fixed or logical (e.g. L2TP, IPSec) 
   connections. Where the user wishes to hold the ŠsecretĂ associated 
   to acceptance of the access and site into the VPN, then PPVPN based 
   solutions require the flexability for either direct authentication 
   by the PE itself or interaction with a customer PPVPN authentication 
   server. Mechanisms are required in the latter case to ensure that 
   the interaction between the PE and the customer authentication 
   server is controlled e.g. limiting it simply to an exchange in 
   relation to the authentication phase and with other attributes e.g. 
   RADIUS optionally being filtered. 
    
   7.2.2 Access Routing 
    
   Mechanisms may be used to provide control at a routing protocol 
   level e.g. RIP, OSPF, BGP between the CE and PE. Per neighbor and 
   per VPN routing policies may be established to enhance security and 
   reduce the impact of a malicious or non-malicious attack on the PE, 
   in particular the following mechanisms should be considered: 
    - limiting the number of prefixes that may be advertised on a per 
      access basis into the PE. Appropriate action may be taken should 
      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. 
 
    
   7.2.3 Access QoS 
    
   PPVPN providers offering QoS enabled services require mechanisms to 
   ensure that individual accesses are validated against their 
   subscribed QOS profile and as such gain access to core resources 
   that match their service profile.  Mechanisms such as per Class of 
     
                         Expires January 2004                       25 




                       PPVPN Security framework              July 2003 
    
   service rate limiting/traffic shaping on ingress to the PPVPN core 
   are one option in providing this level of control.  Such mechanisms 
   may require the per Class of Service profile to be enforced either 
   by marking, remarking or discard of traffic outside of profile. 
    
   7.2.4 Customer VPN monitoring tools  
    
   End users requiring visibility of VPN specific statistics on the 
   core e.g. routing table, interface status, QoS statistics, impose 
   requirements for mechanisms at the PE to both validate the incoming 
   user and limit the views available to that particular users VPN.  
   Mechanisms should also be considered to ensure that such access 
   cannot be used a means of a DOS attack (either malicious or 
   accidental) on the PE itself. This could be accomplished through 
   either separation of these resources within the PE itself or via the 
   capability to rate-limit on a per VPN basis such traffic. 
 
    
7.3.    General Requirements for PPVPN Providers 
    
   The PPVPN providers must support the users security requirements as 
   listed in Section 6. Depending on the technologies used, these 
   requirements may include: 
 
   - User control plane separation ű routing isolation 
   - User address space separation ű supporting overlapping addresses 
     from different VPNs 
   - User data plane separation ű one VPN traffic cannot be intercepted 
     by other VPNs or any other users. 
   - Protection against intrusion, DOS attacks and spoofing 
   - Access Authentication 
   - Techniques highlighted through this document identify 
     methodologies for the protection of PPVPN resources and 
     infrastructure. By following these approaches a secure VPN service 
     can be delivered without the absolute need for cryptographic 
     techniques 
    
   Equipment hardware/software bugs leading to breaches in security are 
   not within the scope of this document. 
 
    
8. Security Evaluation of PPVPN Technologies 
    
   This section presents a brief template that may be used to evaluate 
   and summarize how a given PPVPN approach (solution) measures up 
   against the PPVPN Security Framework.  An evaluation of a given 
   PPVPN approach using this template should appear in the 
   applicability statement for each PPVPN approach. 
    
8.1.    Evaluating the Template 
    
     
                         Expires January 2004                       26 




                       PPVPN Security framework              July 2003 
    
   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) 
    
   - 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) 
    
   - In the VPN approach, the requirement is addressed in a way that is 
     beyond the scope of the VPN approach.  (Explain) 
    
   - The VPN approach does not meet the requirement. 
    
8.2.    Template 
    
   1. The approach provides a completely separate IP address space for 
      each VPN. 
    
   2. The approach provides a completely separate MAC address space for 
      each VPN. 
    
   3. The approach provides a completely separate VLAN ID space for 
      each VPN. 
    
   4. The approach provides a completely separate IP routing table for 
      each VPN. 
    
   5. The approach provides a completely separate MAC layer forwarding 
      table for each VPN. 
    
   6. The approach provides a means to prevent improper cross- 
      connection of sites in separate VPNs. 
    
   7. The approach provides a means to detect improper cross-connection 
      of sites in separate VPNs. 
    
   8. The approach protects against PPVPN-specific DOS attacks (i.e. 
      Inter-trusted-zone DOS attacks). 
    
      a. Protects the service provider infrastructure against Data 
     
                         Expires January 2004                       27 




                       PPVPN Security framework              July 2003 
    
         Plane or Control Plane DOS attacks originated in a private 
         (VPN user) network and aimed at PPVPN mechanisms. 
      b. Protects the service provider infrastructure against Data 
         Plane or Control Plane DOS attacks originated in the Internet 
         and aimed at PPVPN mechanisms. 
      c. Protects VPN users against Data Plane or Control Plane DOS 
         attacks originated from the Internet, or from other VPN users 
         and aimed at PPVPN mechanisms. 
      [Editor's note: DOS attacks directed towards general service 
      provider infrastructure are not VPN-specific, and are therefore 
      out of the scope of this document.] 
    
   9. The approach protects against unstable or malicious operation of 
      a VPN user network: 
    
      a. Protects against excessive routing traffic from VPN user 
         network to the service provider network. 
      b. Protects against excessive or malicious network management 
         traffic to the service provider network. 
      c. Protects against worms and probes originated in the VPN user 
         network to the service provider network. 
    
   10. 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 
    
   11. The approach provides confidentiality 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 sender authentication 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 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 
    
   14. The approach provides protection against replay for PPVPN user 
       data. 
    
     
                         Expires January 2004                       28 




                       PPVPN Security framework              July 2003 
    
       a. In the CE-PE link 
       b. In a single- or multi- provider PPVPN backbone 
       c. In the Internet used as PPVPN backbone 
    
   15. The approach provides protection against 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 
    
   16. The control protocol(s) used for each of the following functions 
       provide for message integrity and peer authentication: 
    
       a. VPN membership discovery 
       b. Tunnel establishment 
       c. VPN topology and reachability advertisement 
          i.  PE-PE 
          ii. PE-CE 
       d. VPN provisioning and management 
       e. VPN monitoring and attack detection and reporting 
    
   17. Is the approach subject to any approach-specific vulnerabilities 
       not specifically addressed by this template?  If so does the  
       approach provide a defense or mitigation for each? 
 
    
9. Security Considerations 
    
   There are no further security considerations in addition to what 
   discussed in the previous sections. 
 
References 
    
   [Beard] D. Beard and Y. Yang, ˘Known Threats to Routing Protocols,÷ 
   draft-beard-rpsec-routing-threats-00.txt, Oct. 2002.  
    
   [GDOI] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group 
   Domain of Interpretation,÷ draft-ietf-msec-gdoi-07.txt, December 
   2002.   
    
   [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 
   for Message Authentication,÷ February 1997. 
    
   [RFC-2246] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", 
   RFC 2246, January 1999. 
 
   [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 
   Internet Protocol,÷ November 1998. 
    
   [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header,÷ November 
     
                         Expires January 2004                       29 




                       PPVPN Security framework              July 2003 
    
   1998. 
    
   [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 
   (ESP),÷ November 1998. 
    
   [RFC2407] D. Piper, "The Internet IP Security Domain of 
   Interpretation for ISAKMP,÷ November 1998. 
    
   [RFC2411] R. Thayer, N. Doraswamy, R. Glenn,  "IP Security Document 
   Roadmap,÷ November 1998. 
    
   [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 
   1 (SHA1),÷ September 2001. 
    
   [SECMECH] S. Bellovin, C. Kaufman, J. Schiller, "Security Mechanisms 
   for the Internet,÷ draft-iab-secmech-02.txt, January 2003. 
     
   [STD62] "Simple Network Management Protocol, Version 3,÷ RFCs 3411-
   3418, December 2002. 
    
   [STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification", 
   STD 8, May 1983. 
 
 
 
 
Author's Addresses 
    
   Luyuan Fang                           
   AT&T                                  
   200 Laurel Avenue, Room C2-3B35      Phone: 732-420-1921 
   Middletown, NJ 07748                 Email: luyuanfang@att.com 
    
   Michael Behringer 
   Cisco                                 
   Avda de la Vega 15                   Phone: 34-639-659-822 
   28100 Alcobendas, Madrid             Email: mbehring@cisco.com 
   Spain 
    
   Ross Callon 
   Juniper Networks 
   10 Technology Park Drive             Phone: 978-692-6724 
   Westford, MA  01886                  Email: rcallon@juniper.net 
    
   Fabio Chiussi 
   Lucent Technologies 
   101 Crawfords Corner Rd, Room 4G502  Phone: 732-949-2407 
   Holmdel, NJ 07733                    Email: fabio@lucent.com  
    

     
                         Expires January 2004                       30 





                       PPVPN Security framework              July 2003 
    
   Jeremy De Clercq  
   Alcatel  
   Fr. Wellesplein 1, 2018 Antwerpen    E-mail: 
   Belgium                              jeremy.de_clercq@alcatel.be 
    
   Mark Duffy 
   Quarry Technologies 
   8 New England Executive Park         Phone: 781-359-5052 
   Burlington, MA 01803                 Email: mduffy@quarrytech.com 
    
   Paul Hitchen 
   BT 
   BT Adastral Park 
   Martlesham Heath                     Phone: 44-1473-606-344 
   Ipswich IP53RE                       Email: paul.hitchen@bt.com 
   UK 
                                 
   Paul Knight 
   Nortel Networks 
   600 Technology Park Drive    Phone: 978-288-6414 
   Billerica, MA 01821          Email: paul.night@nortelnetworks.com 
    
Full Copyright Statement 
 
   "Copyright (C) The Internet Society (date). All Rights Reserved. 
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. This 
   document and the information contained herein is provided on an "AS 
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    


     
                         Expires January 2004                       31 





                       PPVPN Security framework              July 2003 
    
    
 

















































     
                         Expires January 2004                       32