Network Working Group Luyuan Fang
Internet Draft Cisco Systems
Intended status: Informational Ben Niven-Jenkins
Expires: Jan. 6, 2009 BT
July 6, 2009
Security Framework for MPLS-TP
draft-fang-mpls-tp-security-framework-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Abstract
[Page 1]
MPLS-TP Security framework
July 2009
This document provides a security framework for Multiprotocol Label
Switching Transport Profile (MPLS-TP). MPLS-TP Requirements and
MPLS-TP Framework are defined in [MPLS-TP REQ] and [MPLS-TP FW].
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, GMPLS networks. The general
security analysis and guidelines for MPLS and GMPLS are addressed
in [MPLS/GMPLS Security FW], will not be covered in this document.
Table of Contents
1. Introduction..................................................3
1.1. Background and Motivation..................................3
1.2. Scope......................................................3
1.3. Terminology................................................4
1.4. Structure of the document..................................5
2. Security Reference Models.....................................6
2.1. Security Reference Model 1.................................6
2.2. Security Reference Model 2.................................7
3. Security Requirements for MPLS-TP............................10
3.1. Protection within the MPLS-TP Network.....................11
4. Security Threats.............................................12
4.1. Attacks on the Control Plane..............................13
4.2. Attacks on the Data Plane.................................14
5. Defensive Techniques for MPLS-TP Networks....................14
5.1. Authentication............................................15
5.2. Access Control Techniques.................................16
5.3. Use of Isolated Infrastructure............................16
5.4. Use of Aggregated Infrastructure..........................16
5.5. Service Provider Quality Control Processes................17
5.6. Verification of Connectivity..............................17
6. Monitoring, Detection, and Reporting of Security Attacks.....17
7. Security Considerations......................................17
8. IANA Considerations..........................................18
9. Normative References.........................................18
10. Informative References......................................18
11. Author's Addresses..........................................19
[Page 2]
MPLS-TP Security framework
July 2009
Requirements Language
Although this document is not a protocol specification, 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 RFC 2119 [RFC
2119].
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 [MPLS-TP
REQ] and [MPLS-TP FW]. 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
maturity, and it is required to maintain the transport
characteristics.
Focused on meeting the 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). Of course, there are 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
[MPLS/GMPLS SEC FW] can be used for the re-use of the existing
functionalities in MPLS and GMPLS, but not sufficient to cover the
new extensions.
1.2. Scope
[Page 3]
MPLS-TP Security framework
July 2009
This document addresses the security aspects that are specific to
MPLS-TP. It intends to provide the security requirements for MPLS-
TP; defines security models which apply to various MPLS-TP
deployment scenarios; identifies the potential securities threats
and migration procedures for MPLS-TP networks and MPLS-TP inter-
connection to MPLS, GMPLS networks. Inter-AS and Inter-provider
security for MPLS-TP to MPLS-TP connections or MPLS-TP to MPLS
connections are discussed, there connections present higher
security risk factors are than Intra-AS MPLS-TP connections.
The general security analysis and guidelines for MPLS and GMPLS are
addressed in [MPLS/GMPLS Security FW], the content which has no new
impact to MPLS-TP will not be repeated in this document. Other
general security issues regarding transport networks but not
specific to MPLS-TP is out of scope as well. Readers may also refer
to the "Security Best Practices Efforts and Documents" [opsec
effort] and "Security Mechanisms for the Internet" [RFC3631] (if
there are linkage to internet in the applications) for general
network operation security considerations. This document does not
intend to define the specific mechanisms/methods which must be
implemented to satisfy the security requirements.
1.3. Terminology
This document uses MPLS, MPLS-TP, and Security specific
terminology. Detailed definitions and additional terminology for
MPLS-TP may be found in [MPLS-TP REQ], [MPLS-TP FW], and MPLS/GMPLS
security related terminology in [MPLS/GMPLS SEC FW].
Term Definition
----------------------------------------------------
APS Automatic Protection Switching
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection
CE Customer-Edge device
CM Configuration Management
CoS Class of Service
CPU Central Processing Unit
DNS Domain Name System
DoS Denial of Service
EMF Equipment Management Function
ESP Encapsulating Security Payload
FEC Forwarding Equivalence Class
FM Fault Management
GAL Generic Alert Label
G-ACH Generic Associated Channel
[Page 4]
MPLS-TP Security framework
July 2009
GMPLS Generalized Multi-Protocol Label Switching
GCM Galois Counter Mode
IKE Internet Key Exchange
LDP Label Distribution Protocol
LMP Link Management Protocol
LSP Label Switched Path
MD5 Message Digest Algorithm
MEP Maintenance End Point
MIP Maintenance Intermediate Point
MPLS MultiProtocol Label Switching
NTP Network Time Protocol
OAM Operations, Administration, and Management
PE Provider-Edge device
PM Performance Management
PSN Packet-Switched Network
PW Pseudowire
QoS Quality of Service
RSVP Resource Reservation Protocol
RSVP-TE Resource Reservation Protocol with Traffic Engineering
Extensions
SCC Signaling Communication Channel
SDH Synchronous Digital Hierarchy
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SONET Synchronous Optical Network
S-PE Switching Provider Edge
SRLG Shared Risk Link Group
SSH Secure Shell
SSL Secure Sockets Layer
SYN Synchronize packet in TCP
TCP Transmission Control Protocol
TDM Time Division Multiplexing
TE Traffic Engineering
TLS Transport Layer Security
TTL Time-To-Live
T-PE Terminating Provider Edge
UDP User Datagram Protocol
VPN Virtual Private Network
WG Working Group of IETF
WSS Web Services Security
1.4. Structure of the document
Section 1: Introduction
Section 2: MPLS-TP Security Reference Models
Section 3: Security Requirements
Section 4: Security threats
[Page 5]
MPLS-TP Security framework
July 2009
Section 5: Defensive/mitigation techniques/procedures
Note that this document is currently work in progress, not all
requirements and security discussions are included, some sections
will be filled in later revision.
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
[MPLS-TP FW]. The SP boundaries play the important role to
determine the security models for any particular deployment.
This document defines the zone where the single SP has the total
operational control to be a trusted zone for that SP. 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 the total control of
PE/T-PE to PE/T-PE of the MPLS-TP network.
Security reference model 1(a):
MPLS-TP network with Single Segment Pseudowire (SS-PW) from PE to
PE. The trusted zone is PE1 to PE2 as illustrated in 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
[Page 6]
MPLS-TP Security framework
July 2009
Edge 1 | | Edge 2
| |
Native service Native service
----Untrusted--- >|<------- Trusted Zone ----- >|<---Untrusted----
Figure 1: MPLS-TP Security Model 1 (a)
Security reference model 1(b):
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 Figure 2.
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-
Figure 2: MPLS-TP Security Model 2 (b)
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 owned by different SPs or SPs and their customers. The MPLS-
TP network is not contained in one trusted zone.
Security Reference Model 2(a)
[Page 7]
MPLS-TP Security framework
July 2009
MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from PE to
PE. The trusted zone is T-PE1 to S-PE, as illustrated in Figure 3.
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--------
Figure 3: MPLS-TP Security Model 2(a)
Security Reference Model 2(b)
MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from PE to
PE. The trusted zone is S-PE, as illustrated in Figure 3.
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 |
| |
[Page 8]
MPLS-TP Security framework
July 2009
|<---------------- Emulated Service -------------->|
--------Untrusted----------->|<--->|< ------Untrusted--------
Trusted
Zone
Figure 4: MPLS-TP Security Model 2(b)
Security Reference Model 2(c):
MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from
different Service Providers with PW inter-provider 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)
+----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| | | |=========| |=========| |=========| | | |
|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)
The boundaries of a trust domain should be carefully defined when
analyzing the security properties of each individual network, as
illustrated from the above, the security boundaries determined
which model would be applied to the use case analysis.
A key requirement of MPLS-TP networks is that the security of the
trusted zone not be compromised by interconnecting the MPLS-TP,
MPLS core infrastructure with another provider's core or T-PE
devices, or end users.
[Page 9]
MPLS-TP Security framework
July 2009
In addition, neighbors may be trusted or untrusted. Neighbors may
be authorized or unauthorized. Even though a neighbor may be
authorized for communication, it may not be trusted. For example,
when connecting with another provider's S-PE to set up Inter-AS
LSPs, the other provider is considered an untrusted but may be
authorized neighbor.
+---------------+ +----------------+
| | | |
| MPLS-TP S-PE1----S-PE3 MPLS-TP |
CE1---S-PE1 Network | | Network T-PE2--CE2
| Provider A S-PE2----S-PE4 Provider 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: CE1, CE2
Figure 5. MPLS-TP trusted zone and authorized neighbor.
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
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
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 accidentally and
maliciously; 2) prevention of operational errors resulted from
misconfiguration within the trusted zone.
[Page 10]
MPLS-TP Security framework
July 2009
3.1. Protection within the MPLS-TP Network
-
- 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 attached
and cannot function normally, the data plane should continue
to forward packets without being impacted.
-
- 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)
and 2(b) where the some or all T-PEs are not in the trusted
zone, and in the inter-provider cases in security model 2(c)
when the connecting S-PE is in the untrusted zone.
- MPLS-TP MUST support non-IP path options in addition to IP
loopback option. Non-IP path option used in the model 2 may
help to lower the potential risk of the S-PE/T-PE in the
trusted zone to be attacked.
- MPLS-TP MUST support authentication of the any control
protocol used for MPLS-TP network, as well as MPLS-TP network
to dynamic MPLS network inter-connection.
- MPLS-TP MUST support mechanisms to prevent DOS attack through
in-band OAM GACH/GAL.
- MPLS-TP MUST support hiding of the Service Provider
infrastructure for all reference models regardless using
static configuration or dynamic control plane.
- Security management requirements [MPLS-TP NM REQ]:
o MPLS-TP must support management communication channel
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.
Support the use of open cryptographic algorithms [RFC
3871]; Authentication - allow management connectivity and
activity only from authenticated entities, and port
access control.
o Distributed Denial of Service: It is possible to lessen
the impact and potential for DoS and DDoS by using secure
[Page 11]
MPLS-TP Security framework
July 2009
protocols, turning off unnecessary processes, logging and
monitoring, and ingress filtering. [RFC 4732] provides
background on DOS in the context of the Internet.
(more to be added)
- Protection of 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.
(to be added)
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
network 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:
- Observation, modification, or deletion of a provider's or user's
data.
- Replay of a provider's or user's data.
- Injection of inauthentic data into a provider's or user's
traffic stream.
- Traffic pattern analysis on a provider's or user's traffic.
- Disruption of a provider's or user's connectivity.
- Degradation of a provider's service quality.
- Probing a provider's network to determine its configuration,
capacity, or usage.
It is useful to consider that threats, whether malicious or
accidental, may come from different categories of sources. For
example they may come from:
- Other users whose services are provided by the same MPLS-TP
core.
- The MPLS-TP SP or persons working for it.
- Other persons who obtain physical access to a MPLS-TP SP's site.
- Other persons who use social engineering methods to influence
the behavior of a SP's personnel.
- Users of the MPLS-TP network itself.
[Page 12]
MPLS-TP Security framework
July 2009
- Others, e.g., attackers from the other sources, Internet if
connected.
- Other SPs in the case of MPLS-TP Inter-provider connection. The
provider may or may not be using MPLS-TP.
- 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:
- A MPLS-TP network inter-connecting with another provider's core
- 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.
The following sections discuss specific types of exploits that
threaten MPLS-TP networks.
4.1. Attacks on the Control Plane
- MPLS-TP LSP creation by an unauthorized element
- LSP message interception
- Attacks against LDP
- Attacks against RSVP-TE
- Attacks against GMPLS
- Denial of Service Attacks on the Network Infrastructure
[Page 13]
MPLS-TP Security framework
July 2009
- Attacks on the SP's MPLS/GMPLS Equipment via Management
Interfaces
- Social Engineering Attacks on the SP's Infrastructure
- Cross-Connection of Traffic between Users
- Attacks against Routing Protocols
- 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.
- Unauthorized Observation of Data Traffic
- Modification of Data Traffic
- Insertion of Inauthentic Data Traffic: Spoofing and Replay
- Unauthorized Deletion of Data Traffic
- Unauthorized Traffic Pattern Analysis
- Denial of Service Attacks
- 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.
[Page 14]
MPLS-TP Security framework
July 2009
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.
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.
[Page 15]
MPLS-TP Security framework
July 2009
5.2. Access Control Techniques
- Access Control to Management Interfaces
Most of the security issues related to management interfaces can be
addressed through the use of authentication techniques as described
in the section on authentication. However, additional security may
be provided by controlling access to management interfaces in other
ways.
The Optical Internetworking Forum has done relevant work on
protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS,
etc. See OIF-SMI-01.0 "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.
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.
[Page 16]
MPLS-TP Security framework
July 2009
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 Section
3 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 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
[Page 17]
MPLS-TP Security framework
July 2009
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. Normative References
[MPLS-TP REQ], Niven-Jenkins, B., Brungard, D., Betts, M.,
Sprecher, N., and S. Ueno, "MPLS-TP Requirements", draft-ietf-mpls-
tp-requirements-09 (work in progress), June 2009.
[MPLS-TP FW] Bocci, M., Bryant, S., and L. Levrau, "A Framework for
MPLS in Transport Networks", draft-ietf-mpls-tp-framework-01 (work
in progress), June 2009.
[RFC 3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Infrastructure", RFC
3871, September 2004.
[RFC 4732] Handley, M., et al, "Internet Denial-of-Service
Considerations", RFC 4732, November 2006.
10. Informative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces
to Network Elements", Optical Internetworking Forum, Sept. 2003.
[Page 18]
MPLS-TP Security framework
July 2009
[OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for
Management Interfaces to Network Elements", Optical Internetworking
Forum, March 2006.
[RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security
Mechanisms for the Internet," December 2003.
[MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical
Specification", IP/MPLS Forum 19.0.0, April 2008.
[opsec efforts] C. Lonvick and D. Spak, "Security Best Practices
Efforts and Documents", draft-ietf-opsec-efforts-08.txt, June 2008.
[MPLS/GMPLS SEC FW] L. Fang, et al, Security Framework for MPLS and
GMPLS Networks, draft-ietf-mpls-mpls-and-gmpls-security-framework-
05.txt, March 2009.
[MPLS-TP NM REQ] Hing-Kam Lam, Scott Mansfield, Eric Gray, MPLS TP
Network Management Requirements, draft-ietf-mpls-tp-nm-req-02.txt,
June 2009.
11. Author's Addresses
Luyuan Fang
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
Email: lufang@cisco.com
Ben Niven-Jenkins
BT
208 Callisto House
Adastral Park, Ipswich IP5 3RE
UK
Email: benjamin.niven-jenkins@bt.com
[Page 19]