[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

   Network Working Group                            Luyuan Fang (Ed)
   Internet Draft                                  Michael Behringer
   Category: Informational                       Cisco Systems, Inc.
   Expires: August 2007                                  Ross Callon
                                                    Juniper Networks
                                                       J. L. Le Roux
                                                      France Telecom
                                                       Raymond Zhang
                                                     British Telecom
                                                         Paul Knight
                                                              Nortel
                                                        Yaakov Stein
                                             RAD Data Communications

                                                       February 2007


              Security Framework for MPLS and GMPLS Networks
              draft-fang-mpls-gmpls-security-framework-00.txt

Status of this Memo

   This memo provides information for the Internet community. It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

IPR Disclosure Acknowledgement

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

Copyright Notice
   Copyright (C) The IETF Trust (2007).

   Fang, et al.                  Informational                      1

   MPLS/GMPLS Security framework
   February 2007


Abstract

   This document provides a security framework for Multiprotocol Label
   Switching (MPLS) and Generalized Multiprotocol Label Switching
   (GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and
   [RFC3945]). 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 gives
   emphasis to RSVP-TE and LDP security considerations, as well as
   Inter-AS and Inter-provider security considerations for building
   and maintaining MPLS and GMPLS networks across different domains or
   different Service Providers.



Table of Contents

   1. Introduction..................................................3
   1.1.  Structure of This Document.................................4
   1.2.  Contributors...............................................5
   2. Terminology...................................................5
   2.1.  Terminology................................................5
   2.2.  Acronyms and Abbreviations.................................7
   3. Security Reference Models.....................................7
   4. Security Threats..............................................9
   4.1.  Attacks on the Control Plane..............................10
   4.2.  Attacks on the Data Plane.................................13
   5. Defensive Techniques for MPLS/GMPLS Networks.................15
   5.1.  Cryptographic techniques..................................16
   5.2.  Authentication............................................24
   5.3.  Access Control techniques.................................25
   5.4.  Use of Isolated Infrastructure............................29
   5.5.  Use of Aggregated Infrastructure..........................30
   5.6.  Service Provider Quality Control Processes................30
   5.7.  Deployment of Testable MPLS/GMPLS Service.................31
   6. Monitoring, Detection, and Reporting of Security Attacks.....31
   7. Service Provider General Security Requirements...............32
   7.1.  Protection within the Core Network........................32
   7.2.  Protection on the User Access Link........................36
   7.3.  General Requirements for MPLS/GMPLS Providers.............38
   8. Inter-provider Security Requirements.........................38
   8.1.  Control Plane Protection..................................39

   Fang, et al.                  Informational                      2


   MPLS/GMPLS Security framework
   February 2007

   8.2.  Data Plane Protection.....................................43
   9. Security Considerations......................................44
   10.  IANA Considerations........................................45
   11.  Normative References.......................................45
   12.  Informational References...................................46
   13.  Author's Addresses.........................................47
   14.  Acknowledgement............................................49


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC2119 [RFC
   2119].


1. Introduction

   Security is an important aspect of all networks, MPLS and GMPLS
   networks being no exception.

   MPLS and GMPLS are described in [RFC3031] [RFC3945]. Various
   security considerations have been addressed in each of the many
   RFCs that address on MPLS and GMPLS technologies, but there has not
   been a single document which provides 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 the security considerations which are specific to the
   particular technologies the document is describing.

   In this document, we first describe the security threats that are
   relevant in the context of MPLS and GMPLS, and the defensive
   techniques that can be used to combat those threats. We consider
   security issues deriving both from malicious or incorrect behavior
   of users and other parties and from negligent or incorrect behavior
   of the providers. An important part of security defense is the
   detection and report of a security attack, which is also addressed
   in this document.

   We then discuss the possible service provider security requirements
   in a MPLS or GMPLS environment. The users have expectations that
   need to be met on the security characteristics of MPLS or GMPLS
   networks. These will include the security requirements for MPLS and
   GMPLS supporting equipments, and the provider operation security

   Fang, et al.                  Informational                      3


   MPLS/GMPLS Security framework
   February 2007

   requirements. The 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, since the security risk factors are higher with inter-
   provider connections. Depending on different MPLS or GMPLS
   techniques used, the degree of risk and the mitigation
   methodologies vary. This document discusses the security aspects
   and requirements for certain basic MPLS and GMPLS techniques and
   inter-connection models. This document does not attempt to cover
   all current and future MPLS and GMPLS technologies, since it is not
   within the scope of this document to analyze the security
   properties of specific technologies.

   It is important to clarify that, in this document; we limit
   ourselves to describing the providers' security requirements that
   pertain to MPLS and GMPLS networks. Readers may refer to the
   "Security Best Practices Efforts and Documents" [opsec effort] and
   "Security Mechanisms for the Internet" [RFC3631] for general
   network operation security considerations. It is not our intention,
   however, to formulate precise "requirements" on each specific
   technology in terms of defining the mechanisms and techniques that
   must be implemented to satisfy such security requirements.

   1.1. Structure of This Document

   This document is organized as follows. In Section 2, we define the
   terminology used in the document. In section 3, we define the
   security reference models for security in MPLS/GMPLS networks,
   which we use in the rest of the document. In Section 4, we describe
   the security threats that are specific of MPLS and GMPLS. In
   Section 5, we review defense techniques that may be used against
   those threats. In Section 6, we describe how attacks may be
   detected and reported. In Section 7, we describe security
   requirements that the provider may have in order to guarantee the
   security of the network infrastructure to provide MPLS/GMPLS
   services. In section 8, we discuss Inter-provider security
   requirements. Finally, in Section 9, we discuss security
   considerations of this document.

   This document has used relevant content from RFC 4111 "Security
   Framework of Provider Provisioned VPN" [RFC4111], and "MPLS
   InterCarrier Interconnect Technical Specification" [MFA MPLS ICI]
   in the Inter-provider security discussion. We acknowledge the
   authors of these documents for the valuable information and text.



   Fang, et al.                  Informational                      4


   MPLS/GMPLS Security framework
   February 2007

   1.2. Contributors

   As the design team members of MPLS security Framework, the
   following made significant contributions to this document.

         Nabil Bitar, Verizon
         Monique Morrow, Cisco systems, Inc.
         Jerry Ash, AT&T



2. Terminology

   2.1.  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].


   CE: Customer Edge device. A Customer Edge device is a router or a
   switch in the customer network interfacing with the Service
   Provider's network.

   Forwarding equivalence class (FEC): A group of IP packets which 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 which
   is used to identify a FEC, usually of local significance.

   Label switched hop: the hop between two MPLS nodes, on which
   forwarding is done using labels.

   Label switched path (LSP): The path through one or more LSRs at one
   level of the hierarchy followed by a packets in a particular FEC.

   Label switching router (LSR): an MPLS node which is capable of
   forwarding native L3 packets

   Layer 2: the protocol layer under layer 3 (which therefore offers
   the services used by layer 3).  Forwarding, when done by the
   swapping of short fixed length labels, occurs at layer 2 regardless
   of whether the label being examined is an ATM VPI/VCI, a frame
   relay DLCI, or an MPLS label.


   Fang, et al.                  Informational                      5


   MPLS/GMPLS Security framework
   February 2007

   Layer 3: the protocol layer at which IP and its associated routing
   protocols operate link layer synonymous with layer 2.

   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 which operate MPLS routing
   and forwarding and which are also in one Routing or Administrative
   Domain.

   MPLS edge node: an MPLS node that connects an MPLS domain with a
   node which is outside of the domain, either because it does not run
   MPLS, and/or because it is in a different domain.  Note that if an
   LSR has a neighboring host which is not running MPLS, that that LSR
   is an MPLS edge node.

   P: Provider Router. The 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.

   MPLS egress node: an MPLS edge node in its role in handling traffic
   as it leaves an MPLS domain

   MPLS ingress node: an MPLS edge node in its role in handling
   traffic as it enters an MPLS domain

   MPLS label: a label which is carried in a packet header, and which
   represents the packet's FEC

   MPLS node: a node which is running MPLS.  An MPLS node will be
   aware of MPLS control protocols, will operate one or more L3
   routing protocols, and will be capable of forwarding packets based
   on labels. An MPLS node may optionally be also capable of
   forwarding native L3 packets.

   MultiProtocol Label Switching (MPLS): an IETF working group and the
   effort associated with the working group



   Fang, et al.                  Informational                      6


   MPLS/GMPLS Security framework
   February 2007

   PE: Provider Edge device. The Provider Edge device is the equipment
   in the Service Provider's network that interfaces with the
   equipment in the customer's network.


   SP: Service Provider.

   VPN: Virtual Private Network. Restricted communication between a
   set of sites, making use of an IP backbone which is shared by
   traffic that is not going to or coming from those sites. [RFC4110].

   2.2. Acronyms and Abbreviations

      AS                Autonomous System
      ASBR      Autonomous System Border Router
      ATM       Asynchronous Transfer Mode
      BGP       Border Gateway Protocol
      FEC       Forwarding Equivalence Class
      GMPLS     Generalized Multi-Protocol Label Switching
      IGP       Interior Gateway Protocol
      IP        Internet Protocol
      LDP       Label Distribution Protocol
      L2        Layer 2
      L3        Layer 3
      LSP       Label Switched Path
      LSR       Label Switching Router
      MPLS      MultiProtocol Label Switching
      MP-BGP    Multi-Protocol BGP
      PCE       Path Calculation Element
      PSN       Packet-Switched Network
      RSVP-TE   Resource Reservation Protocol with Traffic Engineering
                     Extensions
      TTL       Time-To-Live
      VPN       Virtual Private Network


