Internet Engineering Task Force (IETF) L. Fang, Ed.
Request for Comments: 6941 Cisco
Category: Informational B. Niven-Jenkins, Ed.
ISSN: 2070-1721 Velocix
S. Mansfield, Ed.
Ericsson
R. Graveman, Ed.
RFG Security
April 2013
MPLS Transport Profile (MPLS-TP) Security Framework
Abstract
This document provides a security framework for the MPLS Transport
Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces
new Operations, Administration, and Maintenance (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 relevant in the context of
MPLS-TP specifically. It describes potential security threats as
well as mitigation procedures related to MPLS-TP networks and to
MPLS-TP interconnection to other MPLS and GMPLS networks. This
document is built on RFC 5920 ("Security Framework for MPLS and GMPLS
Networks") by providing additional security considerations that are
applicable to the MPLS-TP extensions. All the security
considerations from RFC 5920 are assumed to apply.
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 Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionality of
a packet transport network.
Fang, et al. Informational [Page 1]
RFC 6941 MPLS-TP Security Framework April 2013
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6941.
Copyright Notice
Copyright (c) 2013 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.
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Security Reference Models .......................................4
2.1. Security Reference Model 1 .................................5
2.2. Security Reference Model 2 .................................6
3. Security Threats ................................................9
4. Defensive Techniques ...........................................10
5. Security Considerations ........................................12
6. Acknowledgements ...............................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................13
Contributors ......................................................14
Fang, et al. Informational [Page 2]
RFC 6941 MPLS-TP Security Framework April 2013
1. Introduction
This document provides a security framework for the MPLS Transport
Profile (MPLS-TP).
As defined in "Requirements of an MPLS Transport Profile" [RFC5654]
and "A Framework for MPLS in Transport Networks" [RFC5921], MPLS-TP
uses a subset of MPLS features and introduces extensions to reflect
the characteristics of the transport technology. The additional
functionality includes in-band OAM, transport-oriented path
protection and recovery mechanisms, and new OAM capabilities that
were developed for MPLS-TP but that also apply to MPLS and GMPLS.
There is strong emphasis in MPLS-TP on static provisioning support
through Network Management Systems (NMSs) or Operational Support
Systems (OSSs).
This document is built on [RFC5920] by providing additional security
considerations that are applicable to the MPLS-TP extensions. The
security models, threats, and defense techniques previously defined
in [RFC5920] are assumed to apply to general aspects of MPLS-TP.
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 functionality of a packet transport network.
Readers can refer to [RFC5654] and [RFC5921] for MPLS-TP
terminologies and to [RFC5920] for security terminologies that are
relevant to MPLS and GMPLS.
1.1. Terminology
Term Definition
------ -----------------------------------------------
AC Attachment Circuit
BFD Bidirectional Forwarding Detection
CE Customer Edge
DoS Denial of Service
G-ACh Generic Associated Channel
GAL G-ACh Label
GMPLS Generalized Multiprotocol Label Switching
IP Internet Protocol
LDP Label Distribution Protocol
LSP Label Switched Path
NMS Network Management System
MPLS Multiprotocol Label Switching
MPLS-TP MPLS Transport Profile
Fang, et al. Informational [Page 3]
RFC 6941 MPLS-TP Security Framework April 2013
MS-PW Multi-Segment Pseudowire
OAM Operations, Administration, and Maintenance
PE Provider Edge
PSN Packet-Switched Network
PW Pseudowire
S-PE PW Switching Provider Edge
SP Service Provider
SS-PW Single-Segment Pseudowire
T-PE PW Terminating Provider Edge
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, as defined in
[RFC5921]. The placement of SP boundaries plays 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.
Fang, et al. Informational [Page 4]
RFC 6941 MPLS-TP Security Framework April 2013
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.
Security reference model 1(a) shows an MPLS-TP network with
Single-Segment Pseudowire (SS-PW) from PE1 to PE2. The trusted zone
is PE1 to PE2, as illustrated in Figure 1.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- 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----
Figure 1. MPLS-TP Security Model 1(a)
Fang, et al. Informational [Page 5]
RFC 6941 MPLS-TP Security Framework April 2013
Security reference model 1(b) shows an MPLS-TP network with
Multi-Segment Pseudowire (MS-PW) from T-PE1 to T-PE2. The trusted
zone is T-PE1 to T-PE2, as illustrated in Figure 2.
Native |<-------------Pseudowire------------>| Native
Service | | Service
(AC) | |<- PSN ->| |<- PSN ->| | (AC)
| v v v v v v |
| +-----+ +-----+ +-----+ |
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |------|......PW.Seg't1.......PW.Seg't3......|-------| |
| CE1| | | | | | | | | |CE2 |
| |------|......PW.Seg't2.......PW.Seg't4......|-------| |
+----+ | | |=========| |=========| | | +----+
^ +-----+ ^ +-----+ ^ +-----+ ^
| | | |
| TP LSP TP LSP |
| |
|<----------------- Emulated Service ---------------->|
-Untrusted->|<---------- Trusted Zone ----------->|<-Untrusted--
Figure 2. MPLS-TP Security Model 1(b)
Fang, et al. Informational [Page 6]
RFC 6941 MPLS-TP Security Framework April 2013
2.2. Security Reference Model 2
In reference model 2, a single SP does not have the end-to-end
control of the segment from PE/T-PE to PE/T-PE. A given S-PE or T-PE
may be under the control of another SP, that SP's customers, or its
partners. In this case, the MPLS-TP network is not contained within
a single trusted zone.
Security reference model 2(a) shows an MPLS-TP network with
Multi-Segment Pseudowire (MS-PW) from T-PE1 to T-PE2. The trusted
zone is T-PE1 to S-PE1, as illustrated in Figure 3.
Native |<-------------Pseudowire------------>| Native
Service | | Service
(AC) | |<--PSN-->| |<--PSN-->| | (AC)
| V V V V V V |
| +-----+ +-----+ +-----+ |
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |------|......PW.Seg't1.......PW.Seg't3......|------| |
| CE1| | | | | | | | | |CE2 |
| |------|......PW.Seg't2.......PW.Seg't4......|------| |
+----+ | | |=========| |=========| | | +----+
^ +-----+ ^ +-----+ ^ +-----+ ^
| | | |
| TP LSP TP LSP |
| |
|<---------------- Emulated Service --------------->|
Untrusted-->|<-- Trusted Zone---->|<---------Untrusted--------
Figure 3. MPLS-TP Security Model 2(a)
Fang, et al. Informational [Page 7]
RFC 6941 MPLS-TP Security Framework April 2013
Security reference model 2(b) shows an MPLS-TP network with
Multi-Segment Pseudowire (MS-PW) from T-PE1 to T-PE2. The trusted
zone is the S-PE1 only, as illustrated in Figure 4.
Native |<-------------Pseudowire------------>| Native
Service | | Service
(AC) | |<--PSN-->| |<--PSN-->| | (AC)
| V V V V V V |
| +-----+ +-----+ +-----+ |
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |------|......PW.Seg't1.......PW.Seg't3......|------| |
| CE1| | | | | | | | | |CE2 |
| |------|......PW.Seg't2.......PW.Seg't4......|------| |
+----+ | | |=========| |=========| | | +----+
^ +-----+ ^ +-----+ ^ +-----+ ^
| | | |
| TP LSP TP LSP |
| |
|<---------------- Emulated Service --------------->|
--------Untrusted---------->|<--->|<-------Untrusted----------
Trusted
Zone
Figure 4. MPLS-TP Security Model 2(b)
Security reference model 2(c) shows an MPLS-TP network with
Multi-Segment Pseudowire (MS-PW) from different SPs with
inter-provider PW connections. The trusted zone is T-PE1 to S-PE3,
as illustrated in Figure 5.
Native |<--------------------- PW15 ------------------>| Native
Layer | | Layer
Service | |<PSN13>| |<PSN3X>| |<PSNXZ>| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2)
| +-----+ +-+ +-----+ +-----+ +-+ +-----+ |
+---+ | |T-PE1| | | |S-PE3| |S-PEX| | | |T-PEZ| | +---+
| | | | |=======| |=======| |=======| | | | |
|CE1|----|........PW1........|..PW3..|........PW5........|---|CE2|
| | | | |=======| |=======| |=======| | | | |
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+-----+ +-+ +-----+ +-----+ +-+ +-----+
|<--Subnetwork 123->| |<--Subnetwork XYZ->|
Untrusted>|<-- Trusted Zone-->|<-------------Untrusted-------------
Figure 5. MPLS-TP Security Model 2(c)
Fang, et al. Informational [Page 8]
RFC 6941 MPLS-TP Security Framework April 2013
In general, the boundaries of a trusted zone must be carefully
defined when analyzing the security properties of each individual
network. The security boundaries determine which reference model
should be applied to a given network topology.
3. Security Threats
This section discusses various network security threats that are
unique to MPLS-TP and may endanger MPLS-TP networks.
Attacks against a GAL or G-ACh may include the following:
- GAL or BFD label manipulation, which includes insertion of false
labels and modification, deletion, or replay of messages.
- DoS attacks through in-band OAM by generating excessive G-ACh/GAL
and BFD messages that consume significant bandwidth and potentially
cause congestion.
These attacks can cause unauthorized protection switchover, inability
to restore one or more LSPs, or loss of network connectivity.
When an NMS is used for LSP setup, attacks on the NMS can cause the
above effects as well. Although this is not unique to MPLS-TP,
MPLS-TP networks can be particularly vulnerable to NMS attacks, due
to the fact that static provisioning through NMSs is a commonly used
model. In the static provisioning model, a compromised NMS can
potentially be comparable to a compromised control plane plus a
compromised management plane in the dynamic controlled network model.
Attacks on NMSs may come from either external attackers or insiders.
Outside attacks are initiated outside of the trusted zone by
unauthorized users of the MPLS-TP NMSs. Insider attacks are
initiated from inside the trusted zone by an entity that has
authorized access to the management systems but that performs
unapproved functions that are harmful to the MPLS-TP networks. These
attacks may directly target the NMS; they may also take place via the
compromised communication channels between the NMS and the network
devices that are being provisioned, or through user access to the
provisioning tools. This type of security threat may include
disclosure of information, generating false OAM messages, taking down
MPLS-TP LSPs, connecting to the wrong MPLS-TP tunnel endpoints, and
DoS attacks on the MPLS-TP networks.
There are other more generic security threats, such as unauthorized
observation of data traffic (including traffic pattern analysis),
modification or deletion of a provider's or user's data, and replay
or insertion of inauthentic data into a provider's or user's data
Fang, et al. Informational [Page 9]
RFC 6941 MPLS-TP Security Framework April 2013
stream. These types of attacks apply to MPLS-TP traffic regardless
of how the LSP or PW is set up, in a way that is similar to how they
apply to MPLS traffic regardless of how the LSP is set up. More
details on the above-mentioned threats are documented in [RFC5920].
Such threats may result from malicious behavior or accidental errors:
Example 1: Attacks from users: Users of the MPLS-TP network may
attack the network infrastructure or attack other users.
Example 2: Attacks from insiders: Employees of the operators may
attack the MPLS-TP network, especially through NMSs.
Example 3: Attacks from interconnecting SPs or other partners: Other
SPs may attack the MPLS-TP network, particularly through the
inter-provider connections.
Example 4: Attacks as the result of operational errors: Operations
staff may fail to follow operational procedures or may make
operational mistakes.