diff options
Diffstat (limited to 'doc/rfc/rfc5920.txt')
-rw-r--r-- | doc/rfc/rfc5920.txt | 3699 |
1 files changed, 3699 insertions, 0 deletions
diff --git a/doc/rfc/rfc5920.txt b/doc/rfc/rfc5920.txt new file mode 100644 index 0000000..18bada2 --- /dev/null +++ b/doc/rfc/rfc5920.txt @@ -0,0 +1,3699 @@ + + + + + + +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 + +Abstract + + This 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. + + + + + + + + + + + + + + + +Fang Informational [Page 1] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + +Fang Informational [Page 2] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +Table of Contents + + 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 + + + + + + + + + + + + +Fang Informational [Page 3] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +1. Introduction + + Security is an important aspect of all networks, MPLS and GMPLS + networks being no exception. + + MPLS and GMPLS are described in [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 + + + +Fang Informational [Page 4] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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. + +2. Terminology + +2.1. Acronyms and Abbreviations + + AS Autonomous System + ASBR Autonomous System Border Router + ATM Asynchronous Transfer Mode + BGP Border Gateway Protocol + BFD Bidirectional Forwarding Detection + CE Customer-Edge device + CoS Class of Service + CPU Central Processing Unit + DNS Domain Name System + DoS Denial of Service + ESP Encapsulating Security Payload + FEC Forwarding Equivalence Class + GMPLS Generalized Multi-Protocol Label Switching + GCM Galois Counter Mode + GRE Generic Routing Encapsulation + ICI InterCarrier Interconnect + ICMP Internet Control Message Protocol + ICMPv6 ICMP in IP Version 6 + IGP Interior Gateway Protocol + IKE Internet Key Exchange + IP Internet Protocol + IPsec IP Security + IPVPN IP-based VPN + LDP Label Distribution Protocol + L2TP Layer 2 Tunneling Protocol + LMP Link Management Protocol + LSP Label Switched Path + LSR Label Switching Router + MD5 Message Digest Algorithm + MPLS Multiprotocol Label Switching + MP-BGP Multiprotocol BGP + NTP Network Time Protocol + OAM Operations, Administration, and Maintenance + PCE Path Computation Element + PE Provider-Edge device + PPVPN Provider-Provisioned Virtual Private Network + PSN Packet-Switched Network + + + +Fang Informational [Page 5] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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 + +2.2. MPLS and GMPLS Terminology + + This document uses MPLS- and GMPLS-specific terminology. Definitions + and details about MPLS and GMPLS terminology can be found in + [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. + + + + +Fang Informational [Page 6] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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. + + + + +Fang Informational [Page 7] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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]. + +3. Security Reference Models + + This section defines a reference model for security in MPLS/GMPLS + networks. + + This document defines each MPLS/GMPLS core in a single domain to be a + trusted zone. A primary concern is about security aspects that + relate to breaches of security from the "outside" of a trusted zone + to the "inside" of this zone. Figure 1 depicts the concept of + trusted zones within the MPLS/GMPLS framework. + + + + + + + + + + + + + + + + +Fang Informational [Page 8] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + /-------------\ + +------------+ / \ +------------+ + | 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 + + + + +Fang Informational [Page 9] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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. + +4. Security Threats + + This section discusses the various network security threats that may + endanger MPLS/GMPLS networks. RFC 4778 [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. + + + +Fang Informational [Page 10] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + - 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 + + + + +Fang Informational [Page 11] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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. + +4.1. Attacks on the Control Plane + + This category encompasses attacks on the control structures operated + by the SP with MPLS/GMPLS cores. + + It should be noted that while connectivity in the MPLS control plane + uses the same links and network resources as are used by the data + plane, the GMPLS control plane may be provided by separate resources + from those used in the data plane. That is, the GMPLS control plane + may be physically separate from the data plane. + + The different cases of physically congruent and physically separate + control/data planes lead to slightly different possibilities of + attack, although most of the cases are the same. Note that, for + example, the data plane cannot be directly congested by an attack on + a physically separate control plane as it could be if the control and + data planes shared network resources. Note also that if the control + plane uses diverse resources from the data plane, no assumptions + should be made about the security of the control plane based on the + security of the data plane resources. + + This section is focused the outsider attack. The insider attack is + discussed in Section 4.4. + +4.1.1. LSP Creation by an Unauthorized Element + + The unauthorized element can be a local CE or a router in another + domain. An unauthorized element can generate MPLS signaling + messages. At the least, this can result in extra control plane and + forwarding state, and if successful, network bandwidth could be + reserved unnecessarily. This may also result in theft of service or + even compromise the entire network. + +4.1.2. LSP Message Interception + + This threat might be accomplished by monitoring network traffic, for + example, after a physical intrusion. Without physical intrusion, it + could be accomplished with an unauthorized software modification. + Also, many technologies such as terrestrial microwave, satellite, or + free-space optical could be intercepted without physical intrusion. + If successful, it could provide information leading to label spoofing + attacks. It also raises confidentiality issues. + + + +Fang Informational [Page 12] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +4.1.3. Attacks against RSVP-TE + + RSVP-TE, described in [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. + +4.1.4. Attacks against LDP + + LDP, described in [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. + +4.1.5. Denial-of-Service Attacks on the Network Infrastructure + + DoS attacks could be accomplished through an MPLS signaling storm, + resulting in high CPU utilization and possibly leading to control- + plane resource starvation. + + Control-plane DoS attacks can be mounted specifically against the + mechanisms the SP uses to provide various services, or against the + general infrastructure of the service provider, e.g., P routers or + shared aspects of PE routers. (An attack against the general + infrastructure is within the scope of this document only if the + attack can occur in relation with the MPLS/GMPLS infrastructure; + otherwise, it is not an MPLS/GMPLS-specific issue.) + + + + + + +Fang Informational [Page 13] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + The attacks described in the following sections may each have denial + of service as one of their effects. Other DoS attacks are also + possible. + +4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via Management + Interfaces + + This includes unauthorized access to an SP's infrastructure + equipment, for example, to reconfigure the equipment or to extract + information (statistics, topology, etc.) pertaining to the network. + +4.1.7. Cross-Connection of Traffic between Users + + This refers to the event in which expected isolation between separate + users (who may be VPN users) is breached. This includes cases such + as: + + - A site being connected into the "wrong" VPN. + + - Traffic being replicated and sent to an unauthorized user. + + - Two or more VPNs being improperly merged together. + + - A point-to-point VPN connecting the wrong two points. + + - Any packet or frame being improperly delivered outside the VPN to + which it belongs + + Misconnection or cross-connection of VPNs may be caused by service + provider or equipment vendor error, or by the malicious action of an + attacker. The breach may be physical (e.g., PE-CE links + misconnected) or logical (e.g., improper device configuration). + + Anecdotal evidence suggests that the cross-connection threat is one + of the largest security concerns of users (or would-be users). + +4.1.8. Attacks against Routing Protocols + + This encompasses attacks against underlying routing protocols that + are run by the SP and that directly support the MPLS/GMPLS core. + (Attacks against the use of routing protocols for the distribution of + backbone routes are beyond the scope of this document.) Specific + attacks against popular routing protocols have been widely studied + and are described in [RFC4593]. + + + + + + + +Fang Informational [Page 14] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +4.1.9. Other Attacks on Control Traffic + + Besides routing and management protocols (covered separately in the + previous sections), a number of other control protocols may be + directly involved in delivering services by the MPLS/GMPLS core. + These include but may not be limited to: + + - MPLS signaling (LDP, RSVP-TE) discussed above in subsections 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. + +4.2. Attacks on the Data Plane + + This category encompasses attacks on the provider's or end-user's + data. Note that from the MPLS/GMPLS network end user's point of + view, some of this might be control-plane traffic, e.g., routing + protocols running from user site A to user site B via IP or non-IP + connections, which may be some type of VPN. + +4.2.1. Unauthorized Observation of Data Traffic + + This refers to "sniffing" provider or end user packets and examining + their contents. This can result in exposure of confidential + information. It can also be a first step in other attacks (described + below) in which the recorded data is modified and re-inserted, or + simply replayed later. + + + +Fang Informational [Page 15] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +4.2.2. Modification of Data Traffic + + This refers to modifying the contents of packets as they traverse the + MPLS/GMPLS core. + +4.2.3. Insertion of Inauthentic Data Traffic: Spoofing and Replay + + Spoofing refers to sending a user packets or inserting packets into a + data stream that do not belong, with the objective of having them + accepted by the recipient as legitimate. Also included in this + category is the insertion of copies of once-legitimate packets that + have been recorded and replayed. + +4.2.4. Unauthorized Deletion of Data Traffic + + This refers to causing packets to be discarded as they traverse the + MPLS/GMPLS networks. This is a specific type of denial-of-service + attack. + +4.2.5. Unauthorized Traffic Pattern Analysis + + This refers to "sniffing" provider or user packets and examining + aspects or meta-aspects of them that may be visible even when the + packets themselves are encrypted. An attacker might gain useful + information based on the amount and timing of traffic, packet sizes, + source and destination addresses, etc. For most users, this type of + attack is generally considered to be significantly less of a concern + than the other types discussed in this section. + +4.2.6. Denial-of-Service Attacks + + Denial-of-service (DoS) attacks are those in which an attacker + attempts to disrupt or prevent the use of a service by its legitimate + users. Taking network devices out of service, modifying their + configuration, or overwhelming them with requests for service are + several of the possible avenues for DoS attack. + + Overwhelming the network with requests for service, otherwise known + as a "resource exhaustion" DoS attack, may target any resource in the + network, e.g., link bandwidth, packet forwarding capacity, session + capacity for various protocols, CPU power, table size, storage + overflows, and so on. + + DoS attacks of the resource exhaustion type can be mounted against + the data plane of a particular provider or end user by attempting to + insert (spoofing) an overwhelming quantity of inauthentic data into + the provider or end-user's network from outside of the trusted zone. + Potential results might be to exhaust the bandwidth available to that + + + +Fang Informational [Page 16] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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. + +4.2.7. Misconnection + + Misconnection may arise through deliberate attack, or through + misconfiguration or misconnection of the network resources. The + result is likely to be delivery of data to the wrong destination or + black-holing of the data. + + In GMPLS with physically diverse control and data planes, it may be + possible for data-plane misconnection to go undetected by the control + plane. + + In optical networks under GMPLS control, misconnection may give rise + to physical safety risks as unprotected lasers may be activated + without warning. + +4.3. Attacks on Operation and Management Plane + + Attacks on the Operation and Management plane have been discussed + extensively as general network security issues over the last 20 + years. RFC 4778 [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 + + + +Fang Informational [Page 17] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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 + + + + + +Fang Informational [Page 18] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 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. + +4.4. Insider Attacks Considerations + + The chain of trust model means that MPLS and GMPLS networks are + particularly vulnerable to insider attacks. These can be launched by + any malign person with access to any LSR in the trust domain. + Insider attacks could also be launched by compromised software within + the trust domain. Such attacks could, for example, advertise non- + existent resources, modify advertisements from other routers, request + unwanted LSPs that use network resources, or deny or modify + legitimate LSP requests. + + Protection against insider attacks is largely for future study in + MPLS and GMPLS networks. Some protection can be obtained by + providing strict security for software upgrades and tight OAM access + control procedures. Further protection can be achieved by strict + control of user (i.e., operator) access to LSRs. Software change + management and change tracking (e.g., CVS diffs from text-based + configuration files) helps in spotting irregularities and human + errors. In some cases, configuration change approval processes may + also be warranted. Software tools could be used to check + configurations for consistency and compliance. Software tools may + also be used to monitor and report network behavior and activity in + order to quickly spot any irregularities that may be the result of an + insider attack. + +5. Defensive Techniques for MPLS/GMPLS Networks + + The defensive techniques discussed in this document are intended to + describe methods by which some security threats can be addressed. + They are not intended as requirements for all MPLS/GMPLS + implementations. The MPLS/GMPLS provider should determine the + applicability of these techniques to the provider's specific service + offerings, and the end user may wish to assess the value of these + techniques to the user's service requirements. The operational + environment determines the security requirements. Therefore, + + + +Fang Informational [Page 19] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + protocol designers need to provide a full set of security services, + which can be used where appropriate. + + The techniques discussed here include encryption, authentication, + filtering, firewalls, access control, isolation, aggregation, and + others. + + Often, security is achieved by careful protocol design, rather than + by adding a security method. For example, one method of mitigating + DoS attacks is to make sure that innocent parties cannot be used to + amplify the attack. Security works better when it is "designed in" + rather than "added on". + + Nothing is ever 100% secure. Defense therefore involves protecting + against those attacks that are most likely to occur or that have the + most direct consequences if successful. For those attacks that are + protected against, absolute protection is seldom achievable; more + often it is sufficient just to make the cost of a successful attack + greater than what the adversary will be willing or able to expend. + + Successfully defending against an attack does not necessarily mean + the attack must be prevented from happening or from reaching its + target. In many cases, the network can instead be designed to + withstand the attack. For example, the introduction of inauthentic + packets could be defended against by preventing their introduction in + the first place, or by making it possible to identify and eliminate + them before delivery to the MPLS/GMPLS user's system. The latter is + frequently a much easier task. + +5.1. Authentication + + To prevent security issues arising from some DoS attacks or from + malicious or accidental misconfiguration, it is critical that devices + in the MPLS/GMPLS should only accept connections or control messages + from valid sources. Authentication refers to methods to ensure that + message sources are properly identified by the MPLS/GMPLS devices + with which they communicate. This section focuses on identifying the + scenarios in which sender authentication is required and recommends + authentication mechanisms for these scenarios. + + Cryptographic techniques (authentication, integrity, and encryption) + do not protect against some types of denial-of-service attacks, + specifically resource exhaustion attacks based on CPU or bandwidth + exhaustion. In fact, the software-based cryptographic processing + required to decrypt or check authentication may in some cases + increase the effect of these resource exhaustion attacks. With a + hardware cryptographic accelerator, attack packets can be dropped at + line speed without a cost to software cycles. Cryptographic + + + +Fang Informational [Page 20] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + techniques may, however, be useful against resource exhaustion + attacks based on the exhaustion of state information (e.g., TCP SYN + attacks). + + The MPLS data plane, as presently defined, is not amenable to source + authentication, as there are no source identifiers in the MPLS packet + to authenticate. The MPLS label is only locally meaningful. It may + be assigned by a downstream node or upstream node for multicast + support. + + When the MPLS payload carries identifiers that may be authenticated + (e.g., IP packets), authentication may be carried out at the client + level, but this does not help the MPLS SP, as these client + identifiers belong to an external, untrusted network. + +5.1.1. Management System Authentication + + Management system authentication includes the authentication of a PE + to a centrally managed network management or directory server when + directory-based "auto-discovery" is used. It also includes + authentication of a CE to the configuration server, when a + configuration server system is used. + + Authentication should be bidirectional, including PE or CE to + configuration server authentication for the PE or CE to be certain it + is communicating with the right server. + +5.1.2. Peer-to-Peer Authentication + + Peer-to-peer authentication includes peer authentication for network + control protocols (e.g., LDP, BGP, etc.) and other peer + authentication (i.e., authentication of one IPsec security gateway by + another). + + Authentication should be bidirectional, including PE or CE to + configuration server authentication for the PE or CE to be certain it + is communicating with the right server. + + As indicated in Section 5.1.1, authentication should be + bidirectional. + +5.1.3. Cryptographic Techniques for Authenticating Identity + + Cryptographic techniques offer several mechanisms for authenticating + the identity of devices or individuals. These include the use of + shared secret keys, one-time keys generated by accessory devices or + software, user-ID and password pairs, and a range of public-private + + + + +Fang Informational [Page 21] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + key systems. Another approach is to use a hierarchical Certification + Authority system to provide digital certificates. + + This section describes or provides references to the specific + cryptographic approaches for authenticating identity. These + approaches provide secure mechanisms for most of the authentication + scenarios required in securing an MPLS/GMPLS network. + +5.2. Cryptographic Techniques + + MPLS/GMPLS defenses against a wide variety of attacks can be enhanced + by the proper application of cryptographic techniques. These same + cryptographic techniques are applicable to general network + communications and can provide confidentiality (encryption) of + communication between devices, authenticate the identities of the + devices, and detect whether the data being communicated has been + changed during transit or replayed from previous messages. + + Several aspects of authentication are addressed in some detail in a + separate "Authentication" section (Section 5.1). + + Cryptographic methods add complexity to a service and thus, for a few + reasons, may not be the most practical solution in every case. + Cryptography adds an additional computational burden to devices, + which may reduce the number of user connections that can be handled + on a device or otherwise reduce the capacity of the device, + potentially driving up the provider's costs. Typically, configuring + encryption services on devices adds to the complexity of their + configuration and adds labor cost. Some key management system is + usually needed. Packet sizes are typically increased when the + packets are encrypted or have integrity checks or replay counters + added, increasing the network traffic load and adding to the + likelihood of packet fragmentation with its increased overhead. + (This packet length increase can often be mitigated to some extent by + data compression techniques, but at the expense of additional + computational burden.) Finally, some providers may employ enough + other defensive techniques, such as physical isolation or filtering + and firewall techniques, that they may not perceive additional + benefit from encryption techniques. + + Users may wish to provide confidentiality end to end. Generally, + encrypting for confidentiality must be accompanied with cryptographic + integrity checks to prevent certain active attacks against the + encrypted communications. On today's processors, encryption and + integrity checks run extremely quickly, but key management may be + more demanding in terms of both computational and administrative + overhead. + + + + +Fang Informational [Page 22] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider, + and other parts of the network is a major element in determining the + applicability of cryptographic protection for any specific MPLS/GMPLS + implementation. In particular, it determines where cryptographic + protection should be applied: + + - If the data path between the user's site and the provider's PE is + not trusted, then it may be used on the PE-CE link. + + - If some part of the backbone network is not trusted, particularly + in implementations where traffic may travel across the Internet or + multiple providers' networks, then the PE-PE traffic may be + cryptographically protected. One also should consider cases where + L1 technology may be vulnerable to eavesdropping. + + - If the user does not trust any zone outside of its premises, it + may require end-to-end or CE-CE cryptographic protection. This + fits within the scope of this MPLS/GMPLS security framework when + the CE is provisioned by the MPLS/GMPLS provider. + + - If the user requires remote access to its site from a system at a + location that is not a customer location (for example, access by a + traveler), there may be a requirement for cryptographically + protecting the traffic between that system and an access point or + a customer's site. If the MPLS/GMPLS provider supplies the access + point, then the customer must cooperate with the provider to + handle the access control services for the remote users. These + access control services are usually protected cryptographically, + as well. + + Access control usually starts with authentication of the entity. If + cryptographic services are part of the scenario, then it is important + to bind the authentication to the key management. Otherwise, the + protocol is vulnerable to being hijacked between the authentication + and key management. + + Although CE-CE cryptographic protection can provide integrity and + confidentiality against third parties, if the MPLS/GMPLS provider has + complete management control over the CE (encryption) devices, then it + may be possible for the provider to gain access to the user's traffic + or internal network. Encryption devices could potentially be + reconfigured to use null encryption, bypass cryptographic processing + altogether, reveal internal configuration, or provide some means of + sniffing or diverting unencrypted traffic. Thus an implementation + using CE-CE encryption needs to consider the trust relationship + between the MPLS/GMPLS user and provider. MPLS/GMPLS users and + providers may wish to negotiate a service level agreement (SLA) for + CE-CE encryption that provides an acceptable demarcation of + + + +Fang Informational [Page 23] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + responsibilities for management of cryptographic protection on the CE + devices. The demarcation may also be affected by the capabilities of + the CE devices. For example, the CE might support some partitioning + of management, a configuration lock-down ability, or shared + capability to verify the configuration. In general, the MPLS/GMPLS + user needs to have a fairly high level of trust that the MPLS/GMPLS + provider will properly provision and manage the CE devices, if the + managed CE-CE model is used. + +5.2.1. IPsec in MPLS/GMPLS + + IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411] + [IPSECME-ROADMAP] is the security protocol of choice for protection + at the IP layer. IPsec provides robust security for IP traffic + between pairs of devices. Non-IP traffic, such as IS-IS routing, + must be converted to IP (e.g., by encapsulation) in order to use + IPsec. When the MPLS is encapsulating IP traffic, then IPsec covers + the encryption of the IP client layer; for non-IP client traffic, see + Section 5.2.4 (MPLS PWs). + + In the MPLS/GMPLS model, IPsec can be employed to protect IP traffic + between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec + may be employed in either a provider-provisioned or a user- + provisioned model. Likewise, IPsec protection of data performed + within the user's site is outside the scope of this document, because + it is simply handled as user data by the MPLS/GMPLS core. However, + if the SP performs compression, pre-encryption will have a major + effect on that operation. + + IPsec does not itself specify cryptographic algorithms. It can use a + variety of integrity or confidentiality algorithms (or even combined + integrity and confidentiality algorithms) with various key lengths, + such as AES encryption or AES message integrity checks. There are + trade-offs between key length, computational burden, and the level of + security of the encryption. A full discussion of these trade-offs is + beyond the scope of this document. In practice, any currently + recommended IPsec protection offers enough security to reduce the + likelihood of its being directly targeted by an attacker + substantially; other weaker links in the chain of security are likely + to be attacked first. MPLS/GMPLS users may wish to use a Service + Level Agreement (SLA) specifying the SP's responsibility for ensuring + data integrity and confidentiality, rather than analyzing the + specific encryption techniques used in the MPLS/GMPLS service. + + Encryption algorithms generally come with two parameters: mode such + as Cipher Block Chaining and key length such as AES-192. (This + should not be confused with two other senses in which the word "mode" + is used: IPsec itself can be used in Tunnel Mode or Transport Mode, + + + +Fang Informational [Page 24] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + and IKE [version 1] uses Main Mode, Aggressive Mode, or Quick Mode). + It should be stressed that IPsec encryption without an integrity + check is a state of sin. + + For many of the MPLS/GMPLS provider's network control messages and + some user requirements, cryptographic authentication of messages + without encryption of the contents of the message may provide + appropriate security. Using IPsec, authentication of messages is + provided by the Authentication Header (AH) or through the use of the + Encapsulating Security Protocol (ESP) with NULL encryption. Where + control messages require integrity but do not use IPsec, other + cryptographic authentication methods are often available. Message + authentication methods currently considered to be secure are based on + hashed message authentication codes (HMAC) [RFC2104] implemented with + a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) + [RFC3174]. No attacks against HMAC SHA-1 are likely to play out in + the near future, but it is possible that people will soon find SHA-1 + collisions. Thus, it is important that mechanisms be designed to be + flexible about the choice of hash functions and message integrity + checks. Also, many of these mechanisms do not include a convenient + way to manage and update keys. + + A mechanism to provide a combination of confidentiality, data-origin + authentication, and connectionless integrity is the use of AES in GCM + (Counter with CBC-MAC) mode (RFC 4106) [RFC4106]. + +5.2.2. MPLS / GMPLS Diffserv and IPsec + + MPLS and GMPLS, which provide differentiated services based on + traffic type, may encounter some conflicts with IPsec encryption of + traffic. Because encryption hides the content of the packets, it may + not be possible to differentiate the encrypted traffic in the same + manner as unencrypted traffic. Although Diffserv markings are copied + to the IPsec header and can provide some differentiation, not all + traffic types can be accommodated by this mechanism. Using IPsec + without IKE or IKEv2 (the better choice) is not advisable. IKEv2 + provides IPsec Security Association creation and management, entity + authentication, key agreement, and key update. It works with a + variety of authentication methods including pre-shared keys, public + key certificates, and EAP. If DoS attacks against IKEv2 are + considered an important threat to mitigate, the cookie-based anti- + spoofing feature of IKEv2 should be used. IKEv2 has its own set of + cryptographic methods, but any of the default suites specified in + [RFC4308] or [RFC4869] provides more than adequate security. + + + + + + + +Fang Informational [Page 25] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +5.2.3. Encryption for Device Configuration and Management + + For configuration and management of MPLS/GMPLS devices, encryption + and authentication of the management connection at a level comparable + to that provided by IPsec is desirable. + + Several methods of transporting MPLS/GMPLS device management traffic + offer authentication, integrity, and confidentiality. + + - Secure Shell (SSH) offers protection for TELNET [STD8] or + terminal-like connections to allow device configuration. + + - SNMPv3 [STD62] provides encrypted and authenticated protection for + SNMP-managed devices. + + - Transport Layer Security (TLS) [RFC5246] and the closely-related + Secure Sockets Layer (SSL) are widely used for securing HTTP-based + communication, and thus can provide support for most XML- and + SOAP-based device management approaches. + + - Since 2004, there has been extensive work proceeding in several + organizations (OASIS, W3C, WS-I, and others) on securing device + management traffic within a "Web Services" framework, using a wide + variety of security models, and providing support for multiple + security token formats, multiple trust domains, multiple signature + formats, and multiple encryption technologies. + + - IPsec provides security services including integrity and + confidentiality at the network layer. With regards to device + management, its current use is primarily focused on in-band + management of user-managed IPsec gateway devices. + + - There is recent work in the ISMS WG (Integrated Security Model for + SNMP Working Group) to define how to use SSH to secure SNMP, due + to the limited deployment of SNMPv3, and the possibility of using + Kerberos, particularly for interfaces like TELNET, where client + code exists. + +5.2.4. Security Considerations for MPLS Pseudowires + + In addition to IP traffic, MPLS networks may be used to transport + other services such as Ethernet, ATM, Frame Relay, and TDM. This is + done by setting up pseudowires (PWs) that tunnel the native service + through the MPLS core by encapsulating at the edges. The PWE + architecture is defined in [RFC3985]. + + + + + + +Fang Informational [Page 26] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + PW tunnels may be set up using the PWE control protocol based on LDP + [RFC4447], and thus security considerations for LDP will most likely + be applicable to the PWE3 control protocol as well. + + PW user packets contain at least one MPLS label (the PW label) and + may contain one or more MPLS tunnel labels. After the label stack, + there is a four-byte control word (which is optional for some PW + types), followed by the native service payload. It must be stressed + that encapsulation of MPLS PW packets in IP for the purpose of + enabling use of IPsec mechanisms is not a valid option. + + The following is a non-exhaustive list of PW-specific threats: + + - Unauthorized setup of a PW (e.g., to gain access to a customer + network) + + - Unauthorized teardown of a PW (thus causing denial of service) + + - Malicious reroute of a PW + + - Unauthorized observation of PW packets + + - Traffic analysis of PW connectivity + + - Unauthorized insertion of PW packets + + - Unauthorized modification of PW packets + + - Unauthorized deletion of PW packets replay of PW packets + + - Denial of service or significant impact on PW service quality + + These threats are not mutually exclusive, for example, rerouting can + be used for snooping or insertion/deletion/replay, etc. Multisegment + PWs introduce additional weaknesses at their stitching points. + + The PW user plane suffers from the following inherent security + weaknesses: + + - Since the PW label is the only identifier in the packet, there is + no authenticatable source address. + + - Since guessing a valid PW label is not difficult, it is relatively + easy to introduce seemingly valid foreign packets. + + - Since the PW packet is not self-describing, minor modification of + control-plane packets renders the data-plane traffic useless. + + + + +Fang Informational [Page 27] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + - The control-word sequence number processing algorithm is + susceptible to a DoS attack. + + The PWE control protocol introduces its own weaknesses: + + - No (secure) peer autodiscovery technique has been standardized . + + - PE authentication is not mandated, so an intruder can potentially + impersonate a PE; after impersonating a PE, unauthorized PWs may + be set up, consuming resources and perhaps allowing access to user + networks. + + - Alternately, desired PWs may be torn down, giving rise to denial + of service. + + The following characteristics of PWs can be considered security + strengths: + + - The most obvious attacks require compromising edge or core routers + (although not necessarily those along the PW path). + + - Adequate protection of the control-plane messaging is sufficient + to rule out many types of attacks. + + - PEs are usually configured to reject MPLS packets from outside the + service provider network, thus ruling out insertion of PW packets + from the outside (since IP packets cannot masquerade as PW + packets). + +5.2.5. End-to-End versus Hop-by-Hop Protection Tradeoffs in MPLS/GMPLS + + In MPLS/GMPLS, cryptographic protection could potentially be applied + to the MPLS/GMPLS traffic at several different places. This section + discusses some of the tradeoffs in implementing encryption in several + different connection topologies among different devices within an + MPLS/GMPLS network. + + Cryptographic protection typically involves a pair of devices that + protect the traffic passing between them. The devices may be + directly connected (over a single "hop"), or intervening devices may + transport the protected traffic between the pair of devices. The + extreme cases involve using protection between every adjacent pair of + devices along a given path (hop-by-hop), or using protection only + between the end devices along a given path (end-to-end). To keep + this discussion within the scope of this document, the latter ("end- + to-end") case considered here is CE-to-CE rather than fully end-to- + end. + + + + +Fang Informational [Page 28] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Figure 3 depicts a simplified topology showing the Customer Edge (CE) + devices, the Provider Edge (PE) devices, and a variable number (three + are shown) of Provider core (P) devices, which might be present along + the path between two sites in a single VPN operated by a single + service provider (SP). + + Site_1---CE---PE---P---P---P---PE---CE---Site_2 + + Figure 3: Simplified Topology Traversing through MPLS/GMPLS Core + + Within this simplified topology, and assuming that the P devices are + not involved with cryptographic protection, four basic, feasible + configurations exist for protecting connections among the devices: + + 1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity + services between the two CE devices, so that traffic will be + protected throughout the SP's network. + + 2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or + integrity services between the two PE devices. Unprotected + traffic is received at one PE from the customer's CE, then it is + protected for transmission through the SP's network to the other + PE, and finally it is decrypted or checked for integrity and sent + to the other CE. + + 3) Access link (CE-to-PE) - Apply confidentiality or integrity + services between the CE and PE on each side or on only one side. + + 4) Configurations 2 and 3 above can also be combined, with + confidentiality or integrity running from CE to PE, then PE to PE, + and then PE to CE. + + Among the four feasible configurations, key tradeoffs in considering + encryption include: + + - Vulnerability to link eavesdropping or tampering - assuming an + attacker can observe or modify data in transit on the links, would + it be protected by encryption? + + - Vulnerability to device compromise - assuming an attacker can get + access to a device (or freely alter its configuration), would the + data be protected? + + - Complexity of device configuration and management - given the + number of sites per VPN customer as Nce and the number of PEs + participating in a given VPN as Npe, how many device + configurations need to be created or maintained, and how do those + configurations scale? + + + +Fang Informational [Page 29] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + - Processing load on devices - how many cryptographic operations + must be performed given N packets? - This raises considerations of + device capacity and perhaps end-to-end delay. + + - Ability of the SP to provide enhanced services (QoS, firewall, + intrusion detection, etc.) - Can the SP inspect the data to + provide these services? + + These tradeoffs are discussed for each configuration, below: + + 1) Site-to-site (CE-to-CE) + + Link eavesdropping or tampering - protected on all links. Device + compromise - vulnerable to CE compromise. + + Complexity - single administration, responsible for one device per + site (Nce devices), but overall configuration per VPN scales as + Nce**2. + + Though the complexity may be reduced: 1) In practice, as Nce + grows, the number of VPNs falls off from being a full clique; + 2) If the CEs run an automated key management protocol, then + they should be able to set up and tear down secured VPNs + without any intervention. + + Processing load - on each of the two CEs, each packet is + cryptographically processed (2P), though the protection may be + "integrity check only" or "integrity check plus encryption." + + Enhanced services - severely limited; typically only Diffserv + markings are visible to the SP, allowing some QoS services. + The CEs could also use the IPv6 Flow Label to identify traffic + classes. + + 2) Provider Edge-to-Edge (PE-to-PE) + + Link eavesdropping or tampering - vulnerable on CE-PE links; + protected on SP's network links. + + Device compromise - vulnerable to CE or PE compromise. + + Complexity - single administration, Npe devices to configure. + (Multiple sites may share a PE device so Npe is typically much + smaller than Nce.) Scalability of the overall configuration + depends on the PPVPN type: if the cryptographic protection is + separate per VPN context, it scales as Npe**2 per customer VPN. + If it is per-PE, it scales as Npe**2 for all customer VPNs + combined. + + + +Fang Informational [Page 30] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Processing load - on each of the two PEs, each packet is + cryptographically processed (2P). + + Enhanced services - full; SP can apply any enhancements based on + detailed view of traffic. + + 3) Access Link (CE-to-PE) + + Link eavesdropping or tampering - protected on CE-PE link; + vulnerable on SP's network links. + + Device compromise - vulnerable to CE or PE compromise. + + Complexity - two administrations (customer and SP) with device + configuration on each side (Nce + Npe devices to configure), + but because there is no mesh, the overall configuration scales + as Nce. + + Processing load - on each of the two CEs, each packet is + cryptographically processed, plus on each of the two PEs, each + packet is cryptographically processed (4P). + + Enhanced services - full; SP can apply any enhancements based on a + detailed view of traffic. + + 4) Combined Access link and PE-to-PE (essentially hop-by-hop). + + Link eavesdropping or tampering - protected on all links. + + Device compromise - vulnerable to CE or PE compromise. + + Complexity - two administrations (customer and SP) with device + configuration on each side (Nce + Npe devices to configure). + Scalability of the overall configuration depends on the PPVPN + type: If the cryptographic processing is separate per VPN + context, it scales as Npe**2 per customer VPN. If it is per- + PE, it scales as Npe**2 for all customer VPNs combined. + + Processing load - on each of the two CEs, each packet is + cryptographically processed, plus on each of the two PEs, each + packet is cryptographically processed twice (6P). + + Enhanced services - full; SP can apply any enhancements based on a + detailed view of traffic. + + + + + + + +Fang Informational [Page 31] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Given the tradeoffs discussed above, a few conclusions can be drawn: + + - Configurations 2 and 3 are subsets of 4 that may be appropriate + alternatives to 4 under certain threat models; the remainder of + these conclusions compare 1 (CE-to-CE) versus 4 (combined access + links and PE-to-PE). + + - If protection from link eavesdropping or tampering is all that is + important, then configurations 1 and 4 are equivalent. + + - If protection from device compromise is most important and the + threat is to the CE devices, both cases are equivalent; if the + threat is to the PE devices, configuration 1 is better. + + - If reducing complexity is most important, and the size of the + network is small, configuration 1 is better. Otherwise, + configuration 4 is better because rather than a mesh of CE + devices, it requires a smaller mesh of PE devices. Also, under + some PPVPN approaches, the scaling of 4 is further improved by + sharing the same PE-PE mesh across all VPN contexts. The scaling + advantage of 4 may be increased or decreased in any given + situation if the CE devices are simpler to configure than the PE + devices, or vice-versa. + + - If the overall processing load is a key factor, then 1 is better, + unless the PEs come with a hardware encryption accelerator and the + CEs do not. + + - If the availability of enhanced services support from the SP is + most important, then 4 is best. + + - If users are concerned with having their VPNs misconnected with + other users' VPNs, then encryption with 1 can provide protection. + + As a quick overall conclusion, CE-to-CE protection is better against + device compromise, but this comes at the cost of enhanced services + and at the cost of operational complexity due to the Order(n**2) + scaling of a larger mesh. + + This analysis of site-to-site vs. hop-by-hop tradeoffs does not + explicitly include cases of multiple providers cooperating to provide + a PPVPN service, public Internet VPN connectivity, or remote access + VPN service, but many of the tradeoffs are similar. + + + + + + + + +Fang Informational [Page 32] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + In addition to the simplified models, the following should also be + considered: + + - There are reasons, perhaps, to protect a specific P-to-P or PE- + to-P. + + - There may be reasons to do multiple encryptions over certain + segments. One may be using an encrypted wireless link under our + IPsec VPN to access an SSL-secured web site to download encrypted + email attachments: four layers.) + + - It may be appropriate that, for example, cryptographic integrity + checks are applied end to end, and confidentiality is applied over + a shorter span. + + - Different cryptographic protection may be required for control + protocols and data traffic. + + - Attention needs to be given to how auxiliary traffic is protected, + e.g., the ICMPv6 packets that flow back during PMTU discovery, + among other examples. + +5.3. Access Control Techniques + + Access control techniques include packet-by-packet or packet-flow- + by-packet-flow access control by means of filters and firewalls on + IPv4/IPv6 packets, as well as by means of admitting a "session" for a + control, signaling, or management protocol. Enforcement of access + control by isolated infrastructure addresses is discussed in Section + 5.4 of this document. + + In this document, we distinguish between filtering and firewalls + based primarily on the direction of traffic flow. We define + filtering as being applicable to unidirectional traffic, while a + firewall can analyze and control both sides of a conversation. + + The definition has two significant corollaries: + + - Routing or traffic flow symmetry: A firewall typically requires + routing symmetry, which is usually enforced by locating a firewall + where the network topology assures that both sides of a + conversation will pass through the firewall. A filter can operate + upon traffic flowing in one direction, without considering traffic + in the reverse direction. Beware that this concept could result + in a single point of failure. + + + + + + +Fang Informational [Page 33] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + - Statefulness: Because it receives both sides of a conversation, a + firewall may be able to interpret a significant amount of + information concerning the state of that conversation and use this + information to control access. A filter can maintain some limited + state information on a unidirectional flow of packets, but cannot + determine the state of the bidirectional conversation as precisely + as a firewall. + + For a general description on filtering and rate limiting for IP + networks, please also see [OPSEC-FILTER]. + +5.3.1. Filtering + + It is relatively common for routers to filter packets. That is, + routers can look for particular values in certain fields of the IP or + higher-level (e.g., TCP or UDP) headers. Packets matching the + criteria associated with a particular filter may either be discarded + or given special treatment. Today, not only routers, but most end + hosts have filters, and every instance of IPsec is also a filter + [RFC4301]. + + In discussing filters, it is useful to separate the filter + characteristics that may be used to determine whether a packet + matches a filter from the packet actions applied to those packets + matching a particular filter. + + o Filter Characteristics + + Filter characteristics or rules are used to determine whether a + particular packet or set of packets matches a particular filter. + + In many cases, filter characteristics may be stateless. A stateless + filter determines whether a particular packet matches a filter based + solely on the filter definition, normal forwarding information (such + as the next hop for a packet), the interface on which a packet + arrived, and the contents of that individual packet. Typically, + stateless filters may consider the incoming and outgoing logical or + physical interface, information in the IP header, and information in + higher-layer headers such as the TCP or UDP header. Information in + the IP header to be considered may for example include source and + destination IP addresses; Protocol field, Fragment Offset, and TOS + field in IPv4; or Next Header, Extension Headers, Flow label, etc. in + IPv6. Filters also may consider fields in the TCP or UDP header such + as the Port numbers, the SYN field in the TCP header, as well as ICMP + and ICMPv6 type. + + + + + + +Fang Informational [Page 34] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Stateful filtering maintains packet-specific state information to aid + in determining whether a filter rule has been met. For example, a + device might apply stateless filtering to the first fragment of a + fragmented IPv4 packet. If the filter matches, then the data unit ID + may be remembered and other fragments of the same packet may then be + considered to match the same filter. Stateful filtering is more + commonly done in firewalls, although firewall technology may be added + to routers. The data unit ID can also be a Fragment Extension Header + Identification field in IPv6. + + o Actions based on Filter Results + + If a packet, or a series of packets, matches a specific filter, then + a variety of actions may be taken based on that match. Examples of + such actions include: + + - Discard + + In many cases, filters are set to catch certain undesirable + packets. Examples may include packets with forged or invalid + source addresses, packets that are part of a DoS or Distributed + DoS (DDoS) attack, or packets trying to access unallowed + resources (such as network management packets from an + unauthorized source). Where such filters are activated, it is + common to discard the packet or set of packets matching the + filter silently. The discarded packets may of course also be + counted or logged. + + - Set CoS + + A filter may be used to set the class of service associated + with the packet. + + - Count packets or bytes + + - Rate Limit + + In some cases, the set of packets matching a particular filter + may be limited to a specified bandwidth. In this case, packets + or bytes would be counted, and would be forwarded normally up + to the specified limit. Excess packets may be discarded or may + be marked (for example, by setting a "discard eligible" bit in + the IPv4 ToS field, or changing the EXP value to identify + traffic as being out of contract). + + + + + + + +Fang Informational [Page 35] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + - Forward and Copy + + It is useful in some cases to forward some set of packets + normally, but also to send a copy to a specified other address + or interface. For example, this may be used to implement a + lawful intercept capability or to feed selected packets to an + Intrusion Detection System. + + o Other Packet Filters Issues + + Filtering performance may vary widely according to implementation and + the types and number of rules. Without acceptable performance, + filtering is not useful. + + The precise definition of "acceptable" may vary from SP to SP, and + may depend upon the intended use of the filters. For example, for + some uses, a filter may be turned on all the time to set CoS, to + prevent an attack, or to mitigate the effect of a possible future + attack. In this case, it is likely that the SP will want the filter + to have minimal or no impact on performance. In other cases, a + filter may be turned on only in response to a major attack (such as a + major DDoS attack). In this case, a greater performance impact may + be acceptable to some service providers. + + A key consideration with the use of packet filters is that they can + provide few options for filtering packets carrying encrypted data. + Because the data itself is not accessible, only packet header + information or other unencrypted fields can be used for filtering. + +5.3.2. Firewalls + + Firewalls provide a mechanism for controlling traffic passing between + different trusted zones in the MPLS/GMPLS model or between a trusted + zone and an untrusted zone. Firewalls typically provide much more + functionality than filters, because they may be able to apply + detailed analysis and logical functions to flows, and not just to + individual packets. They may offer a variety of complex services, + such as threshold-driven DoS attack protection, virus scanning, + acting as a TCP connection proxy, etc. + + As with other access control techniques, the value of firewalls + depends on a clear understanding of the topologies of the MPLS/GMPLS + core network, the user networks, and the threat model. Their + effectiveness depends on a topology with a clearly defined inside + (secure) and outside (not secure). + + Firewalls may be applied to help protect MPLS/GMPLS core network + functions from attacks originating from the Internet or from + + + +Fang Informational [Page 36] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + MPLS/GMPLS user sites, but typically other defensive techniques will + be used for this purpose. + + Where firewalls are employed as a service to protect user VPN sites + from the Internet, different VPN users, and even different sites of a + single VPN user, may have varying firewall requirements. The overall + PPVPN logical and physical topology, along with the capabilities of + the devices implementing the firewall services, has a significant + effect on the feasibility and manageability of such varied firewall + service offerings. + + Another consideration with the use of firewalls is that they can + provide few options for handling packets carrying encrypted data. + Because the data itself is not accessible, only packet header + information, other unencrypted fields, or analysis of the flow of + encrypted packets can be used for making decisions on accepting or + rejecting encrypted traffic. + + Two approaches of using firewalls are to move the firewall outside of + the encrypted part of the path or to register and pre-approve the + encrypted session with the firewall. + + Handling DoS attacks has become increasingly important. Useful + guidelines include the following: + + 1. Perform ingress filtering everywhere. + + 2. Be able to filter DoS attack packets at line speed. + + 3. Do not allow oneself to amplify attacks. + + 4. Continue processing legitimate traffic. Over provide for heavy + loads. Use diverse locations, technologies, etc. + +5.3.3. Access Control to Management Interfaces + + Most of the security issues related to management interfaces can be + addressed through the use of authentication techniques as described + in the section on authentication (Section 5.1). However, additional + security may be provided by controlling access to management + interfaces in other ways. + + The Optical Internetworking Forum has done relevant work on + protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. + See "Security for Management Interfaces to Network Elements" + [OIF-SMI-01.0] and "Addendum to the Security for Management + Interfaces to Network Elements" [OIF-SMI-02.1]. See also the work in + the ISMS WG (http://datatracker.ietf.org/wg/isms/charter/). + + + +Fang Informational [Page 37] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Management interfaces, especially console ports on MPLS/GMPLS + devices, may be configured so they are only accessible out-of-band, + through a system that is physically or logically separated from the + rest of the MPLS/GMPLS infrastructure. + + Where management interfaces are accessible in-band within the + MPLS/GMPLS domain, filtering or firewalling techniques can be used to + restrict unauthorized in-band traffic from having access to + management interfaces. Depending on device capabilities, these + filtering or firewalling techniques can be configured either on other + devices through which the traffic might pass, or on the individual + MPLS/GMPLS devices themselves. + +5.4. Use of Isolated Infrastructure + + One way to protect the infrastructure used for support of MPLS/GMPLS + is to separate the resources for support of MPLS/GMPLS services from + the resources used for other purposes (such as support of Internet + services). In some cases, this may involve using physically separate + equipment for VPN services, or even a physically separate network. + + For example, PE-based IPVPNs may be run on a separate backbone not + connected to the Internet, or may use separate edge routers from + those supporting Internet service. Private IPv4 addresses (local to + the provider and non-routable over the Internet) are sometimes used + to provide additional separation. For a discussion of comparable + techniques for IPv6, see "Local Network Protection for IPv6," RFC + 4864 [RFC4864]. + + In a GMPLS network, it is possible to operate the control plane using + physically separate resources from those used for the data plane. + This means that the data-plane resources can be physically protected + and isolated from other equipment to protect users' data while the + control and management traffic uses network resources that can be + accessed by operators to configure the network. Conversely, the + separation of control and data traffic may lead the operator to + consider that the network is secure because the data-plane resources + are physically secure. However, this is not the case if the control + plane can be attacked through a shared or open network, and control- + plane protection techniques must still be applied. + +5.5. Use of Aggregated Infrastructure + + In general, it is not feasible to use a completely separate set of + resources for support of each service. In fact, one of the main + reasons for MPLS/GMPLS enabled services is to allow sharing of + resources between multiple services and multiple users. Thus, even + if certain services use a separate network from Internet services, + + + +Fang Informational [Page 38] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + nonetheless there will still be multiple MPLS/GMPLS users sharing the + same network resources. In some cases, MPLS/GMPLS services will + share network resources with Internet services or other services. + + It is therefore important for MPLS/GMPLS services to provide + protection between resources used by different parties. Thus, a + well-behaved MPLS/GMPLS user should be protected from possible + misbehavior by other users. This requires several security + measurements to be implemented. Resource limits can be placed on a + per service and per user basis. Possibilities include, for example, + using a virtual router or logical router to define hardware or + software resource limits per service or per individual user; using + rate limiting per Virtual Routing and Forwarding (VRF) or per + Internet connection to provide bandwidth protection; or using + resource reservation for control-plane traffic. In addition to + bandwidth protection, separate resource allocation can be used to + limit security attacks only to directly impacted service(s) or + customer(s). Strict, separate, and clearly defined engineering rules + and provisioning procedures can reduce the risks of network-wide + impact of a control-plane attack, DoS attack, or misconfiguration. + + In general, the use of aggregated infrastructure allows the service + provider to benefit from stochastic multiplexing of multiple bursty + flows, and also may in some cases thwart traffic pattern analysis by + combining the data from multiple users. However, service providers + must minimize security risks introduced from any individual service + or individual users. + +5.6. Service Provider Quality Control Processes + + Deployment of provider-provisioned VPN services in general requires a + relatively large amount of configuration by the SP. For example, the + SP needs to configure which VPN each site belongs to, as well as QoS + and SLA guarantees. This large amount of required configuration + leads to the possibility of misconfiguration. + + It is important for the SP to have operational processes in place to + reduce the potential impact of misconfiguration. CE-to-CE + authentication may also be used to detect misconfiguration when it + occurs. CE-to-CE encryption may also limit the damage when + misconfiguration occurs. + +5.7. Deployment of Testable MPLS/GMPLS Service + + This refers to solutions that can be readily tested to make sure they + are configured correctly. For example, for a point-to-point + connection, checking that the intended connectivity is working pretty + + + + +Fang Informational [Page 39] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + much ensures that there is no unintended connectivity to some other + site. + +5.8. Verification of Connectivity + + In order to protect against deliberate or accidental misconnection, + mechanisms can be put in place to verify both end-to-end connectivity + and hop-by-hop resources. These mechanisms can trace the routes of + LSPs in both the control plane and the data plane. + + It should be noted that if there is an attack on the control plane, + data-plane connectivity test mechanisms that rely on the control + plane can also be attacked. This may hide faults through false + positives or disrupt functioning services through false negatives. + +6. Monitoring, Detection, and Reporting of Security Attacks + + MPLS/GMPLS network and service may be subject to attacks from a + variety of security threats. Many threats are described in Section 4 + of this document. Many of the defensive techniques described in this + document and elsewhere provide significant levels of protection from + a variety of threats. However, in addition to employing defensive + techniques silently to protect against attacks, MPLS/GMPLS services + can also add value for both providers and customers by implementing + security monitoring systems to detect and report on any security + attacks, regardless of whether the attacks are effective. + + Attackers often begin by probing and analyzing defenses, so systems + that can detect and properly report these early stages of attacks can + provide significant benefits. + + Information concerning attack incidents, especially if available + quickly, can be useful in defending against further attacks. It can + be used to help identify attackers or their specific targets at an + early stage. This knowledge about attackers and targets can be used + to strengthen defenses against specific attacks or attackers, or to + improve the defenses for specific targets on an as-needed basis. + Information collected on attacks may also be useful in identifying + and developing defenses against novel attack types. + + Monitoring systems used to detect security attacks in MPLS/GMPLS + typically operate by collecting information from the Provider Edge + (PE), Customer Edge (CE), and/or Provider backbone (P) devices. + Security monitoring systems should have the ability to actively + retrieve information from devices (e.g., SNMP get) or to passively + receive reports from devices (e.g., SNMP notifications). The systems + may actively retrieve information from devices (e.g., SNMP get) or + passively receive reports from devices (e.g., SNMP notifications). + + + +Fang Informational [Page 40] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + The specific information exchanged depends on the capabilities of the + devices and on the type of VPN technology. Particular care should be + given to securing the communications channel between the monitoring + systems and the MPLS/GMPLS devices. + + The CE, PE, and P devices should employ efficient methods to acquire + and communicate the information needed by the security monitoring + systems. It is important that the communication method between + MPLS/GMPLS devices and security monitoring systems be designed so + that it will not disrupt network operations. As an example, multiple + attack events may be reported through a single message, rather than + allowing each attack event to trigger a separate message, which might + result in a flood of messages, essentially becoming a DoS attack + against the monitoring system or the network. + + + The mechanisms for reporting security attacks should be flexible + enough to meet the needs of MPLS/GMPLS service providers, MPLS/GMPLS + customers, and regulatory agencies, if applicable. The specific + reports should depend on the capabilities of the devices, the + security monitoring system, the type of VPN, and the service level + agreements between the provider and customer. + + While SNMP/syslog type monitoring and detection mechanisms can detect + some attacks (usually resulting from flapping protocol adjacencies, + CPU overload scenarios, etc.), other techniques, such as netflow- + based traffic fingerprinting, are needed for more detailed detection + and reporting. + + With netflow-based traffic fingerprinting, each packet that is + forwarded within a device is examined for a set of IP packet + attributes. These attributes are the IP packet identity or + fingerprint of the packet and determine if the packet is unique or + similar to other packets. + + The flow information is extremely useful for understanding network + behavior, and detecting and reporting security attacks: + + - Source address allows the understanding of who is originating the + traffic. + + - Destination address tells who is receiving the traffic. + + - Ports characterize the application utilizing the traffic. + + - Class of service examines the priority of the traffic. + + + + + +Fang Informational [Page 41] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + - The device interface tells how traffic is being utilized by the + network device. + + - Tallied packets and bytes show the amount of traffic. + + - Flow timestamps allow the understanding of the life of a flow; + timestamps are useful for calculating packets and bytes per + second. + + - Next-hop IP addresses including BGP routing Autonomous Systems + (ASes). + + - Subnet mask for the source and destination addresses are for + calculating prefixes. + + - TCP flags are useful for examining TCP handshakes. + +7. Service Provider General Security Requirements + + This section covers security requirements the provider may have for + securing its MPLS/GMPLS network infrastructure including LDP and + RSVP-TE-specific requirements. + + The MPLS/GMPLS service provider's requirements defined here are for + the MPLS/GMPLS core in the reference model. The core network can be + implemented with different types of network technologies, and each + core network may use different technologies to provide the various + services to users with different levels of offered security. + Therefore, an MPLS/GMPLS service provider may fulfill any number of + the security requirements listed in this section. This document does + not state that an MPLS/GMPLS network must fulfill all of these + requirements to be secure. + + These requirements are focused on: 1) how to protect the MPLS/GMPLS + core from various attacks originating outside the core including + those from network users, both accidentally and maliciously, and 2) + how to protect the end users. + +7.1. Protection within the Core Network + +7.1.1. Control-Plane Protection - General + + - Filtering spoofed infrastructure IP addresses at edges + + Many attacks on protocols running in a core involve spoofing a source + IP address of a node in the core (e.g., TCP-RST attacks). It makes + sense to apply anti-spoofing filtering at edges, e.g., using strict + unicast reverse path forwarding (uRPF) [RFC3704] and/or by preventing + + + +Fang Informational [Page 42] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + the use of infrastructure addresses as source. If this is done + comprehensively, the need to cryptographically secure these protocols + is smaller. See [BACKBONE-ATTKS] for more elaborate description. + + - Protocol authentication within the core + + The network infrastructure must support mechanisms for authentication + of the control-plane messages. If an MPLS/GMPLS core is used, LDP + sessions may be authenticated with TCP MD5. In addition, IGP and BGP + authentication should be considered. For a core providing various + IP, VPN, or transport services, PE-to-PE authentication may also be + performed via IPsec. See the above discussion of protocol security + services: authentication, integrity (with replay detection), and + confidentiality. Protocols need to provide a complete set of + security services from which the SP can choose. Also, the important + but often more difficult part is key management. Considerations, + guidelines, and strategies regarding key management are discussed in + [RFC3562], [RFC4107], [RFC4808]. + + With today's processors, applying cryptographic authentication to the + control plane may not increase the cost of deployment for providers + significantly, and will help to improve the security of the core. If + the core is dedicated to MPLS/GMPLS enabled services without any + interconnects to third parties, then this may reduce the requirement + for authentication of the core control plane. + + - Infrastructure Hiding + + Here we discuss means to hide the provider's infrastructure nodes. + An MPLS/GMPLS provider may make its infrastructure routers (P and PE) + unreachable from outside users and unauthorized internal users. For + example, separate address space may be used for the infrastructure + loopbacks. + + Normal TTL propagation may be altered to make the backbone look like + one hop from the outside, but caution needs to be taken for loop + prevention. This prevents the backbone addresses from being exposed + through trace route; however, this must also be assessed against + operational requirements for end-to-end fault tracing. + + An Internet backbone core may be re-engineered to make Internet + routing an edge function, for example, by using MPLS label switching + for all traffic within the core and possibly making the Internet a + VPN within the PPVPN core itself. This helps to detach Internet + access from PPVPN services. + + Separating control-plane, data-plane, and management-plane + functionality in hardware and software may be implemented on the PE + + + +Fang Informational [Page 43] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + devices to improve security. This may help to limit the problems + when attacked in one particular area, and may allow each plane to + implement additional security measures separately. + + PEs are often more vulnerable to attack than P routers, because PEs + cannot be made unreachable from outside users by their very nature. + Access to core trunk resources can be controlled on a per-user basis + by using of inbound rate limiting or traffic shaping; this can be + further enhanced on a per-class-of-service basis (see Section 8.2.3) + + In the PE, using separate routing processes for different services, + for example, Internet and PPVPN service, may help to improve the + PPVPN security and better protect VPN customers. Furthermore, if + resources, such as CPU and memory, can be further separated based on + applications, or even individual VPNs, it may help to provide + improved security and reliability to individual VPN customers. + +7.1.2. Control-Plane Protection with RSVP-TE + + - General RSVP Security Tools + + Isolation of the trusted domain is an important security mechanism + for RSVP, to ensure that an untrusted element cannot access a router + of the trusted domain. However, ASBR-ASBR communication for inter-AS + LSPs needs to be secured specifically. Isolation mechanisms might + also be bypassed by an IPv4 Router Alert or IPv6 using Next Header 0 + packets. A solution could consist of disabling the processing of IP + options. This drops or ignores all IP packets with IPv4 options, + including the router alert option used by RSVP; however, this may + have an impact on other protocols using IPv4 options. An alternative + is to configure access-lists on all incoming interfaces dropping IPv4 + protocol or IPv6 next header 46 (RSVP). + + RSVP security can be strengthened by deactivating RSVP on interfaces + with neighbors who are not authorized to use RSVP, to protect against + adjacent CE-PE attacks. However, this does not really protect + against DoS attacks or attacks on non-adjacent routers. It has been + demonstrated that substantial CPU resources are consumed simply by + processing received RSVP packets, even if the RSVP process is + deactivated for the specific interface on which the RSVP packets are + received. + + RSVP neighbor filtering at the protocol level, to restrict the set of + neighbors that can send RSVP messages to a given router, protects + against non-adjacent attacks. However, this does not protect against + DoS attacks and does not effectively protect against spoofing of the + source address of RSVP packets, if the filter relies on the + neighbor's address within the RSVP message. + + + +Fang Informational [Page 44] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + RSVP neighbor filtering at the data-plane level, with an access list + to accept IP packets with port 46 only for specific neighbors, + requires Router Alert mode to be deactivated and does not protect + against spoofing. + + Another valuable tool is RSVP message pacing, to limit the number of + RSVP messages sent to a given neighbor during a given period. This + allows blocking DoS attack propagation. + + - Another approach is to limit the impact of an attack on control- + plane resources. + + To ensure continued effective operation of the MPLS router even in + the case of an attack that bypasses packet filtering mechanisms such + as Access Control Lists in the data plane, it is important that + routers have some mechanisms to limit the impact of the attack. + There should be a mechanism to rate limit the amount of control-plane + traffic addressed to the router, per interface. This should be + configurable on a per-protocol basis, (and, ideally, on a per-sender + basis) to avoid letting an attacked protocol or a given sender block + all communications. This requires the ability to filter and limit + the rate of incoming messages of particular protocols, such as RSVP + (filtering at the IP protocol level), and particular senders. In + addition, there should be a mechanism to limit CPU and memory + capacity allocated to RSVP, so as to protect other control-plane + elements. To limit memory allocation, it will probably be necessary + to limit the number of LSPs that can be set up. + + - Authentication for RSVP messages + + RSVP message authentication is described in RFC 2747 [RFC2747] and + RFC 3097 [RFC3097]. It is one of the most powerful tools for + protection against RSVP-based attacks. It applies cryptographic + authentication to RSVP messages based on a secure message hash using + a key shared by RSVP neighbors. This protects against LSP creation + attacks, at the expense of consuming significant CPU resources for + digest computation. In addition, if the neighboring RSVP speaker is + compromised, it could be used to launch attacks using authenticated + RSVP messages. These methods, and certain other aspects of RSVP + security, are explained in detail in RFC 4230 [RFC4230]. Key + management must be implemented. Logging and auditing as well as + multiple layers of cryptographic protection can help here. IPsec can + also be used in some cases (see [RFC4230]). + + One challenge using RSVP message authentication arises in many cases + where non-RSVP nodes are present in the network. In such cases, the + RSVP neighbor may not be known up front, thus neighbor-based keying + approaches fail, unless the same key is used everywhere, which is not + + + +Fang Informational [Page 45] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + recommended for security reasons. Group keying may help in such + cases. The security properties of various keying approaches are + discussed in detail in [RSVP-key]. + +7.1.3. Control-Plane Protection with LDP + + The approaches to protect MPLS routers against LDP-based attacks are + similar to those for RSVP, including isolation, protocol deactivation + on specific interfaces, filtering of LDP neighbors at the protocol + level, filtering of LDP neighbors at the data-plane level (with an + access list that filters the TCP and UDP LDP ports), authentication + with a message digest, rate limiting of LDP messages per protocol per + sender, and limiting all resources allocated to LDP-related tasks. + LDP protection could be considered easier in a certain sense. UDP + port matching may be sufficient for LDP protection. Router alter + options and beyond might be involved in RSVP protection. + +7.1.4. Data-Plane Protection + + IPsec can provide authentication, integrity, confidentiality, and + replay detection for provider or user data. It also has an + associated key management protocol. + + In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is + not provided as a basic feature. Mechanisms described in Section 5 + can be used to secure the MPLS data-plane traffic carried over an + MPLS core. Both the Frame Relay Forum and the ATM Forum standardized + cryptographic security services in the late 1990s, but these + standards are not widely implemented. + +7.2. Protection on the User Access Link + + Peer or neighbor protocol authentication may be used to enhance + security. For example, BGP MD5 authentication may be used to enhance + security on PE-CE links using eBGP. In the case of inter-provider + connections, cryptographic protection mechanisms, such as IPsec, may + be used between ASes. + + If multiple services are provided on the same PE platform, different + WAN address spaces may be used for different services (e.g., VPN and + non-VPN) to enhance isolation. + + Firewall and Filtering: access control mechanisms can be used to + filter any packets destined for the service provider's infrastructure + prefix or eliminate routes identified as illegitimate. Filtering + should also be applied to prevent sourcing packets with + infrastructure IP addresses from outside. + + + + +Fang Informational [Page 46] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Rate limiting may be applied to the user interface/logical interfaces + as a defense against DDoS bandwidth attack. This is helpful when the + PE device is supporting both multiple services, especially VPN and + Internet Services, on the same physical interfaces through different + logical interfaces. + +7.2.1. Link Authentication + + Authentication can be used to validate site access to the network via + fixed or logical connections, e.g., L2TP or IPsec, respectively. If + the user wishes to hold the authentication credentials for access, + then provider solutions require the flexibility for either direct + authentication by the PE itself or interaction with a customer + authentication server. Mechanisms are required in the latter case to + ensure that the interaction between the PE and the customer + authentication server is appropriately secured. + +7.2.2. Access Routing Control + + Choice of routing protocols, e.g., RIP, OSPF, or BGP, may be used to + provide control access between a CE and a PE. Per-neighbor and per- + VPN routing policies may be established to enhance security and + reduce the impact of a malicious or non-malicious attack on the PE; + the following mechanisms, in particular, should be considered: + + - Limiting the number of prefixes that may be advertised on a per- + access basis into the PE. Appropriate action may be taken should + a limit be exceeded, e.g., the PE shutting down the peer session + to the CE + + - Applying route dampening at the PE on received routing updates + + - Definition of a per-VPN prefix limit after which additional + prefixes will not be added to the VPN routing table. + + In the case of inter-provider connection, access protection, link + authentication, and routing policies as described above may be + applied. Both inbound and outbound firewall or filtering mechanisms + between ASes may be applied. Proper security procedures must be + implemented in inter-provider interconnection to protect the + providers' network infrastructure and their customers. This may be + custom designed for each inter-provider peering connection, and must + be agreed upon by both providers. + + + + + + + + +Fang Informational [Page 47] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +7.2.3. Access QoS + + MPLS/GMPLS providers offering QoS-enabled services require mechanisms + to ensure that individual accesses are validated against their + subscribed QoS profile and as such gain access to core resources that + match their service profile. Mechanisms such as per-class-of-service + rate limiting or traffic shaping on ingress to the MPLS/GMPLS core + are two options for providing this level of control. Such mechanisms + may require the per-class-of-service profile to be enforced either by + marking, remarking, or discarding of traffic outside of the profile. + +7.2.4. Customer Service Monitoring Tools + + End users needing specific statistics on the core, e.g., routing + table, interface status, or QoS statistics, place requirements on + mechanisms at the PE both to validate the incoming user and limit the + views available to that particular user. Mechanisms should also be + considered to ensure that such access cannot be used as means to + construct a DoS attack (either maliciously or accidentally) on the PE + itself. This could be accomplished either through separation of + these resources within the PE itself or via the capability to rate + limiting, which is performed on the basis of each physical interface + or each logical connection. + +7.3. General User Requirements for MPLS/GMPLS Providers + + MPLS/GMPLS providers must support end users' security requirements. + Depending on the technologies used, these requirements may include: + + - User control plane separation through routing isolation when + applicable, for example, in the case of MPLS VPNs. + + - Protection against intrusion, DoS attacks, and spoofing + + - Access Authentication + + - Techniques highlighted throughout this document that identify + methodologies for the protection of resources and the MPLS/GMPLS + infrastructure. + + Hardware or software errors in equipment leading to breaches in + security are not within the scope of this document. + +8. Inter-Provider Security Requirements + + This section discusses security capabilities that are important at + the MPLS/GMPLS inter-provider connections and at devices (including + ASBR routers) supporting these connections. The security + + + +Fang Informational [Page 48] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + capabilities stated in this section should be considered as + complementary to security considerations addressed in individual + protocol specifications or security frameworks. + + Security vulnerabilities and exposures may be propagated across + multiple networks because of security vulnerabilities arising in one + peer's network. Threats to security originate from accidental, + administrative, and intentional sources. Intentional threats include + events such as spoofing and denial-of-service (DoS) attacks. + + The level and nature of threats, as well as security and availability + requirements, may vary over time and from network to network. This + section, therefore, discusses capabilities that need to be available + in equipment deployed for support of the MPLS InterCarrier + Interconnect (MPLS-ICI). Whether any particular capability is used + in any one specific instance of the ICI is up to the service + providers managing the PE equipment offering or using the ICI + services. + +8.1. Control-Plane Protection + + This section discusses capabilities for control-plane protection, + including protection of routing, signaling, and OAM capabilities. + +8.1.1. Authentication of Signaling Sessions + + Authentication may be needed for signaling sessions (i.e., BGP, LDP, + and RSVP-TE) and routing sessions (e.g., BGP), as well as OAM + sessions across domain boundaries. Equipment must be able to support + the exchange of all protocol messages over IPsec ESP, with NULL + encryption and authentication, between the peering ASBRs. Support + for message authentication for LDP, BGP, and RSVP-TE authentication + must also be provided. Manual keying of IPsec should not be used. + IKEv2 with pre-shared secrets or public key methods should be used. + Replay detection should be used. + + Mechanisms to authenticate and validate a dynamic setup request must + be available. For instance, if dynamic signaling of a TE-LSP or PW + is crossing a domain boundary, there must be a way to detect whether + the LSP source is who it claims to be and that it is allowed to + connect to the destination. + + Message authentication support for all TCP-based protocols within the + scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and + Message authentication with the RSVP-TE Integrity Object must be + provided to interoperate with current practices. Equipment should be + able to support the exchange of all signaling and routing (LDP, RSVP- + TE, and BGP) protocol messages over a single IPsec association pair + + + +Fang Informational [Page 49] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + in tunnel or transport mode with authentication but with NULL + encryption, between the peering ASBRs. IPsec, if supported, must be + supported with HMAC-SHA-1 and alternatively with HMAC-SHA-2 and + optionally SHA-1. It is expected that authentication algorithms will + evolve over time and support can be updated as needed. + + OAM operations 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 OAM messages + could overwhelm the processing capabilities of an ASBR if the ASBR is + not properly protected. Maliciously generated OAM 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 consideration. 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. + +8.1.2. Protection Against DoS Attacks in the Control Plane + + Implementations must have the ability to prevent signaling and + routing DoS attacks on the control plane per interface and provider. + Such prevention may be provided by rate limiting signaling and + routing messages that can be sent by a peer provider according to a + traffic profile and by guarding against malformed packets. + + Equipment must provide the ability to filter signaling, routing, and + OAM packets destined for the device, and must provide the ability to + rate limit such packets. Packet filters should be capable of being + separately applied per interface, and should have minimal or no + performance impact. For example, this allows an operator to filter + or rate limit signaling, routing, and OAM messages that can be sent + by a peer provider and limit such traffic to a given profile. + + During a control-plane DoS attack against an ASBR, the router should + guarantee sufficient resources to allow network operators to execute + network management commands to take corrective action, such as + turning on additional filters or disconnecting an interface under + attack. DoS attacks on the control plane should not adversely affect + data-plane performance. + + Equipment running BGP must support the ability to limit the number of + BGP routes received from any particular peer. Furthermore, in the + case of IPVPN, a router must be able to limit the number of routes + + + + +Fang Informational [Page 50] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + learned from a BGP peer per IPVPN. In the case that a device has + multiple BGP peers, it should be possible for the limit to vary + between peers. + +8.1.3. Protection against Malformed Packets + + Equipment should be robust in the presence of malformed protocol + packets. For example, malformed routing, signaling, and OAM packets + should be treated in accordance with the relevant protocol + specification. + +8.1.4. Ability to Enable/Disable Specific Protocols + + Equipment must have the ability to drop any signaling or routing + protocol messages when these messages are to be processed by the ASBR + but the corresponding protocol is not enabled on that interface. + + Equipment must allow an administrator to enable or disable a protocol + (by default, the protocol is disabled unless administratively + enabled) on an interface basis. + + Equipment must be able to drop any signaling or routing protocol + messages when these messages are to be processed by the ASBR but the + corresponding protocol is not enabled on that interface. This + dropping should not adversely affect data-plane or control-plane + performance. + +8.1.5. Protection against Incorrect Cross Connection + + The capability to detect and locate faults in an LSP cross-connect + must be provided. Such faults may cause security violations as they + result in directing traffic to the wrong destinations. This + capability may rely on OAM functions. Equipment must support MPLS + LSP ping [RFC4379]. This may be used to verify end-to-end + connectivity for the LSP (e.g., PW, TE Tunnel, VPN LSP, etc.), and to + verify PE-to-PE connectivity for IPVPN services. + + When routing information is advertised from one domain to the other, + operators must be able to guard against situations that result in + traffic hijacking, black-holing, resource stealing (e.g., number of + routes), etc. For instance, in the IPVPN case, an operator must be + able to block routes based on associated route target attributes. In + addition, mechanisms to defend against routing protocol attack must + exist to verify whether a route advertised by a peer for a given VPN + is actually a valid route and whether the VPN has a site attached to + or reachable through that domain. + + + + + +Fang Informational [Page 51] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Equipment (ASBRs and Route Reflectors (RRs)) supporting operation of + BGP must be able to restrict which route target attributes are sent + to and accepted from a BGP peer across an ICI. Equipment (ASBRs, + RRs) should also be able to inform the peer regarding which route + target attributes it will accept from a peer, because sending an + incorrect route target can result in an incorrect cross-connection of + VPNs. Also, sending inappropriate route targets to a peer may + disclose confidential information. This is another example of + defense against routing protocol attacks. + +8.1.6. Protection against Spoofed Updates and Route Advertisements + + Equipment must support route filtering of routes received via a BGP + peer session by applying policies that include one or more of the + following: AS path, BGP next hop, standard community, or extended + community. + +8.1.7. Protection of Confidential Information + + The ability to identify and block messages with confidential + information from leaving the trusted domain that can reveal + confidential information about network operation (e.g., performance + OAM messages or LSP ping messages) is required. SPs must have the + flexibility to handle these messages at the ASBR. + + Equipment should be able to identify and restrict where it sends + messages that can reveal confidential information about network + operation (e.g., performance OAM messages, LSP Traceroute messages). + Service Providers must have the flexibility to handle these messages + at the ASBR. For example, equipment supporting LSP Traceroute may + limit to which addresses replies can be sent. Note that this + capability should be used with care. For example, if an SP chooses + to prohibit the exchange of LSP ping messages at the ICI, it may make + it more difficult to debug incorrect cross-connection of LSPs or + other problems. + + An SP may decide to progress these messages if they arrive from a + trusted provider and are targeted to specific, agreed-on addresses. + Another provider may decide to traffic police, reject, or apply other + policies to these messages. Solutions must enable providers to + control the information that is relayed to another provider about the + path that an LSP takes. For example, when using the RSVP-TE record + route object or LSP ping / trace, a provider must be able to control + the information contained in corresponding messages when sent to + another provider. + + + + + + +Fang Informational [Page 52] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +8.1.8. Protection against Over-provisioned Number of RSVP-TE + LSPs and Bandwidth Reservation + + In addition to the control-plane protection mechanisms listed in the + previous section on control-plane protection with RSVP-TE, the ASBR + must be able both to limit the number of LSPs that can be set up by + other domains and to limit the amount of bandwidth that can be + reserved. A provider's ASBR may deny an LSP setup request or a + bandwidth reservation request sent by another provider's whose limits + have been reached. + +8.2. Data-Plane Protection + +8.2.1. Protection against DoS in the Data Plane + + This is described in Section 5 of this document. + +8.2.2. Protection against Label Spoofing + + Equipment must be able to verify that a label received across an + interconnect was actually assigned to an LSP arriving across that + interconnect. If a label not assigned to an LSP arrives at this + router from the correct neighboring provider, the packet must be + dropped. This verification can be applied to the top label only. + The top label is the received top label and every label that is + exposed by label popping is to be used for forwarding decisions. + + Equipment must provide the capability to drop MPLS-labeled packets if + all labels in the stack are not processed. This lets SPs guarantee + that every label that enters its domain from another carrier is + actually assigned to that carrier. + + The following requirements are not directly reflected in this + document but must be used as guidance for addressing further work. + + Solutions must NOT force operators to reveal reachability information + to routers within their domains. Note that it is believed that this + requirement is met via other requirements specified in this section + plus the normal operation of IP routing, which does not reveal + individual hosts. + + Mechanisms to authenticate and validate a dynamic setup request must + be available. For instance, if dynamic signaling of a TE-LSP or PW + is crossing a domain boundary, there must be a way to detect whether + the LSP source is who it claims to be and that it is allowed to + connect to the destination. + + + + + +Fang Informational [Page 53] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +8.2.3. Protection Using Ingress Traffic Policing and Enforcement + + The following simple diagram illustrates a potential security issue + on the data plane across an MPLS interconnect: + + SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1 + | | | | + |< AS2 >|<MPLS interconnect>|< AS1 >| + + Traffic flow direction is from SP2 to SP1 + + In the case of downstream label assignment, the transit label used by + ASBR2 is allocated by ASBR1, which in turn advertises it to ASBR2 + (downstream unsolicited or on-demand); this label is used for a + service context (VPN label, PW VC label, etc.), and this LSP is + normally terminated at a forwarding table belonging to the service + instance on PE (PE1) in SP1. + + In the example above, ASBR1 would not know whether the label of an + incoming packet from ASBR2 over the interconnect is a VPN label or + PSN label for AS1. So it is possible (though unlikely) that ASBR2 + can be accidentally or intentionally configured such that the + incoming label could match a PSN label (e.g., LDP) in AS1. Then, + this LSP would end up on the global plane of an infrastructure router + (P or PE1), and this could invite a unidirectional attack on that P + or PE1 where the LSP terminates. + + To mitigate this threat, implementations should be able to do a + forwarding path look-up for the label on an incoming packet from an + interconnect in a Label Forwarding Information Base (LFIB) space that + is only intended for its own service context or provide a mechanism + on the data plane that would ensure the incoming labels are what + ASBR1 has allocated and advertised. + + A similar concept has been proposed in "Requirements for Multi- + Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [RFC5254]. + + When using upstream label assignment, the upstream source must be + identified and authenticated so the labels can be accepted as from a + trusted source. + +9. Summary of MPLS and GMPLS Security + + The following summary provides a quick checklist of MPLS and GMPLS + security threats, defense techniques, and the best-practice outlines + for MPLS and GMPLS deployment. + + + + + +Fang Informational [Page 54] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +9.1. MPLS and GMPLS Specific Security Threats + +9.1.1. Control-Plane Attacks + + Types of attacks on the control plane: + + - Unauthorized LSP creation + + - LSP message interception + + Attacks against RSVP-TE: DoS attacks that set up unauthorized LSP + and/or LSP messages. + + Attacks against LDP: DoS attack with storms of LDP Hello messages or + LDP TCP SYN messages. + + Attacks may be launched from external or internal sources, or through + an SP's management systems. + + Attacks may be targeted at the SP's routing protocols or + infrastructure elements. + + In general, control protocols may be attacked by: + + - MPLS signaling (LDP, RSVP-TE) + + - PCE signaling + + - IPsec signaling (IKE and IKEv2) + + - ICMP and ICMPv6 + + - L2TP + + - BGP-based membership discovery + + - Database-based membership discovery (e.g., RADIUS) + + - OAM and diagnostic protocols such as LSP ping and LMP + + - Other protocols that may be important to the control + infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE + + + + + + + + + +Fang Informational [Page 55] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +9.1.2. Data-Plane Attacks + + - Unauthorized observation of data traffic + + - Data-traffic modification + + - Spoofing and replay + + - Unauthorized deletion + + - Unauthorized traffic-pattern analysis + + - Denial of Service + +9.2. Defense Techniques + + 1) Authentication: + + - Bidirectional authentication + + - Key management + + - Management system authentication + + - Peer-to-peer authentication + + 2) Cryptographic techniques + + 3) Use of IPsec in MPLS/GMPLS networks + + 4) Encryption for device configuration and management + + 5) Cryptographic techniques for MPLS pseudowires + + 6) End-to-End versus Hop-by-Hop protection (CE-CE, PE-PE, PE-CE) + + 7) Access control techniques + + - Filtering + + - Firewalls + + - Access Control to management interfaces + + 8) Infrastructure isolation + + 9) Use of aggregated infrastructure + + + + +Fang Informational [Page 56] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + 10) Quality control processes + + 11) Testable MPLS/GMPLS service + + 12) End-to-end connectivity verification + + 13) Hop-by-hop resource configuration verification and discovery + +9.3. Service Provider MPLS and GMPLS Best-Practice Outlines + +9.3.1. SP Infrastructure Protection + + 1) General control-plane protection + + - Filtering out infrastructure source addresses at edges + + - Protocol authentication within the core + + - Infrastructure hiding (e.g., disable TTL propagation) + + 2) RSVP control-plane protection + + - RSVP security tools + + - Isolation of the trusted domain + + - Deactivating RSVP on interfaces with neighbors who are not + authorized to use RSVP + + - RSVP neighbor filtering at the protocol level and data-plane + level + + - Authentication for RSVP messages + + - RSVP message pacing + + 3) LDP control-plane protection (similar techniques as for RSVP) + + 4) Data-plane protection + + - User access link protection + + - Link authentication + + - Access routing control (e.g., prefix limits, route dampening, + routing table limits (such as VRF limits) + + - Access QoS control + + + +Fang Informational [Page 57] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + - Customer service monitoring tools + + - Use of LSP ping (with its own control-plane security) to verify + end-to-end connectivity of MPLS LSPs + + - LMP (with its own security) to verify hop-by-hop connectivity. + +9.3.2. Inter-Provider Security + + Inter-provider connections are high security risk areas. Similar + techniques and procedures as described for SP's general core + protection are listed below for inter-provider connections. + + 1) Control-plane protection at inter-provider connections + + - Authentication of signaling sessions + + - Protection against DoS attacks in the control plane + + - Protection against malformed packets + + - Ability to enable/disable specific protocols + + - Protection against incorrect cross connection + + - Protection against spoofed updates and route advertisements + + - Protection of confidential information + + - Protection against an over-provisioned number of RSVP-TE LSPs + and bandwidth reservation + + 2) Data-plane protection at the inter-provider connections + + - Protection against DoS in the data plane + + - Protection against label spoofing + + For MPLS VPN interconnections [RFC4364], in practice, inter-AS option + a), VRF-to-VRF connections at the AS (Autonomous System) border, is + commonly used for inter-provider connections. Option c), Multi-hop + EBGP redistribution of labeled VPN-IPv4 routes between source and + destination ASes with EBGP redistribution of labeled IPv4 routes from + AS to a neighboring AS, on the other hand, is not normally used for + inter-provider connections due to higher security risks. For more + details, please see [RFC4111]. + + + + + +Fang Informational [Page 58] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + +10. Security Considerations + + Security considerations constitute the sole subject of this memo and + hence are discussed throughout. Here we recap what has been + presented and explain at a high level the role of each type of + consideration in an overall secure MPLS/GMPLS system. + + The document describes a number of potential security threats. Some + of these threats have already been observed occurring in running + networks; others are largely hypothetical at this time. + + DoS attacks and intrusion attacks from the Internet against an SPs' + infrastructure have been seen. DoS "attacks" (typically not + malicious) have also been seen in which CE equipment overwhelms PE + equipment with high quantities or rates of packet traffic or routing + information. Operational or provisioning errors are cited by SPs as + one of their prime concerns. + + The document describes a variety of defensive techniques that may be + used to counter the suspected threats. All of the techniques + presented involve mature and widely implemented technologies that are + practical to implement. + + The document describes the importance of detecting, monitoring, and + reporting attacks, both successful and unsuccessful. These + activities are essential for "understanding one's enemy", mobilizing + new defenses, and obtaining metrics about how secure the MPLS/GMPLS + network is. As such, they are vital components of any complete PPVPN + security system. + + The document evaluates MPLS/GMPLS security requirements from a + customer's perspective as well as from a service provider's + perspective. These sections re-evaluate the identified threats from + the perspectives of the various stakeholders and are meant to assist + equipment vendors and service providers, who must ultimately decide + what threats to protect against in any given configuration or service + offering. + +11. References + +11.1. Normative References + + [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP + Cryptographic Authentication", RFC 2747, January + 2000. + + + + + + +Fang Informational [Page 59] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", RFC + 3031, January 2001. + + [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic + Authentication -- Updated Message Type Value", RFC + 3097, April 2001. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., + Srinivasan, V., and G. Swallow, "RSVP-TE: + Extensions to RSVP for LSP Tunnels", RFC 3209, + December 2001. + + [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3945, October + 2004. + + [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter + Mode (GCM) in IPsec Encapsulating Security Payload + (ESP)", RFC 4106, June 2005. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) + Protocol", RFC 4306, December 2005. + + [RFC4309] Housley, R., "Using Advanced Encryption Standard + (AES) CCM Mode with IPsec Encapsulating Security + Payload (ESP)", RFC 4309, December 2005. + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual + Private Networks (VPNs)", RFC 4364, February 2006. + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi- + Protocol Label Switched (MPLS) Data Plane + Failures", RFC 4379, February 2006. + + [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, + T., and G. Heron, "Pseudowire Setup and Maintenance + Using the Label Distribution Protocol (LDP)", RFC + 4447, April 2006. + + + + + + +Fang Informational [Page 60] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + [RFC4835] Manral, V., "Cryptographic Algorithm Implementation + Requirements for Encapsulating Security Payload + (ESP) and Authentication Header (AH)", RFC 4835, + April 2007. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, + Ed., "LDP Specification", RFC 5036, October 2007. + + [STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network + Management Protocol (SNMP) Management Frameworks", + STD 62, RFC 3411, December 2002. + + Case, J., Harrington, D., Presuhn, R., and B. + Wijnen, "Message Processing and Dispatching for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3412, December 2002. + + Levi, D., Meyer, P., and B. Stewart, "Simple + Network Management Protocol (SNMP) Applications", + STD 62, RFC 3413, December 2002. + + Blumenthal, U. and B. Wijnen, "User-based Security + Model (USM) for version 3 of the Simple Network + Management Protocol (SNMPv3)", STD 62, RFC 3414, + December 2002. + + Wijnen, B., Presuhn, R., and K. McCloghrie, "View- + based Access Control Model (VACM) for the Simple + Network Management Protocol (SNMP)", STD 62, RFC + 3415, December 2002. + + Presuhn, R., Ed., "Version 2 of the Protocol + Operations for the Simple Network Management + Protocol (SNMP)", STD 62, RFC 3416, December 2002. + + Presuhn, R., Ed., "Transport Mappings for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3417, December 2002. + + Presuhn, R., Ed., "Management Information Base + (MIB) for the Simple Network Management Protocol + (SNMP)", STD 62, RFC 3418, December 2002. + + + + +Fang Informational [Page 61] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + [STD8] Postel, J. and J. Reynolds, "Telnet Protocol + Specification", STD 8, RFC 854, May 1983. + + Postel, J. and J. Reynolds, "Telnet Option + Specifications", STD 8, RFC 855, May 1983. + +11.2. Informative References + + [OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces + to Network Elements", Optical Internetworking + Forum, Sept. 2003. + + [OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for + Management Interfaces to Network Elements", Optical + Internetworking Forum, March 2006. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC + 2104, February 1997. + + [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP + Security Document Roadmap", RFC 2411, November + 1998. + + [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash + Algorithm 1 (SHA1)", RFC 3174, September 2001. + + [RFC3562] Leech, M., "Key Management Considerations for the + TCP MD5 Signature Option", RFC 3562, July 2003. + + [RFC3631] Bellovin, S., Ed., Schiller, J., Ed., and C. + Kaufman, Ed., "Security Mechanisms for the + Internet", RFC 3631, December 2003. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for + Multihomed Networks", BCP 84, RFC 3704, March 2004. + + [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire + Emulation Edge-to-Edge (PWE3) Architecture", RFC + 3985, March 2005. + + [RFC4107] Bellovin, S. and R. Housley, "Guidelines for + Cryptographic Key Management", BCP 107, RFC 4107, + June 2005. + + [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 + Provider-Provisioned Virtual Private Networks + (PPVPNs)", RFC 4110, July 2005. + + + +Fang Informational [Page 62] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + [RFC4111] Fang, L., Ed., "Security Framework for Provider- + Provisioned Virtual Private Networks (PPVPNs)", RFC + 4111, July 2005. + + [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security + Properties", RFC 4230, December 2005. + + [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC + 4308, December 2005. + + [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and + S. Matsushima, "Operations and Management (OAM) + Requirements for Multi-Protocol Label Switched + (MPLS) Networks", RFC 4377, February 2006. + + [RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework + for Multi-Protocol Label Switching (MPLS) + Operations and Management (OAM)", RFC 4378, + February 2006. + + [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic + Threats to Routing Protocols", RFC 4593, October + 2006. + + [RFC4778] Kaeo, M., "Operational Security Current Practices + in Internet Service Provider Environments", RFC + 4778, January 2007. + + [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", + RFC 4808, March 2007. + + [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, + B., and E. Klein, "Local Network Protection for + IPv6", RFC 4864, May 2007. + + [RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic + Suites for IPsec", RFC 4869, May 2007. + + [RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, + Ed., "Requirements for Multi-Segment Pseudowire + Emulation Edge-to-Edge (PWE3)", RFC 5254, October + 2008. + + [MFA-MPLS-ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical + Specification," IP/MPLS Forum 19.0.0, April 2008. + + + + + + +Fang Informational [Page 63] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + [OIF-Sec-Mag] R. Esposito, R. Graveman, and B. Hazzard, "Security + for Management Interfaces to Network Elements," + OIF-SMI-01.0, September 2003. + + [BACKBONE-ATTKS] Savola, P., "Backbone Infrastructure Attacks and + Protections", Work in Progress, January 2007. + + [OPSEC-FILTER] Morrow, C., Jones, G., and V. Manral, "Filtering + and Rate Limiting Capabilities for IP Network + Infrastructure", Work in Progress, July 2007. + + [IPSECME-ROADMAP] Frankel, S. and S. Krishnan, "IP Security (IPsec) + and Internet Key Exchange (IKE) Document Roadmap", + Work in Progress, May 2010. + + [OPSEC-EFFORTS] Lonvick, C. and D. Spak, "Security Best Practices + Efforts and Documents", Work in Progress, May 2010. + + [RSVP-key] Behringer, M. and F. Le Faucheur, "Applicability of + Keying Methods for RSVP Security", Work in + Progress, June 2009. + +12. Acknowledgements + + The authors and contributors would also like to acknowledge the + helpful comments and suggestions from Sam Hartman, Dimitri + Papadimitriou, Kannan Varadhan, Stephen Farrell, Mircea Pisica, Scott + Brim in particular for his comments and discussion through GEN-ART + review,as well as Suresh Krishnan for his GEN-ART review and + comments. The authors would like to thank Sandra Murphy and Tim Polk + for their comments and help through Security AD review, thank Pekka + Savola for his comments through ops-dir review, and Amanda Baber for + her IANA review. + + This document has used relevant content from RFC 4111 "Security + Framework of Provider Provisioned VPN for Provider-Provisioned + Virtual Private Networks (PPVPNs)" [RFC4111]. We acknowledge the + authors of RFC 4111 for the valuable information and text. + + Authors: + + Luyuan Fang, Ed., Cisco Systems, Inc. + Michael Behringer, Cisco Systems, Inc. + Ross Callon, Juniper Networks + Richard Graveman, RFG Security, LLC + J. L. Le Roux, France Telecom + Raymond Zhang, British Telecom + Paul Knight, Individual Contributor + + + +Fang Informational [Page 64] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Yaakov Stein, RAD Data Communications + Nabil Bitar, Verizon + Monique Morrow, Cisco Systems, Inc. + Adrian Farrel, Old Dog Consulting + + As a design team member for the MPLS Security Framework, Jerry Ash + also made significant contributions to this document. + +13. Contributors' Contact Information + + Michael Behringer + Cisco Systems, Inc. + Village d'Entreprises Green Side + 400, Avenue Roumanille, Batiment T 3 + 06410 Biot, Sophia Antipolis + FRANCE + EMail: mbehring@cisco.com + + Ross Callon + Juniper Networks + 10 Technology Park Drive + Westford, MA 01886 + USA + EMail: rcallon@juniper.net + + Richard Graveman + RFG Security + 15 Park Avenue + Morristown, NJ 07960 + EMail: rfg@acm.org + + Jean-Louis Le Roux + France Telecom + 2, avenue Pierre-Marzin + 22307 Lannion Cedex + FRANCE + EMail: jeanlouis.leroux@francetelecom.com + + Raymond Zhang + British Telecom + BT Center + 81 Newgate Street + London, EC1A 7AJ + United Kingdom + EMail: raymond.zhang@bt.com + + + + + + +Fang Informational [Page 65] + +RFC 5920 MPLS/GMPLS Security Framework July 2010 + + + Paul Knight + 39 N. Hancock St. + Lexington, MA 02420 + EMail: paul.the.knight@gmail.com + + Yaakov (Jonathan) Stein + RAD Data Communications + 24 Raoul Wallenberg St., Bldg C + Tel Aviv 69719 + ISRAEL + EMail: yaakov_s@rad.com + + Nabil Bitar + Verizon + 40 Sylvan Road + Waltham, MA 02145 + EMail: nabil.bitar@verizon.com + + Monique Morrow + Glatt-com + CH-8301 Glattzentrum + Switzerland + EMail: mmorrow@cisco.com + + Adrian Farrel + Old Dog Consulting + EMail: adrian@olddog.co.uk + +Editor's Address + + Luyuan Fang (editor) + Cisco Systems, Inc. + 300 Beaver Brook Road + Boxborough, MA 01719 + USA + EMail: lufang@cisco.com + + + + + + + + + + + + + + + +Fang Informational [Page 66] + |