3. Security Reference Models
   This section defines a reference model for security in MPLS/GMPLS
   networks.

   A MPLS/GMPLS core network is defined here as the central network
   infrastructure (P and PE routers). A MPLS/GMPLS core network
   consists of one or more SP networks. All network elements in the
   core are under the operational control of one or more MPLS/GMPLS
   service providers. Even if the MPLS/GMPLS core is provided by
   several service providers, towards the end users it appears as a
   single zone of trust. However, when several service providers


   Fang, et al.                  Informational                      7


   MPLS/GMPLS Security framework
   February 2007

   provide together an MPLS/GMPLS core, each SP still needs to secure
   itself against the other SPs.

   A MPLS/GMPLS end user is a company, institution or residential
   client of the SP.

   This document defines each MPLS in a single domain 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   |
   | user          |  MPLS/GMPLS Core  |             user   |
   | site       +---\                 /XXX-----+     site   |
   +------------+    \               / XXX     +------------+
                      \-------------/  | |
                                       | |
                                       | +------\
                                       +--------/  "Internet"

        MPLS/GMPLS Core with user connections and Internet connection

   Figure 1: The MPLS/GMPLS trusted zone model


   The trusted zone defined is the MPLS/GMPLS core/network in a single
   AS within a single Service Provider.

   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 the figure 1) is
   defined. In the case of MPLS/GMPLS inter-provider connection, the
   trusted zone ends at the ASBR (marked with "B" in the figure 2) of
   the considered AS/provider.

   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 core
   (MPLS/GMPLS or non-MPLS/GMPLS), Internet, or end user access.

   In addition, neighbors may be trusted or untrusted. Neighbors may
   be authorized or unauthorized. Even though a neighbor may be
   authorized for communication, it may not be trusted. For example,

   Fang, et al.                  Informational                      8


   MPLS/GMPLS Security framework
   February 2007

   when connecting with another provider ASBRs to set up inter-AS
   LSPs, the other provider is considered as an untrusted but
   authorized neighbor.


                +---------------+        +----------------+
                |               |        |                |
                | MPLS/GMPLS   ASBR1----ASBR3  MPLS/GMPLS |
          CE1--PE1   Network    |        |     Network   PE2--CE2
                | Provider A   ASBR2----ASBR4  Provider B |
                |               |        |                |
                +---------------+        +----------------+


   For Provider A:
        Trusted Zone: Provider A MPSL/GMPLS network
        Trusted neighbor: PE1, ASBR1, ASBR2
        Authorized but untrusted neighbor: provider B
        Unauthorized neighbor: CE1, CE2

   Figure 2. MPLS/GMPLS trusted zone and authorized neighbor


   Security against threats that originate within the same trusted
   zone as their targets (for example, attacks from within the core
   network) is outside the scope of this document.

   Also outside the scope are all aspects of network security which
   are independent of whether a network is a MPLS/GMPLS network (for
   example, attacks from the Internet to a user web-server which is
   connected through the MPLS/GMPLS network will not be considered
   here, unless the way the MPLS/GMPLS network is provisioned could
   make a difference to the security of this user server).

4. Security Threats

   This section discusses the various network security threats that
   may endanger MPLS/GMPLS networks.  The discussion is limited to
   those threats that are unique to MPLS/GMPLS networks, or that
   affect MPLS/GMPLS network in unique ways.

   A successful attack on a particular MPLS/GMPLS network or on a
   service provider's MPLS/GMPLS infrastructure may cause one or more
   of the following ill effects:

    - Observation, modification, or deletion of provider/user data.
    - Replay of provider/user data.


   Fang, et al.                  Informational                      9


   MPLS/GMPLS Security framework
   February 2007

    - Injection of non-authentic data into a provider/user traffic
      stream.
    - Traffic pattern analysis on provider/user traffic.
    - Disruption of provider/user connectivity.
    - Degradation of provider service quality.

   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 service provider or persons working for it.
   - Other persons who obtain physical access to a MPLS/GMPLS service
   provider site.
   - Other persons who use social engineering methods to influence
   behavior of service provider personnel.
   - Users of the MPLS/GMPLS network itself, i.e. intra-VPN threats.
   (Such threats are beyond the scope of this document.)
   - Others i.e. attackers from the Internet at large.
   - Other service provider in the case of MPLS/GMPLS Inter-provider
   connection. The core of the other provider may or may not be using
   MPLS/GMPLS core.


   Given that security is generally a compromise between expense and
   risk, it is also useful to consider the likelihood of different
   attacks occurring.  There is at least a perceived difference in the
   likelihood of most types of attacks being successfully mounted in
   different environments, such as:

    - A MPLS/GMPLS inter-connecting with another provider's core
    - A MPLS/GMPLS 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 service provider to multiple cooperating providers 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.

   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 service provider with MPLS/GMPLS cores.

   Fang, et al.                  Informational                      10


   MPLS/GMPLS Security framework
   February 2007


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.

4.1.2.  LSP message interception

   This threat might be accomplished by monitoring network traffic,
   although it would require 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 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 in a DoS attack.  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 [RFC3036], is the control protocol used to set up
   non-TE MPLS tunnels.

   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 established LSPs, an
   attacker can launch a DoS attack in the form of a storm of LDP
   Hello messages and/or LDP TCP Syn messages, leading to high CPU
   utilization on the target router.


   Fang, et al.                  Informational                      11


   MPLS/GMPLS Security framework
   February 2007


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 service provider uses to provide various services,
   or against the general infrastructure of the service provider e.g.
   P routers or shared aspects of PE routers.  (Attacks against the
   general infrastructure are within the scope of this document only
   if the attack happens in relation with the MPLS/GMPLS
   infrastructure, otherwise is not 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 Service Provider MPLS/GMPLS Equipment Via
Management Interfaces

   This includes unauthorized access to service provider
   infrastructure equipment, for example to reconfigure the equipment
   or to extract information (statistics, topology, etc.) pertaining
   to the network.

4.1.7.  Social Engineering Attacks on the Service Provider
Infrastructure

   Attacks in which the service provider network is reconfigured or
   damaged, or in which confidential information is improperly
   disclosed, may be mounted through manipulation of service provider
   personnel. These types of attacks are MPLS/GMPLS-specific if they
   affect MPLS/GMPLS-serving mechanisms.


4.1.8.  Cross-connection of Traffic Between Users

   This refers to the event where 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.

   Fang, et al.                  Informational                      12


   MPLS/GMPLS Security framework
   February 2007

    - Any packet or frame being improperly delivered outside the VPN
      to which it belongs.

   Mis-connection or cross-connection of VPNs may be caused by service
   provider or equipment vendor error, or by the malicious action of
   an attacker. The breach may be physical (e.g. PE-CE links mis-
   connected) or logical (improper device configuration).

   Anecdotal evidence suggests that the cross-connection threat is one
   of the largest security concerns of users (or would-be users).

4.1.9.  Attacks Against User Routing Protocols

   This encompasses attacks against underlying routing protocols that
   are run by the service provider and that directly support the
   MPLS/GMPLS core.  (Attacks against the use of routing protocols for
   the distribution of backbone (non-VPN) routes are beyond the scope
   of this document.)  Specific attacks against popular routing
   protocols have been widely studied and described in [Beard].

4.1.10. 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 the 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)
    - L2TP
    - BGP-based membership discovery
    - Database-based membership discovery (e.g. RADIUS-based)

   Attacks might subvert or disrupt the activities of these protocols,
   for example via impersonation or DOS attacks.


   4.2. Attacks on the Data Plane

   This category encompasses attacks on the provider 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 the user site A to the user site B via an L2
   or L3 connection which may be some type of VPN.



   Fang, et al.                  Informational                      13


   MPLS/GMPLS Security framework
   February 2007

4.2.1.  Unauthorized Observation of Data Traffic

   This refers to "sniffing" provider/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 re-inserted as-is.

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 Non-Authentic Data Traffic: Spoofing and
Replay

   This refers to the insertion (or "spoofing") into the user packets
   that do not belong there, 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/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

   Fang, et al.                  Informational                      14


   MPLS/GMPLS Security framework
   February 2007

   the network e.g. link bandwidth, packet forwarding capacity,
   session capacity for various protocols, CPU power, 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 non-authentic data
   into the provider/end user network from the outside of the trusted
   zone. Potential results might be to exhaust the bandwidth available
   to that provider/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 a MPLS/GMPLS-specific issue,
   unless the attack is mounted by another MPLS/GMPLS network user
   from a privileged position.  (E.g. a MPLS/GMPLS network user might
   be able to monopolize network data plane resources and thus disrupt
   other users.)


