[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fang-mpls-tp-security-framework) 00 01 02 03 04 05 06 07 09 RFC 6941

MPLS Working Group                                          L. Fang, Ed.
Internet-Draft                                        Cisco Systems Inc.
Intended status: Informational                     B. Niven-Jenkins, Ed.
Expires: August 14, 2011                                         Velocix
                                                       S. Mansfield, Ed.
                                                                Ericsson
                                                                R. Zhang
                                                         British Telecom
                                                                N. Bitar
                                                                 Verizon
                                                              M. Daikoku
                                                        KDDI Corporation
                                                                 L. Wang
                                                                 Telenor

                                                       February 14, 2011


                       MPLS-TP Security Framework
                draft-ietf-mpls-tp-security-framework-00

Abstract

   This document provides a security framework for Multiprotocol Label
   Switching Transport Profile (MPLS-TP).  Extended from MPLS
   technologies, MPLS-TP introduces new OAM capabilities, transport
   oriented path protection mechanism, and strong emphasis on static
   provisioning supported by network management systems.  This document
   addresses the security aspects that are relevant in the context of
   MPLS-TP specifically.  It describes the security requirements for
   MPLS-TP; potential securities threats and migration procedures for
   MPLS-TP networks and MPLS-TP inter-connection to MPLS and GMPLS
   networks.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunication Union Telecommunication
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network.

   This Informational Internet-Draft is aimed at achieving IETF
   Consensus before publication as an RFC and will be subject to an IETF
   Last Call.

   [RFC Editor, please remove this note before publication as an RFC and
   insert the correct Streams Boilerplate to indicate that the published
   RFC has IETF Consensus.]

Status of this Memo



Fang, et al.              Expires August 14, 2011               [Page 1]

Internet-Draft         MPLS-TP Security Framework          February 2011


   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 14, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






















Fang, et al.              Expires August 14, 2011               [Page 2]

Internet-Draft         MPLS-TP Security Framework          February 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Background and Motivation  . . . . . . . . . . . . . . . .  4
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Requirement Language . . . . . . . . . . . . . . . . . . .  5
     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     1.5.  Structure of the document  . . . . . . . . . . . . . . . .  7
   2.  Security Reference Models  . . . . . . . . . . . . . . . . . .  7
     2.1.  Security Reference Model 1 . . . . . . . . . . . . . . . .  7
     2.2.  Security Reference Model 2 . . . . . . . . . . . . . . . .  9
     2.3.  Security Reference Model 3 . . . . . . . . . . . . . . . . 12
     2.4.  Trusted Zone Boundaries  . . . . . . . . . . . . . . . . . 13
   3.  Security Requirements for MPLS-TP  . . . . . . . . . . . . . . 14
   4.  Security Threats . . . . . . . . . . . . . . . . . . . . . . . 16
     4.1.  Attacks on the Control Plane . . . . . . . . . . . . . . . 18
     4.2.  Attacks on the Data Plane  . . . . . . . . . . . . . . . . 18
   5.  Defensive Techniques for MPLS-TP Networks  . . . . . . . . . . 19
     5.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 19
       5.1.1.  Management System Authentication . . . . . . . . . . . 19
       5.1.2.  Peer-to-Peer Authentication  . . . . . . . . . . . . . 20
       5.1.3.  Cryptographic Techniques for Authenticating
               Identity . . . . . . . . . . . . . . . . . . . . . . . 20
     5.2.  Access Control Techniques  . . . . . . . . . . . . . . . . 20
     5.3.  Use of Isolated Infrastructure . . . . . . . . . . . . . . 21
     5.4.  Use of Aggregated Infrastructure . . . . . . . . . . . . . 21
     5.5.  Service Provider Quality Control Processes . . . . . . . . 21
     5.6.  Verification of Connectivity . . . . . . . . . . . . . . . 21
   6.  Monitoring, Detection, and Reporting of Security Attacks . . . 21
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
















Fang, et al.              Expires August 14, 2011               [Page 3]

Internet-Draft         MPLS-TP Security Framework          February 2011


1.  Introduction

