[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4381

Network Working Group                             Michael Behringer
Internet Draft                                   Cisco Systems, Inc.
Category: Informational
November 2001
Expires: May 2002

            Analysis of the Security of the MPLS Architecture

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-

   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."

   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at

NOTE: Version 01 of this draft has not changed from version 00. I had
      no time yet to include received feedback.


This document analyses the security of the MPLS architecture,
especially in comparison with other VPN technologies such as ATM and
Frame Relay. The target audience is service providers and VPN users.
The document consists of two main parts: First the requirements for
security in VPN services are defined, second MPLS is examined with
respect to these requirements.

Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

The analysis shows that MPLS networks can be equally secured as
traditional layer-2 networks such as ATM and Frame Relay.

Table of Contents

1. Scope and Introduction
2. Security Requirements of MPLS Networks
3. Analysis of MPLS Security
4. What MPLS Doesn't Provide
5. Summary and Conclusions
Author's Address
Full Copyright Statement

1. Scope and Introduction

Many enterprises are thinking of replacing traditional layer-2 VPNs
such as ATM or Frame Relay (FR) with MPLS based services. As MPLS
(multi protocol label switching) is becoming a more wide-spread
technology for providing VPN (virtual private network) services, the
security of the MPLS architecture is of increasing concern to service
providers and VPN customers. This paper gives an overview of the
security of the MPLS architecture for both service providers and MPLS
users, and compares it with traditional layer-2 services from a
security perspective. The focus is specifically on the MPLS/BGP VPN
architecture as described in [RFC2547].

This paper assumes that the MPLS core network is trusted and provided
in a secure manner. Thus it does not address basic security concerns
such as securing the network elements against unauthorised access,
misconfigurations of the core, internal (within the core) attacks and
the likes. Should a customer not wish to assume the service provider
network as trusted it becomes necessary to use additional security
mechanisms such as IPsec over the MPLS infrastructure.

Analysis of the security features of routing protocols is only covered
to the extend where it influences MPLS. IPsec technology is also not
covered, except to highlight the combination of MPLS with IPsec.

This paper is targeted at technical staff of service providers and
enterprises. Knowledge of the basic MPLS architecture is required to
understand this paper.

Security of the MPLS Architecture                              page 2 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

2. Security Requirements of MPLS Networks

Both service providers offering MPLS services and customers using them
have specific demands for the security of this special VPN solution.
Mostly they compare MPLS based solutions with traditional layer 2 based
VPN solutions such as Frame Relay and ATM, since these are widely
deployed and accepted. This section outlines the security requirements
that are typically made in MPLS networks. The following section
discusses if and how MPLS addresses these requirements, for both the
MPLS core and the connected VPNs.

2.1 Address Space, Routing and Traffic Separation

Between two non-intersecting VPNs of an MPLS VPN service it is assumed
that the address space between different VPNs is entirely independent.
This means that for example two non-intersecting VPNs must be able to
both use the 10/8 network without any interference. In addition traffic
from one VPN must never enter another VPN. This includes routing
protocols, so that also routing is seperate per VPN. Specifically:

* Any VPN must be able to use the same address space as any other VPN.
* Any VPN must be able to use the same address space as the MPLS core.
* Traffic from one VPN must never flow to another VPN.
* Routing between any two VPNs must be independent.
* Routing between any VPN and the core must be independent.

>From a security point of view the basic requirement is to avoid that
packets destined to a host a.b.c.d within a given VPN reach a host with
the same address in another VPN or the core.

2.2 Hiding of the MPLS Core Structure

The internal structure of the MPLS core network (PE and P elements)
should not be visible to outside networks (Internet or any connected
VPN). Whilst a breach of this requirement does not lead to a security
problem itself, many service providers feel that it is advantageous if
the internal addressing and network structure remains hidden to the
outside world. A strong argument is that DoS attacks against a core
router for example are much easier to carry out if an attacker knows
the address. Where addresses are not known, they can be guessed, but
with this attacks become more difficult. Ideally the MPLS core should
be as invisible to the outside world as a comparable layer 2 (e.g.,
frame relay, ATM) infrastructure.

Note that security should never rely on obscurity, i.e., the hiding of
information. On the contrary services should be equally secure if the
implementation is known. However, there is a strong market perception

Security of the MPLS Architecture                              page 3 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

that hiding of details is advantageous. This point addresses that
market perception.

2.3 Resistance to Attacks

There are two basic types of attacks: Denial-of-Service (DoS) attacks,
where resources become unavailable to authorised users, and intrusions,
where resources become available to un-authorised users.

For attacks that give unauthorised access to resources (intrusions)
there are two basic ways to protect the network: Firstly, to harden
protocols that could be abused (e.g., telnet to a router), secondly to
make the network as inaccessible as possible. The latter is achieved by
a combination of packet filtering or firewalling and address hiding, as
discussed above.

DoS attacks are easier to execute, since in the simplest case a known
IP address might be enough to attack a machine. This can be done using
normal "allowed" traffic, but higher than normal packet rates, so that
other users cannot access the targeted machine. The only way to be
certain not be vulnerable to this kind of attack is to make sure that
machines are not reachable, again by packet filtering and optionally
address hiding.

MPLS networks must provide at least the same level of protection
against both forms as current layer 2 networks. Note that this paper
concentrates on protecting the core network against attacks from the
"outside", i.e., the Internet and connected VPNs. Protection against
attacks from the "inside", i.e., if an attacker has logical or physical
access to the core network is not considered here, since any network
can be attacked with access from the inside.

2.4 Impossibility of Label Spoofing

Assuming the address and traffic separation as discussed above, a
potential attacker might try to gain access to other VPNs by inserting
packets with a label that he doesn't "own". This could be done from the
outside, i.e., another CE router or from the Internet, or from within
the MPLS core. The latter case (from within the core) will not be
discussed, since the assumption is that the core network is provided in
a secure manner. Should protection against an insecure core be required
it is necessary to run IPsec on top of the MPLS infrastructure.

It is required that VPNs cannot abuse the label mechanisms or protocols
to gain un-authorised access to other VPNs or the core.

Security of the MPLS Architecture                              page 4 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

3. Analysis of MPLS Security

In this section the MPLS architecture is analysed with respect to the
security requirements listed above.

3.1 Address Space, Routing and Traffic Separation

MPLS allows distinct VPNs to use the same address space, which can also
be private address space [RFC1918]. This is achieved by adding a 64 bit
route distinguisher (RD) to each IPv4 route, making VPN-unique
addresses also unique in the MPLS core. This "extended" address is also
called a "VPN-IPv4 address". Thus customers of an MPLS service do not
need to change current addressing in their networks.

There is only one exception, which is the IP addresses of the PE
routers the CE routers are peering with, in the case of using routing
protocols between CE and PE routers (for static routing between PE and
CE this is not an issue). Routing protocols on the CE routers need to
have configured the address of the peer PE router in the core, to be
able to "talk" to the PE router. This address must be unique from the
CE router's perspective. In an environment where the service provider
manages also the CE routers as CPE, this can be made invisible to the
customer. The address space on the CE-PE link (including the peering PE
address) must be considered as part of the VPN address space.

Routing separation between the VPNs can also be achieved. Every PE
router maintains a separate Virtual Routing and Forwarding instance
(VRF) for each connected VPN. Each VRF on the PE router is populated
with routes from one VPN, through statically configured routes or
through routing protocols that run between the PE and the CE router.
Since every VPN results in a separate VRF there will be no
interferences between the VPNs on the PE router.

Across the MPLS core to the other PE routers this separation is
maintained by adding unique VPN identifiers in multi-protocol BGP, such
as the route distinguisher. VPN routes are exclusively exchanged by MP-
BGP across the core, and this BGP information is not re-distributed to
the core network but only to the other PE routers, where the
information is kept again in VPN specific VRFs. Thus routing across an
MPLS network is separate per VPN.

Traffic separation is achieved by prepending VPN-specific labels to the
packets, so that a packet can also on the core be identified as
belonging to a specific VPN.

Given the addressing, routing and traffic separation across an MPLS
core network, it can be assumed that MPLS offers in this respect the

Security of the MPLS Architecture                              page 5 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

same security as comparable layer-2 VPNs such as ATM or Frame Relay. It
is not possible to intrude into other VPNs through the MPLS could,
unless this has been configured specifically.

3.2 Hiding of the MPLS Core Structure

For reasons of security service providers and end-customers do not
normally want their network topology revealed to the outside. This is
done to make attacks more difficult: If an attacker doesn't know the
target he can only guess the IP addresses to attack. Since most DoS
attacks don't provide direct feedback to the attacker it would be
difficult to attack the network. It has to be mentioned specifically
that information hiding as such does not provide security. However, in
the market this is a perceived requirement.

With a known IP address a potential attacker can launch a DoS attack
more easily against that device. So the ideal is to not reveal any
information of the internal network to the outside. This applies
equally to the customer networks as to the MPLS core. In practice a
number of additional security measures have to be taken, most of all
extensive packet filtering.

MPLS does not reveal unnecessary information to the outside, not even
to customer VPNs. The addressing of the core can be done with private
addresses [RFC1918] or public addresses. Since the interface to the
VPNs as well as potentially to the Internet is BGP, there is no need to
reveal any internal information. The only information required in the
case of a routing protocol between PE and CE is the address of the PE
router. If this is not desired static routing on unnumbered interfaces
can be configured between the PE and CE. With this measure the MPLS
core can be kept completely hidden.

Customer VPNs will have to advertise their routes as a minimum to the
MPLS core (dynamically or statically), to ensure reachability across
the MPLS cloud. Whilst this could be seen too "open", the following has
to be noted: Firstly, the information known to the MPLS core is not
about specific hosts, but networks (routes); this offers some degree of
abstraction. Secondly, in a VPN-only MPLS network (i.e., no shared
Internet access) this is equal to existing layer-2 models, where the
customer has to trust the service provider to some degree. Also in a FR
or ATM network routing information about the VPNs can be seen on the
core network.

In a VPN service with shared Internet access the service provider will
typically announce the routes of customers that wish to use the
Internet to his upstream or peer providers. This can be done via a NAT
function to further obscure the addressing information of the

Security of the MPLS Architecture                              page 6 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

customers' networks. In this case the customer does not reveal more
information to the general Internet than with a general Internet
service. Core information will still not be revealed at all, except for
the peering address(es) of the PE router(s) that hold(s) the peering
with the Internet.

In summary, in a pure MPLS-VPN service, where no Internet access is
provided, the information hiding is as good as on a comparable FR or
ATM network: No addressing information is revealed to third parties or
the Internet. If a customer chooses to access the Internet via the MPLS
core he will have to reveal the same addressing structure as for a
normal Internet service. NAT can be used for further address hiding.

If an MPLS network has no interconnections to the Internet, this is
equal to FR or ATM networks. With an Internet access from the MPLS
cloud the service provider has to reveal at least one IP address (of
the peering PE router) to the next provider, and thus the outside

3.3 Resistance to Attacks

Section 3.1 shows that it is not possible to directly intrude into
other VPNs. Another possibility is to attack the MPLS core, and try to
attack other VPNs from there. There are two basic ways the MPLS core
can be attacked:

1. By attacking the PE routers directly.
2. By attacking the signaling mechanisms of MPLS (mostly routing)

To attack an element of an MPLS network it is first necessary to know
this element, that is, its address. As discussed in section 3.2 it is
possible to hide the addressing structure of the MPLS core to the
outside world. Thus an attacker does not know the IP address of any
router in the core that he wants to attack. The attacker could now
guess addresses and send packets to these addresses. However, due to
the address separation of MPLS each incoming packet will be treated as
belonging to the address space of the customer. Thus it is impossible
to reach an internal router, even through IP address guessing. There is
only one exception to this rule, which is the peer interface of the PE

The routing between the VPN and the MPLS core can be configured two

1. Static; in this case the PE routers are configured with static
routes to the networks behind each CE, and the CEs are configured to
statically point to the PE router for any network in other parts of the

Security of the MPLS Architecture                              page 7 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

VPN (mostly a default route).  There are now two sub-cases: The static
route can point to the IP address of the PE router, or to an interface
of the CE router (e.g., serial0).

2. Dynamic; here a routing protocol (e.g., RIP, OSPF, BGP) is used
exchange the routing information between the CE and the PE at each
peering point.

In the case of a static route from the CE router to the PE router,
which points to an interface, the CE router doesn't need to know any IP
address of the core network, not even of the PE router. This has the
disadvantage of a more extensive (static) configuration, but from a
security point of view is preferable to the other cases. It is now
possible to configure packet filters on the PE interface to deny any
packet to the PE interface. This way the router cannot be attacked.

In all other cases, each CE router needs to know at least the router ID
(RID; peer IP address) of the PE router in the MPLS core, and thus has
a potential destination for an attack. One could imagine various
attacks on various services running on a router. In practice access to
the PE router over the CE-PE interface can be limited to the required
routing protocol by using ACLs (access control lists). This limits the
point of attack to one routing protocol, for example BGP. A potential
attack could be to send an extensive number of routes, or to flood the
PE router with routing updates. Both could lead to a DoS, however, not
to unauthorised access.

To restrict this risk it is necessary to configure the routing protocol
on the PE router as securely as possible. This can be done in various

* By ACL, allow the routing protocol only from the CE router, not from
anywhere else. Furthermore, no access other than that should be allowed
to the PE router in the inbound ACL on each CE interface.

* Where available, configure MD-5 authentication for routing protocols.
This is available for BGP [RFC2385], OSPF [RFC2154] and RIP2 [RFC2082]
for example. It avoids that packets could be spoofed from other parts
of the customer network than the CE router. Note that this requires
service provider and customer to agree on a shared secret between all
CE and PE routers. Note that it is necessary to do this for all VPN
customers, it is not sufficient to do this for the customer with the
highest security requirements.

* To configure where available parameters of the routing protocol, to
further secure this communication. In BGP for example it is possible to
configure dampening, which limits the number of routing interactions.

Security of the MPLS Architecture                              page 8 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

Also, a maximum number of routes accepted per VRF should be configured
where possible.

In summary, it is not possible to intrude from one VPN into other VPNs,
or the core. However, it is theoretically possible to exploit the
routing protocol to execute a DoS attack against the PE router. This in
turn might have negative impact on other VPNs on this PE router. For
this reason PE routers must be extremely well secured, especially on
their interfaces to the CE routers. ACLs must be configured to limit
access only to the port(s) of the routing protocol, and only from the
CE router. MD5 authentication in routing protocols should be used on
all PE-CE peerings. It is easily possible to track the source of such a
potential DoS attack. Without dynamic routing between CEs and PEs the
security is equivalent to the security of ATM or Frame Relay networks.

3.4 Label Spoofing

Within the MPLS network packets are not forwarded based on the IP
destination address, but based on labels that are pre-pended by the PE
routers. Similar to IP spoofing attacks, where an attacker replaces the
source or destination IP address of a packet, it is also theoretically
possible to spoof the label of an MPLS packet. In the first section the
assumption was made that the core network is trusted. If this
assumption cannot be made IPsec must be run over the MPLS cloud. Thus
in this section the emphasis is on whether it is possible to insert
packets with (wrong) labels into the MPLS network from the outside,
i.e., from a VPN (CE router) or from the Internet.

Principally the interface between any CE router and its peering PE
router is an IP interface, i.e., without labels. The CE router is
unaware of the MPLS core, and thinks it is sending IP packets to a
simple router. The "intelligence" is done in the PE device, where based
on the configuration, the label is chosen and pre-pended to the packet.
This is the case for all PE routers, towards CE routers as well as the
upstream service provider. All interfaces into the MPLS cloud only
require IP packets, without labels.

For security reasons a PE router should never accept a packet with a
label from a CE router. [RFC3031] specifies: "Therefore, when a labeled
packet is received with an invalid incoming label, it MUST be
discarded, UNLESS it is determined by some means (not within the scope
of the current document) that forwarding it unlabeled cannot cause any
harm." Since accepting labels on the CE interface would allow passing
packets to other VPNs it is not permitted by the RFC.

There remains the possibility to spoof the IP address of a packet that
is being sent to the MPLS core. However, since there is strict

Security of the MPLS Architecture                              page 9 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

addressing separation within the PE router, and each VPN has its own
VRF, this can only do harm to the VPN the spoofed packet originated
from, in other words, a VPN customer can attack himself. MPLS doesn't
add any security risk here.

3.5 Comparison with ATM/FR VPNs

ATM and FR VPN services often enjoy a very high reputation in terms of
security. Although ATM and FR VPNs can also be provided in a secure
manner, it has been reported that also these technologies can have
severe security vulnerabilities [DataComm]. Also in ATM/FR the security
depends on the configuration of the network being secure, and errors
can also lead to security problems.

4. What MPLS Doesn't Provide

4.1 Protection against Misconfigurations of the Core and Attacks
"within" the Core

The security mechanisms discussed here assume correct configuration of
the involved network elements on the MPLS core network (PE and P
routers). Deliberate or inadvertent misconfigurations from SP staff may
result in undesired behaviour including severe security leaks.

Note that this paragraph specifically refers to the core network, i.e.,
the PE and P elements. Misconfiguration of any of the customer side
elements such as the CE router are covered by the security mechanisms
above. This means that a potential attacker must have access to either
PE or P routers to gain advantage from misconfigurations. If an
attacker has access to core elements, or is able to insert into the
core additional equipment, he will be able to attack both the core
network as well as the connected VPNs. Thus the following is important:

* To avoid the risk of misconfigurations it is important that the
equipment is easy to configure, and that SP staff have the appropriate
training and experience when configuring the network.

* To avoid the risk of "internal" attacks the MPLS core network must be
properly secured. This includes network element security, management
security, physical security of the service provider infrastructure,
access control to service provider installations and other standard SP
security mechanisms.

MPLS can only provide a secure service if the core network is provided
in a secure fashion. This paper assumes this to be the case.

Security of the MPLS Architecture                              page 10 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

4.2 Data Encryption, Integrity and Origin Authentication

MPLS itself does not provide encryption, integrity or authentication
services. If these are required IPsec should be used over the MPLS
infrastructure. The same applies to ATM and Frame Relay: Also here
IPsec can provide these missing services.

4.3 Customer Network Security

MPLS can be secured so that it is comparable with other VPN services.
However, the security of the core network is only one factor for the
overall security of a customer's network. Threats in today's networks
do not only come from the "outside" connection, but also from the
"inside" and from other entry points (modems for example). To reach a
good security level for a customer network in an MPLS infrastructure,
MPLS security is necessary but not sufficient. See also [RFC2196] for
more information on how to secure a network.

5. Summary and Conclusions

MPLS provides full address and traffic separation as in traditional
layer-2 VPN services. It hides addressing structures of the core and
other VPNs, and it is in today's understanding not possible from the
outside to intrude into the core or other VPNs abusing the MPLS
mechanisms. It is also not possible to intrude into the MPLS core if
this is properly secured. However, there is a significant difference
between MPLS based VPNs and for example FR or ATM based VPNs: The
control structure of the core is on layer 3 in the case of MPLS. This
caused significant skepticism in the industry towards MPLS, since this
might open the architecture to DoS attacks from other VPNs or the
Internet (if connected).

As shown in this paper, it is possible to secure an MPLS infrastructure
to the same level of security than a comparable ATM or FR service. It
is also possible to offer Internet connectivity to MPLS VPNs in a
secure manner, and to interconnect different VPNs via firewalls.
Although ATM and FR services have a strong reputation with regard to
security, it has been shown that also in these networks security
problems can exist [DataComm].

As far as attacks from within the MPLS core are concerned, all VPN
classes (MPLS, FR, ATM) have the same problem: If an attacker can
install a sniffer, he can read information in all VPNs, and if he has
access to the core devices, he can execute a large number of attacks,
from packet spoofing to introducing a new peer routers. There are a
number of precautions measures outlined above that a service provider

Security of the MPLS Architecture                              page 11 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

can use to tighten security of the core, but the security of the MPLS
architecture depends on the security of the service provider. If the
service provider is not trusted, the only way to fully secure a VPN
against attacks from the "inside" of the VPN service is to run IPsec on
top, from the CE devices or beyond.

This paper discussed many aspects of MPLS security. It has to be noted
explicitly that the overall security of an MPLS architecture depends on
all components, and is determined by the security of the weakest part
of the solution. For example a perfectly secured static MPLS network
with secured Internet access and secure management is still open to
many attacks if there is a weak remote access solution in place.

Author's Address

Michael H. Behringer
Cisco Systems
Avda de la Vega, 15
28100 Alcobendas, Madrid
E-mail: mbehring@cisco.com


[DataComm] "Frame Relay and ATM: Are they really secure?". Data
Communications Report, Vol 15, No 4, February 2000.

[RFC1918] "Address Allocation for Private Internets". Y. Rekhter et al;
February 1996. (http://search.ietf.org/rfc/rfc1918.txt)

[RFC2082] "RIP-2 MD5 Authentication". F. Baker, R. Atkinson. January
1997. (http://search.ietf.org/rfc/rfc2082.txt)

[RFC2154] "OSPF with Digital Signatures". S. Murphy, M. Badger, B.
Wellington. June 1997. (http://search.ietf.org/rfc/rfc2154.txt)

[RFC2196] "Site Security Handbook". B. Fraser. September 1997.

[RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature
Option". A. Heffernan. August 1998.

Security of the MPLS Architecture                              page 12 
Internet Draft    draft-behringer-mpls-security-01.txt    November 2001

[RFC2547] "BGP/MPLS VPNs". E. Rosen, Y. Rekhter. March 1999.

[RFC2827] "Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing". P. Ferguson, D.
Senie. May 2000. (http://search.ietf.org/rfc/rfc2827.txt)

[RFC2828] "Internet Security Glossary". R. Shirey. May 2000.

[RFC3013] "Recommended Internet Service Provider Security Services and
Procedures". T. Killalea. November 2000.

[RFC3031] "Multiprotocol Label Switching Architecture". E. Rosen, A.
Viswanathan, R. Callon. January

Full Copyright Statement

   Copyright (C) The Internet Society (2000). 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

   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

Security of the MPLS Architecture                            page 13

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/