software, user-ID and password pairs, and a range of public-private
key systems. Another approach is to use a hierarchical Certificate
Authority system to provide digital certificates.
This section describes or provides references to the specific
cryptographic approaches for authenticating identity. These
approaches provide secure mechanisms for most of the authentication
scenarios required in operating a PPVPN.
5.3. Access Control Techniques
Access control techniques include packet-by-packet or packet flow -
by - packet flow access control by means of filters and firewalls, as
well as by means of admitting a "session" for a
control/signaling/management protocol that is being used to implement
PPVPNs. Enforcement of access control by isolated infrastructure
addresses is discussed elsewhere in this document.
We distinguish between filtering and firewalls primarily by the
direction of traffic flow. We define filtering as being applicable
to unidirectional traffic, whereas a firewall can analyze and control
both sides of a conversation.
There are two significant corollaries of this definition:
- Routing or traffic flow symmetry: A firewall typically requires
routing symmetry, which is usually enforced by locating a firewall
where the network topology assures that both sides of a
conversation will pass through the firewall. A filter can then
operate upon traffic flowing in one direction without considering
traffic in the reverse direction.
- Statefulness: Because it receives both sides of a conversation, a
firewall may be able to obtain a significant amount of information
concerning that conversation and to use this information to
control access. A filter can maintain some limited state
information on a unidirectional flow of packets, but it cannot
determine the state of the bi-directional conversation as
precisely as a firewall can.
5.3.1. Filtering
It is relatively common for routers to filter data packets. That is,
routers can look for particular values in certain fields of the IP or
higher level (e.g., TCP or UDP) headers. Packets that match the
criteria associated with a particular filter may be either discarded
or given special treatment.
In discussing filters, it is useful to separate the filter
characteristics that may be used to determine whether a packet
matches a filter from the packet actions that are applied to packets
that 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 determines whether a particular packet matches a
filter based solely on the filter definition, on normal forwarding
information (such as the next hop for a packet), and on the
characteristics of that individual packet. Typically, stateless
filters may consider the incoming and outgoing logical or physical
interface, information in the IP header, and information in higher
layer headers such as the TCP or UDP header. Information in the
IP header to be considered may, for example, include source and
destination IP address, Protocol field, Fragment Offset, and TOS
field. Filters may also consider fields in the TCP or UDP header
such as the Port fields and 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 that 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 that are part of a DoS or DDoS
attack, or packets that are trying to access forbidden
resources (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 also be counted
and/or logged, of course.
- 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 that match a particular
filter may be limited to a specified bandwidth. Packets and/or
bytes would be counted and forwarded normally up to the
specified limit. Excess packets may be discarded or marked
(for example, by setting a "discard eligible" bit in the IP ToS
field or the MPLS EXP field).
- Forward and Copy
It is useful in some cases not only to forward some set of
packets normally, but also to 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 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 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 on the intended use of
the filters. For example, for some uses a filter may be turned on
all the time in order to set CoS, to prevent an attack, or to
mitigate the effect of a possible future attack. In this case it
is likely that the service provider will want the filter to have
minimal or no impact on performance. In other cases, a filter may
be turned on only in response to a major attack (such as a major
DDoS attack). In this case a greater performance impact may be
acceptable to some service providers.
A key consideration with the use of packet filters is that they
can provide few options for filtering packets carrying encrypted
data. Because the data itself is not accessible, only packet
header information or other unencrypted fields can be used for
filtering.
5.3.2. Firewalls
Firewalls provide a mechanism for control over traffic passing
between different trusted zones in the PPVPN model, or between a
trusted zone and an untrusted zone. Firewalls typically provide much
more functionality than filters, as 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, or acting as a TCP connection proxy. 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 it is a part of the basic VPN
mechanism. An exception to the total isolation of VPNs is the case
of "extranets", which allow specific external access to a user’s VPN,
potentially from another VPN. Firewalls can be used to provide the
services required for secure extranet implementation.
In a PPVPN, firewalls can be applied between the public Internet and
user VPNs, in cases where Internet access services are offered by the
provider to the VPN user sites. In addition, firewalls may be
applied between VPN user sites and any shared network-based services
offered by the PPVPN provider.
Firewalls may be applied to help protect PPVPN core network functions
from attacks originating from the Internet or from PPVPN user sites,
but typically other defensive techniques will be used for this
purpose.
Where firewalls are employed as a service to protect user VPN sites
from the Internet, different VPN users, and even different sites of a
single VPN user, may have varying firewall requirements. The overall
PPVPN logical and physical topology, along with the capabilities of
the devices implementing the firewall services, will have a
significant effect on the feasibility and manageability of such
varied firewall service offerings.
Another consideration with the use of firewalls is that they can
provide few options for handling packets carrying encrypted data. As
the data itself is not accessible, only packet header information,
other unencrypted fields, or analysis of the flow of encrypted
packets can be used for making decisions on accepting or rejecting
encrypted traffic.
5.3.3. Access Control to Management Interfaces
Most of the security issues related to management interfaces can be
addressed through the use of authentication techniques 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 that they are only accessible out of band, through a
system that is physically or logically separated from the rest of the
PPVPN infrastructure.
Where management interfaces are accessible in-band within the PPVPN
domain, filtering or firewalling techniques can be used to restrict
unauthorized in-band traffic from having access to management
interfaces. Depending on device capabilities, these filtering or
firewalling techniques can be configured either on other devices
through which the traffic might pass, or on the individual PPVPN
devices themselves.
5.4. Use of Isolated Infrastructure
One way to protect the infrastructure used for support of VPNs is to
separate the VPN support resources from the resources used for other
purposes (such as support of Internet services). In some cases, this
may require the use of physically separate equipment for VPN
services, or even a physically separate network.
For example, PE-based L3 VPNs may be run on a separate backbone not
connected to the Internet, or they may use separate edge routers from
those used to support Internet service. Private IP addresses (local
to the provider and non-routable over the Internet) are sometimes
used to provide additional separation.
It is common for CE-based L3VPNs to make use of CE devices that 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.
5.5. Use of Aggregated Infrastructure
In general it is not feasible to use a completely separate set of
resources for support of each VPN. 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, 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 use by different VPNs. Thus, a well-behaved VPN
user should be protected from possible misbehavior by other VPNs.
This requires that limits be placed on the amount of resources that
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 and CPU and memory resources may be reserved on a
per-VPN basis.
The techniques that 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.
The use of aggregated infrastructure allows the service provider to
benefit from stochastic multiplexing of multiple bursty flows and may
also, in some cases, thwart traffic pattern analysis by combining the
data from multiple VPNs.
5.6. Service Provider Quality Control Processes
Deployment of provider-provisioned VPN services requires a relatively
large amount of configuration by the service provider. For example,
the service provider has 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.
5.7. Deployment of Testable PPVPN Service
This refers to solutions that can readily be tested for correct
configuration. For example, for a point-point VPN, checking that the
intended connectivity is working largely ensures that there is not
connectivity to some unintended site.
6. Monitoring, Detection, and Reporting of Security Attacks
A PPVPN service may be subject to attacks from a variety of security
threats. Many threats are described in another part of this
document. Many of the defensive techniques described in this
document and elsewhere provide significant levels of protection from
a variety of threats. However, in addition to silently employing
defensive techniques to protect against attacks, PPVPN services can
add value for both providers and customers by implementing security-
monitoring systems that detect and report on any security attacks
that occur, regardless of whether the attacks are effective.
Attackers often begin by probing and analyzing defenses, so systems
that 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 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 to 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 Provider Edge (PE),
Customer Edge (CE), and/or Provider backbone (P) devices. Security
monitoring systems should have the ability to actively retrieve
information from devices (e.g., SNMP get) or to passively receive
reports from devices (e.g., SNMP notifications). The specific
information exchanged will depend on the capabilities of the devices
and on the type of VPN technology. Particular care should be given
to securing the communications channel between the monitoring systems
and the PPVPN devices.
The CE, PE, and P devices should employ efficient methods to acquire
and communicate the information needed by the security monitoring
systems. It is important that the communication method between PPVPN
devices and security monitoring systems be designed so that it will
not disrupt network operations. As an example, multiple attack
events may be reported through a single message, rather than allow
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. The specific reports will depend on the
capabilities of the devices, the security monitoring system, the type
of VPN, and the service level agreements between the provider and
customer.
7. User Security Requirements
This section defines a list of security-related requirements that the
users of PPVPN services may have for their PPVPN service. Typically,
these translate into requirements 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 or all of these
security requirements. 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.
7.1. Isolation
A virtual private network usually defines "private" as isolation from
other PPVPNs and the Internet. More specifically, isolation has
several components, which are discussed in the following sections.
7.1.1. Address Separation
A given PPVPN can use the full Internet address range, including
private address ranges [RFC1918], without interfering with other
PPVPNs that use PPVPN services from the same service provider(s).
When Internet access is provided (e.g., by the same service provider
that is offering PPVPN service), NAT functionality may be needed.
In layer-2 VPNs, the same requirement exists for the layer 2
addressing schemes, such as MAC addresses.
7.1.2. Routing Separation
A PPVPN core must maintain routing separation between the trusted
zones. This means that routing information must not leak from any
trusted zone to any other, unless the zones are specifically
engineered this way (e.g., for Internet access.)
In layer-2 VPNs, the switching information must be kept separate
between the trusted zones, so that switching information of one PPVPN
does not influence other PPVPNs or the PPVPN core.
7.1.3. Traffic Separation
Traffic from a given trusted zone must never leave this zone, and
traffic from another zone must never enter this zone. Exceptions are
made where zones are is specifically engineered that way (e.g., for
extranet purposes or Internet access.)
7.2. Protection
The common perception is that a completely separated "private"
network has defined entry points and is only subject to attack or
intrusion over those entry points. By sharing a common core, a PPVPN
appears to lose some of these clear interfaces to networks outside
the trusted zone. Thus, one of the key security requirements of
PPVPN services is that they offer the same level of protection as
private networks.
7.2.1. Protection against Intrusion
An intrusion is defined here as the penetration of a trusted zone
from outside. This could be from the Internet, another PPVPN, or the
core network itself.
The fact that a network is "virtual" must not expose it to additional
threats over private networks. Specifically, it must not add new
interfaces to other parts outside the trusted zone. Intrusions from
known interfaces such as Internet gateways are outside the scope of
this document.
7.2.2. Protection against Denial-of-Service Attacks
A denial-of-service (DoS) attack aims at making services or devices
unavailable to legitimate users. In the framework of this document,
only those DoS attacks are considered that are a consequence of
providing network service through a VPN. 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 it would be if the same network were private.
7.2.3. Protection against Spoofing
It must not be possible to violate the integrity of a PPVPN by
changing the sender identification (source address, source label,
etc) of traffic in transit. For example, if two CEs are connected to
the same PE, it must not be possible for one CE to send crafted
packets that make the PE believe those packets are coming from the
other CE, thus inserting them into the wrong PPVPN.
7.3. Confidentiality
This requirement means that data must be cryptographically secured in
transit over the PPVPN core network to avoid eavesdropping.
7.4. CE Authentication
Where CE authentication is provided, it is not possible for an
outsider to install a CE and pretend to belong to a specific PPVPN to
which this CE does not belong in reality.
7.5. Integrity
Data in transit must be secured in such a manner that it cannot be
altered or that any alteration may be detected at the receiver.
7.6. Anti-replay
Anti-replay means that data in transit cannot be recorded and
replayed later. To protect against anti-replay attacks, the data
must be cryptographically secured.
Note: Even private networks do not necessarily meet the requirements
of confidentiality, integrity, and anti-reply. Thus, when private
and "virtually private" PPVPN services are compared, these
requirements are only applicable if the comparable private service
also included these services. However, the fact that VPNs operate
over a shared infrastructure may make some of these requirements more
important in a VPN environment than in a private network environment.
8. Provider Security Requirements
In this section, we discuss additional security requirements that the
provider may have in order to secure its network infrastructure as it
provides PPVPN services.
The PPVPN service provider requirements defined here are the
requirements for the PPVPN core in the reference model. The core
network can be implemented with different types of network
technologies, and each core network may use different technologies to
provide the PPVPN services to users with different levels of offered
security. Therefore, a PPVPN service provider may fulfill any number
of the security requirements listed in this section. This document
does not state that a PPVPN must fulfill all of these requirements to
be secure.
These requirements are focused on 1) how to protect the PPVPN core
from various attacks outside the core, including PPVPN users and
non-PPVPN alike, both accidentally and maliciously, and 2) how to
protect the PPVPN user VPNs and sites themselves. Note that a PPVPN
core is not more vulnerable against attacks than a core that does not
provide PPVPNs. However, providing PPVPN services over such a core
may lead to additional security requirements, if only because most
users are expecting higher security standards in a core delivering
PPVPN services.
8.1. Protection within the Core Network
8.1.1. Control Plane Protection
- Protocol Authentication within the Core:
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 using 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.