1.1.  Background and Motivation

   This document provides a security framework for Multiprotocol Label
   Switching Transport Profile (MPLS-TP).

   MPLS-TP Requirements and MPLS-TP Framework are defined in [RFC5654]
   and [RFC5921] respectively.  The intent of MPLS-TP development is to
   address the needs for transport evolution, the fast growing bandwidth
   demand accelerated by new packet based services and multimedia
   applications, from Ethernet Services, Layer 2 and Layer 3 VPNS,
   triple play to Mobile Access Network (RAN) backhaul, etc.  MPLS-TP is
   based on MPLS technologies to take advantage of the technology
   maturity, and it is required to maintain the transport
   characteristics.

   Focused on meeting transport requirements, MPLS-TP uses a subset of
   MPLS features, and introduces extensions to reflect the transport
   technology characteristics.  The added functionalities include in-
   band OAM, transport oriented path protection and recovery mechanisms,
   etc.  There is strong emphasis on static provisioning supported by
   Network Management System (NMS) or Operation Support System (OSS).
   There are also needs for MPLS-TP and MPLS interworking.

   The security aspects for the new extensions which are particularly
   designed for MPLS-TP need to be addressed.  The security models,
   requirements, threat and defense techniques previously defined in
   [RFC5921] can be used for the re-use of the existing functionalities
   in MPLS and GMPLS, but not sufficient to cover the new extensions.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunication Union Telecommunication
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network.

1.2.  Scope

   This document addresses the security aspects that are specific to
   MPLS-TP.  It intends to provide the security requirements for
   MPLS-TP; define security models which apply to various MPLS-TP
   deployment scenarios; identify the potential security threats and
   mitigation procedures for MPLS-TP networks and MPLS-TP inter-
   connection to MPLS or GMPLS networks.  Inter-AS and Inter-provider
   security for MPLS-TP to MPLS-TP connections or MPLS-TP to MPLS
   connections are discussed, where connections present higher security
   risk factors than connections for Intra-AS MPLS-TP.



Fang, et al.              Expires August 14, 2011               [Page 4]

Internet-Draft         MPLS-TP Security Framework          February 2011


   The general security analysis and guidelines for MPLS and GMPLS are
   addressed in [RFC5920], the content which has no new impact to
   MPLS-TP will not be repeated in this document.  Other general
   security issues regarding transport networks that are not specific to
   MPLS-TP are also out of scope.  Readers may also refer to the
   "Security Best Practices Efforts and Documents" Opsec Effort
   [opsec-efforts] and "Security Mechanisms for the Internet" [RFC3631]
   (if there are linkages to the Internet in the applications) for
   general network operation security considerations.  This document
   does not intend to define the specific mechanisms/methods that must
   be implemented to satisfy the security requirements.

   Issues/Areas to be addressed:

   o  G-Ach (control plane attack, DoS attack, message intercept, etc.)

   o  Spoofing ID

   o  Loopback

   o  NMS attack

   o  NMS and CP interaction

   o  MIP/MEP assignment and attacks

   o  Topology discovery

   o  Data plane authentication

   o  Label authentication

   o  DoS attack in Data Plane

   o  Performance Monitoring

1.3.  Requirement Language

   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].  Although
   this document is not a protocol specification, the use of this
   language clarifies the instructions to protocol designers producing
   solutions that satisfy the requirements set out in this document.







Fang, et al.              Expires August 14, 2011               [Page 5]

Internet-Draft         MPLS-TP Security Framework          February 2011


1.4.  Terminology

   This document uses MPLS, MPLS-TP, and Security specific terminology.
   Detailed definitions and additional terminology for MPLS-TP may be
   found in [RFC5654], [RFC5921], and MPLS/GMPLS security related
   terminology in [RFC5920].

   o  BFD: Bidirectional Forwarding Detection

   o  CE: Customer-Edge device

   o  DoS: Denial of Service

   o  DDoS: Distributed Denial of Service

   o  GAL: Generic Alert Label

   o  G-ACH: Generic Associated Channel

   o  GMPLS: Generalized Multi-Protocol Label Switching

   o  LDP: Label Distribution Protocol

   o  LSP: Label Switched Path

   o  MCC: Management Communication Channel

   o  MEP: Maintenance End Point

   o  MIP: Maintenance Intermediate Point

   o  MPLS: MultiProtocol Label Switching

   o  OAM: Operations, Administration, and Management

   o  PE: Provider-Edge device

   o  PSN: Packet-Switched Network

   o  PW: Pseudowire

   o  RSVP: Resource Reservation Protocol

   o  RSVP-TE: Resource Reservation Protocol with Traffic Engineering
      Extensions

   o  S-PE: Switching Provider Edge




Fang, et al.              Expires August 14, 2011               [Page 6]