5. Defensive Techniques for MPLS/GMPLS Networks

   The defensive techniques discussed in this document are intended to
   describe methods by which some security threats can be addressed.
   They are not intended as requirements for all MPLS/GMPLS
   implementations.  The MPLS/GMPLS provider should determine the
   applicability of these techniques to the provider's specific
   service offerings, and the end user may wish to assess the value of
   these techniques to the user's service requirements.

   The techniques discussed here include encryption, authentication,
   filtering, firewalls, access control, isolation, aggregation, and
   other techniques.

   Nothing is ever 100% secure.  Defense therefore involves protecting
   against those attacks that are most likely to occur and/or that
   have the most dire consequences if successful.  For those attacks
   that are protected against, absolute protection is seldom
   achievable; more often it is sufficient just to make the cost of a
   successful attack greater than what the adversary will be willing
   to expend.

   Successfully defending against an attack does not necessarily mean
   the attack must be prevented from happening or from reaching its
   target.  In many cases the network can instead be designed to
   withstand the attack.  For example, the introduction of non-
   authentic packets could be defended against by preventing their

   Fang, et al.                  Informational                      15


   MPLS/GMPLS Security framework
   February 2007

   introduction in the first place, or by making it possible to
   identify and eliminate them before delivery to the MPLS/GMPLS
   user's system.  The latter is frequently a much easier task.

   5.1. Cryptographic techniques

   MPLS/GMPLS defenses against a wide variety of attacks can be
   enhanced by the proper application of cryptographic techniques.
   These are the same cryptographic techniques which are applicable to
   general network communications.  In general, these techniques can
   provide confidentiality (encryption) of communication between
   devices, authentication of the identities of the devices, and can
   ensure that it will be detected if the data being communicated is
   changed during transit.


   Several aspects of authentication are addressed in some detail in a
   separate "Authentication" section.

   Encryption adds complexity to a service, and thus it may not be a
   standard offering within every user service. There are a few
   reasons why encryption may not be a standard offering within every
   user service. Encryption adds an additional computational burden to
   the devices performing encryption and decryption.  This may reduce
   the number of user connections which can be handled on a device or
   otherwise reduce the capacity of the device, potentially driving up
   the provider's costs.  Typically, configuring encryption services
   on devices adds to the complexity of the device configuration and
   adds incremental labor cost.  Packet sizes are typically increased
   when the packets are secured, increasing the network traffic load
   and adding to the likelihood of packet fragmentation with its
   increased overhead.  (This packet length increase can often be
   mitigated to some extent by data compression techniques, but at the
   expense of additional computational burden.) Finally, some
   providers may employ enough other defensive techniques, such as
   physical isolation or filtering/firewall techniques, that they may
   not perceive additional benefit from encryption techniques.

   The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider,
   and other parts of the network is a key element in determining the
   applicability of encryption for any specific MPLS/GMPLS
   implementation. In particular, it determines where encryption
   should be applied:
   -  If the data path between the user's site and the
      provider's PE is not trusted, then encryption may be used
      on the PE-CE link.
   -  If some part of the backbone network is not trusted,
      particularly in implementations where traffic may travel

   Fang, et al.                  Informational                      16


   MPLS/GMPLS Security framework
   February 2007

      across the Internet or multiple provider networks, then
      the PE-PE traffic may be encrypted.
   -  If the user does not trust any zone outside of its
      premises, it may require end-to-end or CE-CE encryption
      service. This service fits within the scope of this
      MPLS/GMPLS security framework when the CE is provisioned
      by the MPLS/GMPLS provider.
   -  If the user requires remote access to a its site from a
      system at a location which is not a customer location (for
      example, access by a traveler) there may be a requirement
      for encrypting the traffic between that system and an
      access point or at a customer site. If the MPLS/GMPLS
      provider provides the access point, then the customer must
      cooperate with the provider to handle the access control
      services for the remote users. These access control
      services are usually implemented using encryption, as
      well.

   Although CE-CE encryption provides confidentiality against third-
   party interception, if the MPLS/GMPLS provider has complete
   management control over the CE (encryption) devices, then it may be
   possible for the provider to gain access to the user's traffic or
   internal network. Encryption devices can potentially be configured
   to use null encryption, bypass encryption processing altogether, or
   provide some means of sniffing or diverting unencrypted traffic.
   Thus an implementation using CE-CE encryption needs to consider the
   trust relationship between the MPLS/GMPLS user and provider.
   MPLS/GMPLS users and providers may wish to negotiate a service
   level agreement (SLA) for CE-CE encryption that will provide an
   acceptable demarcation of responsibilities for management of
   encryption on the CE devices. The demarcation may also be affected
   by the capabilities of the CE devices. For example, the CE might
   support some partitioning of management, a configuration lock-down
   ability, or allow both parties to verify the configuration. In
   general, the MPLS/GMPLS user needs to have a fairly high level of
   trust that the MPLS/GMPLS provider will properly provision and
   manage the CE devices, if the managed CE-CE model is used.



5.1.1.  IPsec in MPLS/GMPLS

   IPsec [RFC4301] [RFC4302] [RFC4305] [RFC4306] [RFC2411] is the
   security protocol of choice for encryption at the IP layer (Layer
   3).  IPsec provides robust security for IP traffic between pairs of
   devices.  Non-IP traffic must be converted to IP (e.g. by
   encapsulation) in order to exploit IPsec.

   Fang, et al.                  Informational                      17


   MPLS/GMPLS Security framework
   February 2007



   In the MPLS/GMPLS model, IPsec can be employed to protect IP
   traffic between PEs, between a PE and a CE, or from CE to CE.  CE-
   to-CE IPsec may be employed in either a provider-provisioned or a
   user-provisioned model.  Likewise, encryption of data which is
   performed within the user's site is outside the scope of this
   document, since it is simply handled as user data by the MPLS/GMPLS
   core.

   IPsec does not itself specify an encryption algorithm.  It can use
   a variety of encryption algorithms, with various key lengths, such
   as AES encryption.  There are trade-offs between key length,
   computational burden, and the level of security of the encryption.
   A full discussion of these trade-offs is beyond the scope of this
   document.  In practice, any currently recommended IPsec encryption
   offers enough security to substantially reduce the likelihood of
   being directly targeted by an attacker; other weaker links in the
   chain of security are likely to be attacked first.  MPLS/GMPLS
   users may wish to use a Service Level Agreement (SLA) specifying
   the Service Provider's responsibility for ensuring data
   confidentiality, rather than analyzing the specific encryption
   techniques used in the MPLS/GMPLS service.

   For many of the MPLS/GMPLS provider's network control messages and
   some user requirements, cryptographic authentication of messages
   without encryption of the contents of the message may provide
   acceptable security.  Using IPsec, authentication of messages is
   provided by the Authentication Header (AH) or through the use of
   the Encapsulating Security Protocol (ESP) with authentication only.
   Where control messages require authentication but do not use IPsec,
   then other cryptographic authentication methods are available.
   Message authentication methods currently considered to be secure
   are based on hashed message authentication codes (HMAC) [RFC2104]
   implemented with a secure hash algorithm such as Secure Hash
   Algorithm 1 (SHA-1) [RFC3174].

   The currently recommended mechanism to provide a combination of
   confidentiality, data origin authentication, and connectionless
   integrity is the use of AES in CCM (Counter with CBC-MAC) mode
   (AES-CCM) [AES-CCM], with an explicit initialization vector (IV),
   as the IPsec ESP.

   MPLS/GMPLS which provide differentiated services based on traffic
   type may encounter some conflicts with IPsec encryption of traffic.
   Since encryption hides the content of the packets, it may not be
   possible to differentiate the encrypted traffic in the same manner
   as unencrypted traffic.  Although DiffServ markings are copied to

   Fang, et al.                  Informational                      18


   MPLS/GMPLS Security framework
   February 2007

   the IPsec header and can provide some differentiation, not all
   traffic types can be accommodated by this mechanism.


5.1.2.  Encryption for device configuration and management

   For configuration and management of MPLS/GMPLS devices, encryption
   and authentication of the management connection at a level
   comparable to that provided by IPsec is desirable.

   Several methods of transporting MPLS/GMPLS device management
   traffic offer security and confidentiality.
   -  Secure Shell (SSH) offers protection for TELNET [STD-8] or
      terminal-like connections to allow device configuration.
   -  SNMP v3 [STD62] provides encrypted and authenticated protection
      for SNMP-managed devices.
   -  Transport Layer Security (TLS) [RFC4346] and the closely-related
      Secure Sockets Layer (SSL)  are widely used for securing HTTP-
      based communication, and thus can provide support for most XML-
      and SOAP-based device management approaches.
   -  As of 2004, there is extensive work proceeding in several
      organizations (OASIS, W3C, WS-I, and others) on securing device
      management traffic within a "Web Services" framework, using a
      wide variety of security models, and providing support for
      multiple security token formats, multiple trust domains,
      multiple signature formats, and multiple encryption
      technologies.
   -  IPsec provides the services with security and confidentiality at
      the network layer. With regards to device management, its
      current use is primarily focused on in-band management of user-
      managed IPsec gateway devices.


5.1.3.  Cryptographic techniques for MPLS Pseudowires




5.1.4.  5.1.3  Security Considerations for MPLS Pseudowires

   In addition to IP traffic, MPLS networks may be used to transport
   other services such as Ethernet, ATM, frame relay, and TDM. This is
   done by setting up pseudowires (PWs) that tunnel the native service
   through the MPLS core by encapsulating at the edges. The PWE
   architecture is defined in [RFC3985].


   Fang, et al.                  Informational                      19


   MPLS/GMPLS Security framework
   February 2007


   PW tunnels may be set up using the PWE control protocol based on
   LDP [RFC4447], and thus security considerations for LDP will most
   likely be applicable to the PWE3 control protocol as well.

   PW user packets contain at least one MPLS label (the PW label) and
   may contain one or more MPLS tunnel labels.  After the label stack
   there is a four-byte control word (which is optional for some PW
   types), followed by the native service payload.  It must be
   stressed that encapsulation of MPLS PW packets in IP for the
   purpose of enabling use of IPsec mechanisms is not a valid option.

   The PW client traffic may be secured by use of mechanisms beyond
   the scope of this document.


