Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5920

Security Framework for MPLS and GMPLS Networks

Pages: 66
Informational
Part 1 of 3 – Pages 1 to 19
None   None   Next

Top   ToC   RFC5920 - Page 1
Internet Engineering Task Force (IETF)                      L. Fang, Ed.
Request for Comments: 5920                           Cisco Systems, Inc.
Category: Informational                                        July 2010
ISSN: 2070-1721


             Security Framework for MPLS and GMPLS Networks

Abstract

This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5920.
Top   ToC   RFC5920 - Page 2
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.
Top   ToC   RFC5920 - Page 3

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
Top   ToC   RFC5920 - Page 4

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
Top   ToC   RFC5920 - Page 5
   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
Top   ToC   RFC5920 - Page 6
   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.
Top   ToC   RFC5920 - Page 7
   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.
Top   ToC   RFC5920 - Page 8
   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.
Top   ToC   RFC5920 - Page 9
                         /-------------\
      +------------+    /               \         +------------+
      | 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
Top   ToC   RFC5920 - Page 10
   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.
Top   ToC   RFC5920 - Page 11
   -  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
Top   ToC   RFC5920 - Page 12
   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.
Top   ToC   RFC5920 - Page 13

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.)
Top   ToC   RFC5920 - Page 14
   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].
Top   ToC   RFC5920 - Page 15

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.
Top   ToC   RFC5920 - Page 16

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
Top   ToC   RFC5920 - Page 17
   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
Top   ToC   RFC5920 - Page 18
   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
Top   ToC   RFC5920 - Page 19
   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)

Next Section