Internet Engineering Task Force (IETF) L. Fang, Ed. Request for Comments: 5920 Cisco Systems, Inc. Category: Informational July 2010 ISSN: 2070-1721 Security Framework for MPLS and GMPLS Networks
AbstractThis document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5920.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
1. Introduction ....................................................4 2. Terminology .....................................................5 2.1. Acronyms and Abbreviations .................................5 2.2. MPLS and GMPLS Terminology .................................6 3. Security Reference Models .......................................8 4. Security Threats ...............................................10 4.1. Attacks on the Control Plane ..............................12 4.2. Attacks on the Data Plane .................................15 4.3. Attacks on Operation and Management Plane .................17 4.4. Insider Attacks Considerations ............................19 5. Defensive Techniques for MPLS/GMPLS Networks ...................19 5.1. Authentication ............................................20 5.2. Cryptographic Techniques ..................................22 5.3. Access Control Techniques .................................33 5.4. Use of Isolated Infrastructure ............................38 5.5. Use of Aggregated Infrastructure ..........................38 5.6. Service Provider Quality Control Processes ................39 5.7. Deployment of Testable MPLS/GMPLS Service .................39 5.8. Verification of Connectivity ..............................40 6. Monitoring, Detection, and Reporting of Security Attacks .......40 7. Service Provider General Security Requirements .................42 7.1. Protection within the Core Network ........................42 7.2. Protection on the User Access Link ........................46 7.3. General User Requirements for MPLS/GMPLS Providers ........48 8. Inter-Provider Security Requirements ...........................48 8.1. Control-Plane Protection ..................................49 8.2. Data-Plane Protection .....................................53 9. Summary of MPLS and GMPLS Security .............................54 9.1. MPLS and GMPLS Specific Security Threats ..................55 9.2. Defense Techniques ........................................56 9.3. Service Provider MPLS and GMPLS Best-Practice Outlines ....57 10. Security Considerations .......................................59 11. References ....................................................59 11.1. Normative References .....................................59 11.2. Informative References ...................................62 12. Acknowledgements ..............................................64 13. Contributors' Contact Information .............................65
RFC3031] and [RFC3945]. Various security considerations have been addressed in each of the many RFCs on MPLS and GMPLS technologies, but no single document covers general security considerations. The motivation for creating this document is to provide a comprehensive and consistent security framework for MPLS and GMPLS networks. Each individual document may point to this document for general security considerations in addition to providing security considerations specific to the particular technologies the document is describing. In this document, we first describe the security threats relevant in the context of MPLS and GMPLS and the defensive techniques to combat those threats. We consider security issues resulting both from malicious or incorrect behavior of users and other parties and from negligent or incorrect behavior of providers. An important part of security defense is the detection and reporting of a security attack, which is also addressed in this document. We then discuss possible service provider security requirements in an MPLS or GMPLS environment. Users have expectations for the security characteristics of MPLS or GMPLS networks. These include security requirements for equipment supporting MPLS and GMPLS and operational security requirements for providers. Service providers must protect their network infrastructure and make it secure to the level required to provide services over their MPLS or GMPLS networks. Inter-AS and inter-provider security are discussed with special emphasis, because the security risk factors are higher with inter- provider connections. Note that inter-carrier MPLS security is also considered in [MFA-MPLS-ICI]. Depending on different MPLS or GMPLS techniques used, the degree of risk and the mitigation methodologies vary. This document discusses the security aspects and requirements for certain basic MPLS and GMPLS techniques and interconnection models. This document does not attempt to cover all current and future MPLS and GMPLS technologies, as it is not within the scope of this document to analyze the security properties of specific technologies. It is important to clarify that, in this document, we limit ourselves to describing the providers' security requirements that pertain to MPLS and GMPLS networks, not including the connected user sites. Readers may refer to the "Security Best Practices Efforts and
Documents" [OPSEC-EFFORTS] and "Security Mechanisms for the Internet" [RFC3631] for general network operation security considerations. It is not our intention, however, to formulate precise "requirements" for each specific technology in terms of defining the mechanisms and techniques that must be implemented to satisfy such security requirements.
PW Pseudowire QoS Quality of Service RR Route Reflector RSVP Resource Reservation Protocol RSVP-TE Resource Reservation Protocol with Traffic Engineering Extensions SLA Service Level Agreement SNMP Simple Network Management Protocol SP Service Provider SSH Secure Shell SSL Secure Sockets Layer SYN Synchronize packet in TCP TCP Transmission Control Protocol TDM Time Division Multiplexing TE Traffic Engineering TLS Transport Layer Security ToS Type of Service TTL Time-To-Live UDP User Datagram Protocol VC Virtual Circuit VPN Virtual Private Network WG Working Group of IETF WSS Web Services Security RFC3031] and [RFC3945]. The most important definitions are repeated in this section; for other definitions, the reader is referred to [RFC3031] and [RFC3945]. Core network: An MPLS/GMPLS core network is defined as the central network infrastructure that consists of P and PE routers. An MPLS/GMPLS core network may consist of one or more networks belonging to a single SP. Customer Edge (CE) device: A Customer Edge device is a router or a switch in the customer's network interfacing with the Service Provider's network. Forwarding Equivalence Class (FEC): A group of IP packets that are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment). Label: A short, fixed length, physically contiguous identifier, usually of local significance.
Label merging: the replacement of multiple incoming labels for a particular FEC with a single outgoing label. Label Switched Hop: A hop between two MPLS nodes, on which forwarding is done using labels. Label Switched Path (LSP): The path through one or more LSRs at one level of the hierarchy followed by packets in a particular FEC. Label Switching Routers (LSRs): An MPLS/GMPLS node assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers or cell headers. Loop Detection: A method of dealing with loops in which loops are allowed to be set up, and data may be transmitted over the loop, but the loop is later detected. Loop Prevention: A method of dealing with loops in which data is never transmitted over a loop. Label Stack: An ordered set of labels. Merge Point: A node at which label merging is done. MPLS Domain: A contiguous set of nodes that perform MPLS routing and forwarding and are also in one Routing or Administrative Domain. MPLS Edge Node: An MPLS node that connects an MPLS domain with a node outside of the domain, either because it does not run MPLS, or because it is in a different domain. Note that if an LSR has a neighboring host not running MPLS, then that LSR is an MPLS edge node. MPLS Egress Node: An MPLS edge node in its role in handling traffic as it leaves an MPLS domain. MPLS Ingress Node: A MPLS edge node in its role in handling traffic as it enters a MPLS domain. MPLS Label: A label carried in a packet header, which represents the packet's FEC. MPLS Node: A node running MPLS. An MPLS node is aware of MPLS control protocols, runs one or more routing protocols, and is capable of forwarding packets based on labels. An MPLS node may optionally be also capable of forwarding native IP packets.
Multiprotocol Label Switching (MPLS): MPLS is an architecture for efficient data packet switching and routing. MPLS assigns data packets with labels. Instead of performing the longest match for each packet's destination as in conventional IP forwarding, MPLS makes the packet-forwarding decisions solely on the contents of the label without examining the packet itself. This allows the creation of end-to-end circuits across any type of transport medium, using any protocols. P: Provider Router. A Provider Router is a router in the Service Provider's core network that does not have interfaces directly towards the customer. A P router is used to interconnect the PE routers and/or other P routers within the core network. PE: Provider Edge device. A Provider Edge device is the equipment in the Service Provider's network that interfaces with the equipment in the customer's network. PPVPN: Provider-Provisioned Virtual Private Network, including Layer 2 VPNs and Layer 3 VPNs. VPN: Virtual Private Network, which restricts communication between a set of sites, making use of an IP backbone shared by traffic not going to or not coming from those sites [RFC4110]. Figure 1 depicts the concept of trusted zones within the MPLS/GMPLS framework.
/-------------\ +------------+ / \ +------------+ | MPLS/GMPLS +---/ \--------+ MPLS/GMPLS | | user | MPLS/GMPLS Core | user | | site +---\ /XXX-----+ site | +------------+ \ / XXX +------------+ \-------------/ | | | | | +------\ +--------/ "Internet" |<- Trusted zone ->| MPLS/GMPLS Core with user connections and Internet connection Figure 1: The MPLS/GMPLS Trusted Zone Model The trusted zone is the MPLS/GMPLS core in a single AS within a single Service Provider. A trusted zone contains elements and users with similar security properties, such as exposure and risk level. In the MPLS context, an organization is typically considered as one trusted zone. The boundaries of a trust domain should be carefully defined when analyzing the security properties of each individual network, e.g., the boundaries can be at the link termination, remote peers, areas, or quite commonly, ASes. In principle, the trusted zones should be separate; however, typically MPLS core networks also offer Internet access, in which case a transit point (marked with "XXX" in Figure 1) is defined. In the case of MPLS/GMPLS inter-provider connections or InterCarrier Interconnect (ICI), the trusted zone of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for Provider A and ASBR3 and ASBR4 for Provider B in Figure 2). A key requirement of MPLS and GMPLS networks is that the security of the trusted zone not be compromised by interconnecting the MPLS/GMPLS core infrastructure with another provider's core (MPLS/GMPLS or non- MPLS/GMPLS), the Internet, or end users. In addition, neighbors may be trusted or untrusted. Neighbors may be authorized or unauthorized. An authorized neighbor is the neighbor one establishes a peering relationship with. Even though a neighbor may be authorized for communication, it may not be trusted. For example, when connecting with another provider's ASBRs to set up
inter-AS LSPs, the other provider is considered an untrusted but authorized neighbor. +---------------+ +----------------+ | | | | | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS | CE1--PE1 Network | | Network PE2--CE2 | Provider A ASBR2----ASBR4 Provider B | | | | | +---------------+ +----------------+ InterCarrier Interconnect (ICI) For Provider A: Trusted Zone: Provider A MPLS/GMPLS network Authorized but untrusted neighbor: provider B Unauthorized neighbors: CE1, CE2 Figure 2: MPLS/GMPLS Trusted Zone and Authorized Neighbor All aspects of network security independent of whether a network is an MPLS/GMPLS network, are out of scope. For example, attacks from the Internet to a user's web-server connected through the MPLS/GMPLS network are not considered here, unless the way the MPLS/GMPLS network is provisioned could make a difference to the security of this user's server. RFC4778] provided the best current operational security practices in Internet Service Provider environments. A successful attack on a particular MPLS/GMPLS network or on an SP's MPLS/GMPLS infrastructure may cause one or more of the following ill effects: - Observation, modification, or deletion of a provider's or user's data. - Replay of a provider's or user's data. - Injection of inauthentic data into a provider's or user's traffic stream. - Traffic pattern analysis on a provider's or user's traffic. - Disruption of a provider's or user's connectivity.
- Degradation of a provider's service quality. - Probing a provider's network to determine its configuration, capacity, or usage. It is useful to consider that threats, whether malicious or accidental, may come from different categories of sources. For example, they may come from: - Other users whose services are provided by the same MPLS/GMPLS core. - The MPLS/GMPLS SP or persons working for it. - Other persons who obtain physical access to an MPLS/GMPLS SP's site. - Other persons who use social engineering methods to influence the behavior of an SP's personnel. - Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats. (Such threats are beyond the scope of this document.) - Others, e.g., attackers from the Internet at large. - Other SPs in the case of MPLS/GMPLS inter-provider connection. The core of the other provider may or may not be using MPLS/GMPLS. - Those who create, deliver, install, and maintain software for network equipment. Given that security is generally a tradeoff between expense and risk, it is also useful to consider the likelihood of different attacks occurring. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as: - An MPLS/GMPLS core interconnecting with another provider's core. - An MPLS/GMPLS configuration transiting the public Internet. Most types of attacks become easier to mount and hence more likely as the shared infrastructure via which service is provided expands from a single SP to multiple cooperating SPs to the global Internet. Attacks that may not be of sufficient likeliness to warrant concern in a closely controlled environment often merit defensive measures in broader, more open environments. In closed communities, it is often
practical to deal with misbehavior after the fact: an employee can be disciplined, for example. The following sections discuss specific types of exploits that threaten MPLS/GMPLS networks. Section 4.4.
RFC3209], is the control protocol used to set up GMPLS and traffic engineered MPLS tunnels. There are two major types of denial-of-service (DoS) attacks against an MPLS domain based on RSVP-TE. The attacker may set up numerous unauthorized LSPs or may send a storm of RSVP messages. It has been demonstrated that unprotected routers running RSVP can be effectively disabled by both types of DoS attacks. These attacks may even be combined, by using the unauthorized LSPs to transport additional RSVP (or other) messages across routers where they might otherwise be filtered out. RSVP attacks can be launched against adjacent routers at the border with the attacker, or against non-adjacent routers within the MPLS domain, if there is no effective mechanism to filter them out. RFC5036], is the control protocol used to set up MPLS tunnels without TE. There are two significant types of attack against LDP. An unauthorized network element can establish an LDP session by sending LDP Hello and LDP Init messages, leading to the potential setup of an LSP, as well as accompanying LDP state table consumption. Even without successfully establishing LSPs, an attacker can launch a DoS attack in the form of a storm of LDP Hello messages or LDP TCP SYN messages, leading to high CPU utilization or table space exhaustion on the target router.
The attacks described in the following sections may each have denial of service as one of their effects. Other DoS attacks are also possible. RFC4593].
4.1.4 and 4.1.3 - PCE signaling - IPsec signaling (IKE and IKEv2) - ICMP and ICMPv6 - L2TP - BGP-based membership discovery - Database-based membership discovery (e.g., RADIUS) - Other protocols that may be important to the control infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE. Attacks might subvert or disrupt the activities of these protocols, for example via impersonation or DoS. Note that all of the data-plane attacks can also be carried out against the packets of the control and management planes: insertion, spoofing, replay, deletion, pattern analysis, and other attacks mentioned above.
provider or end user, or to overwhelm the cryptographic authentication mechanisms of the provider or end user. Data-plane resource exhaustion attacks can also be mounted by overwhelming the service provider's general (MPLS/GMPLS-independent) infrastructure with traffic. These attacks on the general infrastructure are not usually an MPLS/GMPLS-specific issue, unless the attack is mounted by another MPLS/GMPLS network user from a privileged position. (For example, an MPLS/GMPLS network user might be able to monopolize network data-plane resources and thus disrupt other users.) Many DoS attacks use amplification, whereby the attacker co-opts otherwise innocent parties to increase the effect of the attack. The attacker may, for example, send packets to a broadcast or multicast address with the spoofed source address of the victim, and all of the recipients may then respond to the victim. RFC4778] may serve as the best current operational security practices in Internet Service Provider environments. RFC 4377 [RFC4377] provided Operations and Management Requirements for MPLS networks. See also the Security Considerations of RFC 4377 and Section 7 of RFC 4378 [RFC4378]. Operation and Management across the MPLS-ICI could also be the source of security threats on the provider infrastructure as well as the service offered over the MPLS-ICI. A large volume of Operation and Management messages could overwhelm the processing capabilities of an ASBR if the ASBR is not properly protected. Maliciously generated
Operation and Management messages could also be used to bring down an otherwise healthy service (e.g., MPLS Pseudowire), and therefore affect service security. LSP ping does not support authentication today, and that support should be a subject for future considerations. Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure. Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing. Regarding GMPLS Operation and Management considerations in optical interworking, there is a good discussion on security for management interfaces to Network Elements [OIF-Sec-Mag]. Network elements typically have one or more (in some cases many) Operation and Management interfaces used for network management, billing and accounting, configuration, maintenance, and other administrative activities. Remote access to a network element through these Operation and Management interfaces is frequently a requirement. Securing the control protocols while leaving these Operation and Management interfaces unprotected opens up a huge security vulnerability. Network elements are an attractive target for intruders who want to disrupt or gain free access to telecommunications facilities. Much has been written about this subject since the 1980s. In the 1990s, telecommunications facilities were identified in the U.S. and other countries as part of the "critical infrastructure", and increased emphasis was placed on thwarting such attacks from a wider range of potentially well-funded and determined adversaries. At one time, careful access controls and password management were a sufficient defense, but are no longer. Networks using the TCP/IP protocol suite are vulnerable to forged source addresses, recording and later replay, packet sniffers picking up passwords, re-routing of traffic to facilitate eavesdropping or tampering, active hijacking attacks of TCP connections, and a variety of denial-of-service attacks. The ease of forging TCP/IP packets is the main reason network management protocols lacking strong security have not been used to configure network elements (e.g., with the SNMP SET command). Readily available hacking tools exist that let an eavesdropper on a LAN take over one end of any TCP connection, so that the legitimate party is cut off. In addition, enterprises and Service Providers in some jurisdictions need to safeguard data about their users and network configurations from prying. An attacker could eavesdrop and
observe traffic to analyze usage patterns and map a network configuration; an attacker could also gain access to systems and manipulate configuration data or send malicious commands. Therefore, in addition to authenticating the human user, more sophisticated protocol security is needed for Operation and Management interfaces, especially when they are configured over TCP/IP stacks. Finally, relying on a perimeter defense, such as firewalls, is insufficient protection against "insider attacks" or against penetrations that compromise a system inside the firewall as a launching pad to attack network elements. The insider attack is discussed in the following session.