5.1.5.  End-to-end vs. hop-by-hop encryption tradeoffs in
MPLS/GMPLS

   In MPLS/GMPLS, encryption could potentially be applied to the
   MPLS/GMPLS traffic at several different places.  This section
   discusses some of the tradeoffs in implementing encryption in
   several different connection topologies among different devices
   within a MPLS/GMPLS network.

   Encryption typically involves a pair of devices which encrypt the
   traffic passing between them.  The devices may be directly
   connected (over a single "hop"), or there may be intervening
   devices which transport the encrypted traffic between the pair of
   devices.  The extreme cases involve using encryption between every
   adjacent pair of devices along a given path (hop-by-hop), or using
   encryption only between the end devices along a given path (end-to-
   end).  To keep this discussion within the scope of this document,
   the latter ("end-to-end") case considered here is CE-to-CE rather
   than fully end-to-end.

   Figure 3 depicts a simplified topology showing the Customer Edge
   (CE) devices, the Provider Edge (PE) devices, and a variable number
   (three are shown) of Provider core (P) devices which might be
   present along the path between two sites in a single VPN, operated
   by a single service provider (SP).


   Site_1---CE---PE---P---P---P---PE---CE---Site_2

   Figure 3: Simplified topology traversing through MPLS/GMPLS core

   Fang, et al.                  Informational                      20


   MPLS/GMPLS Security framework
   February 2007



   Within this simplified topology, and assuming that P devices are
   not to be involved with encryption, there are four basic feasible
   configurations for implementing encryption on connections among the
   devices:

   1) Site-to-site (CE-to-CE) - Encryption can be configured between
   the two CE devices, so that traffic will be encrypted throughout
   the SP's network.

   2) Provider edge-to-edge (PE-to-PE) - Encryption can be configured
   between the two PE devices.  Unencrypted traffic is received at one
   PE from the customer's CE, then it is encrypted for transmission
   through the SP's network to the other PE, where it is decrypted and
   sent to the other CE.

   3) Access link (CE-to-PE) - Encryption can be configured between
   the CE and PE, on each side (or on only one side).

   4) Configurations 2 and 3 above can also be combined, with
   encryption running from CE to PE, then PE to PE, then PE to CE.

   Among the four feasible configurations, key tradeoffs in
   considering encryption include:

   - Vulnerability to link eavesdropping - assuming an attacker can
      observe the data in transit on the links, would it be protected
   by encryption?

   - Vulnerability to device compromise - assuming an attacker can get
   access to a device (or freely alter its configuration), would the
   data be protected?

   - Complexity of device configuration and management - given the
   number of sites per VPN customer as Nce and the number of PEs
   participating in a given VPN as Npe, how many device configurations
   need to be created or maintained, and how do those configurations
   scale?

   - Processing load on devices - how many encryption or decryption
   operations must be done given P packets? - This influences
   considerations of device capacity and perhaps end-to-end delay.

   - Ability of SP to provide enhanced services (QoS, firewall,
   intrusion detection, etc.) - Can the SP inspect the data in order
   to provide these services?


   Fang, et al.                  Informational                      21


   MPLS/GMPLS Security framework
   February 2007

   These tradeoffs are discussed for each configuration, below:

   1) Site-to-site (CE-to-CE)

   Link eavesdropping  - protected on all links
   Device compromise - vulnerable to CE compromise
   Complexity - single administration, responsible for one device per
        site (Nce devices), but overall configuration per VPN scales as
        Nce**2
   Processing load - on each of two CEs, each packet is either
        encrypted or decrypted (2P)
   Enhanced services - severely limited; typically only Diffserv
        markings are visible to SP, allowing some QoS services

   2) Provider edge-to-edge (PE-to-PE)

   Link eavesdropping  - vulnerable on CE-PE links; protected on SP's
        network links
   Device compromise - vulnerable to CE or PE compromise
   Complexity - single administration, Npe devices to configure.
        (Multiple sites may share a PE device so Npe is typically much
        less than Nce.)  Scalability of the overall configuration
        depends on the PPVPN type: If the encryption is separate per
        VPN context, it scales as Npe**2 per customer VPN.  If the
        encryption is per-PE, it scales as Npe**2 for all customer VPNs
        combined.
   Processing load - on each of two PEs, each packet is either
        encrypted or decrypted (2P)
   Enhanced services - full; SP can apply any enhancements based on
        detailed view of traffic

   3) Access link (CE-to-PE)

   Link eavesdropping  - protected on CE-PE link; vulnerable on SP's
        network links
   Device compromise - vulnerable to CE or PE compromise
   Complexity - two administrations (customer and SP) with device
        configuration on each side (Nce + Npe devices to configure) but
        since there is no mesh the overall configuration scales as Nce.
   Processing load - on each of two CEs, each packet is either
        encrypted or decrypted, plus on each of two PEs, each packet is
        either encrypted or decrypted (4P)
   Enhanced services - full; SP can apply any enhancements based on
        detailed view of traffic

   4) Combined Access link and PE-to-PE (essentially hop-by-hop)

   Link eavesdropping  - protected on all links

   Fang, et al.                  Informational                      22


   MPLS/GMPLS Security framework
   February 2007

   Device compromise - vulnerable to CE or PE compromise
   Complexity - two administrations (customer and SP) with device
        configuration on each side (Nce + Npe devices to configure).
        Scalability of the overall configuration depends on the PPVPN
        type: If the encryption is separate per VPN context, it scales
        as Npe**2 per customer VPN.  If the encryption is per-PE, it
        scales as Npe**2 for all customer VPNs combined.
   Processing load - on each of two CEs, each packet is either
        encrypted or decrypted, plus on each of two PEs, each packet is
        both encrypted and decrypted (6P)
   Enhanced services - full; SP can apply any enhancements based on
        detailed view of traffic

   Given the tradeoffs discussed above, a few conclusions can be made:

   - Configurations 2 and 3 are subsets of 4 that may be appropriate
   alternatives to 4 under certain threat models; the remainder of
   these conclusions compare 1 (CE-to-CE) vs. 4 (combined access links
   and PE-to-PE).

   - If protection from link eavesdropping is most important, then
   configurations 1 and 4 are equivalent.

   - If protection from device compromise is most important and the
   threat is to the CE devices, both cases are equivalent; if the
   threat is to the PE devices, configuration 1 is best.

   - If reducing complexity is most important, and the size of the
   network is very small, configuration 1 is the best.  Otherwise
   configuration 4 is the best because rather than a mesh of CE
   devices it requires a smaller mesh of PE devices.  Also under some
   PPVPN approaches the scaling of 4 is further improved by sharing
   the same PE-PE mesh across all VPN contexts. The scaling advantage
   of 4 may be increased or decreased in any given situation if the CE
   devices are simpler to configure than the PE devices, or vice-
   versa.

   - If the overall processing load is a key factor, then 1 is best.

   - If the availability of enhanced services support from the SP is
   most important, then 4 is best.

   As a quick overall conclusion, CE-to-CE encryption provides greater
   protection against device compromise but this comes at the cost of
   enhanced services and at the cost of operational complexity due to
   the Order(n**2) scaling of a larger mesh.



   Fang, et al.                  Informational                      23


   MPLS/GMPLS Security framework
   February 2007

   This analysis of site-to-site vs. hop-by-hop encryption tradeoffs
   does not explicitly include cases of multiple providers cooperating
   to provide a PPVPN service, public Internet VPN connectivity, or
   remote access VPN service, but many of the tradeoffs will be
   similar.


   5.2. Authentication

   In order to prevent security issues from some Denial-of-Service
   attacks or from malicious misconfiguration, it is critical that
   devices in the MPLS/GMPLS should only accept connections or control
   messages from valid sources.  Authentication refers to methods to
   ensure that message sources are properly identified by the
   MPLS/GMPLS devices with which they communicate.  This section
   focuses on identifying the scenarios in which sender authentication
   is required, and recommends authentication mechanisms for these
   scenarios.

   Cryptographic techniques (authentication and encryption) do not
   protect against some types of denial of service attacks,
   specifically resource exhaustion attacks based on CPU or bandwidth
   exhaustion. In fact, the processing required to decrypt and/or
   check authentication may in some cases increase the effect of these
   resource exhaustion attacks. Cryptographic techniques may however,
   be useful against resource exhaustion attacks based on exhaustion
   of state information (e.g., TCP SYN attacks).

   The MPLS user plane, as presently defined, is not amenable to
   source authentication as there are no source identifiers in the
   MPLS packet to authenticate. The MPLS label is only locally
   meaningful, and identifies a downstream semantic rather than an
   upstream source.

   When the MPLS payload carries identifiers that may be authenticated
   (e.g., IP packets), authentication may be carried out at the client
   level, but this does not help the MPLS service provider as these
   client identifiers belong to an external non-trusted network.




5.2.1.  Management System Authentication

   Management system authentication includes the authentication of a
   PE to a centrally-managed directory server, when directory-based

   Fang, et al.                  Informational                      24


   MPLS/GMPLS Security framework
   February 2007

   "auto-discovery" is used.  It also includes authentication of a CE
   to the configuration server, when a configuration server system is
   used.



5.2.2.  Peer-to-peer Authentication

   Peer-to-peer authentication includes peer authentication for
   network control protocols (e.g. LDP, BGP, etc.), and other peer
   authentication (i.e. authentication of one IPsec security gateway
   by another).


5.2.3.  Cryptographic techniques for authenticating identity

   Cryptographic techniques offer several mechanisms for
   authenticating the identity of devices or individuals. These
   include the use of shared secret keys, one-time keys generated by
   accessory devices or software, user-ID and password pairs, and a
   range of public-private key systems. Another approach is to use a
   hierarchical Certificate Authority system to provide digital
   certificates.

   This section describes or provides references to the specific
   cryptographic approaches for authenticating identity.  These
   approaches provide secure mechanisms for most of the authentication
   scenarios required in securing a MPLS/GMPLS network.

   5.3. Access Control techniques

   Access control techniques include packet-by-packet or packet-flow-
   by-packet-flow access control by means of filters and firewalls, as
   well as by means of admitting a "session" for a
   control/signaling/management protocol. Enforcement of access
   control by isolated infrastructure addresses is discussed in
   another section of this document.

   In this document, we distinguish between filtering and firewalls
   based primarily on the direction of traffic flow.  We define
   filtering as being applicable to unidirectional traffic, while a
   firewall can analyze and control both sides of a conversation.

   There are two significant corollaries of this definition:
   - Routing or traffic flow symmetry: A firewall typically requires
   routing symmetry, which is usually enforced by locating a firewall
   where the network topology assures that both sides of a

   Fang, et al.                  Informational                      25


   MPLS/GMPLS Security framework
   February 2007

   conversation will pass through the firewall.  A filter can operate
   upon traffic flowing in one direction, without considering traffic
   in the reverse direction.
   - Statefulness: Since it receives both sides of a conversation, a
   firewall may be able to interpret a significant amount of
   information concerning the state of that conversation, and use this
   information to control access.  A filter can maintain some limited
   state information on a unidirectional flow of packets, but cannot
   determine the state of the bi-directional conversation as precisely
   as a firewall.