Internet-Draft         MPLS-TP Security Framework          February 2011


   o  SSH: Secure Shell

   o  TE: Traffic Engineering

   o  TLS: Transport Layer Security

   o  T-PE: Terminating Provider Edge

   o  VPN: Virtual Private Network

   o  WG: Working Group of IETF

   o  WSS: Web Services Security

1.5.  Structure of the document

   Section 1: Introduction

   Section 2: MPLS-TP Security Reference Models

   Section 3: Security Requirements

   Section 4: Security Threats

   Section 5: Defensive/Mitigation techniques/procedures


2.  Security Reference Models

   This section defines a reference model for security in MPLS-TP
   networks.

   The models are built on the architecture of MPLS-TP defined in
   [RFC5921].  The Service Provider (SP) boundaries play an important
   role in determining the security models for any particular
   deployment.

   This document defines a trusted zone as being where a single SP has
   the total operational control over that part of the network.  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.

2.1.  Security Reference Model 1

   In the reference model 1, a single SP has total control of PE/T-PE to
   PE/T-PE of the MPLS-TP network.




Fang, et al.              Expires August 14, 2011              [Page 7]

Internet-Draft         MPLS-TP Security Framework          February 2011


   Security reference model 1(a)

   An MPLS-TP network with Single Segment Pseudowire (SS-PW) from PE to
   PE.  The trusted zone is PE1 to PE2 as illustrated in MPLS-TP
   Security Model 1 (a) (Figure 1).

          |<-------------- Emulated Service ---------------->|
          |                                                  |
          |          |<------- Pseudo Wire ------>|          |
          |          |                            |          |
          |          |    |<-- PSN Tunnel -->|    |          |
          |          V    V                  V    V          |
          V    AC    +----+                  +----+     AC   V
    +-----+    |     | PE1|==================| PE2|     |    +-----+
    |     |----------|............PW1.............|----------|     |
    | CE1 |    |     |    |                  |    |     |    | CE2 |
    |     |----------|............PW2.............|----------|     |
    +-----+  ^ |     |    |==================|    |     | ^  +-----+
          ^  |       +----+                  +----+     | |  ^
          |  |   Provider Edge 1         Provider Edge 2  |  |
              |  |                                            |  |
    Customer |                                            | Customer
    Edge 1   |                                            | Edge 2
             |                                            |
       Native service                               Native service

      ----Untrusted--- >|<------- Trusted Zone ----- >|<---Untrusted----

                       MPLS-TP Security Model 1 (a)

                                 Figure 1

   Security reference model 1(b)

   An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to
   T-PE.  The trusted zone is T-PE1 to T-PE2 in this model as
   illustrated in MPLS-TP Security Model 1 (b) (Figure 2).














Fang, et al.              Expires August 14, 2011               [Page 8]

Internet-Draft         MPLS-TP Security Framework          February 2011


       Native  |<------------Pseudowire-------------->|  Native
       Service |         PSN              PSN         |  Service
        (AC)   |     |<--cloud->|     |<-cloud-->|    |   (AC)
          |    V     V          V     V          V    V     |
          |    +----+           +-----+          +----+     |
       +----+ |    |TPE1|===========|SPE1 |==========|TPE2|     | +----+
       |    |------|..... PW.Seg't1.........PW.Seg't3.....|-------|    |
       | CE1| |    |    |           |     |          |    |     | |CE2 |
       |    |------|..... PW.Seg't2.........PW.Seg't4.....|-------|    |
       +----+ |    |    |===========|     |==========|    |     | +----+
        ^      +----+     ^     +-----+     ^    +----+       ^
        |                 |                 |                 |
        |              TP LSP            TP LSP               |
        |                                                     |
        |                                                     |
        |<---------------- Emulated Service ----------------->|

   -Untrusted >|<----------- Trusted Zone ---------- >|< Untrusted-

                       MPLS-TP Security Model 1 (b)

                                 Figure 2

2.2.  Security Reference Model 2

   In the reference model 2, a single SP does not have the total control
   of PE/T-PE to PE/T-PE of the MPLS-TP network, S-PE and T-PE may be
   under the control of different SPs or their customers or may not be
   trusted for some other reason.  The MPLS-TP network is not contained
   within a single trusted zone.

   Security Reference Model 2(a)

   An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to
   T-PE.  The trusted zone is T-PE1 to S-PE, as illustrated in MPLS-TP
   Security Model 2 (a) (Figure 3).















