--- 1/draft-ietf-mpls-mpls-and-gmpls-security-framework-06.txt 2009-10-25 23:12:21.000000000 +0100 +++ 2/draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt 2009-10-25 23:12:21.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group Luyuan Fang, Ed. Internet Draft Cisco Systems, Inc. Category: Informational - Expires: January 13, 2010 + Expires: April 25, 2010 - July 13, 2009 + October 25, 2009 Security Framework for MPLS and GMPLS Networks - draft-ietf-mpls-mpls-and-gmpls-security-framework-06.txt + draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -41,20 +41,22 @@ Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 MPLS/GMPLS Security framework + October 2009 + 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. Abstract @@ -65,57 +67,60 @@ 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. Table of Contents 1. Introduction..................................................3 - Authors and Contributors.........................................4 + Authors and Contributors..........................................4 2. Terminology...................................................5 2.1. Acronyms and Abbreviations.................................5 2.2. Terminology................................................6 3. Security Reference Models.....................................8 4. Security Threats.............................................10 4.1. Attacks on the Control Plane..............................11 - 4.2. Attacks on the Data Plane.................................14 + 4.2. Attacks on the Data Plane.................................15 4.3. Attacks on Operation and Management Plane.................17 - 5. Defensive Techniques for MPLS/GMPLS Networks.................18 - 5.1. Authentication............................................19 + 4.4. Insider Attacks Considerations............................18 + 5. Defensive Techniques for MPLS/GMPLS Networks.................19 + 5.1. Authentication............................................20 5.2. Cryptographic Techniques..................................21 5.3. Access Control Techniques.................................31 - 5.4. Use of Isolated Infrastructure............................35 + 5.4. Use of Isolated Infrastructure............................36 5.5. Use of Aggregated Infrastructure..........................36 - 5.6. Service Provider Quality Control Processes................36 + 5.6. Service Provider Quality Control Processes................37 5.7. Deployment of Testable MPLS/GMPLS Service.................37 5.8. Verification of Connectivity..............................37 - 6. Monitoring, Detection, and Reporting of Security Attacks.....37 MPLS/GMPLS Security framework - 7. Service Provider General Security Requirements...............38 + October 2009 + + 6. Monitoring, Detection, and Reporting of Security Attacks.....38 + 7. Service Provider General Security Requirements...............39 7.1. Protection within the Core Network........................39 7.2. Protection on the User Access Link........................43 - 7.3. General User Requirements for MPLS/GMPLS Providers........44 + 7.3. General User Requirements for MPLS/GMPLS Providers........45 8. Inter-provider Security Requirements.........................45 - 8.1. Control Plane Protection..................................45 - 8.2. Data Plane Protection.....................................49 + 8.1. Control Plane Protection..................................46 + 8.2. Data Plane Protection.....................................50 9. Summary of MPLS and GMPLS Security...........................51 9.1. MPLS and GMPLS Specific Security Threats..................51 9.2. Defense Techniques........................................52 9.3. Service Provider MPLS and GMPLS Best Practice Outlines....53 - 10. Security Considerations....................................54 - 11. IANA Considerations........................................55 - 12. Normative References.......................................55 - 13. Informative References.....................................56 - 14. Author's Addresses.........................................58 - 15. Acknowledgements...........................................60 + 10. Security Considerations.....................................54 + 11. IANA Considerations.........................................55 + 12. Normative References........................................55 + 13. Informative References......................................56 + 14. Author's Addresses..........................................58 + 15. Acknowledgements............................................60 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 @@ -126,23 +131,25 @@ 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. + MPLS/GMPLS Security framework + October 2009 + We then discuss possible service provider security requirements in a MPLS or GMPLS environment. Users have expectations for the - MPLS/GMPLS Security framework 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 @@ -151,46 +158,49 @@ 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 inter-connection 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. Readers may refer to the - "Security Best Practices Efforts and Documents" [opsec effort] 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. + pertain to MPLS and GMPLS networks, not including the connected + user sites. Readers may refer to the "Security Best Practices + Efforts and Documents" [opsec effort] 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. 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 and Contributors 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 + MPLS/GMPLS Security framework + October 2009 + Paul Knight, Individual Contributor Yaakov Stein, RAD Data Communications Nabil Bitar, Verizon - MPLS/GMPLS Security framework 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. 2. Terminology 2.1. Acronyms and Abbreviations @@ -221,25 +231,27 @@ 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 Multi-Protocol BGP NTP Network Time Protocol OAM Operations, Administration, and Management PCE Path Computation Element + + MPLS/GMPLS Security framework + October 2009 + PE Provider-Edge device PPVPN Provider-Provisioned Virtual Private Network PSN Packet-Switched Network - - MPLS/GMPLS Security framework 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 @@ -271,24 +283,25 @@ 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). + MPLS/GMPLS Security framework + October 2009 + Label: A short, fixed length, physically contiguous identifier, usually of local significance. - - MPLS/GMPLS Security framework 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 a packets in a particular FEC. Label Switching Routers (LSRs): An MPLS/GMPLS node assumed to have @@ -321,36 +334,41 @@ as it leaves a 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. A MPLS node is aware of MPLS control protocols, runs one or more routing protocols, and is + MPLS/GMPLS Security framework + October 2009 + capable of forwarding packets based on labels. A MPLS node may optionally be also capable of forwarding native IP packets. - MPLS/GMPLS Security framework MultiProtocol Label Switching (MPLS): An IETF working group and the effort associated with the working group. 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. 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 @@ -364,71 +382,82 @@ | user | MPLS/GMPLS Core | user | | site +---\ /XXX-----+ site | +------------+ \ / XXX +------------+ \-------------/ | | | | | +------\ +--------/ "Internet" MPLS/GMPLS Core with user connections and Internet connection + MPLS/GMPLS Security framework + October 2009 + 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. - MPLS/GMPLS Security framework 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, 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). + 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. Even though a neighbor may be - authorized for communication, it may not be trusted. For example, - when connecting with another provider's ASBRs to set up inter-AS - LSPs, the other provider is considered an untrusted but authorized - neighbor. + be authorized or unauthorized. Authorized neighbor is the neighbor + one established peering relationship with. Even though a neighbor + may be authorized for communication, it may not be trusted. For + example, when connecting with another provider's ASBRs to set up + inter-AS LSPs, the other provider is considered an untrusted but + authorized neighbor. +---------------+ +----------------+ | | | | | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS | CE1--PE1 Network | | Network PE2--CE2 | Provider A ASBR2----ASBR4 Provider B | | | | | +---------------+ +----------------+ + InterCarrier + Interconnect (ICI) For Provider A: - Trusted Zone: Provider A MPSL/GMPLS network - Trusted neighbors: PE1, ASBR1, ASBR2 + Trusted Zone: Provider A MPLS/GMPLS network + + MPLS/GMPLS Security framework + October 2009 + 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 a 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 Security framework 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. The discussion is limited to those threats that are unique to MPLS/GMPLS networks or that affect MPLS/GMPLS network in unique ways. RFC 4778 [RFC4778] provided the best current operational security practices in Internet Service @@ -453,31 +482,33 @@ 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 a MPLS/GMPLS SP's site. - Other persons who use social engineering methods to influence the behavior of a SP's personnel. + + MPLS/GMPLS Security framework + October 2009 + - 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. - MPLS/GMPLS Security framework - 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: - A MPLS/GMPLS core inter-connecting with another provider's core - A MPLS/GMPLS configuration transiting the public Internet Most types of attacks become easier to mount and hence more likely @@ -502,30 +533,35 @@ 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 + MPLS/GMPLS Security framework + October 2009 + 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 outsider attach. 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 - MPLS/GMPLS Security framework 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 @@ -546,34 +582,35 @@ 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 + MPLS/GMPLS Security framework + October 2009 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 a LDP session by sending LDP Hello and LDP Init messages, leading to the potential setup of a 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. - MPLS/GMPLS Security framework 4.1.5. Denial of Service Attacks on the Network Infrastructure DoS attacks could be accomplished through a 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 @@ -586,62 +623,55 @@ 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 a SP's infrastructure equipment, for example to reconfigure the equipment or to extract information (statistics, topology, etc.) pertaining to the network. - 4.1.7. Social Engineering Attacks on the SP's - Infrastructure - - Attacks in which the service provider's network is reconfigured or - damaged, or in which confidential information is improperly - disclosed, may be mounted by manipulation of a SP's personnel. - These types of attacks are MPLS/GMPLS-specific if they affect - MPLS/GMPLS-serving mechanisms. - - 4.1.8. Cross-Connection of Traffic between Users + 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 + + MPLS/GMPLS Security framework + October 2009 + - 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 - MPLS/GMPLS Security framework - Mis-connection 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 mis- connected) 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.9. Attacks against Routing Protocols + 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 described in [RFC4593]. - 4.1.10. Other Attacks on Control Traffic + 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) @@ -653,25 +683,27 @@ 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. + MPLS/GMPLS Security framework + October 2009 + 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 - MPLS/GMPLS Security framework 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 @@ -700,26 +732,28 @@ 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. + MPLS/GMPLS Security framework + October 2009 + 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 - MPLS/GMPLS Security framework 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 @@ -750,41 +784,43 @@ 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. + MPLS/GMPLS Security framework + October 2009 + In optical networks under GMPLS control, misconnection may give rise to physical safety risks as unprotected lasers may be activated without warning. - MPLS/GMPLS Security framework 4.3. Attacks on Operation and Management Plane Attacks on OAM 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 OAM Requirements for MPLS networks. See also the Security Considerations of RFC 4377 and Section 7 of RFC 4378 [RFC4378]. 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 - Pseudo Wire), and therefore affect service security. MPLS-ping does + Pseudo Wire), and therefore affect service security. LSP ping does not support authentication today, and that support should be 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 OAM consideration in optical interworking, there is a good discussion on security for management interfaces to Network @@ -796,27 +832,29 @@ Remote access to a network element through these OAM interfaces is frequently a requirement. Securing the control protocols while leaving these OAM 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 + MPLS/GMPLS Security framework + October 2009 + 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 no longer. Networks using the TCP/IP protocol suite are vulnerable to forged source addresses, recording - MPLS/GMPLS Security framework 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 @@ -826,21 +864,46 @@ 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 OAM 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 penetrations that compromise a system inside the firewall as a launching pad to attack - network elements. + 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 preventing + general (e.g. FTP) access to LSRs. Further protection can be + achieved by strict control of user (i.e. operator) access to LSRs. + + MPLS/GMPLS Security framework + October 2009 + + Lastly, software tools may 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 @@ -850,38 +913,41 @@ 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." - MPLS/GMPLS Security framework + 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. + MPLS/GMPLS Security framework + October 2009 + 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 @@ -895,37 +961,39 @@ cryptographic processing, 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 of software cycles. Cryptographic techniques may, however, be useful against resource exhaustion attacks based on 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 - MPLS/GMPLS Security framework 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. + MPLS/GMPLS Security framework + October 2009 + Authentication should be bi-directional, including PE or CE to configuration server authentication for 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). @@ -940,39 +1008,41 @@ 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 key systems. Another approach is to use a hierarchical Certification Authority system to provide digital certificates. - MPLS/GMPLS Security framework 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 a 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. + MPLS/GMPLS Security framework + October 2009 + 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 @@ -986,41 +1056,44 @@ 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. - MPLS/GMPLS Security framework 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. + + MPLS/GMPLS Security framework + October 2009 + - 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. @@ -1035,40 +1108,42 @@ 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 - MPLS/GMPLS Security framework level agreement (SLA) for CE-CE encryption that provides an acceptable demarcation of 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] 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 + MPLS/GMPLS Security framework + October 2009 + client layer, while 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- @@ -1083,41 +1158,43 @@ 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. - MPLS/GMPLS Security framework 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, 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 + MPLS/GMPLS Security framework + October 2009 + 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]. @@ -1131,41 +1208,44 @@ 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 - MPLS/GMPLS Security framework cryptographic methods, but any of the default suites specified in [RFC4308] or [RFC4869] provides more than adequate security. 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 [STD-8] 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. + + MPLS/GMPLS Security framework + October 2009 + - 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 @@ -1177,38 +1257,39 @@ 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]. - MPLS/GMPLS Security framework 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 PW client traffic may be secured by use of mechanisms beyond the scope of this document. Security at the MPLS layer itself is for further study. 5.2.5. End-to-End versus Hop-by-Hop Protection Tradeoffs in MPLS/GMPLS + MPLS/GMPLS Security framework + October 2009 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 a 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 @@ -1223,40 +1304,42 @@ 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. - MPLS/GMPLS Security framework 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. + MPLS/GMPLS Security framework + October 2009 + 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? @@ -1268,22 +1351,20 @@ - 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? - 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. - MPLS/GMPLS Security framework - - 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. @@ -1294,20 +1375,23 @@ 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 two CEs, each packet is cryptographically processed (2P), though the protection may be "integrity check only" or "integrity check plus encryption." + MPLS/GMPLS Security framework + October 2009 + 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. @@ -1317,22 +1401,20 @@ (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. Processing load - on each of two PEs, each packet is cryptographically processed (2P). - MPLS/GMPLS Security framework - 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 @@ -1343,20 +1425,24 @@ packet is cryptographically processed (4P) Enhanced services - full; SP can apply any enhancements based on 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). + + MPLS/GMPLS Security framework + October 2009 + 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 two CEs, each packet is cryptographically processed, plus on each of two PEs, each packet is cryptographically processed twice (6P) Enhanced services - full; SP can apply any enhancements based on detailed view of traffic @@ -1368,22 +1454,20 @@ 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. - MPLS/GMPLS Security framework - - 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. @@ -1393,20 +1477,23 @@ - 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 + MPLS/GMPLS Security framework + October 2009 + 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. In addition to the simplified models, the following should also be considered: @@ -1418,21 +1505,20 @@ email attachments: four layers.) - It may be appropriate that, for example, cryptographic integrity checks are applied end to end, and confidentiality 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. - MPLS/GMPLS Security framework 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 @@ -1441,20 +1527,24 @@ 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. + + MPLS/GMPLS Security framework + October 2009 + - 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 bi-directional conversation as precisely as a firewall. 5.3.1. Filtering @@ -1465,21 +1555,21 @@ discarded or given special treatment. Today, not only routers, 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 - MPLS/GMPLS Security framework + 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 @@ -1489,20 +1579,23 @@ 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. 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 + MPLS/GMPLS Security framework + October 2009 + then be considered to match the same filter. Stateful filtering is more commonly done in firewalls, although firewall technology may be added to routers. Data unit ID can also be 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 which may be taken based on that match. Examples of such actions include: @@ -1513,22 +1606,20 @@ 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 - MPLS/GMPLS Security framework - 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 @@ -1538,20 +1629,22 @@ - 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 + MPLS/GMPLS Security framework + October 2009 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 @@ -1563,21 +1656,20 @@ 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 - MPLS/GMPLS Security framework 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 @@ -1589,20 +1681,23 @@ 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. + MPLS/GMPLS Security framework + October 2009 + 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 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. @@ -1610,21 +1705,21 @@ Handling DoS attacks has become increasingly important. Useful guidelines include the following: 1. Perform ingress filtering everywhere. Upstream detection and prevention are better. 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 - MPLS/GMPLS Security framework + 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. 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 OIF-SMI-01.0 "Security for Management Interfaces to Network Elements" [OIF-SMI-01.0], and "Addendum to the Security for @@ -1637,20 +1732,23 @@ 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. + MPLS/GMPLS Security framework + October 2009 + 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 IP VPNs may be run on a separate backbone not @@ -1658,21 +1756,20 @@ 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 - MPLS/GMPLS Security framework 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 @@ -1683,20 +1780,23 @@ if certain services use a separate network from Internet services, 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 + MPLS/GMPLS Security framework + October 2009 + per service and per user basis. Possibilities include, for example, using virtual router or logical router to define hardware or software resource limits per service or per individual user; using rate limiting per VPN 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, @@ -1706,21 +1806,20 @@ 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, - MPLS/GMPLS Security framework 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 it occurs. @@ -1732,20 +1831,23 @@ pretty 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. + MPLS/GMPLS Security framework + October 2009 + 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 to 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 @@ -1755,21 +1857,20 @@ 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. - MPLS/GMPLS Security framework 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 @@ -1780,20 +1881,22 @@ receive reports from devices (e.g., SNMP notifications). The Security monitoring systems may actively retrieve information from devices (e.g., SNMP get) or passively receive reports from devices (e.g., SNMP notifications). 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. Syslog WG is specifying "Logging Capabilities for IP Network Infrastructure". (The specific references will be made only if the draft(s) became RFC before this draft.) + MPLS/GMPLS Security framework + October 2009 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 @@ -1805,21 +1908,20 @@ 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. 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. - MPLS/GMPLS Security framework 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, a MPLS/GMPLS service provider may fulfill any number of the security requirements listed in this section. This document does not state that a MPLS/GMPLS network must fulfill all of these requirements to be secure. @@ -1830,20 +1932,23 @@ 7.1. Protection within the Core Network 7.1.1. Control Plane Protection - General - Protocol authentication within the core: The network infrastructure must support mechanisms for authentication of the control plane messages. If a MPLS/GMPLS core is used, LDP sessions may be authenticated with TCP MD5. In + MPLS/GMPLS Security framework + October 2009 + 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), confidentiality. Protocols need to provide a complete set of security services from which the SP can choose. Also, the important but often harder part is key management. Considerations, guidelines, and strategies regarding key management are discussed in [RFC3562], [RFC4107], [RFC4808]. @@ -1851,21 +1956,20 @@ 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. - MPLS/GMPLS Security framework A MPLS/GMPLS provider may make its infrastructure routers (P and PE routers) 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. @@ -1878,20 +1982,23 @@ Separating control plane, data plane, and management plane functionality in hardware and software may be implemented on the PE 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 + MPLS/GMPLS Security framework + October 2009 + 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. @@ -1900,21 +2007,20 @@ - 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 IPv4 Router Alert or IPv6 using Next Header 0 packets. A solution could consists of disabling the processing of IP options. This drops or ignores all IP packets - MPLS/GMPLS Security framework 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 @@ -1928,20 +2034,23 @@ 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. 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. + MPLS/GMPLS Security framework + October 2009 + 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 @@ -1949,21 +2058,20 @@ 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 blocking 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 - MPLS/GMPLS Security framework 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 @@ -1977,40 +2085,42 @@ 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 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]. + MPLS/GMPLS Security framework + October 2009 + 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. 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 - MPLS/GMPLS Security framework can be used to secure the MPLS data plane traffic carried over a 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- @@ -2022,20 +2132,23 @@ (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. 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, + MPLS/GMPLS Security framework + October 2009 + 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 @@ -2044,22 +2157,20 @@ 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: - - MPLS/GMPLS Security framework - 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. @@ -2072,40 +2183,43 @@ custom designed for each Inter-Provider peering connection, and must be agreed upon by both providers. 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 Security framework + October 2009 + 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, or 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 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-limit such traffic on a per physical or logical connection basis. 7.3. General User Requirements for MPLS/GMPLS Providers - MPLS/GMPLS Security framework + 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. @@ -2118,39 +2232,41 @@ 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 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, + MPLS/GMPLS Security framework + October 2009 + 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. - MPLS/GMPLS Security framework 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 @@ -2168,36 +2284,38 @@ provided to interoperate with current practices. Equipment should be able to support exchange of all signaling and routing (LDP, RSVP-TE, and BGP) protocol messages over a single IPsec security association pair 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. + MPLS/GMPLS Security framework + October 2009 + 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 - Pseudo Wire), and therefore affect service security. MPLS-ping does + Pseudo Wire), and therefore affect service security. LSP ping does not support authentication today, and that support should be 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. - MPLS/GMPLS Security framework 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. @@ -2217,35 +2335,37 @@ 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 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. + MPLS/GMPLS Security framework + October 2009 + 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. - MPLS/GMPLS Security framework 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. @@ -2257,90 +2377,96 @@ 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 IP VPN 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 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. + target attributes. In addition, mechanisms to 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. 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 + MPLS/GMPLS Security framework + October 2009 + (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 incorrect cross-connection of VPNs. Also, sending inappropriate route targets to a peer may - disclose confidential information. + disclose confidential information. This is another example of + defense against routing protocol attack. 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. - MPLS/GMPLS Security framework 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 MPLS-ping messages) is required. SPs must have the + OAM messages or LSP ping messages) is required. SPs must have the flexibility of handling 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 of handling these messages at the ASBR. For example, equipment supporting LSP Traceroute may limit to which addresses replies can be sent. Note: This capability should be used with care. For example, if a 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. A 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 a LSP takes. For example, when using the RSVP- - TE record route object or MPLS-ping trace, a provider must be able + 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. 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 + MPLS/GMPLS Security framework + October 2009 + 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 a LSP set up request or a bandwidth reservation request sent by another provider's whose the 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 - MPLS/GMPLS Security framework + Equipment must be able to verify that a label received across an interconnect was actually assigned to a LSP arriving across that interconnect. If a label not assigned to a 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 to be used for forwarding decisions. Equipment must provide the capability of dropping MPLS-labeled packets if all labels in the stack are not processed. This lets @@ -2361,34 +2487,36 @@ 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. 8.2.3. Protection Using Ingress Traffic Policing and Enforcement The following simple diagram illustrates a potential security issue on the data plane across a MPLS interconnect: + MPLS/GMPLS Security framework + October 2009 + SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1 | | | | |< AS2 >||< AS1 >| Traffic flow direction is from SP2 to SP1 In the case of down stream label assignment, the transit label used by ASBR2 is allocated by ASBR1, which in turn advertises it to ASB2 (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. - MPLS/GMPLS Security framework 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 @@ -2405,50 +2533,50 @@ 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 check list of MPLS and GMPLS security threats, defense techniques, and the best practice guide outlines for MPLS and GMPLS deployment. 9.1. MPLS and GMPLS Specific Security Threats + MPLS/GMPLS Security framework + October 2009 9.1.1. Control Plane Attacks Types of attacks on the control plane: - Unauthorized LSP creation - LSP message interception - MPLS/GMPLS Security framework - Attacks against RSVP-TE: DoS attack with setting 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 a 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 MPLS-ping and LMP + - 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. 9.1.2. Data Plane Attacks - Unauthorized observation of data traffic - Data traffic modification - Spoofing and replay - Unauthorized Deletion - Unauthorized Traffic Pattern Analysis @@ -2456,26 +2584,27 @@ 9.2. Defense Techniques 1) Authentication: - Bi-directional authentication - Key management - Management System Authentication - Peer-to-peer authentication + MPLS/GMPLS Security framework + October 2009 + 2) Cryptographic techniques 3) Use of IPsec in MPLS/GMPLS networks 4) Encryption for device configuration and management 5) Cryptographic Techniques for MPLS Pseudowires - - MPLS/GMPLS Security framework 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 10) Quality Control Processes @@ -2500,27 +2629,30 @@ - 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 - Customer service monitoring tools - - Use of MPLS-ping (with its own control plane security) to + - 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 MPLS/GMPLS Security framework + October 2009 + +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 @@ -2549,25 +2681,27 @@ 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. + MPLS/GMPLS Security framework + October 2009 + 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 Security framework 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. @@ -2597,26 +2731,27 @@ (GCM) in IPsec Encapsulating Security Payload (ESP)", June 2005. [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet Protocol," December 2005. [RFC4302] S. Kent, "IP Authentication Header," December 2005. [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol",December 2005. + MPLS/GMPLS Security framework + October 2009 + [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", December 2005. - MPLS/GMPLS Security framework - [RFC4379] K. Kompella and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", February 2006. [RFC4447] Martini, et al., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", April 2006. [RFC4835] V. Manral, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", April 2007. @@ -2645,25 +2780,26 @@ [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap," November 1998. [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 1 (SHA1)," September 2001. [RFC3562] M. Leech, "Key Management Considerations for the TCP MD5 Signature Option", July 2003. + MPLS/GMPLS Security framework + October 2009 + [RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security Mechanisms for the Internet," December 2003. - MPLS/GMPLS Security framework - [RFC3985] S. Bryant and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", March 2005. [RFC4107] S. Bellovin, R. Housley, "Guidelines for Cryptographic Key Management", June 2005. [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", July 2005. [RFC4111] L. Fang, "Security Framework of Provider Provisioned @@ -2693,31 +2829,33 @@ [RFC4864] G. Van de Velde, T. Hain, R. Droms, "Local Network Protection for IPv6", May 2007. [RFC4869] L. Law and J. Solinas, "Suite B Cryptographic Suites for IPsec", April 2007. [RFC5254] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi- Segment Pseudowire Emulation Edge-to-Edge (PWE3)", October 2008. + MPLS/GMPLS Security framework + October 2009 + [MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical Specification", IP/MPLS Forum 19.0.0, April 2008. - MPLS/GMPLS Security framework - [OIF Sec Mag] R. Esposito, R. Graveman, and B. Hazzard, "Security for Management Interfaces to Network Elements", OIF-SMI-01.0, September 2003. [opsec efforts] C. Lonvick and D. Spak, "Security Best Practices - Efforts and Documents", draft-ietf-opsec-efforts-08.txt, June 2008. + Efforts and Documents", draft-ietf-opsec-efforts-10.txt, April + 2009. [RSVP-key] M. Behringer, F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", draft-ietf-tsvwg-rsvp-security- groupkeying-05.txt, June 2009. 14. Author's Addresses Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road @@ -2740,23 +2878,25 @@ 10 Technology Park Drive Westford, MA 01886 USA Email: rcallon@juniper.net Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 + MPLS/GMPLS Security framework + October 2009 Email: rfg@acm.org - MPLS/GMPLS Security framework + Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@francetelecom.com Raymond Zhang British Telecom @@ -2785,25 +2925,28 @@ Verizon 40 Sylvan Road Waltham, MA 02145 Email: nabil.bitar@verizon.com Monique Morrow Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com + MPLS/GMPLS Security framework + October 2009 Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk - MPLS/GMPLS Security framework 15. Acknowledgements Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). The authors and contributors would also like to acknowledge the helpful comments and suggestions from Sam Hartman, Dimitri - Papadimitriou, Kannan Varadhan, Stephen Farrell, and Scott Brim in - particular for his comments and discussion through GEN-ART review. + Papadimitriou, Kannan Varadhan, Stephen Farrell, Scott Brim in + particular for his comments and discussion through GEN-ART review, + The authors would like to thank Sandra Murphy and Tim Polk for their + comments and help through Security AD review.