5.3.1.  Filtering

   It is relatively common for routers to filter data packets. That
   is, routers can look for particular values in certain fields of the
   IP or higher level (e.g., TCP or UDP) headers. Packets which match
   the criteria associated with a particular filter may either be
   discarded or given special treatment.

   In discussing filters, it is useful to separate the Filter
   Characteristics which may be used to determine whether a packet
   matches a filter from the Packet Actions which are applied to those
   packets which match a particular filter.

   o Filter Characteristics

   Filter characteristics are used to determine whether a particular
   packet or set of packets matches a particular filter.

   In many cases filter characteristics may be stateless. A stateless
   filter is one which determines whether a particular packet matches
   a filter based solely on the filter definition, normal forwarding
   information (such as the next hop for a packet), and the
   characteristics of that individual packet. Typically stateless
   filters may consider the incoming and outgoing logical or physical
   interface, information in the IP header, and information in higher
   layer headers such as the TCP or UDP header. Information in the IP
   header to be considered may for example include source and
   destination IP address, Protocol field, Fragment Offset, and TOS
   field. Filters also may consider fields in the TCP or UDP header
   such as the Port fields as well as the SYN field in the TCP header.

   Stateful filtering maintains packet-specific state information, to
   aid in determining whether a filter has been met. For example, a
   device might apply stateless filters to the first fragment of a
   fragmented IP packet. If the filter matches, then the data unit ID
   may be remembered and other fragments of the same packet may then
   be considered to match the same filter. Stateful filtering is more

   Fang, et al.                  Informational                      26


   MPLS/GMPLS Security framework
   February 2007

   commonly done in firewalls, although firewall technology may be
   added to routers.

   o Actions based on Filter Results

   If a packet, or a series of packets, matches a specific filter,
   then there are a variety of actions which may be taken based on
   that filter match. Examples of such actions include:

     - Discard

   In many cases filters may be set to catch certain undesirable
   packets. Examples may include packets with forged or invalid source
   addresses, packets which are part of a DOS or DDOS attack, or
   packets which are trying to access resources which are not
   permitted (such as network management packets from an unauthorized
   source). Where such filters are activated, it is common to silently
   discard the packet or set of packets matching the filter. The
   discarded packets may of course also be counted and/or logged.

     - Set CoS

   A filter may be used to set the Class of Service associated with
   the packet.

     - Count packets and/or bytes

     - Rate Limit

   In some cases the set of packets which match a particular filter
   may be limited to a specified bandwidth. In this case packets
   and/or bytes would be counted, and would be forwarded normally up
   to the specified limit. Excess packets may be discarded, or may be
   marked (for example by setting a "discard eligible" bit in the IP
   ToS field or the MPLS EXP field).

     - Forward and Copy

   It is useful in some cases to forward some set of packets normally,
   but to also send a copy to a specified other address or interface.
   For example, this may be used to implement a lawful intercept
   capability, or to feed selected packets to an Intrusion Detection
   System.

   o Other Issues related to Use of Packet Filters

   There may be a very wide variation in the performance impact of
   filtering. This may occur both due to differences between

   Fang, et al.                  Informational                      27


   MPLS/GMPLS Security framework
   February 2007

   implementations, and also due to differences between types or
   numbers of filters deployed. For filtering to be useful, the
   performance of the equipment has to be acceptable in the presence
   of filters.

   The precise definition of "acceptable" may vary from service
   provider to service provider, and may depend upon the intended use
   of the filters. For example, for some uses a filter may be turned
   on all the time in order to set CoS, to prevent an attack, or to
   mitigate the effect of a possible future attack. In this case it is
   likely that the service provider will want the filter to have
   minimal or no impact on performance. In other cases, a filter may
   be turned on only in response to a major attack (such as a major
   DDOS attack). In this case a greater performance impact may be
   acceptable to some service providers.

   A key consideration with the use of packet filters is that they can
   provide few options for filtering packets carrying encrypted data.
   Since the data itself is not accessible, only packet header
   information or other unencrypted fields can be used for filtering.

5.3.2.  Firewalls

   Firewalls provide a mechanism for control over traffic passing
   between different trusted zones in the MPLS/GMPLS model, or between
   a trusted zone and an untrusted zone.  Firewalls typically provide
   much more functionality than filters, since they may be able to
   apply detailed analysis and logical functions to flows, and not
   just to individual packets.  They may offer a variety of complex
   services, such as threshold-driven denial-of-service attack
   protection, virus scanning, acting as a TCP connection proxy, etc.

   As with other access control techniques, the value of firewalls
   depends on a clear understanding of the topologies of the
   MPLS/GMPLS core network, the user networks, and the threat model.
   Their effectiveness depends on a topology with a clearly defined
   inside (secure) and outside (not secure).



   Firewalls may be applied to help protect MPLS/GMPLS core network
   functions from attacks originating from the Internet or from
   MPLS/GMPLS user sites, but typically other defensive techniques
   will be used for this purpose.

   Where firewalls are employed as a service to protect user VPN sites
   from the Internet, different VPN users, and even different sites of
   a single VPN user, may have varying firewall requirements.  The

   Fang, et al.                  Informational                      28


   MPLS/GMPLS Security framework
   February 2007

   overall PPVPN logical and physical topology, along with the
   capabilities of the devices implementing the firewall services,
   will have a significant effect on the feasibility and manageability
   of such varied firewall service offerings.

   Another consideration with the use of firewalls is that they can
   provide few options for handling packets carrying encrypted data.
   Since the data itself is not accessible, only packet header
   information, other unencrypted fields, or analysis of the flow of
   encrypted packets can be used for making decisions on accepting or
   rejecting encrypted traffic.


5.3.3.  Access Control to management interfaces

   Most of the security issues related to management interfaces can be
   addressed through the use of authentication techniques as described
   in the section on authentication.  However, additional security may
   be provided by controlling access to management interfaces in other
   ways.

   Management interfaces, especially console ports on MPLS/GMPLS
   devices, may be configured so they are only accessible out-of-band,
   through a system which is physically and/or logically separated
   from the rest of the MPLS/GMPLS infrastructure.

   Where management interfaces are accessible in-band within the
   MPLS/GMPLS domain, filtering or firewalling techniques can be used
   to restrict unauthorized in-band traffic from having access to
   management interfaces.  Depending on device capabilities, these
   filtering or firewalling techniques can be configured either on
   other devices through which the traffic might pass, or on the
   individual MPLS/GMPLS devices themselves.

   5.4. Use of Isolated Infrastructure

   One way to protect the infrastructure used for support of
   MPLS/GMPLS is to separate the resources for support of MPLS/GMPLS
   services from the resources used for other purposes (such as
   support of Internet services). In some cases this may make use of
   physically separate equipment for VPN services, or even a
   physically separate network.

   For example, PE-based L3 VPNs may be run on a separate backbone not
   connected to the Internet, or may make use of separate edge routers
   from those used to support Internet service. Private IP addresses



   Fang, et al.                  Informational                      29


   MPLS/GMPLS Security framework
   February 2007

   (local to the provider and non-routable over the Internet) are
   sometimes used to provide additional separation.


   5.5. Use of Aggregated Infrastructure

   In general it is not feasible to use a completely separate set of
   resources for support of each service. In fact, one of the main
   reasons for MPLS/GMPLS enabled services is to allow sharing of
   resources between multiple users, including multiple VPNs, etc.
   Thus even if certain services make use of a separate network from
   Internet services, nonetheless there will still be multiple
   MPLS/GMPLS users sharing the same network resources. In some cases
   MPLS/GMPLS services will share the use of network resources with
   Internet services or other services.

   It is therefore important for MPLS/GMPLS services to provide
   protection between resource utilization by different users. Thus a
   well-behaved MPLS/GMPLS user should be protected from possible
   misbehavior by other users. This requires that limits are placed on
   the amount of resources which can be used by any one VPN. For
   example, both control traffic and user data traffic may be rate
   limited. In some cases or in some parts of the network where a
   sufficiently large number of queues are available each VPN (and
   optionally each VPN and CoS within the VPN) may make use of a
   separate queue. Control-plane resources such as link bandwidth as
   well as CPU and memory resources may be reserved on a per-VPN
   basis.

   The techniques which are used to provision resource protection
   between multiple users served by the same infrastructure can also
   be used to protect MPLS/GMPLS networks and services from Internet
   services.

   In general the use of aggregated infrastructure allows the service
   provider to benefit from stochastic multiplexing of multiple bursty
   flows, and also may in some cases thwart traffic pattern analysis
   by combining the data from multiple users.

   5.6. Service Provider Quality Control Processes

   Deployment of provider-provisioned VPN services in general requires
   a relatively large amount of configuration by the service provider.
   For example, the service provider needs to configure which VPN each
   site belongs to, as well as QoS and SLA guarantees. This large
   amount of required configuration leads to the possibility of
   misconfiguration.


   Fang, et al.                  Informational                      30


   MPLS/GMPLS Security framework
   February 2007

   It is important for the service provider to have operational
   processes in place to reduce the potential impact of
   misconfiguration. CE to CE authentication may also be used to
   detect misconfiguration when it occurs.

   5.7. Deployment of Testable MPLS/GMPLS Service.

   This refers to solutions that can be readily tested to make sure
   they are configured correctly.  E.g. for a point-point connection,
   checking that the intended connectivity is working pretty much
   ensures that there is not connectivity to some unintended site.


6. Monitoring, Detection, and Reporting of Security Attacks

   MPLS/GMPLS network and service may be subject to attacks from a
   variety of security threats.  Many threats are described in another
   part of this document.  Many of the defensive techniques described
   in this document and elsewhere provide significant levels of
   protection from a variety of threats.  However, in addition to
   silently employing defensive techniques to protect against attacks,
   MPLS/GMPLS services can also add value for both providers and
   customers by implementing security monitoring systems which detect
   and report on any security attacks which occur, regardless of
   whether the attacks are effective.

   Attackers often begin by probing and analyzing defenses, so systems
   which can detect and properly report these early stages of attacks
   can provide significant benefits.

   Information concerning attack incidents, especially if available
   quickly, can be useful in defending against further attacks.  It
   can be used to help identify attackers and/or their specific
   targets at an early stage.  This knowledge about attackers and
   targets can be used to further strengthen defenses against specific
   attacks or attackers, or improve the defensive services for
   specific targets on an as-needed basis.  Information collected on
   attacks may also be useful in identifying and developing defenses
   against novel attack types.

   Monitoring systems used to detect security attacks in MPLS/GMPLS
   will typically operate by collecting information from the Provider
   Edge (PE), Customer Edge (CE), and/or Provider backbone (P)
   devices.  Security monitoring systems should have the ability to
   actively retrieve information from devices (e.g., SNMP get) or to
   passively receive reports from devices (e.g., SNMP notifications).
   The specific information exchanged will depend on the capabilities
   of the devices and on the type of VPN technology.  Particular care

   Fang, et al.                  Informational                      31


   MPLS/GMPLS Security framework
   February 2007

   should be given to securing the communications channel between the
   monitoring systems and the MPLS/GMPLS devices.

   The CE, PE, and P devices should employ efficient methods to
   acquire and communicate the information needed by the security
   monitoring systems.  It is important that the communication method
   between MPLS/GMPLS devices and security monitoring systems be
   designed so that it will not disrupt network operations.  As an
   example, multiple attack events may be reported through a single
   message, rather than allowing each attack event to trigger a
   separate message, which might result in a flood of messages,
   essentially becoming a denial-of-service attack against the
   monitoring system or the network.

   The mechanisms for reporting security attacks should be flexible
   enough to meet the needs of MPLS/GMPLS service providers,
   MPLS/GMPLS customers, and regulatory agencies, if applicable.  The
   specific reports will depend on the capabilities of the devices,
   the security monitoring system, the type of VPN, and the service
   level agreements between the provider and customer.

