successful attack greater than what the adversary would be willing to
expend.
Successful defense against an attack does not necessarily mean that
the attack must be prevented from happening or from reaching its
target. In many cases, the network can instead be designed to
withstand the attack. For example, the introduction of non-authentic
packets could be defended against by preventing their introduction in
the first place, or by making it possible to identify and eliminate
them before delivery to the PPVPN user’s system. The latter is
frequently a much easier task.
5.1. Cryptographic Techniques
PPVPN defenses against a wide variety of attacks can be enhanced by
the proper application of cryptographic techniques. These are the
same cryptographic techniques that are applicable to general network
communications. In general, these techniques can provide
confidentiality (encryption) of communication between devices,
authentication of the identities of the devices, and detection of a
change of the protected data 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. This section focuses on
encryption; traffic separation is addressed separately.
Several aspects of authentication are addressed in some detail in a
separate "Authentication" section.
Encryption adds complexity, and thus it may not be a standard
offering within every PPVPN service. There are a few reasons for
this. Encryption adds an additional computational burden to the
devices performing encryption and decryption. This may reduce the
number of user VPN connections that 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. Encrypting packets typically increases
packet lengths, thereby increasing the network traffic load and the
likelihood of packet fragmentation, with its increased overhead.
(Packet length increase can often be mitigated to some extent by data
compression techniques, but with additional computational burden.)
Finally, some PPVPN providers may employ enough other defensive
techniques, such as physical isolation or filtering/firewall
techniques, that they may not perceive additional benefit from
encryption techniques.
The trust model among the PPVPN user, the PPVPN provider, and other
parts of the network is a key element in determining the
applicability of encryption for any specific PPVPN implementation.
In particular, it determines where encryption should be applied, as
follows.
- If the data path between the user’s site and the provider’s PE
is not trusted, then encryption may be used on the PE-CE link.
- If some part of the backbone network is not trusted,
particularly in implementations where traffic may travel across
the Internet or multiple provider networks, then the PE-PE
traffic may be encrypted.
- If the PPVPN user does not trust any zone outside of its
premises, it may require end-to-end or CE-CE encryption
service. This service fits within the scope of this PPVPN
security framework when the CE is provisioned by the PPVPN
provider.
- If the PPVPN user requires remote access to a PPVPN from a
system that is not at a PPVPN customer location (for example,
access by a traveler), there may be a requirement for
encrypting the traffic between that system and an access point
on the PPVPN or at a customer site. If the PPVPN provider
provides the access point, then the customer must cooperate
with the provider to handle the access control services for the
remote users. These access control services are usually
implemented by using encryption, as well.
Although CE-CE encryption provides confidentiality against third-
party interception, if the PPVPN provider has complete management
control over the CE (encryption) devices, then it may be possible for
the provider to gain access to the user’s VPN traffic or internal
network. Encryption devices can potentially be configured to use
null encryption, to bypass encryption processing altogether, or to
provide some means of sniffing or diverting unencrypted traffic.
Thus, a PPVPN implementation using CE-CE encryption has to consider
the trust relationship between the PPVPN user and provider. PPVPN
users and providers may wish to negotiate a service level agreement
(SLA) for CE-CE encryption that will provide an acceptable
demarcation of responsibilities for management of encryption on the
CE devices.
The demarcation may also be affected by the capabilities of the CE
devices. For example, the CE might support some partitioning of
management or a configuration lock-down ability, or it might allow
both parties to verify the configuration. In general, if the managed
CE-CE model is used, the PPVPN user has to have a fairly high level
of trust that the PPVPN provider will properly provision and manage
the CE devices.
5.1.1. IPsec in PPVPNs
IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the
security protocol of choice for encryption at the IP layer (Layer 3),
as discussed in [RFC3631]. IPsec provides robust security for IP
traffic between pairs of devices. Non-IP traffic must be converted
to IP packets, or it cannot be transported over IPsec. Encapsulation
is a common conversion method.
In the PPVPN model, IPsec can be employed to protect IP traffic
between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec
may be employed in either a provider-provisioned or a user-
provisioned model. The user-provisioned CE-CE IPsec model is outside
the scope of this document and outside the scope of the PPVPN Working
Group. Likewise, data encryption that is performed within the user’s
site is outside the scope of this document, as it is simply handled
as user data by the PPVPN. IPsec can also be used to protect IP
traffic between a remote user and the PPVPN.
IPsec does not itself specify an encryption algorithm. It can use a
variety of encryption algorithms with various key lengths, such as
AES encryption. There are trade-offs between key length,
computational burden, and the level of security of the encryption. A
full discussion of these trade-offs is beyond the scope of this
document. In order to assess the level of security offered by a
particular IPsec-based PPVPN service, some PPVPN users may wish to
know the specific encryption algorithm and effective key length used
by the PPVPN provider. However, in practice, any currently
recommended IPsec encryption offers enough security to substantially
reduce the likelihood of being directly targeted by an attacker.
Other, weaker, links in the chain of security are likely to be
attacked first. PPVPN users may wish to use a Service Level
Agreement (SLA) specifying the service provider’s responsibility for
ensuring data confidentiality rather than to analyze the specific
encryption techniques used in the PPVPN service.
For many of the PPVPN provider’s network control messages and some
PPVPN user requirements, cryptographic authentication of messages
without encryption of the contents of the message may provide
acceptable security. With IPsec, authentication of messages is
provided by the Authentication Header (AH) or by the Encapsulating
Security Protocol (ESP) with authentication only. Where control
messages require authentication but do not use IPsec, other
cryptographic authentication methods are available. Message
authentication methods currently considered to be secure are based on
hashed message authentication codes (HMAC) [RFC2104] implemented with
a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1)
[RFC3174].
One recommended mechanism for providing a combination
confidentiality, data origin authentication, and connectionless
integrity is the use of AES in Cipher Block Chaining (CBC) Mode, with
an explicit Initialization Vector (IV) [RFC3602], as the IPsec ESP.
PPVPNs that provide differentiated services based on traffic type may
encounter some conflicts with IPsec encryption of traffic. As
encryption hides the content of the packets, it may not be possible
to differentiate the encrypted traffic in the same manner as
unencrypted traffic. Although DiffServ markings are copied to the
IPsec header and can provide some differentiation, not all traffic
types can be accommodated by this mechanism.
5.1.2. Encryption for Device Configuration and Management
For configuration and management of PPVPN devices, encryption and
authentication of the management connection at a level comparable to
that provided by IPsec is desirable.
Several methods of transporting PPVPN device management traffic offer
security and confidentiality.
- Secure Shell (SSH) offers protection for TELNET [STD8] or
terminal-like connections to allow device configuration.
- SNMP v3 [STD62] provides encrypted and authenticated protection
for SNMP-managed devices.
- Transport Layer Security (TLS) [RFC2246] and the closely-related
Secure Sockets Layer (SSL) are widely used for securing HTTP-based
communication, and thus can provide support for most XML- and
SOAP-based device management approaches.
- As of 2004, extensive work is proceeding in several organizations
(OASIS, W3C, WS-I, and others) on securing device management
traffic within a "Web Services" framework. This work uses a wide
variety of security models and supports multiple security token
formats, multiple trust domains, multiple signature formats, and
multiple encryption technologies.
- IPsec provides the services with security and confidentiality at
the network layer. With regard to device management, its current
use is primarily focused on in-band management of user-managed
IPsec gateway devices.
5.1.3. Cryptographic Techniques in Layer-2 PPVPNs
Layer-2 PPVPNs will generally not be able to use IPsec to provide
encryption throughout the entire network. They may be able to use
IPsec for PE-PE traffic where it is encapsulated in IP packets, but
IPsec will generally not be applicable for CE-PE traffic in Layer-2
PPVPNs.
Encryption techniques for Layer-2 links are widely available but are
not within the scope of this document or IETF documents in general.
Layer-2 encryption could be applied to the links from CE to PE, or it
could be applied from CE to CE, as long as the encrypted Layer-2
packets can be handled properly by the intervening PE devices. In
addition, the upper-layer traffic transported by the Layer-2 VPN can
be encrypted by the user. In this case, confidentiality will be
maintained; however, this is transparent to the PPVPN provider and is
outside the scope of this document.
5.1.4. End-to-End vs. Hop-by-Hop Encryption Tradeoffs in PPVPNs
In PPVPNs, encryption could potentially be applied to the VPN traffic
at several different places. This section discusses some of the
tradeoffs in implementing encryption in several different connection
topologies among different devices within a PPVPN.
Encryption typically involves a pair of devices that encrypt the
traffic passing between them. The devices may be directly connected
(over a single "hop"), or there may be intervening devices that
transport the encrypted traffic between the pair of devices. The
extreme cases involve hop-by-hop encryption between every adjacent
pair of devices along a given path or "end-to-end" encryption only
between the end devices along a given path. To keep this discussion
within the scope of PPVPNs, we consider the "end to end" case to be
CE to CE rather than fully end to end.
Figure 2 depicts a simplified PPVPN topology, showing the Customer
Edge (CE) devices, the Provider Edge (PE) devices, and a variable
number (three are shown) of Provider core (P) devices that might be
present along the path between two sites in a single VPN, operated by
a single service provider (SP).
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Figure 2: Simplified PPVPN topology
Within this simplified topology and assuming that P devices are not
to be involved with encryption, there are four basic feasible
configurations for implementing encryption on connections among the
devices:
1) Site-to-site (CE-to-CE): Encryption can be configured between
the two CE devices, so that traffic will be encrypted
throughout the SP’s network.
2) Provider edge-to-edge (PE-to-PE): Encryption can be configured
between the two PE devices. Unencrypted traffic is received at
one PE from the customer’s CE; then it is encrypted for
transmission through the SP’s network to the other PE, where it
is decrypted and sent to the other CE.
3) Access link (CE-to-PE): Encryption can be configured between
the CE and PE, on each side (or on only one side).
4) Configurations 2) and 3) can be combined, with encryption
running from CE to PE, then from PE to PE, and then from PE to
CE.
Among the four feasible configurations, key tradeoffs in considering
encryption include the following:
- Vulnerability to link eavesdropping: Assuming that an attacker can
observe the data in transit on the links, would it be protected by
encryption?
- Vulnerability to device compromise: Assuming an attacker can get
access to a device (or freely alter its configuration), would the
data be protected?
- Complexity of device configuration and management: Given Nce, the
number of sites per VPN customer, and Npe, the number of PEs
participating in a given VPN, how many device configurations have
to be created or maintained and how do those configurations scale?
- Processing load on devices: How many encryption or decryption
operations must be done, given P packets? This influences
considerations of device capacity and perhaps end-to-end delay.
- Ability of SP to provide enhanced services (QoS, firewall,
intrusion detection, etc.): Can the SP inspect the data in order
to provide these services?
These tradeoffs are discussed below for each configuration.
1) Site-to-site (CE-to-CE) Configurations
o Link eavesdropping: Protected on all links.
o Device compromise: Vulnerable to CE compromise.
o Complexity: Single administration, responsible for one device
per site (Nce devices), but overall configuration per VPN
scales as Nce**2.
o Processing load: on each of two CEs, each packet is either
encrypted or decrypted (2P).
o Enhanced services: Severely limited; typically only DiffServ
markings are visible to SP, allowing some QoS services.
2) Provider edge-to-edge (PE-to-PE) Configurations
o Link eavesdropping: Vulnerable on CE-PE links; protected on
SP’s network links.
o Device compromise: Vulnerable to CE or PE compromise.
o Complexity: Single administration; Npe devices to configure.
(Multiple sites may share a PE device, so Npe is typically much
less than Nce.) Scalability of the overall configuration
depends on the PPVPN type: If the encryption is separate per
VPN context, it scales as Npe**2 per customer VPN. If the
encryption is per PE, it scales as Npe**2 for all customer VPNs
combined.
o Processing load: On each of two PEs, each packet is either
encrypted or decrypted (2P).
o Enhanced services: Full; SP can apply any enhancements based on
detailed view of traffic.
3) Access link (CE-to-PE) Configuration
o Link eavesdropping: Protected on CE-PE link; vulnerable on SP’s
network links.
o Device compromise: Vulnerable to CE or PE compromise.
o Complexity: Two administrations (customer and SP) with device
configuration on each side (Nce + Npe devices to configure),
but as there is no mesh, the overall configuration scales as
Nce.
o Processing load: On each of two CEs, each packet is either
encrypted or decrypted. On each of two PEs, each packet is
either encrypted or decrypted (4P).
o Enhanced services: Full; SP can apply any enhancements based on
detailed view of traffic.
4) Combined Access link and PE-to-PE (essentially hop-by-hop).
o Link eavesdropping: Protected on all links.
o Device compromise: Vulnerable to CE or PE compromise.
o Complexity: Two administrations (customer and SP), with device
configuration on each side (Nce + Npe devices to configure).
Scalability of the overall configuration depends on the PPVPN
type. If the encryption is separate per VPN context, it scales
as Npe**2 per customer VPN. If the encryption is per-PE, it
scales as Npe**2 for all customer VPNs combined.
o Processing load: On each of two CEs, each packet is either
encrypted or decrypted. On each of two PEs, each packet is
both encrypted and decrypted (6P).
o Enhanced services: Full; SP can apply any enhancements based on
detailed view of traffic.
Given the tradeoffs discussed above, a few conclusions can be
reached.
- Configurations 2 and 3, which are subsets of 4, may be appropriate
alternatives to 4 under certain threat models. The remainder of
these conclusions compare 1 (CE-to-CE) with 4 (combined access
links and PE-to-PE).
- If protection from link eavesdropping is most important, then
configurations 1 and 4 are equivalent.
- If protection from device compromise is most important and the
threat is to the CE devices, both cases are equivalent; if the
threat is to the PE devices, configuration 1 is best.
- If reducing complexity is most important and the size of the
network is very small, configuration 1 is the best. Otherwise,
the comparison between options 1 and 4 is relatively complex ,
based on a number of issues such as, how close the CE to CE
communication is to a full mesh, and what tools are used for key
management. Option 1 requires configuring keys for each CE-CE
pair that is communicating directly. Option 4 requires
configuring keys on both CE and PE devices but may offer benefit
from the fact that the number of PEs is generally much smaller
than the number of CEs.
Also, under some PPVPN approaches, the scaling of 4 is further
improved by sharing the same PE-PE mesh across all VPN contexts.
The scaling characteristics of 4 may be increased or decreased in
any given situation if the CE devices are simpler to configure
than the PE devices, or vice versa. Furthermore, with option 4,
the impact of operational error may be significantly increased.
- If the overall processing load is a key factor, then 1 is best.
- If the availability of enhanced services support from the SP is
most important, then 4 is best.
As a quick overall conclusion, CE-to-CE encryption provides greater
protection against device compromise, but it comes at the cost of
enhanced services and with additional operational complexity due to
the Order(n**2) scaling of the mesh.
This analysis of site-to-site vs. hop-by-hop encryption tradeoffs
does not explicitly include cases where multiple providers cooperate
to provide a PPVPN service, public Internet VPN connectivity, or
remote access VPN service, but many of the tradeoffs will be similar.
5.2. Authentication
In order to prevent security issues from some denial-of-service
attacks or from malicious misconfiguration, it is critical that
devices in the PPVPN should only accept connections or control
messages from valid sources. Authentication refers to methods for
ensuring 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 it recommends authentication mechanisms for these scenarios.
Cryptographic techniques (authentication and encryption) do not
protect against some types of denial-of-service attacks,
specifically, resource exhaustion attacks based on CPU or bandwidth
exhaustion. In fact, the processing required to decrypt or check
authentication may in some cases increase the effect of these
resource exhaustion attacks. Cryptographic techniques may, however,
be useful against resource exhaustion attacks based on exhaustion of
state information (e.g., TCP SYN attacks).
5.2.1. VPN Member Authentication
This category includes techniques for the CEs to verify that they are
connected to the expected VPN. It includes techniques for CE-PE
authentication, to verify that each specific CE and PE is actually
communicating with its expected peer.
5.2.2. Management System Authentication
Management system authentication includes the authentication of a PE
to a centrally-managed directory server when directory-based "auto-
discovery" is used. It also includes authentication of a CE to its
PPVPN configuration server when a configuration server system is
used.
5.2.3. Peer-to-Peer Authentication
Peer-to-peer authentication includes peer authentication for network
control protocols (e.g., LDP, BGP), and other peer authentication
(i.e., authentication of one IPsec security gateway by another).
5.2.4. Authenticating Remote Access VPN Members
This section describes methods for authentication of remote access
users connecting to a VPN.
Effective authentication of individual connections is a key
requirement for enabling remote access to a PPVPN from an arbitrary
Internet address (for instance, by a traveler).
There are several widely used standards-based protocols to support
remote access authentication. These include RADIUS [RFC2865] and
DIAMETER [RFC3588]. Digital certificate systems also provide
authentication. In addition, there has been extensive development
and deployment of mechanisms for securely transporting individual
remote access connections within tunneling protocols, including L2TP
[RFC2661] and IPsec.
Remote access involves connection to a gateway device, which provides
access to the PPVPN. The gateway device may be managed by the user
at a user site, or by the PPVPN provider at any of several possible
locations in the network. The user-managed case is of limited
interest within the PPVPN security framework, and it is not
considered at this time.
When a PPVPN provider manages authentication at the remote access
gateway, this implies that authentication databases, which are
usually extremely confidential user-managed systems, will have to be
referenced in a secure manner by the PPVPN provider. This can be
accomplished through proxy authentication services, which accept an
encrypted authentication credential from the remote access user, pass
it to the PPVPN user’s authentication system, and receive a yes/no
response as to whether the user has been authenticated. Thus, the
PPVPN provider does not have access to the actual authentication
database, but it can use it on behalf of the PPVPN user to provide
remote access authentication.
Specific cryptographic techniques for handling authentication are
described in the following sections.
5.2.5. Cryptographic Techniques for Authenticating Identity
Cryptographic techniques offer several mechanisms for authenticating
the identity of devices or individuals. These include the use of
shared secret keys, one-time keys generated by accessory devices or