tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5920

Informational
Pages: 66
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

Security Framework for MPLS and GMPLS Networks

Part 1 of 3, p. 1 to 19
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part