7. Service Provider General Security Requirements

   In this section, we discuss the security requirements that the
   provider may have in order to secure its MPLS/GMPLS network
   infrastructure, including LDP and RSVP-TE specific requirements.

   The MPLS/GMPLS service provider requirements defined here are the
   requirements for the MPLS/GMPLS core in the reference model.  The
   core network can be implemented with different types of network
   technologies, and each core network may use different technologies
   to provide the various services to users with different levels of
   offered security. Therefore, a MPLS/GMPLS service provider may
   fulfill any number of the security requirements listed in this
   section. This document does not state that a MPLS/GMPLS network
   must fulfill all of these requirements to be secure.

   These requirements are focused on: 1) how to protect the MPLS/GMPLS
   core from various attacks outside the core including network users,
   both accidentally and maliciously, 2) how to protect the end users.

   7.1. Protection within the Core Network

7.1.1.  Control Plane Protection - General

   - Protocol authentication within the core:



   Fang, et al.                  Informational                      32


   MPLS/GMPLS Security framework
   February 2007

   The network infrastructure must support mechanisms for
   authentication of the control plane. In MPLS/GMPLS core is used,
   LDP sessions may be authenticated by use TCP MD5, in addition, IGP
   and BGP authentication should also be considered. For a core
   providing Layer 2 services, PE to PE authentication may also be
   used via IPsec.

   With the cost of authentication coming down rapidly, the
   application of control plane authentication may not increase the
   cost of implementation for providers significantly, and will help
   to improve the security of the core. If the core is dedicated to
   MPLS/GMPLS enabled services and without any interconnects to third
   parties then this may reduce the requirement for authentication of
   the core control plane.


   - Elements protection

   Here we discuss means to hide the provider's infrastructure nodes.

   A MPLS/GMPLS provider may make the infrastructure routers (P and PE
   routers) unreachable from outside users and unauthorized internal
   users. For example, separate address space may be used for the
   infrastructure loopbacks.

   Normal TTL propagation may be altered to make the backbone look
   like one hop from the outside, but caution needs to be taken for
   loop prevention. This prevents the backbone addresses from being
   exposed through trace route; however this must also be assessed
   against operational requirements for end to end fault tracing.

   An Internet backbone core may be re-engineered to make Internet
   routing an edge function, for example, using MPLS label switching
   for all traffic within the core and possibly make the Internet a
   VPN within the PPVPN core itself. This helps to detach Internet
   access from PPVPN services.

   Separating control plane, data plane, and management plane
   functionality in terms of hardware and software may be implemented
   on the PE devices to improve security. This may help to limit the
   problems when attacked in one particular area, and may allow each
   plane to implement additional security measurement separately.

   PEs are often more vulnerable to attack than P routers, since PEs
   cannot be made unreachable to outside users by their very nature.
   Access to core trunk resources can be controlled on a per user
   basis by the application of inbound rate-limiting/shaping, this can


   Fang, et al.                  Informational                      33


   MPLS/GMPLS Security framework
   February 2007

   be further enhanced on a per Class of Service basis (see section
   8.2.3)

   In the PE, using separate routing processes for different services,
   for example, Internet and PPVPN service may help to improve the
   PPVPN security and better protect VPN customers. Furthermore, if
   the resources, such as CPU and Memory, may be further separated
   based on applications, or even individual VPNs, it may help to
   provide improved security and reliability to individual VPN
   customers.

7.1.2.  Control plane protection with RSVP-TE

   - RSVP Security Tools

   Isolation of the trusted domain is an important security mechanism
   with respect to RSVP, to ensure that an untrusted element cannot
   access a router of the trusted domain.  Though isolation is limited
   by the need to allow ASBR-ASBR communication for inter-AS LSPs.
   Isolation mechanisms might be bypassed by Router Alert IP packets.
   - A solution would consists in disabling the RSVP router alert mode
   and dropping all IP packets with the router alert option, or also
   to drop on an interface all incoming IP packets with port 46, which
   requires an access-list at the IP port level) or spoofed IP packets
   if anti-spoofing is not activated.

   RSVP security can be strengthened by deactivating RSVP on
   interfaces with neighbors who are not authorized to use RSVP, to
   protect against adjacent CE-PE attacks.  However, this does not
   really protect against DoS attacks, and does not protect against
   attacks on non-adjacent routers.  It has been demonstrated that
   substantial CPU resources are consumed simply by processing
   received RSVP packets, even if the RSVP process is deactivated for
   the specific interface on which the RSVP message is received.

   RSVP neighbor filtering at the protocol level, to restrict the set
   of neighbors that can send RSVP messages to a given router,
   protects against non-adjacent attacks.  However, this does not
   protect against DoS attacks, and does not effectively protect
   against spoofing of the source address of RSVP packets, if the
   filter relies on the neighbor's address within the RSVP message.

   RSVP neighbor filtering at the data plane level (access list to
   accept IP packet with port 46, only for specific neighbors). This
   requires Router Alert mode to be deactivated. This does not protect
   against spoofing.

   - Authentication for RSVP messages

   Fang, et al.                  Informational                      34


   MPLS/GMPLS Security framework
   February 2007


   One of the most powerful tools for protection against RSVP-based
   attacks is the use of authentication for RSVP messages, based on a
   secure message hash using a key shared by RSVP neighbors.  This
   protects against LSP creation attacks, at the expense of consuming
   significant CPU resources for digest computation.  In addition, if
   the neighboring RSVP speaker is compromised, it could be used to
   launch attacks using authenticated RSVP messages.

   Another valuable tool is RSVP message pacing, to limit the number
   of RSVP messages sent to a given neighbor during a given period.
   This allows blocking DoS attack propagation.

   In order to ensure continued effective operation of the MPLS router
   even in the case of an attack which is able to bypass packet
   filtering mechanisms such as Access Control Lists in the data
   plane, it is important that routers have some mechanisms to limit
   the impact of the attack.  There should be a mechanism to rate
   limit the amount of control plane traffic addressed to the router,
   per interface.  This should be configurable on a per-protocol
   basis, (and, ideally, on a per sender basis) to avoid an attacked
   protocol, or a given sender blocking all communications.  This
   requires the ability to filter and limit the rate of incoming
   messages of particular protocols, such as RSVP (filtering at the IP
   port level), and particular senders).  In addition, there should be
   a mechanism to limit CPU and memory capacity allocated to RSVP, so
   as to protect other control plane elements.  In order to limit the
   memory allocation, it will probably be necessary to limit the
   number of LSPs which can be set up.

   - limit the impact of an attack on control plane resources

   In order to ensure continued effective operation of the MPLS router
   even in the case of an attack which is able to bypass packet
   filtering mechanisms such as Access Control Lists in the data
   plane, it is important that routers have some mechanisms to limit
   the impact of the attack.  There should be a mechanism to rate
   limit the amount of control plane traffic addressed to the router,
   per interface.  This should be configurable on a per-protocol
   basis, (and, ideally, on a per sender basis) to avoid an attacked
   protocol, or a given sender blocking all communications.  This
   requires the ability to filter and limit the rate of incoming
   messages of particular protocols, such as RSVP (filtering at the IP
   port level, and particular senders).  In addition, there should be
   a mechanism to limit CPU and memory capacity allocated to RSVP, so
   as to protect other control plane elements.  In order to limit the
   memory allocation, it will probably be necessary to limit the
   number of LSPs which can be set up.

   Fang, et al.                  Informational                      35


   MPLS/GMPLS Security framework
   February 2007


7.1.3.  Control plane protection with LDP

   The approaches to protect MPLS routers against LDP-based attacks
   are very similar to those for RSVP, including isolation, protocol
   deactivation on specific interfaces, filtering of LDP neighbors at
   the protocol level, filtering of LDP neighbors at the data plane
   level (access list that filter the TCP & UDP LDP ports),
   authentication with message digest, rate limiting of LDP messages
   per protocol per sender and limiting all resources which might be
   allocated to LDP-related tasks.


7.1.4.  Data Plane Protection

   IPsec technologies can provide - encryption of secure provider or
   user data.

   In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is
   not provided as a basic feature. Mechanisms described in section 5
   can be used to secure the MPLS data plane to secure the data
   carried over MPLS core.


   7.2. Protection on the User Access Link

   Peer / Neighbor protocol authentication may be used to enhance
   security. For example, BGP MD5 authentication may be used to
   enhance security on PE-CE links using eBGP. In the case of Inter-
   provider connection, authentication / encryption mechanisms between
   ASes, such as IPsec, may be used.

   WAN link address space separation for different services (e.g. VPN
   and non-VPN) may be implemented to improve security in order to
   protect each service if multiple services are provided on the same
   PE platform.

   Firewall / Filtering: access control mechanisms can be used to
   filter out any packets destined for the service provider's
   infrastructure prefix or eliminate routes identified as
   illegitimate routes.

   Rate limiting may be applied to the user interface/logical
   interfaces against DDOS bandwidth attack. This is very helpful when
   the PE device is supporting both multi-services, especially when
   supporting VPN and Internet Services on the same physical
   interfaces through different logical interfaces.


   Fang, et al.                  Informational                      36


   MPLS/GMPLS Security framework
   February 2007

7.2.1.  Link Authentication

   Authentication mechanisms can be employed to validate site access
   to the network via fixed or logical (e.g. L2TP, IPsec) connections.
   Where the user wishes to hold the 'secret' associated to acceptance
   of the access and site into the VPN, then provider solutions
   require the flexibility for either direct authentication by the PE
   itself or interaction with a customer authentication server.
   Mechanisms are required in the latter case to ensure that the
   interaction between the PE and the customer authentication server
   is controlled e.g. limiting it simply to an exchange in relation to
   the authentication phase and with other attributes e.g. RADIUS
   optionally being filtered.

