RFC 5920
Security Framework for MPLS and GMPLS Networks
Pages: 66
Informational
Informational
Part 1 of 3 – Pages 1 to 19
Internet Engineering Task Force (IETF) L. Fang, Ed. Request for Comments: 5920 Cisco Systems, Inc. Category: Informational July 2010 ISSN: 2070-1721 Security Framework for MPLS and GMPLS NetworksAbstract
This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5920.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction ....................................................4 2. Terminology .....................................................5 2.1. Acronyms and Abbreviations .................................5 2.2. MPLS and GMPLS Terminology .................................6 3. Security Reference Models .......................................8 4. Security Threats ...............................................10 4.1. Attacks on the Control Plane ..............................12 4.2. Attacks on the Data Plane .................................15 4.3. Attacks on Operation and Management Plane .................17 4.4. Insider Attacks Considerations ............................19 5. Defensive Techniques for MPLS/GMPLS Networks ...................19 5.1. Authentication ............................................20 5.2. Cryptographic Techniques ..................................22 5.3. Access Control Techniques .................................33 5.4. Use of Isolated Infrastructure ............................38 5.5. Use of Aggregated Infrastructure ..........................38 5.6. Service Provider Quality Control Processes ................39 5.7. Deployment of Testable MPLS/GMPLS Service .................39 5.8. Verification of Connectivity ..............................40 6. Monitoring, Detection, and Reporting of Security Attacks .......40 7. Service Provider General Security Requirements .................42 7.1. Protection within the Core Network ........................42 7.2. Protection on the User Access Link ........................46 7.3. General User Requirements for MPLS/GMPLS Providers ........48 8. Inter-Provider Security Requirements ...........................48 8.1. Control-Plane Protection ..................................49 8.2. Data-Plane Protection .....................................53 9. Summary of MPLS and GMPLS Security .............................54 9.1. MPLS and GMPLS Specific Security Threats ..................55 9.2. Defense Techniques ........................................56 9.3. Service Provider MPLS and GMPLS Best-Practice Outlines ....57 10. Security Considerations .......................................59 11. References ....................................................59 11.1. Normative References .....................................59 11.2. Informative References ...................................62 12. Acknowledgements ..............................................64 13. Contributors' Contact Information .............................65
1. Introduction
Security is an important aspect of all networks, MPLS and GMPLS networks being no exception. MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Various security considerations have been addressed in each of the many RFCs on MPLS and GMPLS technologies, but no single document covers general security considerations. The motivation for creating this document is to provide a comprehensive and consistent security framework for MPLS and GMPLS networks. Each individual document may point to this document for general security considerations in addition to providing security considerations specific to the particular technologies the document is describing. In this document, we first describe the security threats relevant in the context of MPLS and GMPLS and the defensive techniques to combat those threats. We consider security issues resulting both from malicious or incorrect behavior of users and other parties and from negligent or incorrect behavior of providers. An important part of security defense is the detection and reporting of a security attack, which is also addressed in this document. We then discuss possible service provider security requirements in an MPLS or GMPLS environment. Users have expectations for the security characteristics of MPLS or GMPLS networks. These include security requirements for equipment supporting MPLS and GMPLS and operational security requirements for providers. Service providers must protect their network infrastructure and make it secure to the level required to provide services over their MPLS or GMPLS networks. Inter-AS and inter-provider security are discussed with special emphasis, because the security risk factors are higher with inter- provider connections. Note that inter-carrier MPLS security is also considered in [MFA-MPLS-ICI]. Depending on different MPLS or GMPLS techniques used, the degree of risk and the mitigation methodologies vary. This document discusses the security aspects and requirements for certain basic MPLS and GMPLS techniques and interconnection models. This document does not attempt to cover all current and future MPLS and GMPLS technologies, as it is not within the scope of this document to analyze the security properties of specific technologies. It is important to clarify that, in this document, we limit ourselves to describing the providers' security requirements that pertain to MPLS and GMPLS networks, not including the connected user sites. Readers may refer to the "Security Best Practices Efforts and
Documents" [OPSEC-EFFORTS] and "Security Mechanisms for the Internet" [RFC3631] for general network operation security considerations. It is not our intention, however, to formulate precise "requirements" for each specific technology in terms of defining the mechanisms and techniques that must be implemented to satisfy such security requirements.2. Terminology
2.1. Acronyms and Abbreviations
AS Autonomous System ASBR Autonomous System Border Router ATM Asynchronous Transfer Mode BGP Border Gateway Protocol BFD Bidirectional Forwarding Detection CE Customer-Edge device CoS Class of Service CPU Central Processing Unit DNS Domain Name System DoS Denial of Service ESP Encapsulating Security Payload FEC Forwarding Equivalence Class GMPLS Generalized Multi-Protocol Label Switching GCM Galois Counter Mode GRE Generic Routing Encapsulation ICI InterCarrier Interconnect ICMP Internet Control Message Protocol ICMPv6 ICMP in IP Version 6 IGP Interior Gateway Protocol IKE Internet Key Exchange IP Internet Protocol IPsec IP Security IPVPN IP-based VPN LDP Label Distribution Protocol L2TP Layer 2 Tunneling Protocol LMP Link Management Protocol LSP Label Switched Path LSR Label Switching Router MD5 Message Digest Algorithm MPLS Multiprotocol Label Switching MP-BGP Multiprotocol BGP NTP Network Time Protocol OAM Operations, Administration, and Maintenance PCE Path Computation Element PE Provider-Edge device PPVPN Provider-Provisioned Virtual Private Network PSN Packet-Switched Network
PW Pseudowire
QoS Quality of Service
RR Route Reflector
RSVP Resource Reservation Protocol
RSVP-TE Resource Reservation Protocol with Traffic Engineering
Extensions
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SP Service Provider
SSH Secure Shell
SSL Secure Sockets Layer
SYN Synchronize packet in TCP
TCP Transmission Control Protocol
TDM Time Division Multiplexing
TE Traffic Engineering
TLS Transport Layer Security
ToS Type of Service
TTL Time-To-Live
UDP User Datagram Protocol
VC Virtual Circuit
VPN Virtual Private Network
WG Working Group of IETF
WSS Web Services Security
2.2. MPLS and GMPLS Terminology
This document uses MPLS- and GMPLS-specific terminology. Definitions
and details about MPLS and GMPLS terminology can be found in
[RFC3031] and [RFC3945]. The most important definitions are repeated
in this section; for other definitions, the reader is referred to
[RFC3031] and [RFC3945].
Core network: An MPLS/GMPLS core network is defined as the central
network infrastructure that consists of P and PE routers. An
MPLS/GMPLS core network may consist of one or more networks belonging
to a single SP.
Customer Edge (CE) device: A Customer Edge device is a router or a
switch in the customer's network interfacing with the Service
Provider's network.
Forwarding Equivalence Class (FEC): A group of IP packets that are
forwarded in the same manner (e.g., over the same path, with the same
forwarding treatment).
Label: A short, fixed length, physically contiguous identifier,
usually of local significance.
Label merging: the replacement of multiple incoming labels for a particular FEC with a single outgoing label. Label Switched Hop: A hop between two MPLS nodes, on which forwarding is done using labels. Label Switched Path (LSP): The path through one or more LSRs at one level of the hierarchy followed by packets in a particular FEC. Label Switching Routers (LSRs): An MPLS/GMPLS node assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers or cell headers. Loop Detection: A method of dealing with loops in which loops are allowed to be set up, and data may be transmitted over the loop, but the loop is later detected. Loop Prevention: A method of dealing with loops in which data is never transmitted over a loop. Label Stack: An ordered set of labels. Merge Point: A node at which label merging is done. MPLS Domain: A contiguous set of nodes that perform MPLS routing and forwarding and are also in one Routing or Administrative Domain. MPLS Edge Node: An MPLS node that connects an MPLS domain with a node outside of the domain, either because it does not run MPLS, or because it is in a different domain. Note that if an LSR has a neighboring host not running MPLS, then that LSR is an MPLS edge node. MPLS Egress Node: An MPLS edge node in its role in handling traffic as it leaves an MPLS domain. MPLS Ingress Node: A MPLS edge node in its role in handling traffic as it enters a MPLS domain. MPLS Label: A label carried in a packet header, which represents the packet's FEC. MPLS Node: A node running MPLS. An MPLS node is aware of MPLS control protocols, runs one or more routing protocols, and is capable of forwarding packets based on labels. An MPLS node may optionally be also capable of forwarding native IP packets.
Multiprotocol Label Switching (MPLS): MPLS is an architecture for efficient data packet switching and routing. MPLS assigns data packets with labels. Instead of performing the longest match for each packet's destination as in conventional IP forwarding, MPLS makes the packet-forwarding decisions solely on the contents of the label without examining the packet itself. This allows the creation of end-to-end circuits across any type of transport medium, using any protocols. P: Provider Router. A Provider Router is a router in the Service Provider's core network that does not have interfaces directly towards the customer. A P router is used to interconnect the PE routers and/or other P routers within the core network. PE: Provider Edge device. A Provider Edge device is the equipment in the Service Provider's network that interfaces with the equipment in the customer's network. PPVPN: Provider-Provisioned Virtual Private Network, including Layer 2 VPNs and Layer 3 VPNs. VPN: Virtual Private Network, which restricts communication between a set of sites, making use of an IP backbone shared by traffic not going to or not coming from those sites [RFC4110].3. Security Reference Models
This section defines a reference model for security in MPLS/GMPLS networks. This document defines each MPLS/GMPLS core in a single domain to be a trusted zone. A primary concern is about security aspects that relate to breaches of security from the "outside" of a trusted zone to the "inside" of this zone. Figure 1 depicts the concept of trusted zones within the MPLS/GMPLS framework.
/-------------\ +------------+ / \ +------------+ | MPLS/GMPLS +---/ \--------+ MPLS/GMPLS | | user | MPLS/GMPLS Core | user | | site +---\ /XXX-----+ site | +------------+ \ / XXX +------------+ \-------------/ | | | | | +------\ +--------/ "Internet" |<- Trusted zone ->| MPLS/GMPLS Core with user connections and Internet connection Figure 1: The MPLS/GMPLS Trusted Zone Model The trusted zone is the MPLS/GMPLS core in a single AS within a single Service Provider. A trusted zone contains elements and users with similar security properties, such as exposure and risk level. In the MPLS context, an organization is typically considered as one trusted zone. The boundaries of a trust domain should be carefully defined when analyzing the security properties of each individual network, e.g., the boundaries can be at the link termination, remote peers, areas, or quite commonly, ASes. In principle, the trusted zones should be separate; however, typically MPLS core networks also offer Internet access, in which case a transit point (marked with "XXX" in Figure 1) is defined. In the case of MPLS/GMPLS inter-provider connections or InterCarrier Interconnect (ICI), the trusted zone of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for Provider A and ASBR3 and ASBR4 for Provider B in Figure 2). A key requirement of MPLS and GMPLS networks is that the security of the trusted zone not be compromised by interconnecting the MPLS/GMPLS core infrastructure with another provider's core (MPLS/GMPLS or non- MPLS/GMPLS), the Internet, or end users. In addition, neighbors may be trusted or untrusted. Neighbors may be authorized or unauthorized. An authorized neighbor is the neighbor one establishes a peering relationship with. Even though a neighbor may be authorized for communication, it may not be trusted. For example, when connecting with another provider's ASBRs to set up
inter-AS LSPs, the other provider is considered an untrusted but authorized neighbor. +---------------+ +----------------+ | | | | | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS | CE1--PE1 Network | | Network PE2--CE2 | Provider A ASBR2----ASBR4 Provider B | | | | | +---------------+ +----------------+ InterCarrier Interconnect (ICI) For Provider A: Trusted Zone: Provider A MPLS/GMPLS network Authorized but untrusted neighbor: provider B Unauthorized neighbors: CE1, CE2 Figure 2: MPLS/GMPLS Trusted Zone and Authorized Neighbor All aspects of network security independent of whether a network is an MPLS/GMPLS network, are out of scope. For example, attacks from the Internet to a user's web-server connected through the MPLS/GMPLS network are not considered here, unless the way the MPLS/GMPLS network is provisioned could make a difference to the security of this user's server.4. Security Threats
This section discusses the various network security threats that may endanger MPLS/GMPLS networks. RFC 4778 [RFC4778] provided the best current operational security practices in Internet Service Provider environments. A successful attack on a particular MPLS/GMPLS network or on an SP's MPLS/GMPLS infrastructure may cause one or more of the following ill effects: - Observation, modification, or deletion of a provider's or user's data. - Replay of a provider's or user's data. - Injection of inauthentic data into a provider's or user's traffic stream. - Traffic pattern analysis on a provider's or user's traffic. - Disruption of a provider's or user's connectivity.
- Degradation of a provider's service quality.
- Probing a provider's network to determine its configuration,
capacity, or usage.
It is useful to consider that threats, whether malicious or
accidental, may come from different categories of sources. For
example, they may come from:
- Other users whose services are provided by the same MPLS/GMPLS
core.
- The MPLS/GMPLS SP or persons working for it.
- Other persons who obtain physical access to an MPLS/GMPLS SP's
site.
- Other persons who use social engineering methods to influence the
behavior of an SP's personnel.
- Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats.
(Such threats are beyond the scope of this document.)
- Others, e.g., attackers from the Internet at large.
- Other SPs in the case of MPLS/GMPLS inter-provider connection.
The core of the other provider may or may not be using MPLS/GMPLS.
- Those who create, deliver, install, and maintain software for
network equipment.
Given that security is generally a tradeoff between expense and risk,
it is also useful to consider the likelihood of different attacks
occurring. There is at least a perceived difference in the
likelihood of most types of attacks being successfully mounted in
different environments, such as:
- An MPLS/GMPLS core interconnecting with another provider's core.
- An MPLS/GMPLS configuration transiting the public Internet.
Most types of attacks become easier to mount and hence more likely as
the shared infrastructure via which service is provided expands from
a single SP to multiple cooperating SPs to the global Internet.
Attacks that may not be of sufficient likeliness to warrant concern
in a closely controlled environment often merit defensive measures in
broader, more open environments. In closed communities, it is often
practical to deal with misbehavior after the fact: an employee can be disciplined, for example. The following sections discuss specific types of exploits that threaten MPLS/GMPLS networks.4.1. Attacks on the Control Plane
This category encompasses attacks on the control structures operated by the SP with MPLS/GMPLS cores. It should be noted that while connectivity in the MPLS control plane uses the same links and network resources as are used by the data plane, the GMPLS control plane may be provided by separate resources from those used in the data plane. That is, the GMPLS control plane may be physically separate from the data plane. The different cases of physically congruent and physically separate control/data planes lead to slightly different possibilities of attack, although most of the cases are the same. Note that, for example, the data plane cannot be directly congested by an attack on a physically separate control plane as it could be if the control and data planes shared network resources. Note also that if the control plane uses diverse resources from the data plane, no assumptions should be made about the security of the control plane based on the security of the data plane resources. This section is focused the outsider attack. The insider attack is discussed in Section 4.4.4.1.1. LSP Creation by an Unauthorized Element
The unauthorized element can be a local CE or a router in another domain. An unauthorized element can generate MPLS signaling messages. At the least, this can result in extra control plane and forwarding state, and if successful, network bandwidth could be reserved unnecessarily. This may also result in theft of service or even compromise the entire network.4.1.2. LSP Message Interception
This threat might be accomplished by monitoring network traffic, for example, after a physical intrusion. Without physical intrusion, it could be accomplished with an unauthorized software modification. Also, many technologies such as terrestrial microwave, satellite, or free-space optical could be intercepted without physical intrusion. If successful, it could provide information leading to label spoofing attacks. It also raises confidentiality issues.
4.1.3. Attacks against RSVP-TE
RSVP-TE, described in [RFC3209], is the control protocol used to set up GMPLS and traffic engineered MPLS tunnels. There are two major types of denial-of-service (DoS) attacks against an MPLS domain based on RSVP-TE. The attacker may set up numerous unauthorized LSPs or may send a storm of RSVP messages. It has been demonstrated that unprotected routers running RSVP can be effectively disabled by both types of DoS attacks. These attacks may even be combined, by using the unauthorized LSPs to transport additional RSVP (or other) messages across routers where they might otherwise be filtered out. RSVP attacks can be launched against adjacent routers at the border with the attacker, or against non-adjacent routers within the MPLS domain, if there is no effective mechanism to filter them out.4.1.4. Attacks against LDP
LDP, described in [RFC5036], is the control protocol used to set up MPLS tunnels without TE. There are two significant types of attack against LDP. An unauthorized network element can establish an LDP session by sending LDP Hello and LDP Init messages, leading to the potential setup of an LSP, as well as accompanying LDP state table consumption. Even without successfully establishing LSPs, an attacker can launch a DoS attack in the form of a storm of LDP Hello messages or LDP TCP SYN messages, leading to high CPU utilization or table space exhaustion on the target router.4.1.5. Denial-of-Service Attacks on the Network Infrastructure
DoS attacks could be accomplished through an MPLS signaling storm, resulting in high CPU utilization and possibly leading to control- plane resource starvation. Control-plane DoS attacks can be mounted specifically against the mechanisms the SP uses to provide various services, or against the general infrastructure of the service provider, e.g., P routers or shared aspects of PE routers. (An attack against the general infrastructure is within the scope of this document only if the attack can occur in relation with the MPLS/GMPLS infrastructure; otherwise, it is not an MPLS/GMPLS-specific issue.)
The attacks described in the following sections may each have denial of service as one of their effects. Other DoS attacks are also possible.4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via Management Interfaces
This includes unauthorized access to an SP's infrastructure equipment, for example, to reconfigure the equipment or to extract information (statistics, topology, etc.) pertaining to the network.4.1.7. Cross-Connection of Traffic between Users
This refers to the event in which expected isolation between separate users (who may be VPN users) is breached. This includes cases such as: - A site being connected into the "wrong" VPN. - Traffic being replicated and sent to an unauthorized user. - Two or more VPNs being improperly merged together. - A point-to-point VPN connecting the wrong two points. - Any packet or frame being improperly delivered outside the VPN to which it belongs Misconnection or cross-connection of VPNs may be caused by service provider or equipment vendor error, or by the malicious action of an attacker. The breach may be physical (e.g., PE-CE links misconnected) or logical (e.g., improper device configuration). Anecdotal evidence suggests that the cross-connection threat is one of the largest security concerns of users (or would-be users).4.1.8. Attacks against Routing Protocols
This encompasses attacks against underlying routing protocols that are run by the SP and that directly support the MPLS/GMPLS core. (Attacks against the use of routing protocols for the distribution of backbone routes are beyond the scope of this document.) Specific attacks against popular routing protocols have been widely studied and are described in [RFC4593].
4.1.9. Other Attacks on Control Traffic
Besides routing and management protocols (covered separately in the previous sections), a number of other control protocols may be directly involved in delivering services by the MPLS/GMPLS core. These include but may not be limited to: - MPLS signaling (LDP, RSVP-TE) discussed above in subsections 4.1.4 and 4.1.3 - PCE signaling - IPsec signaling (IKE and IKEv2) - ICMP and ICMPv6 - L2TP - BGP-based membership discovery - Database-based membership discovery (e.g., RADIUS) - Other protocols that may be important to the control infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE. Attacks might subvert or disrupt the activities of these protocols, for example via impersonation or DoS. Note that all of the data-plane attacks can also be carried out against the packets of the control and management planes: insertion, spoofing, replay, deletion, pattern analysis, and other attacks mentioned above.4.2. Attacks on the Data Plane
This category encompasses attacks on the provider's or end-user's data. Note that from the MPLS/GMPLS network end user's point of view, some of this might be control-plane traffic, e.g., routing protocols running from user site A to user site B via IP or non-IP connections, which may be some type of VPN.4.2.1. Unauthorized Observation of Data Traffic
This refers to "sniffing" provider or end user packets and examining their contents. This can result in exposure of confidential information. It can also be a first step in other attacks (described below) in which the recorded data is modified and re-inserted, or simply replayed later.
4.2.2. Modification of Data Traffic
This refers to modifying the contents of packets as they traverse the MPLS/GMPLS core.4.2.3. Insertion of Inauthentic Data Traffic: Spoofing and Replay
Spoofing refers to sending a user packets or inserting packets into a data stream that do not belong, with the objective of having them accepted by the recipient as legitimate. Also included in this category is the insertion of copies of once-legitimate packets that have been recorded and replayed.4.2.4. Unauthorized Deletion of Data Traffic
This refers to causing packets to be discarded as they traverse the MPLS/GMPLS networks. This is a specific type of denial-of-service attack.4.2.5. Unauthorized Traffic Pattern Analysis
This refers to "sniffing" provider or user packets and examining aspects or meta-aspects of them that may be visible even when the packets themselves are encrypted. An attacker might gain useful information based on the amount and timing of traffic, packet sizes, source and destination addresses, etc. For most users, this type of attack is generally considered to be significantly less of a concern than the other types discussed in this section.4.2.6. Denial-of-Service Attacks
Denial-of-service (DoS) attacks are those in which an attacker attempts to disrupt or prevent the use of a service by its legitimate users. Taking network devices out of service, modifying their configuration, or overwhelming them with requests for service are several of the possible avenues for DoS attack. Overwhelming the network with requests for service, otherwise known as a "resource exhaustion" DoS attack, may target any resource in the network, e.g., link bandwidth, packet forwarding capacity, session capacity for various protocols, CPU power, table size, storage overflows, and so on. DoS attacks of the resource exhaustion type can be mounted against the data plane of a particular provider or end user by attempting to insert (spoofing) an overwhelming quantity of inauthentic data into the provider or end-user's network from outside of the trusted zone. Potential results might be to exhaust the bandwidth available to that
provider or end user, or to overwhelm the cryptographic authentication mechanisms of the provider or end user. Data-plane resource exhaustion attacks can also be mounted by overwhelming the service provider's general (MPLS/GMPLS-independent) infrastructure with traffic. These attacks on the general infrastructure are not usually an MPLS/GMPLS-specific issue, unless the attack is mounted by another MPLS/GMPLS network user from a privileged position. (For example, an MPLS/GMPLS network user might be able to monopolize network data-plane resources and thus disrupt other users.) Many DoS attacks use amplification, whereby the attacker co-opts otherwise innocent parties to increase the effect of the attack. The attacker may, for example, send packets to a broadcast or multicast address with the spoofed source address of the victim, and all of the recipients may then respond to the victim.4.2.7. Misconnection
Misconnection may arise through deliberate attack, or through misconfiguration or misconnection of the network resources. The result is likely to be delivery of data to the wrong destination or black-holing of the data. In GMPLS with physically diverse control and data planes, it may be possible for data-plane misconnection to go undetected by the control plane. In optical networks under GMPLS control, misconnection may give rise to physical safety risks as unprotected lasers may be activated without warning.4.3. Attacks on Operation and Management Plane
Attacks on the Operation and Management plane have been discussed extensively as general network security issues over the last 20 years. RFC 4778 [RFC4778] may serve as the best current operational security practices in Internet Service Provider environments. RFC 4377 [RFC4377] provided Operations and Management Requirements for MPLS networks. See also the Security Considerations of RFC 4377 and Section 7 of RFC 4378 [RFC4378]. Operation and Management across the MPLS-ICI could also be the source of security threats on the provider infrastructure as well as the service offered over the MPLS-ICI. A large volume of Operation and Management messages could overwhelm the processing capabilities of an ASBR if the ASBR is not properly protected. Maliciously generated
Operation and Management messages could also be used to bring down an otherwise healthy service (e.g., MPLS Pseudowire), and therefore affect service security. LSP ping does not support authentication today, and that support should be a subject for future considerations. Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure. Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing. Regarding GMPLS Operation and Management considerations in optical interworking, there is a good discussion on security for management interfaces to Network Elements [OIF-Sec-Mag]. Network elements typically have one or more (in some cases many) Operation and Management interfaces used for network management, billing and accounting, configuration, maintenance, and other administrative activities. Remote access to a network element through these Operation and Management interfaces is frequently a requirement. Securing the control protocols while leaving these Operation and Management interfaces unprotected opens up a huge security vulnerability. Network elements are an attractive target for intruders who want to disrupt or gain free access to telecommunications facilities. Much has been written about this subject since the 1980s. In the 1990s, telecommunications facilities were identified in the U.S. and other countries as part of the "critical infrastructure", and increased emphasis was placed on thwarting such attacks from a wider range of potentially well-funded and determined adversaries. At one time, careful access controls and password management were a sufficient defense, but are no longer. Networks using the TCP/IP protocol suite are vulnerable to forged source addresses, recording and later replay, packet sniffers picking up passwords, re-routing of traffic to facilitate eavesdropping or tampering, active hijacking attacks of TCP connections, and a variety of denial-of-service attacks. The ease of forging TCP/IP packets is the main reason network management protocols lacking strong security have not been used to configure network elements (e.g., with the SNMP SET command). Readily available hacking tools exist that let an eavesdropper on a LAN take over one end of any TCP connection, so that the legitimate party is cut off. In addition, enterprises and Service Providers in some jurisdictions need to safeguard data about their users and network configurations from prying. An attacker could eavesdrop and
observe traffic to analyze usage patterns and map a network configuration; an attacker could also gain access to systems and manipulate configuration data or send malicious commands. Therefore, in addition to authenticating the human user, more sophisticated protocol security is needed for Operation and Management interfaces, especially when they are configured over TCP/IP stacks. Finally, relying on a perimeter defense, such as firewalls, is insufficient protection against "insider attacks" or against penetrations that compromise a system inside the firewall as a launching pad to attack network elements. The insider attack is discussed in the following session.4.4. Insider Attacks Considerations
The chain of trust model means that MPLS and GMPLS networks are particularly vulnerable to insider attacks. These can be launched by any malign person with access to any LSR in the trust domain. Insider attacks could also be launched by compromised software within the trust domain. Such attacks could, for example, advertise non- existent resources, modify advertisements from other routers, request unwanted LSPs that use network resources, or deny or modify legitimate LSP requests. Protection against insider attacks is largely for future study in MPLS and GMPLS networks. Some protection can be obtained by providing strict security for software upgrades and tight OAM access control procedures. Further protection can be achieved by strict control of user (i.e., operator) access to LSRs. Software change management and change tracking (e.g., CVS diffs from text-based configuration files) helps in spotting irregularities and human errors. In some cases, configuration change approval processes may also be warranted. Software tools could be used to check configurations for consistency and compliance. Software tools may also be used to monitor and report network behavior and activity in order to quickly spot any irregularities that may be the result of an insider attack.
(page 19 continued on part 2)