should not accept MPLS packets from its external interfaces (i.e.,
interfaces to CE devices or to other providers’ networks) unless the
top label of the packet was legitimately distributed to the system
from which the packet is being received. If the packet’s incoming
interface leads to a different SP (rather than to a customer), an
appropriate trust relationship must also be present, including the
trust that the other SP also provides appropriate security measures.
If the SP is providing the VPN service by using an IP (rather than an
MPLS) encapsulation, or if it accepts IP-encapsulated VPN packets
from other SPs, it should apply filtering at its borders so that it
does not accept from other SPs or from customers any IP packets that
are addressed to the PE routers, unless appropriate trust
relationships are in place.
Cryptographic authentication of the encapsulated data packets is
certainly advantageous when there are multiple SPs providing a single
VPN.
When a dynamic routing protocol is run on the link between a CE
router and a PE router, routing instability in the private network
may have an effect on the PE router. For example, an unusually large
number of routing updates could be sent from the CE router to the PE
router, placing an unusually large processing load on the PE router.
This can potentially be used as a Denial-of-Service (DoS) attack on
the PE router.
This issue can be mitigated via resource partitioning in the PE, in
order to limit the amount of resources (e.g., CPU and memory) that
any one VPN is permitted to use in PE routers. Also, rate limits may
be applied to the routing traffic sent from the CE to the PE.
Alternately, when this problem is detected, the CE-to-PE interface
may be shut down.
Network management traffic from the CE to the PE may be rate limited
(for example, to prevent network management traffic from CE to PE to
be used in a DoS attack).
6.3. Security Framework Template
Section 9 of [L2VPN-SEC-FRMWRK] provides "a brief template that may
be used to evaluate and summarize how a given PPVPN [Provider-
Provisioned Virtual Private Network] approach (solution) measures up
against the PPVPN Security Framework". It further states "an
evaluation using this template should appear in the applicability
statement for each PPVPN approach". The purpose of this subsection
is to provide the information in the form required by this template.
Security requirements that are relevant only to L2VPNs are not
applicable and are not further discussed.
- Does the approach provides complete IP address space separation
for each L3VPN?
Yes.
The IP address prefixes from a particular VPN appear in their
native form only in routing tables that are specific to the
particular VPN. They are distributed in their native form only
by routing instances that are specific to the particular VPN.
When address prefixes from different VPNs are combined into a
common table, or distributed by a common mechanism, the address
prefixes are first prepended with a Route Distinguisher (RD).
The RD is a 64-bit quantity, structured so that globally unique
RD values can easily be created by an SP. As long as no two VPNs
are assigned the same RD value, complete IP address space
separation is provided. It is however possible for an SP to
misconfigure the RD assignments.
- Does the approach provide complete IP route separation for each
L3VPN?
Yes.
The distribution of routes is controlled by assigning import and
export Route Targets (RTs). A route that is exported from a VRF
carries an RT specified by the SP as an export RT for that VRF.
The route can be imported into other VRFs only if the RT that it
carries has been configured by the SP as an import RT for those
other VRFS. Thus, the SP has complete control over the set of
VRFs to which a route will be distributed. It is of course
possible for the SP to misconfigure the RT assignments.
- Does the approach provide a means to prevent improper cross-
connection of sites in separate VPNs?
This requirement is addressed in a way that is beyond the scope
of the VPN mechanisms.
In BGP/MPLS IP VPNs, an SP makes a particular site part of a
particular VPN by configuring the PE router’s interface to that
site to be associated with a particular VRF in that PE. The VRF
is configured with import and export RTs, and it is the way in
which VRFs are configured with RTs in the various PEs that
results in a particular set of sites being connected as a VPN.
Connecting the sites properly in this way is regarded as a
network management function, and the VPN scheme itself does not
provide a means to prevent misconfiguration.
The VPN scheme does not provide any particular method for
ensuring that a given interface from a PE leads to the CE that is
expected to be there. If a routing algorithm is run on a
particular PE/CE interface, any security procedures that the
routing algorithm provides (e.g., MD5 authentication of BGP
sessions) can be used; this is outside the scope of the VPN
scheme. Also, a CE can attach to a PE via an IPsec tunnel, if
this is desired, for a greater degree of security.
- Does the approach provide a means to detect improper cross-
connection of sites in separate VPNs?
The base specifications for BGP/MPLS IP VPNs do not provide a
means for detecting that a site has been connected to the wrong
VPN. However, the optional procedure specified in [CE-VERIF]
does provide such a means. Basically, each PE obtains, via
protocol, a secret from each CE to which it is directly attached.
When the routes from a given CE are distributed, the secret from
that CE is attached as an attribute of the route. This secret
will ultimately be distributed to any other CE that receives any
route from the given CE. A CE that is not supposed to be part of
a given VPN will not know the right secret, and if it is
connected to the given VPN the other CEs in that VPN will realize
that a CE that doesn’t know the proper secret has been connected
to the VPN.
- Does the approach protect against the introduction of
unauthorized packets into each VPN?
We must look separately at the various points at which one might
attempt to introduce unauthorized packets.
* Packets arriving at a PE over a PE/CE interface
If a given PE is directly connected to a given CE, the PE
will accept any packets that the CE sends it. The VPN scheme
has no special procedures for determining that these packets
actually came from the CE. However, various means of
securing the PE/CE connection can be used (for instance, the
PE and CE can be connected by an IPsec tunnel) if desired.
That is, this aspect of the requirement can be addressed by
means that are outside the scope of the VPN specification.
Once a packet has been accepted from a CE by a PE, the packet
is routed according to the VRF associated with that PE’s
interface to that CE. Such packets can only be sent along
routes that are in that VRF. There is no way a packet from a
CE can be routed to an arbitrary VPN. In particular, there
is nothing a VPN user can do to cause any particular packet
to be sent to the wrong VPN. So this aspect of the
requirement is fully addressed.
* Packets arriving at a PE over an interface from the backbone
The optional procedures of [MPLS/BGP-IPsec] can be used to
ensure that a packet that is received by a PE from the
backbone will not be recognized as a VPN packet unless it
actually is one. Those procedures also ensure that a
received VPN packet came from a particular PE and that it
carries the MPLS label that that PE put on it. These
procedures protect the packet from ingress PE to egress PE,
but do not protect the PE/CE interfaces.
If the optional procedures of [MPLS/BGP-IPsec] are not used,
then the following considerations apply.
Undetected corruption of the routing information carried in a
packet’s VPN encapsulation can result in misdelivery of the
packet, possibly to the wrong VPN.
If a packet enters an SP’s network on an interface other than
a PE/CE interface, the SP should ensure that the packet
either does not look like a VPN packet or else is not routed
to a PE router. This can be done in a variety of ways that
are outside the scope of the VPN scheme. For example, IP
packets addressed to the PE routers can be filtered, MPLS
packets (or, e.g., MPLS-in-IP) from outside the SP network
can be refused, etc.
In the case of a multi-provider L3VPN backbone, the SP will
have to know which interfaces lead to SPs that are VPN
partners, so that VPN packets can be allowed to flow on those
interfaces.
If the public Internet is used as the L3VPN backbone,
protection against unauthorized packets cannot be achieved by
the above measures. IPsec tunnels should always be used to
carry VPN traffic across the public Internet.
- Does the approach provide confidentiality (secrecy) protection,
sender authentication, integrity protection, or protection
against replay attacks for PPVPN user data?
If these are desired, they must be provided by mechanisms that
are outside the scope of the VPN mechanisms. For instance, the
users can use secure protocols on an end-to-end basis, e.g.,
IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc.
- Does the approach provide protection against unauthorized traffic
pattern analysis for PPVPN user data?
Preventing an observer from obtaining traffic pattern analysis
from the SP network is beyond the scope of the VPN mechanisms.
- Do the control protocol(s) used for each of the following
functions provide for message integrity and peer authentication?
* VPN membership discovery
This requirement is fully satisfied. Membership discovery is
done by means of BGP. Control message integrity and peer
authentication in BGP may be achieved by use of the TCP MD5
option.
* Tunnel establishment
The answer to this question depends of course on the tunnel
protocol and tunnel establishment protocol; a variety of
different tunneling schemes can be used in BGP/MPLS IP VPNs.
Thus, this question is out of scope.
In the common case where the tunnels are MPLS Label Switching
Routers (LSRs) established by LDP, then control message
integrity and peer authentication may be achieved by use of
the TCP MD5 option.
* VPN topology and reachability advertisement
With respect to PE-PE interactions, the relevant control
protocol is BGP, so control message integrity and peer
authentication can be achieved by use of the TCP MD5 option.
With respect to CE-PE interactions, the answer depends on the
protocol used for exchanging information between PE and CE,
as the security mechanisms (if any) of those protocols would
need to be used. In the common case where the PE/CE protocol
is BGP, the TCP MD5 option can be used.
* VPN provisioning and management
The protocols procedures for provisioning VPNs and managing
the PE routers are outside the scope of the VPN scheme.
* VPN monitoring and attack detection and reporting
The protocols and procedures for monitoring the VPNs are
outside the scope of the VPN scheme.
- What protection does the approach provide against PPVPN-specific
DoS attacks (i.e., inter-trusted-zone DoS attacks)?
* Protection of the service provider infrastructure against
Data Plane or Control Plane DoS attacks originated in a
private (PPVPN user) network and aimed at PPVPN mechanisms.
The PE/CE interfaces of a given VPN will generally be
addressable from within that VPN. Apart from that, a user
within an L3VPN has no more access to the service provider
infrastructure than does any user of the Internet.
Therefore, we will focus in this section on possible DoS
attacks against a PE router that may occur when traffic from
within a VPN is addressed to a PE router.
A user within the VPN may address traffic to a PE router and
may attempt to send an excessive amount of traffic to it.
Presumably, the PE routers will not accept unauthorized TCP
connections or Simple Network Management Protocol (SNMP)
commands, so such traffic will be thrown away; the danger is
that the PE may need to use a significant proportion of its
capacity to discard such traffic. However, this case is no
different than the case of any SP access router that attaches
to subscriber equipment. The presence of the VPN mechanisms
does not make the PE any more or less vulnerable to DoS
attacks from arbitrary end users.
* Protection of the service provider infrastructure against
Data Plane or Control Plane DoS attacks originated in the
Internet and aimed at PPVPN mechanisms.
DoS attacks of this sort can be prevented if the PE routers
are not addressable from the Internet. Alternatively, an SP
can apply address filtering at its boundaries so that packets
from the Internet are filtered if they are addressed to a PE
router.
* Protection of PPVPN users against Data Plane or Control Plane
DoS attacks originated from the Internet or from other PPVPN
users and aimed at PPVPN mechanisms.
Mechanisms already discussed prevent users in a VPN from
receiving packets from the Internet, unless this is
specifically allowed. In the case where it is specifically
allowed, it is no different than any other situation in which
a network is connected to the Internet, and there is no
special vulnerability to DoS attacks due to the L3VPN
mechanisms.
There is nothing to prevent a user in a VPN from mounting a
DoS attack against other users in the VPN. However, the
L3VPN mechanisms make this neither more nor less likely.
- Does the approach provide protection against unstable or
malicious operation of a PPVPN user network?
* Protection against high levels of, or malicious design of,
routing traffic from PPVPN user networks to the service
provider network.
If a dynamic routing algorithm is running on the PE/CE
interface, it can be used to mount an attack on the PE
router, by having the CE present the PE with an excessive
number of routing events. If an end user within a VPN
successfully attacks the routing algorithm of the VPN, that
might also result in an excessive number of routing events
being seen by the PE router. This sort of attack can be
ameliorated by having the PE limit the amount of its
resources that can be expended processing routing events from
a particular VPN. If the PE/CE routing algorithm is BGP,
then such mechanisms as route flap damping may be appropriate
as well.
* Protection against high levels of, or malicious design of,
network management traffic from PPVPN user networks to the
service provider network.
A user in a BGP/MPLS IP VPN has no more ability than any
Internet user to send management traffic to the service
provider network.
* Protection against worms and probes originated in the PPVPN
user networks, sent towards the service provider network.
A user in a BGP/MPLS IP VPN has no more ability than any
Internet user to send worms or probes to the service provider
network.
7. Addressing
Overlapping customer addresses are supported. There is no
requirement that such addresses be in conformance with [RFC1918].
There is no requirement that customer VPN addresses be distinct from
addresses in the SP network.
Any set of addresses used in the VPN can be supported, irrespective
of how they are assigned, how well they aggregate, and whether they
are public or private. However, the set of addresses that are
reachable from a given site must be unique.
Network address translation for packets leaving/entering a VPN is
possible and is transparent to the VPN scheme.
There is nothing in the architecture to preclude the mechanisms from
being extended to support IPv6, provided that the appropriate IPv6-
capable routing algorithms are in place. That is, PE/CE routing must
support IPv6, and the PE-PE BGP must support the labeled IPv6 address
family. The latter has not been specified, but its specification is
obvious from the specification of the labeled IPv4 address family.
The IGP used in the SP backbone need not be IPv6 capable in order to
support customer IPv6 networks.
In theory, the same could be said of other network layers, but in
practice a customer who has non-IP traffic to carry must expect to
carry it either in site-to-site IP tunnels or using some additional
service (such as a layer 2 service) from the SP.
Layer 2 addresses and identifiers are never carried across the SP
backbone.
No restrictions are placed on the customer’s addressing schemes or
policies. Note though that the SP may place restrictions on the
number of routes from a given customer site, or may charge
differentially depending on the number of such routes, and such
restrictions may have implications for the customer’s addressing
scheme. In particular, addressing schemes that facilitate route
aggregation on a per-site basis will result in the most efficient use
of the SP’s resources, and this may be reflected in SP charging
policies.
8. Interoperability and Interworking
Interoperability should be ensured by proper implementation of the
published standards.
Direct PE-PE interworking over the SP backbone with other VPN
solutions is not supported.
As all the different types of L3VPNs are IP networks, they can of
course interwork in the same way that any two IP networks can
interwork. For example, a single site can contain a CE router of one
VPN scheme and a CE router of another VPN scheme, and these CE
routers could be IGP peers, or they might even be the same CE router.
This would result in the redistribution of routes from one type of
VPN to the other, providing the necessary interworking.
9. Network Access
9.1. Physical/Link Layer Topology
The architecture and protocols do not restrict the link layer or the
physical layer in any manner.
9.2. Temporary Access
Temporary access via PPP is possible, using industry standard PPP-
based authentication mechanisms. For example:
- A dial-up user (or other PPP user) is authenticated by the PE,
using the SP’s AAA server, based on a login string or on the
number dialed.
- The SP’s AAA server returns a VPN-id to PE.
- The PE assigns the user to a VRF, based on that VPN-id.
- The user is then authenticated by a AAA server within the VPN
(i.e., managed by the customer rather than by the SP). This AAA
server would typically be addressed through the VRF (i.e., may be
in VPN’s private address space).
- The user gets disconnected if either authentication step is
unsuccessful.
IPsec access to a VRF is also possible. In this case, the security
association is between the end user and the SP.
In these ways, a user can access a BGP/MPLS IP VPN via the public
Internet.
There is no explicit support for mobility, other than what is stated
above.
9.3. Access Connectivity
Homing of a CE to two or more PEs is fully supported, whether or not
the PEs are on the same SP network.
If a CE is connected to two or more PEs, all its PE/CE links can be
used to carry traffic in both directions. In particular, traffic
from different ingress PEs to a particular CE may arrive at that CE
over different PE/CE links. This depends on the backbone network
routing between the CE and the various ingress PEs.
If a VRF on a particular ingress PE contains several routes to a
particular destination, then traffic from that ingress PE can be
split among these routes. If these routes end with different PE/CE
links, then traffic from that ingress PE will be split among those
links.
BGP contains a multitude of knobs that allow an SP to control the