7.2.2.  Access Routing

   Mechanisms may be used to provide control at a routing protocol
   level e.g. RIP, OSPF, BGP between the CE and PE. Per neighbor and
   per VPN routing policies may be established to enhance security and
   reduce the impact of a malicious or non-malicious attack on the PE,
   in particular the following mechanisms should be considered:
    - Limiting the number of prefixes that may be advertised on
       a per access basis into the PE. Appropriate action may be
       taken should a limit be exceeded e.g. the PE shutting
       down the peer session to the CE
    - Applying route dampening at the PE on received routing
       updates
    - Definition of a per VPN prefix limit after which
       additional prefixes will not be added to the VPN routing
       table.

   In the case of Inter-provider connection, access protection, link
   authentication, and routing policies as described above may be
   applied. Both inbound and outbound firewall/filtering mechanism
   between ASes may be applied. Proper security procedures must be
   implemented in Inter-provider VPN interconnection to protect the
   providers' network infrastructure and their customer VPNs. This may
   be custom designed for each Inter-Provider VPN peering connection,
   and must be agreed by both providers.

7.2.3.  Access QoS

   MPLS/GMPLS providers offering QoS enabled services require
   mechanisms to ensure that individual accesses are validated against
   their subscribed QOS profile and as such gain access to core
   resources that match their service profile.  Mechanisms such as per
   Class of service rate limiting/traffic shaping on ingress to the
   MPLS/GMPLS core are one option in providing this level of control.

   Fang, et al.                  Informational                      37


   MPLS/GMPLS Security framework
   February 2007

   Such mechanisms may require the per Class of Service profile to be
   enforced either by marking, remarking or discard of traffic outside
   of profile.

7.2.4.  Customer service monitoring tools

   End users requiring visibility of the specific statistics on the
   core e.g. routing table, interface status, QoS statistics, impose
   requirements for mechanisms at the PE to both validate the incoming
   user and limit the views available to that particular user.
   Mechanisms should also be considered to ensure that such access
   cannot be used a means of a DOS attack (either malicious or
   accidental) on the PE itself. This could be accomplished through
   either separation of these resources within the PE itself or via
   the capability to rate-limit on a per physical/logical connection
   basis such traffic.


   7.3. General Requirements for MPLS/GMPLS Providers

   The MPLS/GMPLS providers must support the users' security
   requirements as listed in Section 7. Depending on the technologies
   used, these requirements may include:

   - User control plane separation - routing isolation
   - Protection against intrusion, DOS attacks and spoofing
   - Access Authentication
   - Techniques highlighted through this document identify
      methodologies for the protection of resources and
      MPLS/GMPLS infrastructure.

   Equipment hardware/software bugs leading to breaches in security
   are not within the scope of this document.


8. Inter-provider Security Requirements

   This section discusses security capabilities that are important at
   the MPLS/GMPLS Inter-provider connections, and at devices
   (including ASBR routers) which support the Inter-provider
   connections. The security capabilities stated in this section
   should be considered as complementary to security considerations
   addressed in the individual protocol specifications and/or security
   frameworks.

   Security vulnerabilities and exposures may be propagated across
   multiple networks because of security vulnerabilities arising in
   one peer's network. Threats to security originate from accidental,

   Fang, et al.                  Informational                      38


   MPLS/GMPLS Security framework
   February 2007

   administrative and intentional sources. Intentional threats include
   events such as spoofing and Denial of Service (DoS) attacks.
   The level and nature of threats, as well as security and
   availability requirements, may vary over time and from network to
   network. This section therefore discusses capabilities that need to
   be available in equipment deployed for support of the MPLS-ICI.
   Whether any particular capability is used in any one specific
   instance of the ICI is up to the service providers managing the
   provider edge equipment offering/using the ICI services.

   8.1. Control Plane Protection

   This section discusses capabilities for control plane protection,
   including protection of routing, signaling, and OAM capabilities.

8.1.1.  Authentication of Signaling Sessions

   Authentication of signaling sessions (i.e., BGP, LDP and RSVP-TE)
   and routing sessions (e.g., BGP) as well as OAM sessions across
   domain boundaries. Equipment must be able to support exchange of
   all protocol messages over a single IPsec tunnel, with NULL
   encryption and authentication, between the peering ASBRs. Support
   for TCP MD5 authentication for LDP and BGP and for RSVP-TE
   authentication must also be provided.

   Mechanisms to authenticate and validate a dynamic setup request
   MUST be available. For instance, if dynamic signaling of a TE-LSP
   or PW is crossing a domain boundary, there must be a way to detect
   whether the LSP source is who he claims to be and that he is
   allowed to connect to the destination.

   MD5 authentication support for all TCP-based protocols within the
   scope of the MPLS-ICI (i.e., LDP signaling, and BGP routing) and
   MD5 authentication for the RSVP-TE Integrity Object MUST be
   provided to interoperate with current practices.
   Equipment SHOULD be able to support exchange of all signaling and
   routing (LDP, RSVP-TE, and BGP) protocol messages over a single
   IPSec in tunnel or transport mode with authentication but with NULL
   encryption, between the peering ASBRs. IPSec, if supported, must be
   supported with HMAC-MD-5 and optionally SHA-1.  It is expected that
   authentication algorithms will evolve over time and support can be
   updated as needed.

   OAM Operations across the MPLS-ICI could also be the source of
   security threats on the provider infrastructure as well as the
   service offered over the MPLS-ICI. A large volume of OAM messages
   could overwhelm the processing capabilities of an ASBR if the ASBR
   is not probably protected. Maliciously-generated OAM messages could

   Fang, et al.                  Informational                      39


   MPLS/GMPLS Security framework
   February 2007

   also be used to bring down an otherwise healthy service (e.g., MPLS
   Pseudo Wire), and therefore effecting service security. MPLS-ping
   does not support authentication today and that support should be
   subject for future considerations. Bidirectional Forwarding
   Detection (BFD) however, does have support for carrying an
   authentication object. It also supports Time-To-Live (TTL)
   processing as anti-replay measure. Implementations conformant to
   this MPLS-ICI should support BFD authentication using MD-5 and must
   support the procedures for TTL processing.

8.1.2.  Protection against DoS attacks in the Control Plane

   Ability to prevent signaling and routing DOS attacks on the control
   plane per interface and provider. Such prevention may be provided
   by rate-limiting signaling and routing messages that can be sent by
   a peer provider according to a traffic profile and by guarding
   against malformed packets.

   Equipment MUST provide the ability to filter signaling, routing,
   and OAM packets destined for the device, and MUST provide the
   ability to rate limit such packets. Packet filters SHOULD be
   capable of being separately applied per interface, and SHOULD have
   minimal or no performance impact. For example, this allows an
   operator to filter or rate-limit signaling, routing, and OAM
   messages that can be sent by a peer provider and limit such traffic
   to a traffic profile.

   In the presence of a control plane DoS attack against an ASBR, the
   router SHOULD guarantee sufficient resources to allow network
   operators to execute network management commands to take corrective
   action, such as turning on additional filters or disconnecting an
   interface which is under attack. DoS attacks on the control plane
   SHOULD NOT adversely affect data plane performance.
   Equipment which supports BGP MUST support the ability to limit the
   number of BGP routes received from any particular peer.
   Furthermore, in the case of IPVPN, a router MUST be able to limit
   the number of routes learned from a BGP peer per IPVPN. In the case
   that a device has multiple BGP peers, it SHOULD be possible for the
   limit to vary between peers.

8.1.3.  Protection against Malformed Packets

   Equipment SHOULD be robust in the presence of malformed protocol
   packets. For example, malformed routing, signaling, and OAM packets
   should be treated in accordance to the relevant protocol
   specification.



   Fang, et al.                  Informational                      40


   MPLS/GMPLS Security framework
   February 2007

8.1.4.  Ability to Enable/Disable Specific Protocols

   Ability to drop any signaling or routing protocol messages when
   these messages are to be processed by the ASBR but the
   corresponding protocol is not enabled on that interface.

   Equipment must allow an administrator to enable or disable a
   protocol (default protocol is disabled unless administratively
   enable) on an interface basis.
   Equipment MUST be able to drop any signaling or routing protocol
   messages when these messages are to be processed by the ASBR but
   the corresponding protocol is not enabled on that interface. This
   dropping SHOULD NOT adversely affect data plane or control plane
   performance.

8.1.5.  Protection Against Incorrect Cross Connection

   Capability of detecting and locating faults in an LSP cross-connect
   MUST be provided. Such faults cause security violations as they
   result in directing traffic to the wrong destinations. This
   capability may rely on OAM functions.

   Equipment MUST support MPLS LSP Ping [RFC4379]. This MAY be used to
   verify end to end connectivity for the LSP (e.g., PW, TE Tunnel,
   VPN LSP, etc), and to verify PE to PE connectivity for L3 VPN
   services.

   When routing information is advertised from one domain to the
   other, there MUST be mechanisms that enable operators to guard
   against situations that result in traffic hijacking, black-holing,
   resource stealing (e.g., number of routes), etc. For instance, in
   the IPVPN case, an operator must be able to block routes based on
   associated route target attributes. In addition, mechanisms must
   exist to verify whether a route advertised by a peer for a given
   VPN is actually a valid route and whether the VPN has a site
   attached or reachable through that domain.

   Equipment (ASBRs and RRs) which supports operation of BGP MUST
   allow a means to restrict which Route Target attributes are sent to
   and accepted from a BGP peer across an ICI. Equipment (ASBRs, RRs)
   SHOULD also be able to inform the peer regarding which Route Target
   attributes it will accept from the peer.  This is due to the fact
   that a peer which sends an incorrect Route Target can result in
   incorrect cross-connection of VPNs. Also, sending inappropriate
   route targets to a peer may disclose confidential information.
   Further Security Consideration for inter-provider BGP/MPLS IPVPN
   operations are discussed in the IPVPN Annex.


   Fang, et al.                  Informational                      41


   MPLS/GMPLS Security framework
   February 2007

8.1.6.  Protection Against Spoofed Updates and Route
Advertisements

   Equipment MUST support signaling and routing.
   Equipment MUST support route filtering of routes received via a BGP
   peer sessions by applying policies that include one or more the
   following: AS path, BGP next hop, standard community and/or
   extended community.