Fang, et al.              Expires August 14, 2011               [Page 9]

Internet-Draft         MPLS-TP Security Framework          February 2011


            Native  |<------------Pseudowire-------------->|  Native
            Service |         PSN              PSN         |  Service
             (AC)   |    |<cloud->|     |<-cloud-->|    |   (AC)
               |    V    V        V     V          V    V     |
               |    +----+         +----+          +----+     |
        +----+ |    |TPE1|=========|SPE1|==========|TPE2|     | +----+
        |    |------|.....PW.Seg't1......PW.Seg't3.... .|-------|    |
        | CE1| |    |    |         |    |          |    |     | |CE2 |
        |    |------|.....PW.Seg't2......PW.Seg't4..... |-------|    |
        +----+ |    |    |=========|    |==========|    |     | +----+
             ^      +----+    ^    +----+     ^    +----+       ^
             |                |               |                 |
             |              TP LSP            TP LSP            |
             |                                                  |
             |<---------------- Emulated Service -------------->|

    --Untrusted-- >|<-- Trusted Zone -->|< ------Untrusted--------

                       MPLS-TP Security Model 2 (a)

                                 Figure 3

   Security Reference Model 2(b)

   An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to
   T-PE.  The trusted zone is the S-PE, as illustrated in MPLS-TP
   Security Model 2 (b) (Figure 4).
























Fang, et al.              Expires August 14, 2011             [Page 10]

Internet-Draft         MPLS-TP Security Framework          February 2011


            Native  |<------------Pseudowire-------------->|  Native
            Service |         PSN              PSN         |  Service
             (AC)   |    |<cloud->|     |<-cloud-->|    |   (AC)
               |    V    V        V     V          V    V     |
               |    +----+         +----+          +----+     |
        +----+ |    |TPE1|=========|SPE1|==========|TPE2|     | +----+
        |    |------|.....PW.Seg't1......PW.Seg't3.... .|-------|    |
        | CE1| |    |    |         |    |          |    |     | |CE2 |
        |    |------|.....PW.Seg't2......PW.Seg't4..... |-------|    |
        +----+ |    |    |=========|    |==========|    |     | +----+
             ^      +----+    ^    +----+     ^    +----+       ^
             |                |               |                 |
             |              TP LSP            TP LSP            |
             |                                                  |
             |<---------------- Emulated Service -------------->|

    --------Untrusted----------->|<--->|< ------Untrusted--------
                                   Trusted
                                     Zone

                       MPLS-TP Security Model 2 (b)

                                 Figure 4

   Security Reference Model 2(c)

   An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from
   different Service Providers with inter-provider PW connections.  The
   trusted zone is T-PE1 to S-PE3, as illustrated in MPLS-TP Security
   Model 2 (c) (Figure 5).





















Fang, et al.              Expires August 14, 2011              [Page 11]

Internet-Draft         MPLS-TP Security Framework          February 2011


   Native  |<-------------------- PW15 --------------------->| Native
    Layer  |                                                 |  Layer
  Service  |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    | Service
     (AC1) V    V   LSP   V    V   LSP   V    V   LSP   V    V  (AC2)
               +----+   +-+   +----+         +----+   +-+   +----+
  +---+    |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|   +---+
  |   |    |    |=========|    |=========|    |=========|    |   |   |
  |CE1|----|........PW1........|...PW3...|........PW5........|---|CE2|
  |   |    |    |=========|    |=========|    |=========|    |   |   |
  +---+    | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |   +---+
               +----+   +-+   +----+         +----+   +-+   +----+

           |<- Subnetwork 123->|         |<- Subnetwork XYZ->|

    Untrusted->|<- Trusted Zone - >| <-------------Untrusted------------

                       MPLS-TP Security Model 2 (c)

                                 Figure 5

2.3.  Security Reference Model 3

   An MPLS-TP network with a Transport LSP from PE1 to PE2.  The trusted
   zone is PE1 to PE2 as illustrated in MPLS-TP Security Model 3 (a)
   (Figure 6).


























Fang, et al.              Expires August 14, 2011              [Page 12]

