One document matched: draft-ietf-mpls-tp-security-framework-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-mpls-tp-security-framework-01" ipr="trust200902">
<front>
<title abbrev="MPLS-TP Security Framework">MPLS-TP Security Framework</title>
<author fullname="Luyuan Fang" initials="L" surname="Fang" role="editor">
<organization>Cisco Systems Inc.</organization>
<address>
<postal>
<street>111 Wood Ave. South</street>
<city>Iselin</city>
<region>NJ</region>
<code>08830</code>
<country>US</country>
</postal>
<email>lufang@cisco.com</email>
</address>
</author>
<author fullname="Ben Niven-Jenkins" initials="B" surname="Niven-Jenkins" role="editor">
<organization>Velocix</organization>
<address>
<postal>
<street>326 Cambridge Science Park</street>
<street>Milton Road</street>
<city>Cambridge</city>
<code>CB4 0WG</code>
<country>UK</country>
</postal>
<email>ben@niven-jenkins.co.uk</email>
</address>
</author>
<author fullname="Scott Mansfield" initials="S" surname="Mansfield" role="editor">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>scott.mansfield@ericsson.com</email>
</address>
</author>
<author fullname="Raymond Zhang" initials="R" surname="Zhang">
<organization>British Telecom</organization>
<address>
<postal>
<street>BT Center</street>
<street>81 Newgate Street</street>
<city>London</city>
<code>EC1A 7AJ</code>
<country>Uk</country>
</postal>
<email>raymond.zhang@bt.com</email>
</address>
</author>
<author fullname="Nabil Bitar" initials="N" surname="Bitar">
<organization>Verizon</organization>
<address>
<postal>
<street>40 Sylvan Road</street>
<city>Waltham</city>
<region>MA</region>
<code>02145</code>
<country>US</country>
</postal>
<email>nabil.bitar@verizon.com</email>
</address>
</author>
<author fullname="Masahiro Daikoku" initials="M" surname="Daikoku">
<organization>KDDI Corporation</organization>
<address>
<postal>
<street>3-11-11 Iidabashi, Chiyodaku</street>
<city>Tokyo</city>
<country>Japan</country>
</postal>
<email>ms-daikoku@kddi.com</email>
</address>
</author>
<author fullname="Lei Wang" initials="L" surname="Wang">
<organization>Telenor</organization>
<address>
<postal>
<street>Telenor Norway</street>
<street>Office Snaroyveien</street>
<street>1331 Fornedbu</street>
<country>Norway</country>
</postal>
<email>lei.wang@telenor.com</email>
</address>
</author>
<author fullname="Henry Yu" initials="H" surname="Yu">
<organization>TW Telecom</organization>
<address>
<postal>
<street>10475 Park Meadow Drive</street>
<city>Littleton</city>
<region>CO</region>
<code>80124</code>
<country>US</country>
</postal>
<email>henry.yu@twtelecom.com</email>
</address>
</author>
<date year="2011" />
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>mpls-tp security framework</keyword>
<abstract>
<t> 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.
</t>
<t> 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.
</t>
<t>This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call.
</t>
<t>[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.]
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Background and Motivation">
<t> This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP).
</t>
<t> MPLS-TP Requirements and MPLS-TP Framework are defined in <xref target="RFC5654" /> and <xref target="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.
</t>
<t> 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.
</t>
<t> 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 <xref target="RFC5921" /> can be used for the re-use of the existing functionalities in MPLS and GMPLS, but not sufficient to cover the new extensions.
</t>
<t> 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.
</t>
</section>
<section title="Scope">
<t> 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.
</t>
<t> The general security analysis and guidelines for MPLS and GMPLS are addressed in <xref target="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" <xref target="opsec-efforts">Opsec Effort</xref> and "Security Mechanisms for the Internet" <xref target="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.
</t>
<t> Issues/Areas to be addressed:
<list style="symbols">
<t>G-Ach (control plane attack, DoS attack, message intercept, etc.)
</t>
<t>Spoofing ID
</t>
<t>Loopback
</t>
<t>NMS attack
</t>
<t>NMS and CP interaction
</t>
<t>MIP/MEP assignment and attacks
</t>
<t>Topology discovery
</t>
<t>Data plane authentication
</t>
<t>Label authentication
</t>
<t>DoS attack in Data Plane
</t>
<t>Performance Monitoring
</t>
</list>
</t>
</section>
<section title="Requirement Language">
<t> 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 <xref target="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.
</t>
</section>
<section title="Terminology">
<t> This document uses MPLS, MPLS-TP, and Security specific terminology. Detailed definitions and additional terminology for MPLS-TP may be found in <xref target="RFC5654" />, <xref target="RFC5921" />, and MPLS/GMPLS security related terminology in <xref target="RFC5920" />.
</t>
<t>
<list style="symbols">
<t>BFD: Bidirectional Forwarding Detection
</t>
<t>CE: Customer-Edge device
</t>
<t>DoS: Denial of Service
</t>
<t>DDoS: Distributed Denial of Service
</t>
<t>GAL: Generic Alert Label
</t>
<t>G-ACH: Generic Associated Channel
</t>
<t>GMPLS: Generalized Multi-Protocol Label Switching
</t>
<t>LDP: Label Distribution Protocol
</t>
<t>LSP: Label Switched Path
</t>
<t>MCC: Management Communication Channel
</t>
<t>MEP: Maintenance End Point
</t>
<t>MIP: Maintenance Intermediate Point
</t>
<t>MPLS: MultiProtocol Label Switching
</t>
<t>OAM: Operations, Administration, and Management
</t>
<t>PE: Provider-Edge device
</t>
<t>PSN: Packet-Switched Network
</t>
<t>PW: Pseudowire
</t>
<t>RSVP: Resource Reservation Protocol
</t>
<t>RSVP-TE: Resource Reservation Protocol with Traffic Engineering Extensions
</t>
<t>S-PE: Switching Provider Edge
</t>
<t>SSH: Secure Shell
</t>
<t>TE: Traffic Engineering
</t>
<t>TLS: Transport Layer Security
</t>
<t>T-PE: Terminating Provider Edge
</t>
<t>VPN: Virtual Private Network
</t>
<t>WG: Working Group of IETF
</t>
<t>WSS: Web Services Security
</t>
</list>
</t>
</section>
<section title="Structure of the document">
<t>Section 1: Introduction
</t>
<t>Section 2: MPLS-TP Security Reference Models
</t>
<t>Section 3: Security Requirements
</t>
<t>Section 4: Security Threats
</t>
<t>Section 5: Defensive/Mitigation techniques/procedures
</t>
</section>
</section>
<section anchor="Security-Reference-Models" title="Security Reference Models">
<t> This section defines a reference model for security in MPLS-TP networks.
</t>
<t> The models are built on the architecture of MPLS-TP defined in <xref target="RFC5921" />. The Service Provider (SP) boundaries play an important role in determining the security models for any particular deployment.
</t>
<t>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.
</t>
<section anchor="secref-1" title="Security Reference Model 1">
<t> In the reference model 1, a single SP has total control of PE/T-PE to PE/T-PE of the MPLS-TP network.
</t>
<t> Security reference model 1(a)
</t>
<t>An MPLS-TP network with Single Segment Pseudowire (SS-PW) from PE to PE. The trusted zone is PE1 to PE2 as illustrated in <xref target="secref-1a">MPLS-TP Security Model 1 (a)</xref>.
</t>
<figure align="center" anchor="secref-1a">
<!-- <preamble></preamble> -->
<artwork align="left"><![CDATA[
|<-------------- 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----
]]></artwork>
<postamble>MPLS-TP Security Model 1 (a)</postamble>
</figure>
<t> Security reference model 1(b)
</t>
<t>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 <xref target="secref-1b">MPLS-TP Security Model 1 (b)</xref>.
</t>
<figure align="center" anchor="secref-1b">
<!-- <preamble></preamble> -->
<artwork align="left"><![CDATA[
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-
]]></artwork>
<postamble>MPLS-TP Security Model 1 (b)</postamble>
</figure>
</section>
<section anchor="secref-2" title="Security Reference Model 2">
<t> 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.
</t>
<t> Security Reference Model 2(a)
</t>
<t>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 <xref target="secref-2a">MPLS-TP Security Model 2 (a)</xref>.
</t>
<figure align="center" anchor="secref-2a">
<!-- <preamble></preamble> -->
<artwork align="left"><![CDATA[
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--------
]]></artwork>
<postamble>MPLS-TP Security Model 2 (a)</postamble>
</figure>
<t> Security Reference Model 2(b)
</t>
<t> 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 <xref target="secref-2b">MPLS-TP Security Model 2 (b)</xref>.
</t>
<figure align="center" anchor="secref-2b">
<!-- <preamble></preamble> -->
<artwork align="left"><![CDATA[
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
]]></artwork>
<postamble>MPLS-TP Security Model 2 (b)</postamble>
</figure>
<t> Security Reference Model 2(c)
</t>
<t> 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 <xref target="secref-2c">MPLS-TP Security Model 2 (c)</xref>.
</t>
<figure align="center" anchor="secref-2c">
<!-- <preamble></preamble> -->
<artwork align="left"><![CDATA[
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------------
]]></artwork>
<postamble>MPLS-TP Security Model 2 (c)</postamble>
</figure>
</section>
<section anchor="secref-3" title="Security Reference Model 3">
<t>An MPLS-TP network with a Transport LSP from PE1 to PE2. The trusted zone is PE1 to PE2 as illustrated in <xref target="secref-3a">MPLS-TP Security Model 3 (a)</xref>.
</t>
<figure align="center" anchor="secref-3a">
<!-- <preamble></preamble> -->
<artwork align="left"><![CDATA[
|<------------- 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----
]]></artwork>
<postamble>MPLS-TP Security Model 3 (a)</postamble>
</figure>
</section>
<section anchor="boundaries" title="Trusted Zone Boundaries">
<t> 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.
</t>
<t> 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.
</t>
<t> 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.
</t>
<figure align="center" anchor="seczone">
<!-- <preamble></preamble> -->
<artwork align="left"><![CDATA[
+---------------+ +----------------+
| | | |
| 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
]]></artwork>
<postamble>MPLS-TP trusted zone and authorized neighbor</postamble>
</figure>
</section>
</section>
<section anchor="Security-Requirements" title="Security Requirements for MPLS-TP">
<t> 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.
</t>
<t> 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.
</t>
<t> 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.
</t>
<t>
<list style="symbols">
<t> 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.
</t>
<t>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 <xref target="secref-2a">security model 2(a)</xref> and <xref target="secref-2b">security model 2(b)</xref> where some or all T-PEs are not in the trusted zone, and in the inter-provider cases in <xref target="secref-2c">security model 2(c)</xref> when the connecting S-PE is in the untrusted zone.
</t>
<t>MPLS-TP MUST support non-IP path options in addition to IP loopback option. Non-IP path options when used in <xref target="secref-2">security model 2</xref> may help to lower the potential risk of attack on the S-PE/T-PE in the trusted zone.
</t>
<t>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.
</t>
<t>MPLS-TP MUST support mechanisms to prevent Denial of Service (DOS) attacks via any in-band OAM or G-ACh/GAL.
</t>
<t>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.
</t>
<t>Security management requirements from <xref target="RFC5951" />:
<list style="symbols">
<t>MPLS-TP MUST support management communication channel (MCC) security.
</t>
<t>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.
</t>
<t>The MCC MUST support application protocols that provide confidentiality and data integrity protection.
</t>
<t>The MCC MUST support the use of open cryptographic algorithms <xref target="RFC3871" />.
</t>
<t>The MCC MUST support authentication to ensure that management connectivity and activity is only from authenticated entities.
</t>
<t>The MCC MUST support port access control.
</t>
<t>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. <xref target="RFC4732" /> provides background on DOS in the context of the Internet.
</t>
</list>
</t>
<t> 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.
</t>
</list>
</t>
</section>
<section anchor="Security-Threats" title="Security Threats">
<t> 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.
</t>
<t> 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:
<list style="numbers">
<t>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.
</t>
<t>Attacks on GAL label, BFD messages:
<list style="numbers">
<t> GAL label or BFD label manipulation: including insertion of false label or messages, or modification, or removal the GAL labels or messages by attackers.
</t>
<t> DOS attack through in-band OAM G-ACH/GAL, and BFD messages.
</t>
</list>
</t>
<t> Disruption of a provider's and/or user's connectivity, or degradation of a provider's service quality.
<list style="numbers">
<t> Provider connectivity attacks:
<list style="symbols">
<t> In the case of NMS is used for LSP set-up, the attacks would be through the attack of NMS.
</t>
<t> In the case of dynamic is used for dynamic provisioning, the attack would be on dynamic control plane. Most aspects are addressed in <xref target="RFC5920" />.
</t>
</list>
</t>
<t>User connectivity attack. This would be similar as PE/CE access attack in typical MPLS networks, addressed in <xref target="RFC5920" />.
</t>
</list>
</t>
<t>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.
</t>
</list>
</t>
<t> It is useful to consider that threats, whether malicious or accidental, may come from different categories of sources. For example they may come from:
<list style="symbols">
<t>Other users whose services are provided by the same MPLS-TP core.
</t>
<t>The MPLS-TP SP or persons working for it.
</t>
<t>Other persons who obtain physical access to a MPLS-TP SP's site.
</t>
<t>Other persons who use social engineering methods to influence the behavior of a SP's personnel.
</t>
<t>Users of the MPLS-TP network itself.
</t>
<t>Others, e.g., attackers from the other sources, Internet if connected.
</t>
<t>Other SPs in the case of MPLS-TP Inter-provider connection. The provider may or may not be using MPLS-TP.
</t>
<t>Those who create, deliver, install, and maintain software for network equipment.
</t>
</list>
</t>
<t>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:
<list style="symbols">
<t> A MPLS-TP network inter-connecting with another provider's core
</t>
<t> A MPLS-TP configuration transiting the public Internet
</t>
</list>
</t>
<t> 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.
</t>
<t> The following sections discuss specific types of exploits that threaten MPLS-TP networks.
</t>
<section anchor="Attacks-on-the-Control-Plane" title="Attacks on the Control Plane">
<t>
<list style="symbols">
<t>MPLS-TP LSP creation by an unauthorized element
</t>
<t>LSP message interception
</t>
<t>Attacks on G-Ach
</t>
<t>Attacks against LDP
</t>
<t>Attacks against RSVP-TE
</t>
<t>Attacks against GMPLS
</t>
<t>Denial of Service Attacks on the Network Infrastructure
</t>
<t>Attacks on the SP's MPLS/GMPLS Equipment via Management Interfaces
</t>
<t>Social Engineering Attacks on the SP's Infrastructure
</t>
<t>Cross-Connection of Traffic between Users
</t>
<t>Attacks against Routing Protocols
</t>
<t>Other Attacks on Control Traffic
</t>
</list>
</t>
</section>
<section anchor="Attacks-on-the-Data-Plane" title="Attacks on the Data Plane">
<t>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.
</t>
<t>
<list style="symbols">
<t>Unauthorized Observation of Data Traffic
</t>
<t>Modification of Data Traffic
</t>
<t>Insertion of Inauthentic Data Traffic: Spoofing and Replay
</t>
<t>Unauthorized Deletion of Data Traffic
</t>
<t>Unauthorized Traffic Pattern Analysis
</t>
<t>Denial of Service Attacks
</t>
<t>Misconnection
</t>
</list>
</t>
</section>
</section>
<section anchor="Defensive-Techniques" title="Defensive Techniques for MPLS-TP Networks">
<t>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.
</t>
<t>The techniques discussed here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and others.
</t>
<section anchor="Authentication" title="Authentication">
<t>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.
</t>
<section anchor="Management-System-Authentication" title="Management System Authentication">
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor="Peer-to-Peer-Authentication" title="Peer-to-Peer Authentication">
<t>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).
</t>
<t>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.
</t>
</section>
<section anchor="Cryptographic-Techniques-for-Authenticating-Identity" title="Cryptographic Techniques for Authenticating Identity">
<t>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.
</t>
</section>
</section>
<section anchor="Access-Control-Techniques" title="Access Control Techniques">
<t>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.
</t>
<t>The Optical Internetworking Forum has done relevant work on protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. See <xref target = "OIF-SMI-01.0">Security for Management Interfaces to Network Elements</xref>, and <xref target = "OIF-SMI-02.1">Addendum to the Security for Management Interfaces to Network Elements</xref>. See also the work in the ISMS WG.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor="Use-of-Isolated-Infrastructure" title="Use of Isolated Infrastructure">
<t>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.
</t>
</section>
<section anchor="Use-of-Aggregated-Infrastructure" title="Use of Aggregated Infrastructure">
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor="Service-Provider-Quality-Control-Processes" title="Service Provider Quality Control Processes">
</section>
<section anchor="Verification-of-Connectivity" title="Verification of Connectivity">
<t>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.
</t>
</section>
</section>
<section anchor="Monitoring-Detection-and-Reporting-of-Security-Attacks" title="Monitoring, Detection, and Reporting of Security Attacks">
<t> MPLS-TP network and service may be subject to attacks from a variety of security threats. Many threats are described in the <xref target="Security-Requirements">Security Requirements</xref> 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.
</t>
<t> 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.
</t>
<t> 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.
</t>
</section>
<section anchor="Security-Considerations" title="Security Considerations">
<t> Security considerations constitute the sole subject of this memo and hence are discussed throughout.
</t>
<t> 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.
</t>
<t> 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.
</t>
</section>
<section anchor="IANA-Considerations" title="IANA Considerations">
<t>This document contains no new IANA considerations.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3871" ?>
<?rfc include="reference.RFC.4732" ?>
<?rfc include="reference.RFC.5654" ?>
<?rfc include="reference.RFC.5951" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3631" ?>
<?rfc include="reference.RFC.5920" ?>
<?rfc include="reference.RFC.5921" ?>
<reference anchor="opsec-efforts">
<front>
<title>Security Best Practices Efforts and Documents</title>
<author fullname='C. Lonvick'>
<organization />
</author>
<author fullname='D. Spak'>
<organization />
</author>
<date month="June" year="2008"/>
</front>
<seriesInfo name="IETF" value="draft-ietf-opsec-efforts-08.txt"/>
</reference>
<reference anchor="OIF-SMI-01.0">
<front>
<title>Security for Management Interfaces to Network Elements</title>
<author fullname='Renee Esposito'>
<organization>Optical Internetworking Forum</organization>
</author>
<date month="Sept" year="2003"/>
</front>
<seriesInfo name="OIF" value="OIF-SMI-01.0"/>
</reference>
<reference anchor="OIF-SMI-02.1">
<front>
<title>Addendum to the Security for Management Interfaces to Network Elements</title>
<author fullname='Renee Esposito'>
<organization>Optical Internetworking Forum</organization>
</author>
<date month="March" year="2006"/>
</front>
<seriesInfo name="OIF" value="OIF-SMI-02.1"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:26:03 |