In summary, it is not possible to intrude from one VPN into other
VPNs, or the core. However, it is theoretically possible to attack
the routing protocol port to execute a DoS attack against the PE
router. This in turn might have a negative impact on other VPNs on
this PE router. For this reason, PE routers must be extremely well
secured, especially on their interfaces to CE routers. ACLs must be
configured to limit access only to the port(s) of the routing
protocol, and only from the CE router. Further routing protocols’
security mechanisms such as MD5 authentication, maximum prefix
limits, and Time to Live (TTL) security mechanisms should be used on
all PE-CE peerings. With all these security measures, the only
possible attack is a DoS attack against the routing protocol itself.
BGP has a number of countermeasures such as prefix filtering and
damping built into the protocol, to assist with stability. It is
also easy 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
Similar to IP spoofing attacks, where an attacker fakes the source 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
spoofed labels into the MPLS network from the outside, i.e., from a
VPN (CE router) or from the Internet.
The interface between a 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 another 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. RFC 3031 [9] 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
potentially allow passing packets to other VPNs it is not permitted
by the RFC.
Thus, it is impossible for an outside attacker to send labeled
packets into the BGP/MPLS IP VPN core.
There remains the possibility to spoof the IP address of a packet
being sent to the MPLS core. Since there is strict address
separation within the PE router, and each VPN has its own VRF, this
can only harm the VPN the spoofed packet originated from; that is, a
VPN customer can attack only himself. MPLS doesn’t add any security
risk here.
The Inter-AS and Carrier’s Carrier cases are special cases, since on
the interfaces between providers typically packets with labels are
exchanged. See section 4 for an analysis of these architectures.
3.5. Comparison with ATM/FR VPNs
ATM and FR VPN services enjoy a very high reputation in terms of
security. Although ATM and FR VPNs can be provided in a secure
manner, it has been reported that these technologies also can have
security vulnerabilities [14]. In ATM/FR as in any other networking
technology, the security depends on the configuration of the network
being secure, and errors can also lead to security problems.
4. Security of Advanced BGP/MPLS IP VPN Architectures
The BGP/MPLS IP VPN architecture described in RFC 2547 [7] defines
the PE-CE interface as the only external interface seen from the
service provider network. In this case, the PE treats the CE as
untrusted and only accepts IP packets from the CE. The IP address
range is treated as belonging to the VPN of the CE, so the PE
maintains full control over VPN separation.
RFC 4364 [1] has subsequently defined a more complex architecture,
with more open interfaces. These interfaces allow the exchange of
label information and labeled packets to and from devices outside the
control of the service provider. This section discusses the security
implications of this advanced architecture.
4.1. Carriers’ Carrier
In the Carriers’ Carrier (CsC) architecture, the CE is linked to a
VRF on the PE. The CE may send labeled packets to the PE. The label
has been previously assigned by the PE to the CE, and represents the
label switched path (LSP) from this CE to the remote CE via the
carrier’s network.
RFC 4364 [1] specifies for this case: "When the PE receives a labeled
packet from a CE, it must verify that the top label is one that was
distributed to that CE." This ensures that the CE can only use
labels that the PE correctly associates with the corresponding VPN.
Packets with incorrect labels will be discarded, and thus label
spoofing is impossible.
The use of label maps on the PE leaves the control of the label
information entirely with the PE, so that this has no impact on the
security of the solution.
The packet underneath the top label will -- as in standard RFC 2547
[7] networks -- remain local to the customer carrier’s VPN and not be
inspected in the carriers’ carrier core. Potential spoofing of
subsequent labels or IP addresses remains local to the carrier’s VPN;
it has no implication on the carriers’ carrier core nor on other VPNs
in that core. This is specifically stated in section 6 of RFC 4364
[1].
Note that if the PE and CE are interconnected using a shared layer 2
infrastructure such as a switch, attacks are possible on layer 2,
which might enable a third party on the shared layer 2 network to
intrude into a VPN on that PE router. RFC 4364 [1] specifies
therefore that either all devices on a shared layer 2 network have to
be part of the same VPN, or the layer 2 network must be split
logically to avoid this issue. This will be discussed in more detail
in section 6.
In the CsC architecture, the customer carrier needs to trust the
carriers’ carrier for correct configuration and operation. The
customer of the carrier thus implicitly needs to trust both his
carrier and the carriers’ carrier.
In summary, a correctly configured carriers’ carrier network provides
the same level of security as comparable layer 2 networks or
traditional RFC 2547 [7] networks.
4.2. Inter-Provider Backbones
RFC 4364 [1] specifies three sub-cases for the inter-provider
backbone (Inter-AS) case.
a) VRF-to-VRF connections at the autonomous system border routers
(ASBRs).
In this case, each PE sees and treats the other PE as a CE; each will
not accept labeled packets, and there is no signaling between the PEs
other than inside the VRFs on both sides. Thus, the separation of
the VPNs on both sides and the security of those are the same as on a
single AS RFC 2547 [7] network. This has already been shown to have
the same security properties as traditional layer 2 VPNs.
This solution has potential scalability issues in that the ASBRs need
to maintain a VRF per VPN, and all of the VRFs need to hold all
routes of the specific VPNs. Thus, an ASBR can run into memory
problems affecting all VPNs if one single VRF contains too many
routes. Thus, the service providers needs to ensure that the ASBRs
are properly dimensioned and apply appropriate security measures such
as limiting the number of prefixes per VRF.
The two service providers connecting their VPNs in this way must
trust each other. Since the VPNs are separated on different
(sub-)interfaces, all signaling between ASBRs remains within a given
VPN. This means that dynamic cross-VPN security breaches are
impossible. It is conceivable that a service provider connects a
specific VPN to the wrong interface, thus interconnecting two VPNs
that should not be connected. This must be controlled operationally.
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to
neighboring AS.
In this case, ASBRs on both sides hold full routing information for
all shared VPNs on both sides. This is not held in separate VRFs,
but in the BGP database. (This is typically limited to the Inter-AS
VPNs through filtering.) The separation inside the PE is maintained
through the use of VPN-IPv4 addresses. The control plane between the
ASBRs uses Multi-Protocol BGP (MP-BGP, RFC 2858 [8]). It exchanges
VPN routes as VPN-IPv4 addresses, the ASBR addresses as BGP next-hop
IPv4 addresses, and labels to be used in the data plane.
The data plane is separated through the use of a single label,
representing a VRF or a subset thereof. RFC 4364 [1] states that an
ASBR should only accept packets with a label that it has assigned to
this router. This prevents the insertion of packets with unknown
labels, but it is possible for a service provider to use any label
that the ASBR of the other provider has passed on. This allows one
provider to insert packets into any VPN of the other provider for
which it has a label.
This solution also needs to consider the security on layer 2 at the
interconnection. The RFC states that this type of interconnection
should only be implemented on private interconnection points. See
section 6 for more details.
RFC 4364 [1] states that a trust relationship between the two
connecting ASes must exist for this model to work securely.
Effectively, all ASes interconnected in this way form a single zone
of trust. The VPN customer needs to trust all the service providers
involved in the provisioning of his VPN on this architecture.
c) PEs exchange labeled VPN-IPv4 routes, ASBRs only exchange
loopbacks of PEs with labels.
In this solution, there are effectively two control connections
between ASes. The route reflectors (RRs) exchange the VPN-IPv4
routes via multihop eBGP. The ASBRs only exchange the labeled
addresses of those PE routers that hold VPN routes that are shared
between those ASes. This maintains scalability for the ASBRs, since
they do not need to know the VPN-IPv4 routes.
In this solution, the top label specifies an LSP to an egress PE
router, and the second label specifies a VPN connected to this egress
PE. The security of the ASBR connection has the same constraints as
in solution b): An ASBR should only accept packets with top labels
that it has assigned to the other router, thus verifying that the
packet is addressed to a valid PE router. Any label, which was
assigned to the other ASBR, will be accepted. It is impossible for
an ASBR to distinguish between different egress PEs or between
different VPNs on those PEs. A malicious service provider of one AS
could introduce packets into any VPN on a PE of the other AS; it only
needs a valid LSP on its ASBR and PEs to the corresponding PE on the
other AS. The VPN label can be statistically guessed from the
theoretical label space, which allows unidirectional traffic into a
VPN.
This means that such an ASBR-ASBR connection can only be made with a
trusted party over a private interface, as described in b).
In addition, this solution exchanges labeled VPN-IPv4 addresses
between route reflectors (RRs) via MP-eBGP. The control plane itself
can be protected via routing authentication (RFC 2385 [6]), which
ensures that the routing information has been originated by the
expected RR and has not been modified in transit. The received VPN
information cannot be verified, as in the previous case. Thus, a
service provider can introduce bogus routes for any shared VPN. The
ASes need to trust each other to configure their respective networks
correctly. All ASes involved in this design form one trusted zone.
The customer needs to trust all service providers involved.
The difference between case b) and case c) is that in b) the ASBRs
act as iBGP next-hops for their AS; thus, each SP needs to know of
the other SP’s core only the addresses of the ASBRs. In case c), the
SPs exchange the loopback addresses of their PE routers; thus, each
SP reveals information to the other about its PE routers, and these
routers must be accessible from the other AS. As stated above,
accessibility does not necessarily mean insecurity, and networks
should never rely on "security through obscurity". This should not
be an issue if the PE routers are appropriately secured. However,
there is an increasing perception that network devices should
generally not be accessible.
In addition, there are scalability considerations for case c). A
number of BGP peerings have to be made for the overall network
including all ASes linked this way. SPs on both sides need to work
together in defining a scalable architecture, probably with route
reflectors.
In summary, all of these Inter-AS solutions logically merge several
provider networks. For all cases of Inter-AS configuration, all ASes
form a single zone of trust and service providers need to trust each
other. For the VPN customer, the security of the overall solution is
equal to the security of traditional RFC 2547 [7] networks, but the
customer needs to trust all service providers involved in the
provisioning of this Inter-AS solution.
5. What BGP/MPLS IP VPNs Do Not Provide
5.1. Protection against Misconfigurations of the Core and Attacks
’within’ the Core
The security mechanisms discussed here assume correct configuration
of the network elements of the core network (PE and P routers).
Deliberate or inadvertent misconfiguration may result in severe
security leaks.
Note that this paragraph specifically refers to the core network,
i.e., the PE and P elements. Misconfigurations 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 and the connected VPNs. Thus, the
following is important:
o 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.
Proper tools are required to configure the core network.
o To minimise the risk of "internal" attacks, the 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.
BGP/MPLS IP VPNs can only provide a secure service if the core
network is provided in a secure fashion. This document assumes this
to be the case.
There are various approaches to control the security of a core if the
VPN customer cannot or does not want to trust the service provider.
IPsec from customer-controlled devices is one of them. The document
"CE-to-CE Member Verification for Layer 3 VPNs" [13] proposes a
CE-based authentication scheme using tokens, aimed at detecting
misconfigurations in the MPLS core. The document "MPLS VPN
Import/Export Verification" [12] proposes a similar scheme based on
using the MD5 routing authentication. Both schemes aim to detect and
prevent misconfigurations in the core.
5.2. Data Encryption, Integrity, and Origin Authentication
BGP/MPLS IP VPNs themselves do not provide encryption, integrity, or
authentication service. If these are required, IPsec should be used
over the MPLS infrastructure. The same applies to ATM and Frame
Relay: IPsec can provide these missing services.
5.3. Customer Network Security
BGP/MPLS IP VPNs can be secured so that they are 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 come only from an "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 a BGP/MPLS infrastructure, MPLS security is necessary but
not sufficient. The same applies to other VPN technologies like ATM
or Frame Relay. See also RFC 2196 [5] for more information on how to
secure a network.
6. Layer 2 Security Considerations
In most cases of Inter-AS or Carrier’s Carrier solutions, a network
will be interconnected to other networks via a point-to-point private
connection. This connection cannot be interfered with by third
parties. It is important to understand that the use of any
shared-medium layer 2 technology for such interconnections, such as
Ethernet switches, may carry additional security risks.
There are two types of risks with layer 2 infrastructure:
a) Attacks against layer 2 protocols or mechanisms
Risks in a layer 2 environment include many different forms of
Address Resolution Protocol (ARP) attacks, VLAN trunking attacks, or
Content Addressable Memory (CAM) overflow attacks. For example, ARP
spoofing allows an attacker to redirect traffic between two routers
through his device, gaining access to all packets between those two
routers.
These attacks can be prevented by appropriate security measures, but
often these security concerns are overlooked. It is of the utmost
importance that if a shared medium (such as a switch) is used in the
above scenarios, that all available layer 2 security mechanisms are
used to prevent layer 2 based attacks.
b) Traffic insertion attacks
Where many routers share a common layer 2 network (for example, at an
Internet exchange point), it is possible for a third party to
introduce packets into a network. This has been abused in the past
on traditional exchange points when some service providers have
defaulted to another provider on this exchange point. In effect,
they are sending all their traffic into the other SP’s network even
though the control plane (routing) might not allow that.
For this reason, routers on exchange points (or other shared layer 2
connections) should only accept non-labeled IP packets into the
global routing table. Any labeled packet must be discarded. This
maintains the security of connected networks.
Some of the above designs require the exchange of labeled packets.
This would make it possible for a third party to introduce labeled
packets, which if correctly crafted might be associated with certain
VPNs on an BGP/MPLS IP VPN network, effectively introducing false
packets into a VPN.
The current recommendation is therefore to discard labeled packets on
generic shared-medium layer 2 networks such as Internet exchange
points (IXPs). Where labeled packets need to be exchanged, it is
strongly recommended to use private connections.
7. Summary and Conclusions
BGP/MPLS IP VPNs provide 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 not possible to intrude into other
VPNs abusing the BGP/MPLS mechanisms. It is also impossible to
intrude into the MPLS core if this is properly secured. However,
there is a significant difference between BGP/MPLS-based IP VPNs and,
for example, FR- or ATM-based VPNs: The control structure of the core
is 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 document, it is possible to secure a BGP/MPLS IP VPN
infrastructure to the same level of security as 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 [14].
As far as attacks from within the MPLS core are concerned, all VPN
classes (BGP/MPLS, FR, ATM) have the same problem: If an attacker can
install a sniffer, he can read information in all VPNs, and if the
attacker has access to the core devices, he can execute a large
number of attacks, from packet spoofing to introducing new peer
routers. There are a number of precautionary measures outlined above
that a service provider can use to tighten security of the core, but
the security of the BGP/MPLS IP VPN 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 document discussed many aspects of BGP/MPLS IP VPN security. It
has to be noted that the overall security of this architecture
depends on all components and is determined by the security of the
weakest part of the solution. For example, a perfectly secured
static BGP/MPLS IP VPN network with secured Internet access and
secure management is still open to many attacks if there is a weak
remote access solution in place.
8. Security Considerations
The entire document is discussing security considerations of the RFC
4364 [1] architecture.
9. Acknowledgements
The author would like to thank everybody who has provided input to
this document. Specific thanks go to Yakov Rekhter, for his
continued strong support, and Eric Rosen, Loa Andersson, Alexander
Renner, Jim Guichard, Monique Morrow, Eric Vyncke, and Steve Simlo,
for their extended feedback and support.
10. Normative References
[1] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
11. Informative References
[2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996.
[3] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5
Authentication", RFC 2082, January 1997.
[4] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
Signatures", RFC 2154, June 1997.
[5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997.
[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[7] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
[8] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[9] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[10] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[11] Fang, L., "Security Framework for Provider-Provisioned Virtual
Private Networks (PPVPNs)", RFC 4111, July 2005.
[12] Behringer, M., Guichard, J., and P. Marques, "MPLS VPN
Import/Export Verification", Work in Progress, June 2004.
[13] Bonica, R. and Y. Rekhter, "CE-to-CE Member Verification for
Layer 3 VPNs", Work in Progress, September 2003.
[14] DataComm, "Data Communications Report, Vol 15, No 4: Frame
Relay and ATM: Are they really secure?", February 2000.
Author’s Address
Michael H. Behringer
Cisco Systems Inc
Village d’Entreprises Green Side
400, Avenue Roumanille, Batiment T 3
Biot - Sophia Antipolis 06410
France
EMail: mbehring@cisco.com
URI: http://www.cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions