Network Working Group Michael Behringer Internet Draft Cisco Systems, Inc. <draft-behringer-mpls-security-02.txt> Category: Informational June 2002 Expires: December 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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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-02.txt June 2002 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 References 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-02.txt June 2002 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-02.txt June 2002 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-02.txt June 2002 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-02.txt June 2002 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-02.txt June 2002 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 world. 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 router. The routing between the VPN and the MPLS core can be configured two ways: 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-02.txt June 2002 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 ways: * 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-02.txt June 2002 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-02.txt June 2002 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-02.txt June 2002 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-02.txt June 2002 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 Spain E-mail: mbehring@cisco.com References [DataComm] "Frame Relay and ATM: Are they really secure?". Data Communications Report, Vol 15, No 4, February 2000. (http://www.yankeegroup.com) [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. (http://search.ietf.org/rfc/rfc2196.txt) [RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature Option". A. Heffernan. August 1998. (http://search.ietf.org/rfc/rfc2385.txt) Security of the MPLS Architecture page 12 Internet Draft draft-behringer-mpls-security-02.txt June 2002 [RFC2547] "BGP/MPLS VPNs". E. Rosen, Y. Rekhter. March 1999. (http://search.ietf.org/rfc/rfc2547.txt) [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. (http://search.ietf.org/rfc/rfc2828.txt) [RFC3013] "Recommended Internet Service Provider Security Services and Procedures". T. Killalea. November 2000. (http://search.ietf.org/rfc/rfc3013.txt) [RFC3031] "Multiprotocol Label Switching Architecture". E. Rosen, A. Viswanathan, R. Callon. January 2001.(http://search.ietf.org/rfc/rfc3031.txt) 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 English. 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Security of the MPLS Architecture page 13