Internet-Draft         MPLS-TP Security Framework          February 2011


            |<------------- Client Network Layer --------------->|
            |                                                    |
            |          |<----------- Packet --------->|          |
            |          |         Transport Service    |          |
            |          |                              |          |
            |          |                              |          |
            |          |          Transport           |          |
            |          |    |<------ LSP ------->|    |          |
            |          V    V                    V    V          |
            V    AC    +----+      +-----+       +----+     AC   V
      +-----+    |     | PE1|=======\   /========| PE2|     |    +-----+
      |     |----------|..Svc LSP1.| \ / |............|----------|     |
      | CE1 |    |     |    |      |  X  |       |    |     |    | CE2 |
      |     |----------|..Svc LSP2.| / \ |............|----------|     |
      +-----+  ^ |     |    |=======/   \========|    |     | ^  +-----+
            ^  |       +----+  ^   +-----+       +----+     | |  ^
            |  |      Provider |       ^         Provider     |  |
            |  |       Edge 1  |       |          Edge 2      |  |
      Customer |               |    P Router                  | Customer
       Edge 1  |             TE LSP                           |  Edge 2
               |                                              |
               |                                              |
         Native service                                 Native service

    -----Untrusted---- >|< ----- Trusted Zone ----- >|<----Untrusted----

                       MPLS-TP Security Model 3 (a)

                                 Figure 6

2.4.  Trusted Zone Boundaries

   The boundaries of a trusted zone should be carefully defined when
   analyzing the security properties of each individual network, as
   illustrated from the above, the security boundaries determine which
   reference model should be applied to the use case analysis.

   A key requirement of MPLS-TP networks is that the security of the
   trusted zone MUST NOT be compromised by interconnecting one SP's
   MPLS-TP or MPLS infrastructure with another SP's core, T-PE devices,
   or end users.

   In addition, neighboring nodes in the network may be trusted or
   untrusted.  Neighbors may also be authorized or unauthorized.  Even
   though a neighbor may be authorized for communication, it may not be
   trusted.  For example, when connecting with another provider's S-PE
   to set up Inter-AS LSPs, the other provider is considered to be
   untrusted but may be authorized for communication.



Fang, et al.              Expires August 14, 2011              [Page 13]

Internet-Draft         MPLS-TP Security Framework          February 2011


                +---------------+        +----------------+
                |               |        |                |
                |    MPLS-TP   S-PE1----S-PE3  MPLS-TP    |
        CE1--T-PE1   Network    |        |     Network  T-PE2--CE2
                |    Provider  S-PE2----S-PE4  Provider   |
                |       A       |        |        B       |
                +---------------+        +----------------+

           For Provider A:
                   Trusted Zone: Provider A MPLS-TP network
                   Trusted neighbors: T-PE1, S-PE1, S-PE2
                   Authorized but untrusted neighbor: Provider B
                   Unauthorized neighbors: CE2

               MPLS-TP trusted zone and authorized neighbor

                                 Figure 7


3.  Security Requirements for MPLS-TP

   This section covers security requirements for securing MPLS-TP
   network infrastructure.  The MPLS-TP network can be operated without
   a control plane or via dynamic control planes protocols.  The
   security requirements related to new MPLS-TP OAM, recovery
   mechanisms, MPLS-TP and MPLS interconnection, and MPLS-TP specific
   operational requirements will be addressed in this section.

   A service provider may choose the implementation options which are
   the best fit for his/her network operation.  This document does not
   state that a MPLS/GMPLS network must fulfill all security
   requirements listed to be secure.

   These requirements are focused on: 1) how to protect the MPLS-TP
   network from various attacks originating outside the trusted zone
   including those from network users, both accidental and malicious; 2)
   prevention of operational errors resulting from misconfiguration
   within the trusted zone.

   o  MPLS-TP MUST support the physical and logical separation of data
      plane from the control plane and management plane.  That is, if
      the control plane or/and management plane are attacked and cannot
      function normally, the data plane should continue to forward
      packets without being impacted.

   o  MPLS-TP MUST support static provisioning of MPLS-TP LSP and PW
      with or without NMS/OSS, without using control protocols.  This is
      particularly important in the case of security model 2(a)



Fang, et al.              Expires August 14, 2011              [Page 14]

