MPLS-TP Security Framework
draft-ietf-mpls-tp-security-framework-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6941.
|
|
|---|---|---|---|
| Authors | Ben Niven-Jenkins , Luyuan Fang , Richard F. Graveman , Scott Mansfield | ||
| Last updated | 2011-10-31 (Latest revision 2011-05-16) | ||
| Replaces | draft-fang-mpls-tp-security-framework | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-07)
by Dan Romascanu
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6941 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-mpls-tp-security-framework-02
Internet Engineering Task Force L. Fang, Ed.
Internet-Draft Cisco Systems
Intended status: Informational B. Niven-Jenkins, Ed.
Expires: April 30, 2012 Velocix
S. Mansfield, Ed.
Ericsson
R. Graveman, Ed.
RFG Security
October 31, 2011
MPLS-TP Security Framework
draft-ietf-mpls-tp-security-framework-02
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, a 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 and potential security threats and mitigation 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.]
Fang, et al. Expires April 30, 2012 [Page 1]
Internet-Draft MPLS-TP Security Framework October 2011
Status of this Memo
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 April 30, 2012.
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 April 30, 2012 [Page 2]
Internet-Draft MPLS-TP Security Framework October 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 April 30, 2012 [Page 3]
Internet-Draft MPLS-TP Security Framework October 2011
1. Introduction
1.1. Background and Motivation
This document provides a security framework for Multiprotocol Label
Switching Transport Profile (MPLS-TP).
The 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 and the fast-growing
bandwidth demand accelerated by new packet-based services and multimedia
applications, from Ethernet Services, Layer 2 and Layer 3 VPNS, and
triple play to Mobile Access Network (RAN) backhaul, etc. MPLS-TP is
based on MPLS technologies to take advantage of this technology's
maturity, and MPLS-TP is required to maintain the transport
characteristics of MPLS.
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 Systems (NMS) or Operation Support Systems (OSS).
There are also needs for MPLS-TP and MPLS interworking.
The security aspects for the new extensions particularly designed for
MPLS-TP need to be addressed. The security models, requirements,
threats, and defense techniques previously defined in [RFC5921] can be
applied to reuse existing functionalities in MPLS and GMPLS but are 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 specific to MPLS-TP. It
provides the security requirements for MPLS-TP, defines security models
that apply to various MPLS-TP deployment scenarios, and identifies 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, because these connections
present higher security risk factors than connections for Intra-AS
MPLS-TP.
Fang, et al. Expires April 30, 2012 [Page 4]
Internet-Draft MPLS-TP Security Framework October 2011
The general security analysis and guidelines for MPLS and GMPLS are
addressed in [RFC5920], and the content of [RFC5920] that has no new
impact on MPLS-TP is not 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 operations
security considerations. This document does not define the specific
mechanisms or methods that must be implemented to satisfy the security
requirements.
The issues and areas addressed with respect to MPLS-TP security are:
o G-Ach (control plane attack, DoS attack, message intercept, etc.)
o ID Spoofing
o Loopback attacks
o NMS attacks
o NMS and CP interaction vulnerabilities
o MIP and MEP assignment and attacks on these mechanisms
o Topology discovery vulnerabilities
o Data plane authentication
o Label authentication
o DoS attacks on the Data Plane
o Performance Monitoring vulnerabilities
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 April 30, 2012 [Page 5]
Internet-Draft MPLS-TP Security Framework October 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 April 30, 2012 [Page 6]
Internet-Draft MPLS-TP Security Framework October 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 and mitigation techniques and procedures
2. Security Reference Models
This section defines reference models 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
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 reference model 1, a single SP has total control of the PE/T-PE to
PE/T-PE part of the MPLS-TP network.
Fang, et al. Expires April 30, 2012 [Page 7]
Internet-Draft MPLS-TP Security Framework May 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
AC: Attachment Circuit
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 April 30, 2012 [Page 8]
Internet-Draft MPLS-TP Security Framework October 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 reference model 2, a single SP does not have total control
of the PE/T-PE to PE/T-PE part 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 April 30, 2012 [Page 9]
Internet-Draft MPLS-TP Security Framework October 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 April 30, 2012 [Page 10]
Internet-Draft MPLS-TP Security Framework October 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 April 30, 2012 [Page 11]
Internet-Draft MPLS-TP Security Framework October 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 April 30, 2012 [Page 12]
Internet-Draft MPLS-TP Security Framework October 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 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 a
trusted zone MUST NOT be compromised by interconnecting one SP's
MPLS-TP or MPLS infrastructure with another SP's core devices, 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 April 30, 2012 [Page 13]
Internet-Draft MPLS-TP Security Framework October 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 an MPLS-TP
network infrastructure. The MPLS-TP network can be operated without
a control plane or via dynamic control plane protocols. The
security requirements related to new MPLS-TP OAM, recovery
mechanisms, MPLS-TP and MPLS interconnection, and MPLS-TP specific
operations are addressed in this section.
A service provider may choose the deployment options best fitting
for its network operations. This document does not mandate that an
MPLS-TP 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 the
data plane from the control plane and the management plane. That is,
if the control plane, management plane, or both 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 LSPs and PWs
with or without an NMS or OSS, without using control protocols. This
is particularly important in the case of security model 2(a)
Fang, et al. Expires April 30, 2012 [Page 14]
Internet-Draft MPLS-TP Security Framework October 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 not in
the trusted zone.
o MPLS-TP MUST support non-IP path options in addition to the IP
loopback option. Non-IP path options when used in security model 2
(Section 2.2) may help to lower the potential risk of attacks 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's
infrastructure for all reference models regardless of whether the
network(s) are using static configuration or a dynamic control
plane.
o Management security requirements from [RFC5951] include the
following:
* MPLS-TP MUST support security for the management communication
channel (MCC).
* 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 provide support for confidentiality and data integrity
protection for applications.
* The MCC MUST support the use of a flexible set of strong, open, and
standard cryptographic algorithms (see Section 2.2 of [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
potential and impact for DoS and DDoS attacks by using secure
protocols, turning off unnecessary processes, logging and
monitoring, and ingress filtering. See [RFC4732] for
background on DoS in the context of the Internet.
Fang, et al. Expires April 30, 2012 [Page 15]
Internet-Draft MPLS-TP Security Framework October 2011
o MPLS-TP MUST provide protection from operational errors. Due to
the extensive use of static provisioning with or without a NMS or
OSS, the prevention of configuration errors should be addressed as
a major set of 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 inauthentic 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 or BFD messages:
a. GAL label or BFD label manipulation, which includes insertion
of false labels or messages, and modification or removal of
GAL labels or messages by attackers.
b. DoS attack through in-band OAM G-ACH/GAL and BFD messages.
3. Disruption of a provider's or user's connectivity, or degradation
of a provider's service quality.
a. Attacks against provider connectivity:
+ In the case in which an NMS is used for LSP set-up, the
attacks occur through attacks on the NMS.
+ In the case in which dynamic provisioning is used, the
attacks
occur on the dynamic control plane. Most aspects of these
are addressed in [RFC5920].
b. Attacks against user connectivity. These are similar to
PE/CE attacks against access in typical MPLS networks and
are addressed in [RFC5920].
Fang, et al. Expires April 30, 2012 [Page 16]
Internet-Draft MPLS-TP Security Framework October 2011
4. Probing a provider's network to determine its configuration,
capacity, or usage. These types of attack can occur through
attacks against an NMS in the case of static provisioning, or
through attacks against the control plane in dynamic MPLS
networks. They 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, including the
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 hardware or 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. Even though surveys show that 40% to
60% of attacks originate from insiders, 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 April 30, 2012 [Page 17]
Internet-Draft MPLS-TP Security Framework October 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 April 30, 2012 [Page 18]
Internet-Draft MPLS-TP Security Framework October 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
specific operational environment determines the security requirements
for any instance of MPLS-TP. Therefore, protocol designers should
provide a full set of security capabilities, which can be selected and
used where appropriate. 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 techniques discussed here include entity authentication for
identity verification, encryption for confidentiality, message integrity
and replay detection to ensure the validity of message streams, network-
based access controls such as packet filtering and firewalls, host-based
access controls, isolation, aggregation, and event logging. Where these
techniques apply to MPLS and GMPLS in general, they are described in
Section 5.2 of [RFC5920]. The remainder of this section covers aspects
that apply particularly to MPLS-TP.
5.1. Authentication
To prevent security issues arising from impersonation, masquerade, or
some DoS attacks or from malicious or accidental misconfiguration, it is
critical that MPLS-TP devices should accept connections or control
messages only from known sources. Authentication refers to methods for
ensuring that the identities of message sources are properly verified by
the MPLS-TP devices with which they communicate. This section focuses
on 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.
This type of authentication should be bi-directional. The PE or CE needs
to be certain it is communicating with the right server.
Fang, et al. Expires April 30, 2012 [Page 19]
Internet-Draft MPLS-TP Security Framework October 2011
5.1.2. Peer-to-Peer Authentication
Peer-to-peer authentication includes peer authentication for network
control protocols and other peer authentication (e.g., 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 variety of public-private
key systems. Some of these use digital certificates binding a user's
name and public key. One method of using digital certificates is within
a hierarchical Certification Authority system.
5.2. Access Control Techniques
Many of the security issues related to management interfaces can be
addressed through the use of authentication as described in Section
5.1. However, additional security may be provided by controlling access
to management interfaces or to specific resources with an access control
model. In addition to identification and authentication, access control
deals with authorization.
Much of the work on security for SNMP has focused on access control
models. For the most recent version of SNMP security, see the work of
the ISMS WG.
The Optical Internetworking Forum has done relevant work on
Protecting interfaces to management systems with TLS, SSH, 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].
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 April 30, 2012 [Page 20]
Internet-Draft MPLS-TP Security Framework October 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
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 networks and services may be subject to attacks from a
variety of security threats. Many types of threats are described
in the Security Requirements (Section 3) Section of this document.
The defensive techniques described in this document and elsewhere
provide significant levels of protection from many of these 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
provide significant benefits.
Fang, et al. Expires April 30, 2012 [Page 21]
Internet-Draft MPLS-TP Security Framework October 2011
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.
Also, extensive logging of normal processing, error conditions and
security events can be an invaluable source of information for tracking
down attacks, recovering from them, and determining how to prevent
future attacks. Different methods may be appropriate from case to case,
and in fact comparing the same or similar information obtained in
different ways (e.g., with syslog and SNMP) has sometimes reveals subtle
security flaws or actual intrusions. Implementations should also pay
attention to the security of the logs themselves.
7. Security Considerations
Security considerations constitute the sole subject of this document
and hence are discussed throughout.
The document describes a variety of defensive techniques that may be
used to counter the potential 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 April 30, 2012 [Page 22]
Internet-Draft MPLS-TP Security Framework October 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.
Note: A single document updating these two OIF agreements may be
published in November 2011. If so, it will be posted at
http://www.oiforum.com/public/impagreements.html.
[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
111 Wood Ave. South
Iselin, NJ 08830
US
Email: lufang@cisco.com
Fang, et al. Expires April 30, 2012 [Page 23]
Internet-Draft MPLS-TP Security Framework October 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
Richard F. Graveman (editor)
RFG Security, LLC
15 Park Avenue
Morristown, NJ 07960 US
Email: rfg@acm.org
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
Fang, et al. Expires April 30, 2012 [Page 24]
Internet-Draft MPLS-TP Security Framework October 2011
Masahiro Daikoku
KDDI Corporation
3-11-11 Iidabashi, Chiyodaku
Tokyo
Japan
Email: ms-daikoku@kddi.com
Lei Wang
Telenor
Telenor Norway
Office Snaroyveien
1331 Fornedbu
Norway
Email: lei.wang@telenor.com
Henry Yu
TW Telecom
10475 Park Meadow Drive
Littleton, CO 80124
US
Email: henry.yu@twtelecom.com
Fang, et al. Expires April 30, 2012 [Page 25]