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