Internet-Draft         MPLS-TP Security Framework          February 2011


      (Figure 3) and security model 2(b) (Figure 4) where some or all
      T-PEs are not in the trusted zone, and in the inter-provider cases
      in security model 2(c) (Figure 5) when the connecting S-PE is in
      the untrusted zone.

   o  MPLS-TP MUST support non-IP path options in addition to IP
      loopback option.  Non-IP path options when used in security model
      2 (Section 2.2) may help to lower the potential risk of attack on
      the S-PE/T-PE in the trusted zone.

   o  MPLS-TP MUST support authentication of any control protocol used
      for an MPLS-TP network, as well as for MPLS-TP network to dynamic
      MPLS network inter-connection.

   o  MPLS-TP MUST support mechanisms to prevent Denial of Service (DOS)
      attacks via any in-band OAM or G-ACh/GAL.

   o  MPLS-TP MUST support hiding of the Service Provider infrastructure
      for all reference models regardless of whether the network(s) are
      using static configuration or a dynamic control plane.

   o  Security management requirements from [RFC5951]:

      *  MPLS-TP MUST support management communication channel (MCC)
         security.

      *  Secure communication channels MUST be supported for all network
         traffic and protocols used to support management functions.
         This MUST include protocols used for configuration, monitoring,
         configuration backup, logging, time synchronization,
         authentication, and routing.

      *  The MCC MUST support application protocols that provide
         confidentiality and data integrity protection.

      *  The MCC MUST support the use of open cryptographic algorithms
         [RFC3871].

      *  The MCC MUST support authentication to ensure that management
         connectivity and activity is only from authenticated entities.

      *  The MCC MUST support port access control.

      *  Distributed Denial of Service: It is possible to lessen the
         impact and potential for DoS and DDoS by using secure
         protocols, turning off unnecessary processes, logging and
         monitoring, and ingress filtering.  [RFC4732] provides
         background on DOS in the context of the Internet.



Fang, et al.              Expires August 14, 2011              [Page 15]

Internet-Draft         MPLS-TP Security Framework          February 2011


   o  MPLS-TP MUST provide protection from operational error.  Due to
      the extensive use of static provisioning with or without NMS and
      OSS, the prevention of configuration errors should be addressed as
      major security requirements.


4.  Security Threats

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

   A successful attack on a particular MPLS-TP network or on a SP's
   MPLS-TP infrastructure may cause one or more of the following ill
   effects:

   1.  Observation (including traffic pattern analysis), modification,
       or deletion of a provider's or user's data, as well as replay or
       insertion of non-authentic data into a provider's or user's data
       stream.  These types of attacks apply to MPLS-TP traffic
       regardless of how the LSP or PW is set up in a similar way to how
       they apply to MPLS traffic regardless how the LSP is set up.

   2.  Attacks on GAL label, BFD messages:

       1.  GAL label or BFD label manipulation: including insertion of
           false label or messages, or modification, or removal the GAL
           labels or messages by attackers.

       2.  DOS attack through in-band OAM G-ACH/GAL, and BFD messages.

   3.  Disruption of a provider's and/or user's connectivity, or
       degradation of a provider's service quality.

       1.  Provider connectivity attacks:

           +  In the case of NMS is used for LSP set-up, the attacks
              would be through the attack of NMS.

           +  In the case of dynamic is used for dynamic provisioning,
              the attack would be on dynamic control plane.  Most
              aspects are addressed in [RFC5920].

       2.  User connectivity attack.  This would be similar as PE/CE
           access attack in typical MPLS networks, addressed in
           [RFC5920].




Fang, et al.              Expires August 14, 2011              [Page 16]

Internet-Draft         MPLS-TP Security Framework          February 2011


   4.  Probing a provider's network to determine its configuration,
       capacity, or usage.  These types of attack can happen through NMS
       attacks in the case of static provisioning, or through control
       plane attacks as in dynamic MPLS networks.  It can also be
       combined attacks.

   It is useful to consider that threats, whether malicious or
   accidental, may come from different categories of sources.  For
   example they may come from:

   o  Other users whose services are provided by the same MPLS-TP core.

   o  The MPLS-TP SP or persons working for it.

   o  Other persons who obtain physical access to a MPLS-TP SP's site.

   o  Other persons who use social engineering methods to influence the
      behavior of a SP's personnel.

   o  Users of the MPLS-TP network itself.

   o  Others, e.g., attackers from the other sources, Internet if
      connected.

   o  Other SPs in the case of MPLS-TP Inter-provider connection.  The
      provider may or may not be using MPLS-TP.

   o  Those who create, deliver, install, and maintain software for
      network equipment.

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

   o  A MPLS-TP network inter-connecting with another provider's core

   o  A MPLS-TP configuration transiting the public Internet

   Most types of attacks become easier to mount and hence more likely as
   the shared infrastructure via which service is provided expands from
   a single SP to multiple cooperating SPs to the global Internet.
   Attacks that may not be of sufficient likeliness to warrant concern
   in a closely controlled environment often merit defensive measures in
   broader, more open environments.  In closed communities, it is often
   practical to deal with misbehavior after the fact: an employee can be
   disciplined, for example.