8.1.7.  Protection of Confidential Information

   Ability to identify and prohibit messages that can reveal
   confidential information about network operation (e.g., performance
   OAM messages, MPLS-ping messages). Service Providers must have the
   flexibility of handling these messages at the ASBR.

   Equipment SHOULD provide the ability to identify and prohibit
   messages that can reveal confidential information about network
   operation (e.g., performance OAM messages, LSP Traceroute
   messages). Service Providers must have the flexibility of handling
   these messages at the ASBR. For example, equipment supporting LSP
   Traceroute MAY limit which addresses replies can be sent to.
   Note: This capability should be used with care. For example, if a
   service provider chooses to prohibit the exchange of LSP PING
   messages at the ICI, it may make it more difficult to debug
   incorrect cross-connection of LSPs or other problems.
   A provider may decide to progress these messages if they are
   incoming from a trusted provider and are targeted to specific
   agreed-on addresses. Another provider may decide to traffic police,
   reject or apply policies to these messages. Solutions must enable
   providers to control the information that is relayed to another
   provider about the path that an LSP takes. For example, in RSVP-TE
   record route object or MPLS-ping trace, a provider must be able to
   control the information contained in corresponding messages when
   sent to another provider.

8.1.8.  Protection Against over-provisioned number of RSVP-TE
LSPs and bandwidth reservation

   In addition to the control plane protection mechanisms listed in
   the previous section on Control plane protection with RSVP-TE, the
   ASBR needs mechanisms to both limit the number of LSPs that can be
   set up by other domains and to limit the amount of bandwidth that
   can be reserved. A provider's ASBR may deny the LSPs set up request
   or the bandwidth reservation request sent by another provider's the
   limits are reached.



   Fang, et al.                  Informational                      42


   MPLS/GMPLS Security framework
   February 2007

   8.2. Data Plane Protection

8.2.1.  Protection against DoS in the Data Plane
    This is provided earlier in this document.

8.2.2.  Protection against Label Spoofing

   Verification that a label received across an interconnect was
   actually assigned to the provider across the interconnect. If the
   label was not assigned to the provider, the packet MUST be dropped.

   Equipment MUST be able to verify that a label received across an
   interconnect was actually assigned to an LSP arriving from the
   provider across that interconnect. If the label was not assigned to
   an LSP which arrives at this router from the correct neighboring
   provider, the packet MUST be dropped.  This verification can be
   applied to the top label only. The top label is the received top
   label and every label that is exposed by label popping to be used
   for forwarding decisions.

   Equipment MUST provide the capability of dropping MPLS-labeled
   packets if all labels in the stack are not processed.  This
   provides carriers the capability of guaranteeing that every label
   that enters its domain from another carrier was actually assigned
   to that carrier.

   The following requirements are not directly reflected in this
   document but must be used as guidance for addressing further work.

   Solutions MUST NOT force operators to reveal reachability
   information to routers within their domains. <note, it is believed
   that this requirement is met via other requirements specified in
   this section plus the normal operation of IP routing, which does
   not reveal individual hosts.

   Mechanisms to authenticate and validate a dynamic setup request
   MUST be available. For instance, if dynamic signaling of a TE-LSP
   or PW is crossing a domain boundary, there must be a way to detect
   whether the LSP source is who he claims to be and that he is
   allowed to connect to the destination.

8.2.3.  Protection using ingress traffic policing and enforcement

   In the following diagram, we use a simple diagram to illustrate a
   potential security issue on the data plane issue across the MPLS
   interconnect:

   SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1

   Fang, et al.                  Informational                      43


   MPLS/GMPLS Security framework
   February 2007

   |         |                   |                          |
   |<  AS2  >|<MPLS interconnect>|<             AS1              >|

   Traffic flow direction is from SP2 to SP1

   Usually, the transit label used by ASBR2 is allocated by ASBR1
   which in turn advertises to ASB2 (downstream unsolicited or on-
   demand) and this label is used for a service context (VPN label, PW
   VC label, etc.) and this LSP is normally terminated at a forwarding
   table belonging to the service instance on PE (PE1) in SP1.

   In the example above, ASBR1 would not know if the label of an
   incoming packet from ASBR2 over the interconnect is VPN label or
   PSN label for AS1. So it is possible (though rare) that ASBR2 can
   be tempered such that the incoming label could match a PSN label
   (e.g., LDP) in AS1 - then this LSP would end up on the global plane
   of an infrastructure router (P or PE1) - this could invite a
   unidirectional attack on that P or PE1 the LSP terminates.

   To mitigate this threat, we SHOULD be able to do a forwarding path
   look-up for the label on an incoming packet from a interconnect in
   a LFIB space that is only intended for its own service context or
   provide a mechanism on the data plane that would ensure the
   incoming labels are what ASBR1 has allocated and advertised.

   Similar concept has been proposed in "Requirements for Multi-
   Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [PW-REQ].



9. Security Considerations


   Security considerations constitute the sole subject of this memo
   and hence are discussed throughout.  Here we recap what has been
   presented and explain at a very high level the role of each type of
   consideration in an overall secure MPLS/GMPLS system.

   The document describes a number of potential security threats.
   Some of these threats have already been observed occurring in
   running networks; others are largely theoretical at this time.  DOS
   attacks and intrusion

   Attacks from the Internet against service provider infrastructure
   have been seen to occur.  DOS "attacks" (typically not malicious)
   have also been seen in which CE equipment overwhelms PE equipment
   with high quantities or rates of packet traffic or routing


   Fang, et al.                  Informational                      44


   MPLS/GMPLS Security framework
   February 2007

   information.  Operational/provisioning errors are cited by service
   providers as one of their prime concerns.

   The document describes a variety of defensive techniques that may
   be used to counter the suspected threats.  All of the techniques
   presented involve mature and widely implemented technologies that
   are practical to implement.

   The document describes the importance of detecting, monitoring, and
   reporting attacks, both successful and unsuccessful.  These
   activities are essential for "understanding one's enemy",
   mobilizing new defenses, and obtaining metrics about how secure the
   MPLS/GMPLS network is.  As such they are vital components of any
   complete PPVPN security system.

   The document evaluates MPLS/GMPLS security requirements from a
   customer perspective as well as from a service provider
   perspective.  These sections re-evaluate the identified threats
   from the perspectives of the various stakeholders and are meant to
   assist equipment vendors and service providers, who must ultimately
   decide what threats to protect against in any given equipment or
   service offering.


10.     IANA Considerations
   TBD.


11.     Normative References

   [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
   Switching Architecture", RFC 3031, January 2001.

   [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching
   (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC3036] Andersson, et al., "LDP Specification", January 2001.

   [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
   Tunnels", December 2001.

   [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet
   Protocol," December 2005.

   [RFC4302] S. Kent, "IP Authentication Header," December 2005.




   Fang, et al.                  Informational                      45


   MPLS/GMPLS Security framework
   February 2007

   [RFC4305] D. Eastlake 3rd, "Cryptographic Algorithm Implementation
   Requirements for Encapsulating Security Payload (ESP) and
   Authentication Header (AH)", December 2005.

   [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2)
   Protocol",December 2005.

   [RFC4346] T. Dierks and E. Rescorla, "The Transport Layer Security
   (TLS) Protocol, Version 1.1," April 2006.

   [RFC4379] K. Kompella and G. Swallow, "Detecting Multi-Protocol
   Label Switched (MPLS) Data Plane Failures", February 2006.

   [RFC4447] Martini, et al., "Pseudowire Setup and Maintenance Using
   the Label Distribution Protocol (LDP)", April 2006.

   [STD62] "Simple Network Management Protocol, Version 3," RFCs 3411-
   3418, December 2002.

   [STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification",
   STD 8, May 1983.


12.     Informational References


   [AES-CCM] Housley, R., "Using AES CCM Mode With IPsec ESP", draft-
   ietf-ipsec-ciph-aes-ccm-05.txt, work in progress, November 2003.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997

   [Beard] D. Beard and Y. Yang, "Known Threats to Routing Protocols,"
   draft-beard-rpsec-routing-threats-00.txt, Oct. 2002. (Note, this is
   now approved as RFC, no number yet, http://www.ietf.org/internet-
   drafts/draft-ietf-rpsec-routing-threats-06.txt.

   [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
   for Message Authentication," February 1997.

   [RFC2411] R. Thayer, N. Doraswamy, R. Glenn,  "IP Security Document
   Roadmap," November 1998.

   [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm
   1 (SHA1)," September 2001.




   Fang, et al.                  Informational                      46


   MPLS/GMPLS Security framework
   February 2007

   [RFC3985] S. Bryant and P. Pate, "Pseudo Wire Emulation Edge-to-
   Edge (PWE3) Architecture", March 2005.

   [RFC4111] L. Fang, "Security Framework of Provider Provisioned
   VPN", RFC 4111, July 2005.

   [RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security
   Mechanisms for the Internet," December 2003.

   [RFC4110]  R. Callon and M. Suzuki, "A Framework for Layer 3
   Provider-Provisioned Virtual Private Networks (PPVPNs), July 2005.

   [MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical
   Specification", MFA2006.109.01, August 2006.

   [opsec efforts] C. Lonvick and D. Spak, "Security Best Practices
   Efforts and Documents", draft-ietf-opsec-efforts-05.txt, December
   2006.

   [PW-REQ] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi-
   Segment Pseudowire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-
   requirements-04.txt.



13.     Author's Addresses

   Luyuan Fang
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA 01719
   USA

   EMail: lufang@cisco.com

   Michael Behringer
   Cisco Systems, Inc.
   Village d'Entreprises Green Side
   400, Avenue Roumanille, Batiment T 3
   06410 Biot, Sophia Antipolis
   FRANCE

   Email: mbehring@cisco.com

   Ross Callon
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886

   Fang, et al.                  Informational                      47


   MPLS/GMPLS Security framework
   February 2007

   USA

   Email: rcallon@juniper.net

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   FRANCE

   Email: jeanlouis.leroux@francetelecom.com

   Raymond Zhang
   British Telecom
   2160 E. Grand Ave. El Segundo, CA 90025
   USA

   Email: raymond.zhang@bt.com

   Paul Knight
   Nortel
   600 Technology Park Drive
   Billerica, MA 01821

   EMail: paul.knight@nortel.com

   Yaakov (Jonathan) Stein
   RAD Data Communications
   24 Raoul Wallenberg St., Bldg C
   Tel Aviv  69719
   ISRAEL

   Email: yaakov_s@rad.com



Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.



   Fang, et al.                  Informational                      48


   MPLS/GMPLS Security framework
   February 2007

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Disclaimer

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.


14.     Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).











   Fang, et al.                  Informational                      49


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/