Request for Comments: 4111 AT&T Labs.
Category: Informational July 2005
Security Framework for
Provider-Provisioned Virtual Private Networks (PPVPNs)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document addresses security aspects pertaining to Provider-
Provisioned Virtual Private Networks (PPVPNs). First, it describes
the security threats in the context of PPVPNs and defensive
techniques to combat those threats. It considers security issues
deriving both from malicious behavior of anyone and from negligent or
incorrect behavior of the providers. It also describes how these
security attacks should be detected and reported. It then discusses
possible user requirements for security of a PPVPN service. These
user requirements translate into corresponding provider requirements.
In addition, the provider may have additional requirements to make
its network infrastructure secure to a level that can meet the PPVPN
customer’s expectations. Finally, this document defines a template
that may be used to describe and analyze the security characteristics
of a specific PPVPN technology.
Table of Contents
1. Introduction ................................................. 2
2. Terminology .................................................. 4
3. Security Reference Model ..................................... 4
4. Security Threats ............................................. 6
4.1. Attacks on the Data Plane .............................. 7
4.2. Attacks on the Control Plane ........................... 9
5. Defensive Techniques for PPVPN Service Providers ............. 11
5.1. Cryptographic Techniques ............................... 12
5.2. Authentication ......................................... 20
5.3. Access Control Techniques .............................. 22
5.4. Use of Isolated Infrastructure ......................... 27
5.5. Use of Aggregated Infrastructure ....................... 27
5.6. Service Provider Quality Control Processes ............. 28
5.7. Deployment of Testable PPVPN Service ................... 28
6. Monitoring, Detection, and Reporting of Security Attacks ..... 28
7. User Security Requirements ................................... 29
7.1. Isolation .............................................. 30
7.2. Protection ............................................. 30
7.3. Confidentiality ........................................ 31
7.4. CE Authentication ...................................... 31
7.5. Integrity .............................................. 31
7.6. Anti-replay ............................................ 32
8. Provider Security Requirements ............................... 32
8.1. Protection within the Core Network ..................... 32
8.2. Protection on the User Access Link ..................... 34
8.3. General Requirements for PPVPN Providers ............... 36
9. Security Evaluation of PPVPN Technologies .................... 37
9.1. Evaluating the Template ................................ 37
9.2. Template ............................................... 37
10. Security Considerations ...................................... 40
11. Contributors ................................................. 41
12. Acknowledgement .............................................. 42
13. Normative References ......................................... 42
14. Informative References ....................................... 43
1. Introduction
Security is 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 [RFC4110] and [RFC4031]. These
documents acknowledge that security is an important and integral
aspect of PPVPN services, for both VPN customers and VPN service
providers. Both will benefit from a PPVPN Security Framework
document that lists the customer and provider security requirements
related to PPVPN services, and that can be used to assess how much a
particular technology protects against security threats and fulfills
the security requirements.
First, we describe the security threats that are relevant in the
context of PPVPNs, and the defensive techniques that can be used to
combat those threats. We consider security issues deriving both from
malicious or incorrect behavior of users and other parties and from
negligent or incorrect behavior of the providers. An important part
of security defense is the detection and report of a security attack,
which is also addressed in this document. Special considerations
engendered by IP mobility within PPVPNs are not in the scope of this
document.
Then, we discuss the possible user and provider security requirements
for a PPVPN service. Users expectations must be met for the security
characteristics of a VPN service. These user requirements translate
into corresponding requirements for the providers offering the
service. Furthermore, providers have security requirements to
protect their network infrastructure, securing it to the level
required to provide the PPVPN services in addition to other services.
Finally, we define a template that may be used to describe the
security characteristics of a specific PPVPN technology in a manner
consistent with the security framework described in this document.
It is not within the scope of this document to analyze the security
properties of specific technologies. Instead, our intention is to
provide a common tool, in the form of a checklist, that may be used
in other documents dedicated to an in-depth security analysis of
individual PPVPN technologies to describe their security
characteristics in a comprehensive and coherent way, thereby
providing a common ground for comparison between different
technologies.
It is important to clarify that this document is limited to
describing users’ and providers’ security requirements that pertain
to PPVPN services. It is not the intention to formulate precise
"requirements" on each specific technology by defining the mechanisms
and techniques that must be implemented to satisfy such users’ and
providers’ requirements.
This document is organized as follows. Section 2 defines the
terminology used in the document. Section 3 defines the security
reference model for security in PPVPN networks. Section 4 describes
the security threats that are specific of PPVPNs. Section 5 reviews
defense techniques that may be used against those threats. Section 6
describes how attacks may be detected and reported. Section 7
discusses the user security requirements that apply to PPVPN
services. Section 8 describes additional security requirements on
the provider to guarantee the security of the network infrastructure
providing PPVPN services. In Section 9, we provide a template that
may be used to describe the security characteristics of specific
PPVPN technologies. Finally, Section 10 discusses security
considerations.
2. Terminology
This document uses PPVPN-specific terminology. Definitions and
details specific to PPVPN terminology can be found in [RFC4026] and
[RFC4110]. The most important definitions are repeated in this
section; for other definitions, the reader is referred to
[RFC4026] and [RFC4110].
CE: Customer Edge device, a router or a switch in the customer
network interfacing with the service provider’s network.
P: Provider Router. The Provider Router is a router in the
service provider’s core network that does not have interfaces
directly toward the customer. A P router is used to
interconnect the PE routers. A P router does not have to
maintain VPN state and is thus VPN unaware.
PE: Provider Edge device, the equipment in the service provider’s
network that interfaces with the equipment in the customer’s
network.
PPVPN: Provider-Provisioned Virtual Private Network, a VPN that is
configured and managed by the service provider (and thus not by
the customer itself).
SP: Service Provider.
VPN: Virtual Private Network, which restricts communication
between a set of sites using an IP backbone shared by traffic
that is not going to or coming from those sites.
3. Security Reference Model
This section defines a reference model for security in PPVPN
networks.
A PPVPN core network is 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, it appears to the PPVPN users as a single zone of
trust. However, several service providers providing a common PPVPN
core still have 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 wherein restricted and controlled communication
is allowed between trusted zones, often via well-defined transit
points.
This document defines each PPVPN as a trusted zone and the PPVPN core
as another trusted zone. A primary concern is security aspects that
relate to breaches of security from the "outside" of a trusted zone
to the "inside" of this zone. Figure 1 depicts the concept of
trusted zones within the PPVPN framework.
+------------+ +------------+
| PPVPN +-----------------------------+ PPVPN |
| user PPVPN user |
| site +---------------------XXX-----+ site |
+------------+ +------------------XXX--+ +------------+
| PPVPN core | | |
+------------------| |--+
| |
| +------\
+--------/ Internet
Figure 1: The PPVPN trusted zone model
In principle, the trusted zones should be separate. However, PPVPN
core networks often offer Internet access, in which case a transit
point (marked "XXX" in the figure) is defined.
The key requirement of a "virtual private" network (VPN) is that the
security of the trusted zone of the VPN is not compromised by sharing
the core infrastructure with other VPNs.
Security against threats that originate within the same trusted zone
as their targets (for example, attacks from a user in a PPVPN to
other users within the same PPVPN, or attacks entirely within the
core network) is outside the scope of this document.
Also outside the scope are all aspects of network security that are
independent of whether a network is a PPVPN network or a private
network. For example, attacks from the Internet to a web server
inside a given PPVPN will not be considered here, unless the
provisioning of the PPVPN network could make a difference to the
security of this server.
4. Security Threats
This section discusses the various network security threats that may
endanger PPVPNs. The discussion is limited to threats that are
unique to PPVPNs, or that affect PPVPNs in unique ways. A successful
attack on a particular PPVPN or on a service provider’s PPVPN
infrastructure may cause one or more of the following ill effects:
- observation, modification, or deletion of PPVPN user data,
- replay of PPVPN user data,
- injection of non-authentic data into a PPVPN,
- traffic pattern analysis on PPVPN traffic,
- disruption of PPVPN connectivity, or
- degradation of PPVPN service quality.
It is useful to consider that threats to a PPVPN, whether malicious
or accidental, may come from different categories of sources. For
example they may come from:
- users of other PPVPNs provided by the same PPVPN service provider,
- the PPVPN service provider or persons working for it,
- other persons who obtain physical access to a service provider
site,
- 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), or
- others, i.e., attackers from the Internet at large.
In the case of PPVPNs, some parties may be in more advantageous
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 who
are completely outside the network cannot.
Given that security is generally a compromise between expense and
risk, it is also useful to consider the likelihood of different
attacks. There is at least a perceived difference in the likelihood
of most types of attacks being successfully mounted in different
environments, such as
- in a PPVPN contained within one service provider’s network, or
- in a PPVPN transiting the public Internet.
Most types of attacks become easier to mount, and hence more likely,
as the shared infrastructure that provides VPN service expands from a
single service provider to multiple cooperating providers, and then
to the global Internet. Attacks that may not be sufficiently likely
to warrant concern in a closely controlled environment often merit
defensive measures in broader, more open environments.
The following sections discuss specific types of exploits that
threaten PPVPNs.
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 unchanged.
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 into the VPN (or "spoofing") of packets
that do not belong there, with the objective of having them accepted
as legitimate by the recipient. 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 significantly less of a concern than
are 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 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, and CPU power.
DoS attacks of the resource exhaustion type can be mounted against
the data plane of a particular PPVPN by attempting to insert (spoof)
an overwhelming quantity of non-authentic data into the VPN from
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.
For example, a PPVPN user might be able to monopolize network data
plane resources and thus to 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 Network Infrastructure
Control plane DoS attacks can be mounted specifically against the
mechanisms that the service provider uses to provide PPVPNs (e.g.,
IPsec, MPLS) 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 to the VPN service;
otherwise, they are not a PPVPN-specific issue.
Of special concern for PPVPNs is denial of service to one PPVPN user
caused by the activities of another. 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.
4.2.2. Attacks on Service Provider Equipment via Management
Interfaces
This includes unauthorized access to service provider infrastructure
equipment, in order, for example, to reconfigure the equipment or to
extract information (statistics, topology, etc.) about one or more
PPVPNs.
This can be accomplished through malicious entrance of the systems,
or as an inadvertent 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 Service Provider
Infrastructure
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 self-provisioned by the customer at
the IP layer.
4.2.4. Cross-Connection of Traffic between PPVPNs
This refers to events 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,
- a point-to-point VPN connecting the wrong two points, or
- any packet or frame being improperly delivered outside the VPN it
is sent in.
Misconnection 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
misconnected) 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 users).
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 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 are
described in [RFC3889].
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 layer-3 VPN types for which 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 have to be
kept separate. In layer-2 VPNs, the MAC address and VLAN spaces of
different VPNs have 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, and
- 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 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 in regard
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 protects against
those attacks that are most likely to occur or that could have the
most dire consequences. Absolute protection against these attacks is
seldom achievable; more often it is sufficient to make the cost of a