Fang, et al.              Expires August 14, 2011              [Page 17]

Internet-Draft         MPLS-TP Security Framework          February 2011


   The following sections discuss specific types of exploits that
   threaten MPLS-TP networks.

4.1.  Attacks on the Control Plane

   o  MPLS-TP LSP creation by an unauthorized element

   o  LSP message interception

   o  Attacks on G-Ach

   o  Attacks against LDP

   o  Attacks against RSVP-TE

   o  Attacks against GMPLS

   o  Denial of Service Attacks on the Network Infrastructure

   o  Attacks on the SP's MPLS/GMPLS Equipment via Management Interfaces

   o  Social Engineering Attacks on the SP's Infrastructure

   o  Cross-Connection of Traffic between Users

   o  Attacks against Routing Protocols

   o  Other Attacks on Control Traffic

4.2.  Attacks on the Data Plane

   This category encompasses attacks on the provider's or end user's
   data.  Note that from the MPLS-TP network end user's point of view,
   some of this might be control plane traffic, e.g. routing protocols
   running from user site A to user site B via IP or non-IP connections,
   which may be some type of VPN.

   o  Unauthorized Observation of Data Traffic

   o  Modification of Data Traffic

   o  Insertion of Inauthentic Data Traffic: Spoofing and Replay

   o  Unauthorized Deletion of Data Traffic

   o  Unauthorized Traffic Pattern Analysis





Fang, et al.              Expires August 14, 2011              [Page 18]

Internet-Draft         MPLS-TP Security Framework          February 2011


   o  Denial of Service Attacks

   o  Misconnection


5.  Defensive Techniques for MPLS-TP 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-TP
   implementations.  The MPLS-TP 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 operational
   environment determines the security requirements.  Therefore,
   protocol designers need to provide a full set of security services,
   which can be used where appropriate.

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

5.1.  Authentication

   To prevent security issues arising from some DoS attacks or from
   malicious or accidental misconfiguration, it is critical that devices
   in the MPLS-TP 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-TP 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.

5.1.1.  Management System Authentication

   Management system authentication includes the authentication of a PE
   to a centrally-managed network management or directory server when
   directory-based "auto-discovery" is used.  It also includes
   authentication of a CE to the configuration server, when a
   configuration server system is used.

   Authentication should be bi-directional, including PE or CE to
   configuration server authentication for PE or CE to be certain it is
   communicating with the right server.







Fang, et al.              Expires August 14, 2011              [Page 19]

Internet-Draft         MPLS-TP Security Framework          February 2011


5.1.2.  Peer-to-Peer Authentication

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

   Authentication should be bi-directional, including S-PE, T-PE, PE or
   CE to configuration server authentication for PE or CE to be certain
   it is communicating with the right server.

5.1.3.  Cryptographic Techniques for Authenticating Identity

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

5.2.  Access Control Techniques

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

   The Optical Internetworking Forum has done relevant work on
   protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc.
   See Security for Management Interfaces to Network Elements
   [OIF-SMI-01.0], and Addendum to the Security for Management
   Interfaces to Network Elements [OIF-SMI-02.1].  See also the work in
   the ISMS WG.

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

   Where management interfaces are accessible in-band within the MPLS-TP
   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-TP
   devices themselves.





Fang, et al.              Expires August 14, 2011              [Page 20]

Internet-Draft         MPLS-TP Security Framework          February 2011


5.3.  Use of Isolated Infrastructure

   One way to protect the infrastructure used for support of MPLS-TP is
   to separate the resources for support of MPLS-TP services from the
   resources used for other purposes.

5.4.  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-TP enabled services is to allow sharing of resources
   between multiple services and multiple users.  Thus, even if certain
   services use a separate network from Internet services, nonetheless
   there will still be multiple MPLS-TP users sharing the same network
   resources.

   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.  However, service providers
   must minimize security risks introduced from any individual service
   or individual users.

5.5.  Service Provider Quality Control Processes

5.6.  Verification of Connectivity

   In order to protect against deliberate or accidental misconnection,
   mechanisms can be put in place to verify both end-to-end connectivity
   and hop-by-hop resources.  These mechanisms can trace the routes of
   LSPs in both the control plane and the data plane.


6.  Monitoring, Detection, and Reporting of Security Attacks

   MPLS-TP network and service may be subject to attacks from a variety
   of security threats.  Many threats are described in the Security
   Requirements (Section 3) Section 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 employing defensive techniques silently to protect
   against attacks, MPLS-TP services can also add value for both
   providers and customers by implementing security monitoring systems
   to detect and report on any security attacks, regardless of whether
   the attacks are effective.

   Attackers often begin by probing and analyzing defenses, so systems
   that can detect and properly report these early stages of attacks can



Fang, et al.              Expires August 14, 2011              [Page 21]

Internet-Draft         MPLS-TP Security Framework          February 2011


   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 or their specific targets at an
   early stage.  This knowledge about attackers and targets can be used
   to strengthen defenses against specific attacks or attackers, or to
   improve the defenses for specific targets on an as-needed basis.
   Information collected on attacks may also be useful in identifying
   and developing defenses against novel attack types.


7.  Security Considerations

   Security considerations constitute the sole subject of this memo and
   hence are discussed throughout.

   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 evaluates MPLS-TP security requirements from a
   customer's perspective as well as from a service provider's
   perspective.  These sections re-evaluate the identified threats from
   the perspectives of the various stakeholders and are meant to assist
   equipment vendors and service providers, who must ultimately decide
   what threats to protect against in any given configuration or service
   offering.


8.  IANA Considerations

   This document contains no new IANA considerations.


9.  References

9.1.  Normative References

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

   [RFC3871]  Jones, G., "Operational Security Requirements for Large
              Internet Service Provider (ISP) IP Network
              Infrastructure", RFC 3871, September 2004.

   [RFC4732]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-



Fang, et al.              Expires August 14, 2011              [Page 22]

Internet-Draft         MPLS-TP Security Framework          February 2011


              Service Considerations", RFC 4732, December 2006.

   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
              and S. Ueno, "Requirements of an MPLS Transport Profile",
              RFC 5654, September 2009.

   [RFC5951]  Lam, K., Mansfield, S., and E. Gray, "Network Management
              Requirements for MPLS-based Transport Networks", RFC 5951,
              September 2010.

9.2.  Informative References

   [OIF-SMI-01.0]
              Optical Internetworking Forum, "Security for Management
              Interfaces to Network Elements", OIF OIF-SMI-01.0,
              Sept 2003.

   [OIF-SMI-02.1]
              Optical Internetworking Forum, "Addendum to the Security
              for Management Interfaces to Network Elements", OIF OIF-
              SMI-02.1, March 2006.

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

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
              Berger, "A Framework for MPLS in Transport Networks",
              RFC 5921, July 2010.

   [opsec-efforts]
              "Security Best Practices Efforts and Documents",
              IETF draft-ietf-opsec-efforts-08.txt, June 2008.


Authors' Addresses

   Luyuan Fang (editor)
   Cisco Systems Inc.
   111 Wood Ave. South
   Iselin, NJ 08830
   US

   Email: lufang@cisco.com





Fang, et al.              Expires August 14, 2011              [Page 23]

Internet-Draft         MPLS-TP Security Framework          February 2011


   Ben Niven-Jenkins (editor)
   Velocix
   326 Cambridge Science Park
   Milton Road
   Cambridge  CB4 0WG
   UK

   Email: ben@niven-jenkins.co.uk


   Scott Mansfield (editor)
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   US

   Email: scott.mansfield@ericsson.com


   Raymond Zhang
   British Telecom
   BT Center
   81 Newgate Street
   London  EC1A 7AJ
   Uk

   Email: raymond.zhang@bt.com


   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA  02145
   US

   Email: nabil.bitar@verizon.com


   Masahiro Daikoku
   KDDI Corporation
   3-11-11 Iidabashi, Chiyodaku
   Tokyo
   Japan

   Email: ms-daikoku@kddi.com






Fang, et al.              Expires August 14, 2011              [Page 24]

Internet-Draft         MPLS-TP Security Framework          February 2011


   Lei Wang
   Telenor
   Telenor Norway
   Office Snaroyveien
   1331 Fornedbu
   Norway

   Email: lei.wang@telenor.com











































Fang, et al.              Expires August 14, 2011              [Page 25]


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