< draft-fang-mpls-gmpls-security-framework-00.txt   draft-fang-mpls-gmpls-security-framework-01.txt >
Network Working Group Luyuan Fang (Ed) Network Working Group Luyuan Fang (Ed)
Internet Draft Michael Behringer Internet Draft Michael Behringer
Category: Informational Cisco Systems, Inc. Category: Informational Cisco Systems, Inc.
Expires: August 2007 Ross Callon Expires: January 2008 Ross Callon
Juniper Networks Juniper Networks
J. L. Le Roux J. L. Le Roux
France Telecom France Telecom
Raymond Zhang Raymond Zhang
British Telecom British Telecom
Paul Knight Paul Knight
Nortel Nortel
Yaakov Stein Yaakov Stein
RAD Data Communications RAD Data Communications
Nabil Bitar
Verizon
Richard Graveman
RFC Security, LLC
February 2007 July 2007
Security Framework for MPLS and GMPLS Networks Security Framework for MPLS and GMPLS Networks
draft-fang-mpls-gmpls-security-framework-00.txt draft-fang-mpls-gmpls-security-framework-01.txt
Status of this Memo Status of this Memo
This memo provides information for the Internet community. It does By submitting this Internet-Draft, each author represents that any
not specify an Internet standard of any kind. Distribution of this applicable patent or other IPR claims of which he or she is aware
memo is unlimited. have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007).
Fang, et al. Informational 1 Fang, et al. Informational 1
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides a security framework for Multiprotocol Label This document provides a security framework for Multiprotocol Label
Switching (MPLS) and Generalized Multiprotocol Label Switching Switching (MPLS) and Generalized Multiprotocol Label Switching
(GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and (GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and
[RFC3945]). This document addresses the security aspects that are [RFC3945]). This document addresses the security aspects that are
relevant in the context of MPLS and GMPLS. It describes the relevant in the context of MPLS and GMPLS. It describes the
security threats, the related defensive techniques, and the security threats, the related defensive techniques, and the
mechanisms for detection and reporting. This document gives mechanisms for detection and reporting. This document emphasizes
emphasis to RSVP-TE and LDP security considerations, as well as RSVP-TE and LDP security considerations, as well as Inter-AS and
Inter-AS and Inter-provider security considerations for building Inter-provider security considerations for building and maintaining
and maintaining MPLS and GMPLS networks across different domains or MPLS and GMPLS networks across different domains or different
different Service Providers. Service Providers.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction.................................................3
1.1. Structure of This Document.................................4 1.1. Structure of this Document................................4
1.2. Contributors...............................................5 1.2. Contributors..............................................5
2. Terminology...................................................5 2. Terminology .................................................5
2.1. Terminology................................................5 2.1. Terminology...............................................5
2.2. Acronyms and Abbreviations.................................7 2.2. Acronyms and Abbreviations................................7
3. Security Reference Models.....................................7 3. Security Reference Models....................................7
4. Security Threats..............................................9 4. Security Threats.............................................9
4.1. Attacks on the Control Plane..............................10 4.1. Attacks on the Control Plane.............................11
4.2. Attacks on the Data Plane.................................13 4.2. Attacks on the Data Plane................................14
5. Defensive Techniques for MPLS/GMPLS Networks.................15 5. Defensive Techniques for MPLS/GMPLS Networks................15
5.1. Cryptographic techniques..................................16 5.1. Authentication ..........................................16
5.2. Authentication............................................24 5.2. Cryptographic techniques.................................18
5.3. Access Control techniques.................................25 5.3. Access Control techniques................................27
5.4. Use of Isolated Infrastructure............................29 5.4. Use of Isolated Infrastructure...........................32
5.5. Use of Aggregated Infrastructure..........................30 5.5. Use of Aggregated Infrastructure.........................32
5.6. Service Provider Quality Control Processes................30 5.6. Service Provider Quality Control Processes...............33
5.7. Deployment of Testable MPLS/GMPLS Service.................31 5.7. Deployment of Testable MPLS/GMPLS Service................33
6. Monitoring, Detection, and Reporting of Security Attacks.....31 6. Monitoring, Detection, and Reporting of Security Attacks....33
7. Service Provider General Security Requirements...............32 7. Service Provider General Security Requirements..............35
7.1. Protection within the Core Network........................32 7.1. Protection within the Core Network.......................35
7.2. Protection on the User Access Link........................36 7.2. Protection on the User Access Link.......................39
7.3. General Requirements for MPLS/GMPLS Providers.............38 7.3. General Requirements for MPLS/GMPLS Providers ...........40
8. Inter-provider Security Requirements.........................38 8. Inter-provider Security Requirements........................41
8.1. Control Plane Protection..................................39
Fang, et al. Informational 2 Fang, et al. Informational 2
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 8.1. Control Plane Protection.................................41
8.2. Data Plane Protection....................................45
8.2. Data Plane Protection.....................................43 9. Security Considerations.....................................47
9. Security Considerations......................................44 10. IANA Considerations.......................................47
10. IANA Considerations........................................45 11. Normative References .....................................48
11. Normative References.......................................45 12. Informational References..................................49
12. Informational References...................................46 13. Author's Addresses........................................50
13. Author's Addresses.........................................47 14. Acknowledgements..........................................53
14. Acknowledgement............................................49
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC2119 [RFC this document are to be interpreted as described in RFC2119 [RFC
2119]. 2119].
1. Introduction 1. Introduction
Security is an important aspect of all networks, MPLS and GMPLS Security is an important aspect of all networks, MPLS and GMPLS
networks being no exception. networks being no exception.
MPLS and GMPLS are described in [RFC3031] [RFC3945]. Various MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Various
security considerations have been addressed in each of the many security considerations have been addressed in each of the many
RFCs that address on MPLS and GMPLS technologies, but there has not RFCs on MPLS and GMPLS technologies, but no single document covers
been a single document which provides general security general security considerations. The motivation for creating this
considerations. The motivation for creating this document is to document is to provide a comprehensive and consistent security
provide a comprehensive and consistent security framework for MPLS framework for MPLS and GMPLS networks. Each individual document may
and GMPLS networks. Each individual document may point to this point to this document for general security considerations in
document for general security considerations in addition to addition to providing security considerations specific to the
providing the security considerations which are specific to the
particular technologies the document is describing. particular technologies the document is describing.
In this document, we first describe the security threats that are In this document, we first describe the security threats relevant
relevant in the context of MPLS and GMPLS, and the defensive in the context of MPLS and GMPLS and the defensive techniques to
techniques that can be used to combat those threats. We consider combat those threats. We consider security issues deriving both
security issues deriving both from malicious or incorrect behavior from malicious or incorrect behavior of users and other parties and
of users and other parties and from negligent or incorrect behavior from negligent or incorrect behavior of providers. An important
of the providers. An important part of security defense is the part of security defense is the detection and reporting of a
detection and report of a security attack, which is also addressed security attack, which is also addressed in this document.
in this document.
We then discuss the possible service provider security requirements We then discuss possible service provider security requirements in
in a MPLS or GMPLS environment. The users have expectations that a MPLS or GMPLS environment. Users have expectations for the
need to be met on the security characteristics of MPLS or GMPLS security characteristics of MPLS or GMPLS networks. These include
networks. These will include the security requirements for MPLS and security requirements for equipment supporting MPLS and GMPLS and
GMPLS supporting equipments, and the provider operation security operational security requirements for providers. Service providers
Fang, et al. Informational 3 Fang, et al. Informational 3
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 must protect their network infrastructure and make it secure to the
level required to provide services over their MPLS or GMPLS
requirements. The service providers must protect their network networks.
infrastructure, and make it secure to the level required to provide
services over their MPLS or GMPLS networks.
Inter-As and Inter-provider security are discussed with special Inter-AS and Inter-provider security are discussed with special
emphasis, since the security risk factors are higher with inter- emphasis, because the security risk factors are higher with inter-
provider connections. Depending on different MPLS or GMPLS provider connections. Depending on different MPLS or GMPLS
techniques used, the degree of risk and the mitigation techniques used, the degree of risk and the mitigation
methodologies vary. This document discusses the security aspects methodologies vary. This document discusses the security aspects
and requirements for certain basic MPLS and GMPLS techniques and and requirements for certain basic MPLS and GMPLS techniques and
inter-connection models. This document does not attempt to cover inter-connection models. This document does not attempt to cover
all current and future MPLS and GMPLS technologies, since it is not all current and future MPLS and GMPLS technologies, as it is not
within the scope of this document to analyze the security within the scope of this document to analyze the security
properties of specific technologies. properties of specific technologies.
It is important to clarify that, in this document; we limit It is important to clarify that, in this document, we limit
ourselves to describing the providers' security requirements that ourselves to describing the providers' security requirements that
pertain to MPLS and GMPLS networks. Readers may refer to the pertain to MPLS and GMPLS networks. Readers may refer to the
"Security Best Practices Efforts and Documents" [opsec effort] and "Security Best Practices Efforts and Documents" [opsec effort] and
"Security Mechanisms for the Internet" [RFC3631] for general "Security Mechanisms for the Internet" [RFC3631] for general
network operation security considerations. It is not our intention, network operation security considerations. It is not our intention,
however, to formulate precise "requirements" on each specific however, to formulate precise "requirements" for each specific
technology in terms of defining the mechanisms and techniques that technology in terms of defining the mechanisms and techniques that
must be implemented to satisfy such security requirements. must be implemented to satisfy such security requirements.
1.1. Structure of This Document 1.1. Structure of this Document
This document is organized as follows. In Section 2, we define the This document is organized as follows. In Section 2, we define the
terminology used in the document. In section 3, we define the terminology used. In Section 3, we define the security reference
security reference models for security in MPLS/GMPLS networks, models for security in MPLS/GMPLS networks, which we use in the
which we use in the rest of the document. In Section 4, we describe rest of the document. In Section 4, we describe the security
the security threats that are specific of MPLS and GMPLS. In threats specific to MPLS and GMPLS. In Section 5, we review
Section 5, we review defense techniques that may be used against defensive techniques that may be used against those threats. In
those threats. In Section 6, we describe how attacks may be Section 6, we describe how attacks may be detected and reported. In
detected and reported. In Section 7, we describe security Section 7, we describe security requirements providers may have to
requirements that the provider may have in order to guarantee the guarantee the security of the network infrastructure for MPLS/GMPLS
security of the network infrastructure to provide MPLS/GMPLS
services. In section 8, we discuss Inter-provider security services. In section 8, we discuss Inter-provider security
requirements. Finally, in Section 9, we discuss security requirements. Finally, in Section 9, we discuss security
considerations of this document. considerations for this document.
This document has used relevant content from RFC 4111 "Security This document has used relevant content from RFC 4111 "Security
Framework of Provider Provisioned VPN" [RFC4111], and "MPLS Framework of Provider Provisioned VPN for Provider-Provisioned
Virtual Private Networks (PPVPNs)" [RFC4111], and "MPLS
InterCarrier Interconnect Technical Specification" [MFA MPLS ICI] InterCarrier Interconnect Technical Specification" [MFA MPLS ICI]
in the Inter-provider security discussion. We acknowledge the in the Inter-provider security discussion. We acknowledge the
authors of these documents for the valuable information and text. authors of these documents for the valuable information and text.
Fang, et al. Informational 4 Fang, et al. Informational 4
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007
1.2. Contributors 1.2. Contributors
As the design team members of MPLS security Framework, the As the design team members for the MPLS Security Framework, the
following made significant contributions to this document. following made significant contributions to this document.
Nabil Bitar, Verizon
Monique Morrow, Cisco systems, Inc. Monique Morrow, Cisco systems, Inc.
Jerry Ash, AT&T Jerry Ash
2. Terminology 2. Terminology
2.1. Terminology 2.1. Terminology
This document uses MPLS and GMPLS specific terminology. Definitions This document uses MPLS and GMPLS specific terminology. Definitions
and details about MPLS and GMPLS terminology can be found in and details about MPLS and GMPLS terminology can be found in
[RFC3031] and [RFC3945]. The most important definitions are [RFC3031] and [RFC3945]. The most important definitions are
repeated in this section, for other definitions the reader is repeated in this section; for other definitions the reader is
referred to [RFC3031] and [RFC3945]. referred to [RFC3031] and [RFC3945].
CE: Customer Edge device. A Customer Edge device is a router or a Customer Edge (CE) device: A Customer Edge device is a router or a
switch in the customer network interfacing with the Service switch in the customer's network interfacing with the Service
Provider's network. Provider's network.
Forwarding equivalence class (FEC): A group of IP packets which are Forwarding Equivalence Class (FEC): A group of IP packets that are
forwarded in the same manner (e.g., over the same path, with the forwarded in the same manner (e.g., over the same path, with the
same forwarding treatment) same forwarding treatment).
Label: A short fixed length physically contiguous identifier which Label: A short, fixed length, physically contiguous identifier used
is used to identify a FEC, usually of local significance. to identify a FEC, usually of local significance.
Label switched hop: the hop between two MPLS nodes, on which Label Switched Hop: A hop between two MPLS nodes, on which
forwarding is done using labels. forwarding is done using labels.
Label switched path (LSP): The path through one or more LSRs at one Label Switched Path (LSP): The path through one or more LSRs at one
level of the hierarchy followed by a packets in a particular FEC. level of the hierarchy followed by a packets in a particular FEC.
Label switching router (LSR): an MPLS node which is capable of Label Switching Router (LSR): A MPLS node capable of forwarding
forwarding native L3 packets native L3 packets.
Layer 2: the protocol layer under layer 3 (which therefore offers Layer 2: The protocol layer under layer 3 (which therefore offers
the services used by layer 3). Forwarding, when done by the the services used by layer 3). Forwarding, when done by the
swapping of short fixed length labels, occurs at layer 2 regardless swapping of short fixed length labels, occurs at layer 2 regardless
of whether the label being examined is an ATM VPI/VCI, a frame of whether the label being examined is an ATM VPI/VCI, a frame
relay DLCI, or an MPLS label. relay DLCI, or a MPLS label.
Fang, et al. Informational 5 Fang, et al. Informational 5
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 Layer 3: The protocol layer at which IP and its associated routing
protocols operate.
Layer 3: the protocol layer at which IP and its associated routing Link Layer: Synonymous with layer 2.
protocols operate link layer synonymous with layer 2.
Loop detection: a method of dealing with loops in which loops are Loop Detection: A method of dealing with loops in which loops are
allowed to be set up, and data may be transmitted over the loop, allowed to be set up, and data may be transmitted over the loop,
but the loop is later detected. but the loop is later detected.
Loop prevention: a method of dealing with loops in which data is Loop Prevention: A method of dealing with loops in which data is
never transmitted over a loop. never transmitted over a loop.
Label stack: an ordered set of labels. Label Stack: An ordered set of labels.
Merge point: a node at which label merging is done Merge Point: A node at which label merging is done.
MPLS domain: a contiguous set of nodes which operate MPLS routing MPLS Domain: A contiguous set of nodes that perform MPLS routing
and forwarding and which are also in one Routing or Administrative and forwarding and are also in one Routing or Administrative
Domain. Domain.
MPLS edge node: an MPLS node that connects an MPLS domain with a MPLS Edge Node: A MPLS node that connects a MPLS domain with a node
node which is outside of the domain, either because it does not run outside of the domain, either because it does not run MPLS, or
MPLS, and/or because it is in a different domain. Note that if an because it is in a different domain. Note that if a LSR has a
LSR has a neighboring host which is not running MPLS, that that LSR neighboring host not running MPLS, then that LSR is a MPLS edge
is an MPLS edge node. node.
P: Provider Router. The Provider Router is a router in the Service MPLS Egress Node: A MPLS edge node in its role in handling traffic
Provider's core network that does not have interfaces directly as it leaves a MPLS domain.
towards the customer. A P router is used to interconnect the PE
routers.
MPLS egress node: an MPLS edge node in its role in handling traffic MPLS Ingress Node: A MPLS edge node in its role in handling traffic
as it leaves an MPLS domain as it enters a MPLS domain.
MPLS ingress node: an MPLS edge node in its role in handling MPLS Label: A label carried in a packet header, which represents
traffic as it enters an MPLS domain the packet's FEC.
MPLS label: a label which is carried in a packet header, and which MPLS Node: A node running MPLS. A MPLS node is aware of MPLS
represents the packet's FEC control protocols, runs one or more L3 routing protocols, and is
capable of forwarding packets based on labels. A MPLS node may
optionally be also capable of forwarding native L3 packets.
MPLS node: a node which is running MPLS. An MPLS node will be MultiProtocol Label Switching (MPLS): An IETF working group and the
aware of MPLS control protocols, will operate one or more L3 effort associated with the working group.
routing protocols, and will be capable of forwarding packets based
on labels. An MPLS node may optionally be also capable of
forwarding native L3 packets.
MultiProtocol Label Switching (MPLS): an IETF working group and the P: Provider Router. A Provider Router is a router in the Service
effort associated with the working group Provider's core network that does not have interfaces directly
towards the customer. A P router is used to interconnect the PE
routers.
Fang, et al. Informational 6 Fang, et al. Informational 6
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 PE: Provider Edge device. A Provider Edge device is the equipment
PE: Provider Edge device. The Provider Edge device is the equipment
in the Service Provider's network that interfaces with the in the Service Provider's network that interfaces with the
equipment in the customer's network. equipment in the customer's network.
SP: Service Provider. VPN: Virtual Private Network, which restricts communication between
a set of sites, making use of an IP backbone shared by traffic not
VPN: Virtual Private Network. Restricted communication between a going to or not coming from those sites ([RFC4110]).
set of sites, making use of an IP backbone which is shared by
traffic that is not going to or coming from those sites. [RFC4110].
2.2. Acronyms and Abbreviations 2.2. Acronyms and Abbreviations
AS Autonomous System AS Autonomous System
ASBR Autonomous System Border Router ASBR Autonomous System Border Router
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol BGP Border Gateway Protocol
DoS Denial of Service
FEC Forwarding Equivalence Class FEC Forwarding Equivalence Class
GMPLS Generalized Multi-Protocol Label Switching GMPLS Generalized Multi-Protocol Label Switching
ICI InterCarrier Interconnect
IGP Interior Gateway Protocol IGP Interior Gateway Protocol
IP Internet Protocol IP Internet Protocol
LDP Label Distribution Protocol LDP Label Distribution Protocol
L2 Layer 2 L2 Layer 2
L3 Layer 3 L3 Layer 3
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
MPLS MultiProtocol Label Switching MPLS MultiProtocol Label Switching
MP-BGP Multi-Protocol BGP MP-BGP Multi-Protocol BGP
PCE Path Calculation Element PCE Path Computation Element
PPVPN Provider-Provisioned Vitual Private Network
PSN Packet-Switched Network PSN Packet-Switched Network
RR Route Reflector
RSVP-TE Resource Reservation Protocol with Traffic Engineering RSVP-TE Resource Reservation Protocol with Traffic Engineering
Extensions Extensions
SP Service Provider
TTL Time-To-Live TTL Time-To-Live
VPN Virtual Private Network VPN Virtual Private Network
3. Security Reference Models 3. Security Reference Models
This section defines a reference model for security in MPLS/GMPLS This section defines a reference model for security in MPLS/GMPLS
networks. networks.
A MPLS/GMPLS core network is defined here as the central network A MPLS/GMPLS core network is defined here as the central network
infrastructure (P and PE routers). A MPLS/GMPLS core network infrastructure (P and PE routers). A MPLS/GMPLS core network
consists of one or more SP networks. All network elements in the consists of one or more SP networks. All network elements in the
core are under the operational control of one or more MPLS/GMPLS core are under the operational control of one or more MPLS/GMPLS
service providers. Even if the MPLS/GMPLS core is provided by
several service providers, towards the end users it appears as a
single zone of trust. However, when several service providers
Fang, et al. Informational 7 Fang, et al. Informational 7
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 SPs. Even if the MPLS/GMPLS core is provided by several SPs,
towards the end users it appears as a single zone of trust.
provide together an MPLS/GMPLS core, each SP still needs to secure However, when several SPs together provide a MPLS/GMPLS core, each
itself against the other SPs. SP still needs to secure itself against the other SPs.
A MPLS/GMPLS end user is a company, institution or residential A MPLS/GMPLS end user is a company, institution, or residential
client of the SP. client of the SP.
This document defines each MPLS in a single domain a trusted zone. This document defines each MPLS/GMPLS core in a single domain to be
A primary concern is about security aspects that relate to breaches a trusted zone. A primary concern is about security aspects that
of security from the "outside" of a trusted zone to the "inside" of relate to breaches of security from the "outside" of a trusted zone
this zone. Figure 1 depicts the concept of trusted zones within the to the "inside" of this zone. Figure 1 depicts the concept of
MPLS/GMPLS framework. trusted zones within the MPLS/GMPLS framework.
/-------------\ /-------------\
+------------+ / \ +------------+ +------------+ / \ +------------+
| MPLS/GMPLS +---/ \--------+ MPLS | | MPLS/GMPLS +---/ \--------+ MPLS |
| user | MPLS/GMPLS Core | user | | user | MPLS/GMPLS Core | user |
| site +---\ /XXX-----+ site | | site +---\ /XXX-----+ site |
+------------+ \ / XXX +------------+ +------------+ \ / XXX +------------+
\-------------/ | | \-------------/ | |
| | | |
| +------\ | +------\
+--------/ "Internet" +--------/ "Internet"
MPLS/GMPLS Core with user connections and Internet connection MPLS/GMPLS Core with user connections and Internet connection
Figure 1: The MPLS/GMPLS trusted zone model Figure 1: The MPLS/GMPLS trusted zone model.
The trusted zone defined is the MPLS/GMPLS core/network in a single The trusted zone is the MPLS/GMPLS core in a single AS within a
AS within a single Service Provider. single Service Provider.
In principle the trusted zones should be separate; however, The boundaries of a trust domain should be carefully defined when
analyzing the security property of each individual network, e.g.,
the boundaries can be at the link termination, remote peers, areas,
or quite commonly, ASes.
In principle, the trusted zones should be separate; however,
typically MPLS core networks also offer Internet access, in which typically MPLS core networks also offer Internet access, in which
case a transit point (marked with "XXX" in the figure 1) is case a transit point (marked with "XXX" in Figure 1) is defined. In
defined. In the case of MPLS/GMPLS inter-provider connection, the the case of MPLS/GMPLS inter-provider connections, the trusted zone
trusted zone ends at the ASBR (marked with "B" in the figure 2) of ends at the ASBR (marked with "B" in Figure 2) of the given AS or
the considered AS/provider. provider.
Fang, et al. Informational 8
MPLS/GMPLS Security framework
A key requirement of MPLS and GMPLS networks is that the security A key requirement of MPLS and GMPLS networks is that the security
of the trusted zone not be compromised by interconnecting the of the trusted zone not be compromised by interconnecting the
MPLS/GMPLS core infrastructure with another provider core MPLS/GMPLS core infrastructure with another provider's core
(MPLS/GMPLS or non-MPLS/GMPLS), Internet, or end user access. (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users.
In addition, neighbors may be trusted or untrusted. Neighbors may In addition, neighbors may be trusted or untrusted. Neighbors may
be authorized or unauthorized. Even though a neighbor may be be authorized or unauthorized. Even though a neighbor may be
authorized for communication, it may not be trusted. For example, authorized for communication, it may not be trusted. For example,
when connecting with another provider's ASBRs to set up inter-AS
Fang, et al. Informational 8 LSPs, the other provider is considered an untrusted but authorized
MPLS/GMPLS Security framework neighbor.
February 2007
when connecting with another provider ASBRs to set up inter-AS
LSPs, the other provider is considered as an untrusted but
authorized neighbor.
+---------------+ +----------------+ +---------------+ +----------------+
| | | | | | | |
| MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS | | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS |
CE1--PE1 Network | | Network PE2--CE2 CE1--PE1 Network | | Network PE2--CE2
| Provider A ASBR2----ASBR4 Provider B | | Provider A ASBR2----ASBR4 Provider B |
| | | | | | | |
+---------------+ +----------------+ +---------------+ +----------------+
For Provider A: For Provider A:
Trusted Zone: Provider A MPSL/GMPLS network Trusted Zone: Provider A MPSL/GMPLS network
Trusted neighbor: PE1, ASBR1, ASBR2 Trusted neighbors: PE1, ASBR1, ASBR2
Authorized but untrusted neighbor: provider B Authorized but untrusted neighbor: provider B
Unauthorized neighbor: CE1, CE2 Unauthorized neighbors: CE1, CE2
Figure 2. MPLS/GMPLS trusted zone and authorized neighbor
Security against threats that originate within the same trusted Figure 2. MPLS/GMPLS trusted zone and authorized neighbor.
zone as their targets (for example, attacks from within the core
network) is outside the scope of this document.
Also outside the scope are all aspects of network security which All aspects of network security independent of whether a network is
are independent of whether a network is a MPLS/GMPLS network (for a MPLS/GMPLS network are out of scope. For example, attacks from
example, attacks from the Internet to a user web-server which is the Internet to a user's web-server connected through the
connected through the MPLS/GMPLS network will not be considered MPLS/GMPLS network are not considered here, unless the way the
here, unless the way the MPLS/GMPLS network is provisioned could MPLS/GMPLS network is provisioned could make a difference to the
make a difference to the security of this user server). security of this user's server.
4. Security Threats 4. Security Threats
This section discusses the various network security threats that This section discusses the various network security threats that
may endanger MPLS/GMPLS networks. The discussion is limited to may endanger MPLS/GMPLS networks. The discussion is limited to
those threats that are unique to MPLS/GMPLS networks, or that those threats that are unique to MPLS/GMPLS networks or that affect
affect MPLS/GMPLS network in unique ways. MPLS/GMPLS network in unique ways.
A successful attack on a particular MPLS/GMPLS network or on a
service provider's MPLS/GMPLS infrastructure may cause one or more
of the following ill effects:
- Observation, modification, or deletion of provider/user data. A successful attack on a particular MPLS/GMPLS network or on a SP's
- Replay of provider/user data. MPLS/GMPLS infrastructure may cause one or more of the following
ill effects:
Fang, et al. Informational 9 Fang, et al. Informational 9
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 - Observation, modification, or deletion of a provider's or user's
data.
- Injection of non-authentic data into a provider/user traffic - Replay of a provider's or user's data.
stream. - Injection of inauthentic data into a provider's or user's
- Traffic pattern analysis on provider/user traffic. traffic stream.
- Disruption of provider/user connectivity. - Traffic pattern analysis on a provider's or user's traffic.
- Degradation of provider service quality. - Disruption of a provider's or user's connectivity.
- Degradation of a provider's service quality.
It is useful to consider that threats, whether malicious or It is useful to consider that threats, whether malicious or
accidental, may come from different categories of sources. For accidental, may come from different categories of sources. For
example they may come from: example they may come from:
- Other users whose services are provided by the same MPLS/GMPLS - Other users whose services are provided by the same MPLS/GMPLS
core. core.
- The MPLS/GMPLS service provider or persons working for it. - The MPLS/GMPLS SP or persons working for it.
- Other persons who obtain physical access to a MPLS/GMPLS service - Other persons who obtain physical access to a MPLS/GMPLS SP's
provider site. site.
- Other persons who use social engineering methods to influence - Other persons who use social engineering methods to influence
behavior of service provider personnel. the behavior of a SP's personnel.
- Users of the MPLS/GMPLS network itself, i.e. intra-VPN threats. - Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats.
(Such threats are beyond the scope of this document.) (Such threats are beyond the scope of this document.)
- Others i.e. attackers from the Internet at large. - Others, e.g., attackers from the Internet at large.
- Other service provider in the case of MPLS/GMPLS Inter-provider - Other SPs in the case of MPLS/GMPLS Inter-
connection. The core of the other provider may or may not be using provider connection. The core of the other provider may or may
MPLS/GMPLS core. not be using MPLS/GMPLS.
- Those who create, deliver, install, and maintain software for
network equipment.
Given that security is generally a compromise between expense and Given that security is generally a tradeoff between expense and
risk, it is also useful to consider the likelihood of different risk, it is also useful to consider the likelihood of different
attacks occurring. There is at least a perceived difference in the attacks occurring. There is at least a perceived difference in the
likelihood of most types of attacks being successfully mounted in likelihood of most types of attacks being successfully mounted in
different environments, such as: different environments, such as:
- A MPLS/GMPLS inter-connecting with another provider's core - A MPLS/GMPLS core inter-connecting with another provider's core
- A MPLS/GMPLS transiting the public Internet - A MPLS/GMPLS configuration transiting the public Internet
Most types of attacks become easier to mount and hence more likely Most types of attacks become easier to mount and hence more likely
as the shared infrastructure via which service is provided expands as the shared infrastructure via which service is provided expands
from a single service provider to multiple cooperating providers to from a single SP to multiple cooperating SPs to the global
the global Internet. Attacks that may not be of sufficient Internet. Attacks that may not be of sufficient likeliness to
likeliness to warrant concern in a closely controlled environment warrant concern in a closely controlled environment often merit
often merit defensive measures in broader, more open environments. defensive measures in broader, more open environments. In closed
communities, it is often practical to deal with misbehavior after
the fact: an employee can be disciplined, for example.
Fang, et al. Informational 10
MPLS/GMPLS Security framework
The following sections discuss specific types of exploits that The following sections discuss specific types of exploits that
threaten MPLS/GMPLS networks. threaten MPLS/GMPLS networks.
4.1. Attacks on the Control Plane 4.1. Attacks on the Control Plane
This category encompasses attacks on the control structures This category encompasses attacks on the control structures
operated by the service provider with MPLS/GMPLS cores. operated by the SP with MPLS/GMPLS cores.
Fang, et al. Informational 10
MPLS/GMPLS Security framework
February 2007
4.1.1. LSP creation by an unauthorized element 4.1.1. LSP creation by an unauthorized element
The unauthorized element can be a local CE or a router in another The unauthorized element can be a local CE or a router in another
domain. An unauthorized element can generate MPLS signaling domain. An unauthorized element can generate MPLS signaling
messages. At the least, this can result in extra control plane and messages. At the least, this can result in extra control plane and
forwarding state, and if successful, network bandwidth could be forwarding state, and if successful, network bandwidth could be
reserved unnecessarily. reserved unnecessarily. This may also result in theft of service
and loss of revenue.
4.1.2. LSP message interception 4.1.2. LSP message interception
This threat might be accomplished by monitoring network traffic, This threat might be accomplished by monitoring network traffic,
although it would require physical intrusion. If successful, it for example, after a physical intrusion. Without physical
could provide information leading to label spoofing attacks. It intrusion, it could be accomplished with an unauthorized software
also raises confidentiality issues. modification. Also many technologies such as terrestrail microwave,
satellite, or free-space optical could be intercepted without
physical intrusion. If successful, it could provide information
leading to label spoofing attacks. It also raises confidentiality
issues.
4.1.3. Attacks against RSVP-TE 4.1.3. Attacks against RSVP-TE
RSVP-TE, described in [RFC3209], is the control protocol used to RSVP-TE, described in [RFC3209], is the control protocol used to
set up GMPLS and traffic engineered MPLS tunnels. set up GMPLS and traffic engineered MPLS tunnels.
There are two major types of attacks against an MPLS domain based There are two major types of Denial of Dervice (DoS) attacks
on RSVP-TE. The attacker may set up numerous unauthorized LSPs, or against a MPLS domain based on RSVP-TE. The attacker may set up
may send a storm of RSVP messages in a DoS attack. It has been numerous unauthorized LSPs or may send a storm of RSVP messages.
demonstrated that unprotected routers running RSVP can be It has been demonstrated that unprotected routers running RSVP can
effectively disabled by both types of DoS attacks. be effectively disabled by both types of DoS attacks.
These attacks may even be combined, by using the unauthorized LSPs These attacks may even be combined, by using the unauthorized LSPs
to transport additional RSVP (or other) messages across routers to transport additional RSVP (or other) messages across routers
where they might otherwise be filtered out. RSVP attacks can be where they might otherwise be filtered out. RSVP attacks can be
launched against adjacent routers at the border with the attacker, launched against adjacent routers at the border with the attacker,
or against non-adjacent routers within the MPLS domain, if there is or against non-adjacent routers within the MPLS domain, if there is
no effective mechanism to filter them out. no effective mechanism to filter them out.
4.1.4. Attacks against LDP Fang, et al. Informational 11
MPLS/GMPLS Security framework
4.1.4. Attacks against LDP
LDP, described in [RFC3036], is the control protocol used to set up LDP, described in [RFC3036], is the control protocol used to set up
non-TE MPLS tunnels. MPLS tunnels without TE.
There are two significant types of attack against LDP. An There are two significant types of attack against LDP. An
unauthorized network element can establish an LDP session by unauthorized network element can establish a LDP session by sending
sending LDP Hello and LDP Init messages, leading to the potential LDP Hello and LDP Init messages, leading to the potential setup of
setup of an LSP, as well as accompanying LDP state table a LSP, as well as accompanying LDP state table consumption. Even
consumption. Even without successfully established LSPs, an without successfully establishing LSPs, an attacker can launch a
attacker can launch a DoS attack in the form of a storm of LDP DoS attack in the form of a storm of LDP Hello messages or LDP TCP
Hello messages and/or LDP TCP Syn messages, leading to high CPU Syn messages, leading to high CPU utilization on the target router.
utilization on the target router.
Fang, et al. Informational 11
MPLS/GMPLS Security framework
February 2007
4.1.5. Denial of Service Attacks on the Network Infrastructure 4.1.5. Denial of Service Attacks on the Network Infrastructure
DoS attacks could be accomplished through an MPLS signaling storm, DoS attacks could be accomplished through a MPLS signaling storm,
resulting in high CPU utilization and possibly leading to control resulting in high CPU utilization and possibly leading to control
plane resource starvation. plane resource starvation.
Control plane DOS attacks can be mounted specifically against the Control plane DoS attacks can be mounted specifically against the
mechanisms the service provider uses to provide various services, mechanisms the SPuses to provide various services, or against the
or against the general infrastructure of the service provider e.g. general infrastructure of the service provider, e.g., P routers or
P routers or shared aspects of PE routers. (Attacks against the shared aspects of PE routers. (An attack against the general
general infrastructure are within the scope of this document only infrastructure is within the scope of this document only if the
if the attack happens in relation with the MPLS/GMPLS attack can occur in relation with the MPLS/GMPLS infrastructure;
infrastructure, otherwise is not MPLS/GMPLS-specific issue.) otherwise is not a MPLS/GMPLS-specific issue.)
The attacks described in the following sections may each have The attacks described in the following sections may each have
denial of service as one of their effects. Other DOS attacks are denial of service as one of their effects. Other DoS attacks are
also possible. also possible.
4.1.6. Attacks on the Service Provider MPLS/GMPLS Equipment Via 4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via Management
Management Interfaces Interfaces
This includes unauthorized access to service provider This includes unauthorized access to a SP's infrastructure
infrastructure equipment, for example to reconfigure the equipment equipment, for example to reconfigure the equipment or to extract
or to extract information (statistics, topology, etc.) pertaining information (statistics, topology, etc.) pertaining to the network.
to the network.
4.1.7. Social Engineering Attacks on the Service Provider 4.1.7. Social Engineering Attacks on the SP's Infrastructure
Infrastructure
Attacks in which the service provider network is reconfigured or Attacks in which the service provider network is reconfigured or
damaged, or in which confidential information is improperly damaged, or in which confidential information is improperly
disclosed, may be mounted through manipulation of service provider disclosed, may be mounted by manipulation of a SP's personnel.
personnel. These types of attacks are MPLS/GMPLS-specific if they These types of attacks are MPLS/GMPLS-specific if they affect
affect MPLS/GMPLS-serving mechanisms. MPLS/GMPLS-serving mechanisms.
4.1.8. Cross-connection of Traffic Between Users
This refers to the event where expected isolation between separate
users (who may be VPN users) is breached. This includes cases such
as:
- A site being connected into the "wrong" VPN.
- Traffic being replicated and sent to an unauthorized
user.
- Two or more VPNs being improperly merged together.
- A point-to-point VPN connecting the wrong two points.
Fang, et al. Informational 12 Fang, et al. Informational 12
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 4.1.8. Cross-Connection of Traffic between Users
This refers to the event in which expected isolation between
separate users (who may be VPN users) is breached. This includes
cases such as:
- A site being connected into the "wrong" VPN
- Traffic being replicated and sent to an unauthorized user
- Two or more VPNs being improperly merged together
- A point-to-point VPN connecting the wrong two points
- Any packet or frame being improperly delivered outside the VPN - Any packet or frame being improperly delivered outside the VPN
to which it belongs. to which it belongs
Mis-connection or cross-connection of VPNs may be caused by service Mis-connection or cross-connection of VPNs may be caused by service
provider or equipment vendor error, or by the malicious action of provider or equipment vendor error, or by the malicious action of
an attacker. The breach may be physical (e.g. PE-CE links mis- an attacker. The breach may be physical (e.g., PE-CE links mis-
connected) or logical (improper device configuration). connected) or logical (e.g., improper device configuration).
Anecdotal evidence suggests that the cross-connection threat is one Anecdotal evidence suggests that the cross-connection threat is one
of the largest security concerns of users (or would-be users). of the largest security concerns of users (or would-be users).
4.1.9. Attacks Against User Routing Protocols 4.1.9. Attacks against Routing Protocols
This encompasses attacks against underlying routing protocols that This encompasses attacks against underlying routing protocols that
are run by the service provider and that directly support the are run by the SP and that directly support the MPLS/GMPLS core.
MPLS/GMPLS core. (Attacks against the use of routing protocols for (Attacks against the use of routing protocols for the distribution
the distribution of backbone (non-VPN) routes are beyond the scope of backbone routes are beyond the scope of this document.)
of this document.) Specific attacks against popular routing Specific attacks against popular routing protocols have been widely
protocols have been widely studied and described in [Beard]. studied and described in [Beard].
4.1.10. Other Attacks on Control Traffic 4.1.10. Other Attacks on Control Traffic
Besides routing and management protocols (covered separately in the Besides routing and management protocols (covered separately in the
previous sections) a number of other control protocols may be previous sections), a number of other control protocols may be
directly involved in delivering the services by the MPLS/GMPLS directly involved in delivering services by the MPLS/GMPLS core.
core. These include but may not be limited to: These include but may not be limited to:
- MPLS signaling (LDP, RSVP-TE) discussed above in subsections - MPLS signaling (LDP, RSVP-TE) discussed above in subsections
4.1.4 and 4.1.3 4.1.4 and 4.1.3
- PCE signaling - PCE signaling
- IPsec signaling (IKE) - IPsec signaling (IKE and IKEv2)
- ICMP and ICMPv6
- L2TP - L2TP
- BGP-based membership discovery - BGP-based membership discovery
- Database-based membership discovery (e.g. RADIUS-based) - Database-based membership discovery (e.g., RADIUS)
- Other protocols that may be important to the control
infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE.
Fang, et al. Informational 13
MPLS/GMPLS Security framework
Attacks might subvert or disrupt the activities of these protocols, Attacks might subvert or disrupt the activities of these protocols,
for example via impersonation or DOS attacks. for example via impersonation or DoS.
4.2. Attacks on the Data Plane 4.2. Attacks on the Data Plane
This category encompasses attacks on the provider or end user's This category encompasses attacks on the provider's or end user's
data. Note that from the MPLS/GMPLS network end user's point of data. Note that from the MPLS/GMPLS network end user's point of
view, some of this might be control plane traffic, e.g. routing view, some of this might be control plane traffic, e.g. routing
protocols running from the user site A to the user site B via an L2 protocols running from user site A to user site B via a L2 or L3
or L3 connection which may be some type of VPN. connection, which may be some type of VPN.
Fang, et al. Informational 13
MPLS/GMPLS Security framework
February 2007
4.2.1. Unauthorized Observation of Data Traffic 4.2.1. Unauthorized Observation of Data Traffic
This refers to "sniffing" provider/end user packets and examining This refers to "sniffing" provider or end user packets and
their contents. This can result in exposure of confidential examining their contents. This can result in exposure of
information. It can also be a first step in other attacks confidential information. It can also be a first step in other
(described below) in which the recorded data is modified and re- attacks (described below) in which the recorded data is modified
inserted, or re-inserted as-is. and re-inserted, or simply replayed later.
4.2.2. Modification of Data Traffic 4.2.2. Modification of Data Traffic
This refers to modifying the contents of packets as they traverse This refers to modifying the contents of packets as they traverse
the MPLS/GMPLS core. the MPLS/GMPLS core.
4.2.3. Insertion of Non-Authentic Data Traffic: Spoofing and 4.2.3. Insertion of Inauthentic Data Traffic: Spoofing and Replay
Replay
This refers to the insertion (or "spoofing") into the user packets Spoofing refers to sending a user or inserting into a data stream
that do not belong there, with the objective of having them packets that do not belong, with the objective of having them
accepted by the recipient as legitimate. Also included in this accepted by the recipient as legitimate. Also included in this
category is the insertion of copies of once-legitimate packets that category is the insertion of copies of once-legitimate packets that
have been recorded and replayed. have been recorded and replayed.
4.2.4. Unauthorized Deletion of Data Traffic 4.2.4. Unauthorized Deletion of Data Traffic
This refers to causing packets to be discarded as they traverse the This refers to causing packets to be discarded as they traverse the
MPLS/GMPLS networks. This is a specific type of Denial of Service MPLS/GMPLS networks. This is a specific type of Denial of Service
attack. attack.
4.2.5. Unauthorized Traffic Pattern Analysis 4.2.5. Unauthorized Traffic Pattern Analysis
This refers to "sniffing" provider/user packets and examining This refers to "sniffing" provider or user packets and examining
aspects or meta-aspects of them that may be visible even when the aspects or meta-aspects of them that may be visible even when the
packets themselves are encrypted. An attacker might gain useful packets themselves are encrypted. An attacker might gain useful
information based on the amount and timing of traffic, packet information based on the amount and timing of traffic, packet
sizes, source and destination addresses, etc. For most users, this sizes, source and destination addresses, etc. For most users, this
Fang, et al. Informational 14
MPLS/GMPLS Security framework
type of attack is generally considered to be significantly less of type of attack is generally considered to be significantly less of
a concern than the other types discussed in this section. a concern than the other types discussed in this section.
4.2.6. Denial of Service Attacks 4.2.6. Denial of Service Attacks
Denial of Service (DOS) attacks are those in which an attacker Denial of Service (DoS) attacks are those in which an attacker
attempts to disrupt or prevent the use of a service by its attempts to disrupt or prevent the use of a service by its
legitimate users. Taking network devices out of service, modifying legitimate users. Taking network devices out of service, modifying
their configuration, or overwhelming them with requests for service their configuration, or overwhelming them with requests for service
are several of the possible avenues for DOS attack. are several of the possible avenues for DoS attack.
Overwhelming the network with requests for service, otherwise known Overwhelming the network with requests for service, otherwise known
as a "resource exhaustion" DOS attack, may target any resource in as a "resource exhaustion" DoS attack, may target any resource in
the network, e.g., link bandwidth, packet forwarding capacity,
Fang, et al. Informational 14 session capacity for various protocols, CPU power, table size,
MPLS/GMPLS Security framework storage overflows, and so on.
February 2007
the network e.g. link bandwidth, packet forwarding capacity,
session capacity for various protocols, CPU power, and so on.
DOS attacks of the resource exhaustion type can be mounted against DoS attacks of the resource exhaustion type can be mounted against
the data plane of a particular provider or end-user by attempting the data plane of a particular provider or end user by attempting
to insert (spoofing) an overwhelming quantity of non-authentic data to insert (spoofing) an overwhelming quantity of inauthentic data
into the provider/end user network from the outside of the trusted into the provider or end user network from the outside of the
zone. Potential results might be to exhaust the bandwidth available trusted zone. Potential results might be to exhaust the bandwidth
to that provider/end user or to overwhelm the cryptographic available to that provider or end user or to overwhelm the
authentication mechanisms of the provider or end user. cryptographic authentication mechanisms of the provider or end
user.
Data plane resource exhaustion attacks can also be mounted by Data plane resource exhaustion attacks can also be mounted by
overwhelming the service provider's general (MPLS/GMPLS- overwhelming the service provider's general (MPLS/GMPLS-
independent) infrastructure with traffic. These attacks on the independent) infrastructure with traffic. These attacks on the
general infrastructure are not usually a MPLS/GMPLS-specific issue, general infrastructure are not usually a MPLS/GMPLS-specific issue,
unless the attack is mounted by another MPLS/GMPLS network user unless the attack is mounted by another MPLS/GMPLS network user
from a privileged position. (E.g. a MPLS/GMPLS network user might from a privileged position. (E.g., a MPLS/GMPLS network user might
be able to monopolize network data plane resources and thus disrupt be able to monopolize network data plane resources and thus disrupt
other users.) other users.)
Many DoS attacks use amplification, whereby the attacker co-opts
otherwise innocent parties to increase the effect of the attack.
The attacker may, for example, send packets to a broadcast or
multicast address with the spoofed source address of the victim,
and all of the recipients may then respond to the victim.
5. Defensive Techniques for MPLS/GMPLS Networks 5. Defensive Techniques for MPLS/GMPLS Networks
The defensive techniques discussed in this document are intended to The defensive techniques discussed in this document are intended to
describe methods by which some security threats can be addressed. describe methods by which some security threats can be addressed.
They are not intended as requirements for all MPLS/GMPLS They are not intended as requirements for all MPLS/GMPLS
implementations. The MPLS/GMPLS provider should determine the implementations. The MPLS/GMPLS provider should determine the
Fang, et al. Informational 15
MPLS/GMPLS Security framework
applicability of these techniques to the provider's specific applicability of these techniques to the provider's specific
service offerings, and the end user may wish to assess the value of service offerings, and the end user may wish to assess the value of
these techniques to the user's service requirements. 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, The techniques discussed here include encryption, authentication,
filtering, firewalls, access control, isolation, aggregation, and filtering, firewalls, access control, isolation, aggregation, and
other techniques. other techniques.
Often, security is achieved by careful protocol design, rather than
by adding a security method. For example, one method of mitigating
DoS attacks is to make sure that innocent parties cannot be used to
amplify the attack. Security works better when it is "designed in"
rather than "added on."
Nothing is ever 100% secure. Defense therefore involves protecting Nothing is ever 100% secure. Defense therefore involves protecting
against those attacks that are most likely to occur and/or that against those attacks that are most likely to occur or that have
have the most dire consequences if successful. For those attacks the most direct consequences if successful. For those attacks that
that are protected against, absolute protection is seldom are protected against, absolute protection is seldom achievable;
achievable; more often it is sufficient just to make the cost of a more often it is sufficient just to make the cost of a successful
successful attack greater than what the adversary will be willing attack greater than what the adversary will be willing or able to
to expend. expend.
Successfully defending against an attack does not necessarily mean Successfully defending against an attack does not necessarily mean
the attack must be prevented from happening or from reaching its the attack must be prevented from happening or from reaching its
target. In many cases the network can instead be designed to target. In many cases the network can instead be designed to
withstand the attack. For example, the introduction of non- withstand the attack. For example, the introduction of inauthentic
authentic packets could be defended against by preventing their packets could be defended against by preventing their introduction
in the first place, or by making it possible to identify and
eliminate them before delivery to the MPLS/GMPLS user's system.
The latter is frequently a much easier task.
Fang, et al. Informational 15 5.1. Authentication
To prevent security issues arising from some Denial-of-Service
attacks or from malicious or accidental misconfiguration, it is
critical that devices in the MPLS/GMPLS 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/GMPLS 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.
Fang, et al. Informational 16
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 Cryptographic techniques (authentication, integrity, and
encryption) do not protect against some types of denial of service
attacks, specifically resource exhaustion attacks based on CPU or
bandwidth exhaustion. In fact, the processing required to decrypt
or check authentication may, in the case of software crypto, in
some cases increase the effect of these resource exhaustion
attacks. With a hardware crypto accelerator, attack packets can be
dropped at line speed without a cost of software cycles.
Cryptographic techniques may, however, be useful against resource
exhaustion attacks based on exhaustion of state information (e.g.,
TCP SYN attacks).
introduction in the first place, or by making it possible to The MPLS user plane, as presently defined, is not amenable to
identify and eliminate them before delivery to the MPLS/GMPLS source authentication as there are no source identifiers in the
user's system. The latter is frequently a much easier task. MPLS packet to authenticate. The MPLS label is only locally
meaningful, and it identifies a downstream semantic rather than an
upstream source.
5.1. Cryptographic techniques When the MPLS payload carries identifiers that may be authenticated
(e.g., IP packets), authentication may be carried out at the client
level, but this does not help the MPLS SP, as these client
identifiers belong to an external, untrusted network.
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.
5.1.2. Peer-to-Peer Authentication
Peer-to-peer authentication includes peer authentication for
network control protocols (e.g., LDP, BGP, etc.), and other peer
authentication (i.e., authentication of one IPsec security gateway
by another).
5.1.3. Cryptographic techniques for authenticating identity
Cryptographic techniques offer several mechanisms for
authenticating the identity of devices or individuals. These
Fang, et al. Informational 17
MPLS/GMPLS Security framework
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.
This section describes or provides references to the specific
cryptographic approaches for authenticating identity. These
approaches provide secure mechanisms for most of the authentication
scenarios required in securing a MPLS/GMPLS network.
5.2. Cryptographic techniques
MPLS/GMPLS defenses against a wide variety of attacks can be MPLS/GMPLS defenses against a wide variety of attacks can be
enhanced by the proper application of cryptographic techniques. enhanced by the proper application of cryptographic techniques.
These are the same cryptographic techniques which are applicable to These are the same cryptographic techniques that are applicable to
general network communications. In general, these techniques can general network communications. In general, these techniques can
provide confidentiality (encryption) of communication between provide confidentiality (encryption) of communication between
devices, authentication of the identities of the devices, and can devices, can authenticate the identities of the devices, and can
ensure that it will be detected if the data being communicated is ensure that it will be detected if the data being communicated is
changed during transit. changed during transit.
Several aspects of authentication are addressed in some detail in a Several aspects of authentication are addressed in some detail in a
separate "Authentication" section. separate "Authentication" section.
Encryption adds complexity to a service, and thus it may not be a Cryptographic methods add complexity to a service and thus, for a
standard offering within every user service. There are a few few reasons, may not be the most practical soloution in every case.
reasons why encryption may not be a standard offering within every Cryptography adds an additional computational burden to devices,
user service. Encryption adds an additional computational burden to which may reduce the number of user connections that can be handled
the devices performing encryption and decryption. This may reduce on a device or otherwise reduce the capacity of the device,
the number of user connections which can be handled on a device or potentially driving up the provider's costs. Typically,
otherwise reduce the capacity of the device, potentially driving up configuring encryption services on devices adds to the complexity
the provider's costs. Typically, configuring encryption services of their configuration and adds labor cost. Some key management
on devices adds to the complexity of the device configuration and system is usually needed. Packet sizes are typically increased when
adds incremental labor cost. Packet sizes are typically increased the packets are encrypted or have integrity checks or replay
when the packets are secured, increasing the network traffic load counters added, increasing the network traffic load and adding to
and adding to the likelihood of packet fragmentation with its the likelihood of packet fragmentation with its increased overhead.
increased overhead. (This packet length increase can often be (This packet length increase can often be mitigated to some extent
mitigated to some extent by data compression techniques, but at the by data compression techniques, but at the expense of additional
expense of additional computational burden.) Finally, some computational burden.) Finally, some providers may employ enough
providers may employ enough other defensive techniques, such as other defensive techniques, such as physical isolation or filtering
physical isolation or filtering/firewall techniques, that they may and firewall techniques, that they may not perceive additional
not perceive additional benefit from encryption techniques. benefit from encryption techniques.
Users may wish to provide confidentiality end to end. Generally,
encrypting for confidentiality must be accompanied with
cryptographic integrity checks to prevent certain active attacks
Fang, et al. Informational 18
MPLS/GMPLS Security framework
against the encrypted communications. On today's processors,
encryption and integrity checks run extremely quickly, but key
management may be more demanding in terms of both computational and
administrative overhead.
The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider, The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider,
and other parts of the network is a key element in determining the and other parts of the network is a major element in determining
applicability of encryption for any specific MPLS/GMPLS the applicability of cryptographic protection for any specific
implementation. In particular, it determines where encryption MPLS/GMPLS implementation. In particular, it determines where
should be applied: cryptographic protection should be applied:
- If the data path between the user's site and the - If the data path between the user's site and the
provider's PE is not trusted, then encryption may be used provider's PE is not trusted, then it may be used on the
on the PE-CE link. PE-CE link.
- If some part of the backbone network is not trusted, - If some part of the backbone network is not trusted,
particularly in implementations where traffic may travel particularly in implementations where traffic may travel
across the Internet or multiple providers' networks, then
Fang, et al. Informational 16 the PE-PE traffic may be cryptographically protected. One
MPLS/GMPLS Security framework also should consider cases where L1 technology may be
February 2007 vulnerable to eavesdropping.
across the Internet or multiple provider networks, then
the PE-PE traffic may be encrypted.
- If the user does not trust any zone outside of its - If the user does not trust any zone outside of its
premises, it may require end-to-end or CE-CE encryption premises, it may require end-to-end or CE-CE
service. This service fits within the scope of this cryptotographic protection. This fits within the scope of
MPLS/GMPLS security framework when the CE is provisioned this MPLS/GMPLS security framework when the CE is
by the MPLS/GMPLS provider. provisioned by the MPLS/GMPLS provider.
- If the user requires remote access to a its site from a - If the user requires remote access to its site from a
system at a location which is not a customer location (for system at a location that is not a customer location (for
example, access by a traveler) there may be a requirement example, access by a traveler) there may be a requirement
for encrypting the traffic between that system and an for cryptographically protecting the traffic between that
access point or at a customer site. If the MPLS/GMPLS system and an access point or a customer's site. If the
provider provides the access point, then the customer must MPLS/GMPLS provider supplies the access point, then the
cooperate with the provider to handle the access control customer must cooperate with the provider to handle the
services for the remote users. These access control access control services for the remote users. These access
services are usually implemented using encryption, as control services are usually protected cryptographically,
well. as well.
Although CE-CE encryption provides confidentiality against third- Access control usually starts with authentication of the
party interception, if the MPLS/GMPLS provider has complete entity. If cryptographic services are part of the scenario,
management control over the CE (encryption) devices, then it may be then it is important to bind the authentication to the key
possible for the provider to gain access to the user's traffic or management. Otherwise the protocol is vulnerable to being
internal network. Encryption devices can potentially be configured hijacked between the authentication and key management.
to use null encryption, bypass encryption processing altogether, or
provide some means of sniffing or diverting unencrypted traffic. Although CE-CE cryptographic protection can provide integrity and
confidentiality against third parties, if the MPLS/GMPLS provider
has complete management control over the CE (encryption) devices,
then it may be possible for the provider to gain access to the
user's traffic or internal network. Encryption devices could
potentially be reconfigured to use null encryption, bypass
Fang, et al. Informational 19
MPLS/GMPLS Security framework
cryptographic processing altogether, reveal internal congiguration,
or provide some means of sniffing or diverting unencrypted traffic.
Thus an implementation using CE-CE encryption needs to consider the Thus an implementation using CE-CE encryption needs to consider the
trust relationship between the MPLS/GMPLS user and provider. trust relationship between the MPLS/GMPLS user and provider.
MPLS/GMPLS users and providers may wish to negotiate a service MPLS/GMPLS users and providers may wish to negotiate a service
level agreement (SLA) for CE-CE encryption that will provide an level agreement (SLA) for CE-CE encryption that provides an
acceptable demarcation of responsibilities for management of acceptable demarcation of responsibilities for management of
encryption on the CE devices. The demarcation may also be affected cryptographic protection on the CE devices. The demarcation may
by the capabilities of the CE devices. For example, the CE might also be affected by the capabilities of the CE devices. For
support some partitioning of management, a configuration lock-down example, the CE might support some partitioning of management, a
ability, or allow both parties to verify the configuration. In configuration lock-down ability, or shared capability to verify the
general, the MPLS/GMPLS user needs to have a fairly high level of configuration. In general, the MPLS/GMPLS user needs to have a
trust that the MPLS/GMPLS provider will properly provision and fairly high level of trust that the MPLS/GMPLS provider will
manage the CE devices, if the managed CE-CE model is used. properly provision and manage the CE devices, if the managed CE-CE
model is used.
5.1.1. IPsec in MPLS/GMPLS 5.2.1. IPsec in MPLS/GMPLS
IPsec [RFC4301] [RFC4302] [RFC4305] [RFC4306] [RFC2411] is the IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC2411] is the
security protocol of choice for encryption at the IP layer (Layer security protocol of choice for encryption at the IP layer (Layer
3). IPsec provides robust security for IP traffic between pairs of 3). IPsec provides robust security for IP traffic between pairs of
devices. Non-IP traffic must be converted to IP (e.g. by devices. Non-IP traffic such as IS-IS routing must be converted to
encapsulation) in order to exploit IPsec. IP (e.g., by encapsulation) in order to use IPsec.
Fang, et al. Informational 17
MPLS/GMPLS Security framework
February 2007
In the MPLS/GMPLS model, IPsec can be employed to protect IP In the MPLS/GMPLS model, IPsec can be employed to protect IP
traffic between PEs, between a PE and a CE, or from CE to CE. CE- traffic between PEs, between a PE and a CE, or from CE to CE. CE-
to-CE IPsec may be employed in either a provider-provisioned or a to-CE IPsec may be employed in either a provider-provisioned or a
user-provisioned model. Likewise, encryption of data which is user-provisioned model. Likewise, IPsec protection of data
performed within the user's site is outside the scope of this performed within the user's site is outside the scope of this
document, since it is simply handled as user data by the MPLS/GMPLS document, because it is simply handled as user data by the
core. MPLS/GMPLS core. However, if the SP performs compression, pre-
encryption will have a major effect on that operation.
IPsec does not itself specify an encryption algorithm. It can use IPsec does not itself specify an encryption algorithm. It can use
a variety of encryption algorithms, with various key lengths, such a variety of integrity or confidentiality algorithms (or even
as AES encryption. There are trade-offs between key length, combined integrity and confidentiality algorithms), with various
computational burden, and the level of security of the encryption. key lengths, such as AES encryption or AES message integrity
A full discussion of these trade-offs is beyond the scope of this checks. There are trade-offs between key length, computational
document. In practice, any currently recommended IPsec encryption burden, and the level of security of the encryption. A full
offers enough security to substantially reduce the likelihood of discussion of these trade-offs is beyond the scope of this
being directly targeted by an attacker; other weaker links in the document. In practice, any currently recommended IPsec protection
chain of security are likely to be attacked first. MPLS/GMPLS offers enough security to reduce the likelihood of its being
users may wish to use a Service Level Agreement (SLA) specifying directly targeted by an attacker substantially; other weaker links
the Service Provider's responsibility for ensuring data in the chain of security are likely to be attacked first.
MPLS/GMPLS users may wish to use a Service Level Agreement (SLA)
Fang, et al. Informational 20
MPLS/GMPLS Security framework
specifying the SP's responsibility for ensuring data integrity and
confidentiality, rather than analyzing the specific encryption confidentiality, rather than analyzing the specific encryption
techniques used in the MPLS/GMPLS service. techniques used in the MPLS/GMPLS service.
Encryption algorithms generally come with two parameters: mode such
as Cipher Block Chaining and key length such as AES-192. (This
should not be confused with two other senses in which the word
"mode" is used: IPsec itself can be used in Tunnel Mode or
Transport Mode, and IKE [version 1] uses Main Mode, Aggressive
Mode, or Quick Mode). It should be stressed that IPsec encryption
without an integrity check is a state of sin.
For many of the MPLS/GMPLS provider's network control messages and For many of the MPLS/GMPLS provider's network control messages and
some user requirements, cryptographic authentication of messages some user requirements, cryptographic authentication of messages
without encryption of the contents of the message may provide without encryption of the contents of the message may provide
acceptable security. Using IPsec, authentication of messages is appropriate security. Using IPsec, authentication of messages is
provided by the Authentication Header (AH) or through the use of provided by the Authentication Header (AH) or through the use of
the Encapsulating Security Protocol (ESP) with authentication only. the Encapsulating Security Protocol (ESP) with NULL encryption.
Where control messages require authentication but do not use IPsec, Where control messages require integrity but do not use IPsec,
then other cryptographic authentication methods are available. other cryptographic authentication methods are often available.
Message authentication methods currently considered to be secure Message authentication methods currently considered to be secure
are based on hashed message authentication codes (HMAC) [RFC2104] are based on hashed message authentication codes (HMAC) [RFC2104]
implemented with a secure hash algorithm such as Secure Hash implemented with a secure hash algorithm such as Secure Hash
Algorithm 1 (SHA-1) [RFC3174]. Algorithm 1 (SHA-1) [RFC3174]. No attacks against HMAC SHA-1 are
likely to play out in the near future, but it is possible that
people will soon find SHA-1 collisions. Thus, it is important that
mechanisms be designed to be flexible about the choice of hash
functions and message integrity checks. Also, many of these
mechanisms do not include a convenient way to manage and update
keys.
The currently recommended mechanism to provide a combination of A mechanism to provide a combination of confidentiality, data
confidentiality, data origin authentication, and connectionless origin authentication, and connectionless integrity is the use of
integrity is the use of AES in CCM (Counter with CBC-MAC) mode AES in CCM (Counter with CBC-MAC) mode (RFC 4309) [RFC4309], with
(AES-CCM) [AES-CCM], with an explicit initialization vector (IV), an explicit initialization vector (IV), as the IPsec ESP. Recently,
as the IPsec ESP. GCM is rapidly replacing CCM as the preferred method: [RFC4103].
MPLS/GMPLS which provide differentiated services based on traffic MPLS and GMPLS, which provide differentiated services based on
type may encounter some conflicts with IPsec encryption of traffic. traffic type, may encounter some conflicts with IPsec encryption of
Since encryption hides the content of the packets, it may not be traffic. Because encryption hides the content of the packets, it
possible to differentiate the encrypted traffic in the same manner may not be possible to differentiate the encrypted traffic in the
as unencrypted traffic. Although DiffServ markings are copied to same manner as unencrypted traffic. Although DiffServ markings are
copied to the IPsec header and can provide some differentiation,
not all traffic types can be accommodated by this mechanism. Using
IPsec without IKE or IKEv2 (the better choice) is not advisable.
IKEv2 provides IPsec Security Association creation and management,
entity authentication, key agreement, and key update. It works with
a variety of authentication methods including pre-shared keys,
Fang, et al. Informational 18 Fang, et al. Informational 21
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 public key certificates, and EAP. If DoS attacks against IKEv2 are
considered an important threat to mitigate, the cookie-based anti-
the IPsec header and can provide some differentiation, not all spoofing feature of IKEv2 should be used. IKEv2 has its own set of
traffic types can be accommodated by this mechanism. cryptographic methods, but any of the default suites specified in
[RFC4308] or [RFC4869] provides more than adequate security.
5.1.2. Encryption for device configuration and management 5.2.2. Encryption for device configuration and management
For configuration and management of MPLS/GMPLS devices, encryption For configuration and management of MPLS/GMPLS devices, encryption
and authentication of the management connection at a level and authentication of the management connection at a level
comparable to that provided by IPsec is desirable. comparable to that provided by IPsec is desirable.
Several methods of transporting MPLS/GMPLS device management Several methods of transporting MPLS/GMPLS device management
traffic offer security and confidentiality. traffic offer security and confidentiality.
- Secure Shell (SSH) offers protection for TELNET [STD-8] or - Secure Shell (SSH) offers protection for TELNET [STD-8] or
terminal-like connections to allow device configuration. terminal-like connections to allow device configuration.
- SNMP v3 [STD62] provides encrypted and authenticated protection - SNMPv3 [STD62] provides encrypted and authenticated protection
for SNMP-managed devices. for SNMP-managed devices.
- Transport Layer Security (TLS) [RFC4346] and the closely-related - Transport Layer Security (TLS) [RFC4346] and the closely-related
Secure Sockets Layer (SSL) are widely used for securing HTTP- Secure Sockets Layer (SSL) are widely used for securing HTTP-
based communication, and thus can provide support for most XML- based communication, and thus can provide support for most XML-
and SOAP-based device management approaches. and SOAP-based device management approaches.
- As of 2004, there is extensive work proceeding in several - Since 2004, there has been extensive work proceeding in several
organizations (OASIS, W3C, WS-I, and others) on securing device organizations (OASIS, W3C, WS-I, and others) on securing device
management traffic within a "Web Services" framework, using a management traffic within a "Web Services" framework, using a
wide variety of security models, and providing support for wide variety of security models, and providing support for
multiple security token formats, multiple trust domains, multiple security token formats, multiple trust domains,
multiple signature formats, and multiple encryption multiple signature formats, and multiple encryption
technologies. technologies.
- IPsec provides the services with security and confidentiality at - IPsec provides the services with integrity and confidentiality
the network layer. With regards to device management, its at the network layer. With regards to device management, its
current use is primarily focused on in-band management of user- current use is primarily focused on in-band management of user-
managed IPsec gateway devices. managed IPsec gateway devices.
- There are recent work in ISMS WG (Integrated Security Model for
SNMP Working Group) to define how to use SSH to secure SNMP, due to
the limited deployment of SNMPv3; and the possibility of using
Kerberos, particularly for interfaces like TELNET, where client code
exists.
5.1.3. Cryptographic techniques for MPLS Pseudowires Cryptographic Techniques for MPLS Pseudowires
5.1.4. 5.1.3 Security Considerations for MPLS Pseudowires 5.2.3. 5.1.3 Security Considerations for MPLS Pseudowires
In addition to IP traffic, MPLS networks may be used to transport In addition to IP traffic, MPLS networks may be used to transport
other services such as Ethernet, ATM, frame relay, and TDM. This is other services such as Ethernet, ATM, Frame Relay, and TDM. This is
Fang, et al. Informational 22
MPLS/GMPLS Security framework
done by setting up pseudowires (PWs) that tunnel the native service done by setting up pseudowires (PWs) that tunnel the native service
through the MPLS core by encapsulating at the edges. The PWE through the MPLS core by encapsulating at the edges. The PWE
architecture is defined in [RFC3985]. architecture is defined in [RFC3985].
Fang, et al. Informational 19
MPLS/GMPLS Security framework
February 2007
PW tunnels may be set up using the PWE control protocol based on PW tunnels may be set up using the PWE control protocol based on
LDP [RFC4447], and thus security considerations for LDP will most LDP [RFC4447], and thus security considerations for LDP will most
likely be applicable to the PWE3 control protocol as well. likely be applicable to the PWE3 control protocol as well.
PW user packets contain at least one MPLS label (the PW label) and PW user packets contain at least one MPLS label (the PW label) and
may contain one or more MPLS tunnel labels. After the label stack may contain one or more MPLS tunnel labels. After the label stack
there is a four-byte control word (which is optional for some PW there is a four-byte control word (which is optional for some PW
types), followed by the native service payload. It must be types), followed by the native service payload. It must be
stressed that encapsulation of MPLS PW packets in IP for the stressed that encapsulation of MPLS PW packets in IP for the
purpose of enabling use of IPsec mechanisms is not a valid option. purpose of enabling use of IPsec mechanisms is not a valid option.
The PW client traffic may be secured by use of mechanisms beyond The PW client traffic may be secured by use of mechanisms beyond
the scope of this document. the scope of this document.
5.1.5. End-to-end vs. hop-by-hop encryption tradeoffs in 5.2.4. End-to-End versus Hop-by-Hop Protection Tradeoffs in
MPLS/GMPLS MPLS/GMPLS
In MPLS/GMPLS, encryption could potentially be applied to the In MPLS/GMPLS, cryptographic protection could potentially be
MPLS/GMPLS traffic at several different places. This section applied to the MPLS/GMPLS traffic at several different places.
discusses some of the tradeoffs in implementing encryption in This section discusses some of the tradeoffs in implementing
several different connection topologies among different devices encryption in several different connection topologies among
within a MPLS/GMPLS network. different devices within a MPLS/GMPLS network.
Encryption typically involves a pair of devices which encrypt the Cryptographic protection typically involves a pair of devices that
traffic passing between them. The devices may be directly protect the traffic passing between them. The devices may be
connected (over a single "hop"), or there may be intervening directly connected (over a single "hop"), or intervening devices
devices which transport the encrypted traffic between the pair of may transport the protected traffic between the pair of devices.
devices. The extreme cases involve using encryption between every The extreme cases involve using protection between every adjacent
adjacent pair of devices along a given path (hop-by-hop), or using pair of devices along a given path (hop-by-hop), or using
encryption only between the end devices along a given path (end-to- protection only between the end devices along a given path (end-to-
end). To keep this discussion within the scope of this document, end). To keep this discussion within the scope of this document,
the latter ("end-to-end") case considered here is CE-to-CE rather the latter ("end-to-end") case considered here is CE-to-CE rather
than fully end-to-end. than fully end-to-end.
Figure 3 depicts a simplified topology showing the Customer Edge Figure 3 depicts a simplified topology showing the Customer Edge
(CE) devices, the Provider Edge (PE) devices, and a variable number (CE) devices, the Provider Edge (PE) devices, and a variable number
(three are shown) of Provider core (P) devices which might be (three are shown) of Provider core (P) devices, which might be
present along the path between two sites in a single VPN, operated present along the path between two sites in a single VPN operated
by a single service provider (SP). by a single service provider (SP).
Fang, et al. Informational 23
MPLS/GMPLS Security framework
Site_1---CE---PE---P---P---P---PE---CE---Site_2 Site_1---CE---PE---P---P---P---PE---CE---Site_2
Figure 3: Simplified topology traversing through MPLS/GMPLS core Figure 3: Simplified topology traversing through MPLS/GMPLS core.
Fang, et al. Informational 20
MPLS/GMPLS Security framework
February 2007
Within this simplified topology, and assuming that P devices are Within this simplified topology, and assuming that the P devices
not to be involved with encryption, there are four basic feasible are not involved with cryptographic protection, four basic,
configurations for implementing encryption on connections among the feasible configurations exist for protecting connections among the
devices: devices:
1) Site-to-site (CE-to-CE) - Encryption can be configured between 1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity
the two CE devices, so that traffic will be encrypted throughout services between the two CE devices, so that traffic will be
the SP's network. protected throughout the SP's network.
2) Provider edge-to-edge (PE-to-PE) - Encryption can be configured 2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or
between the two PE devices. Unencrypted traffic is received at one integrity services between the two PE devices. Unprotected traffic
PE from the customer's CE, then it is encrypted for transmission is received at one PE from the customer's CE, then it is protected
through the SP's network to the other PE, where it is decrypted and for transmission through the SP's network to the other PE, and
sent to the other CE. finally it is decrypted or checked for integrity and sent to the
other CE.
3) Access link (CE-to-PE) - Encryption can be configured between 3) Access link (CE-to-PE) - Apply confidentiality or integrity
the CE and PE, on each side (or on only one side). services between the CE and PE on each side or on only one side.
4) Configurations 2 and 3 above can also be combined, with 4) Configurations 2 and 3 above can also be combined, with
encryption running from CE to PE, then PE to PE, then PE to CE. confidentiality or integrity running from CE to PE, then PE to PE,
and then PE to CE.
Among the four feasible configurations, key tradeoffs in Among the four feasible configurations, key tradeoffs in
considering encryption include: considering encryption include:
- Vulnerability to link eavesdropping - assuming an attacker can - Vulnerability to link eavesdropping or tampering - assuming an
observe the data in transit on the links, would it be protected attacker can
by encryption? observe or modify data in transit on the links, would it be
protected by encryption?
- Vulnerability to device compromise - assuming an attacker can get - Vulnerability to device compromise - assuming an attacker can get
access to a device (or freely alter its configuration), would the access to a device (or freely alter its configuration), would the
data be protected? data be protected?
- Complexity of device configuration and management - given the - Complexity of device configuration and management - given the
number of sites per VPN customer as Nce and the number of PEs number of sites per VPN customer as Nce and the number of PEs
participating in a given VPN as Npe, how many device configurations participating in a given VPN as Npe, how many device configurations
need to be created or maintained, and how do those configurations need to be created or maintained, and how do those configurations
scale? scale?
- Processing load on devices - how many encryption or decryption Fang, et al. Informational 24
operations must be done given P packets? - This influences
considerations of device capacity and perhaps end-to-end delay.
- Ability of SP to provide enhanced services (QoS, firewall,
intrusion detection, etc.) - Can the SP inspect the data in order
to provide these services?
Fang, et al. Informational 21
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
February 2007 - Processing load on devices - how many cryptographic operations
must be performed given N packets? - This raises considerations of
device capacity and perhaps end-to-end delay.
- Ability of the SP to provide enhanced services (QoS, firewall,
intrusion detection, etc.) - Can the SP inspect the data to provide
these services?
These tradeoffs are discussed for each configuration, below: These tradeoffs are discussed for each configuration, below:
1) Site-to-site (CE-to-CE) 1) Site-to-site (CE-to-CE)
Link eavesdropping - protected on all links Link eavesdropping or tampering - protected on all links
Device compromise - vulnerable to CE compromise Device compromise - vulnerable to CE compromise
Complexity - single administration, responsible for one device per Complexity - single administration, responsible for one device per
site (Nce devices), but overall configuration per VPN scales as site (Nce devices), but overall configuration per VPN scales as
Nce**2 Nce**2.
Though the complexity may be reduced: 1) In practice, as Nce
grows, the number of VPNs falls off from being a full clique;
2) If the CEs run an automated key management protocol, then
they should be able to set up and tear down secured VPNs
without any intervention
Processing load - on each of two CEs, each packet is either Processing load - on each of two CEs, each packet is either
encrypted or decrypted (2P) cryptographically processed (2P), though the protection may be
"integrity check only" or "integrity check plus encryption."
Enhanced services - severely limited; typically only Diffserv Enhanced services - severely limited; typically only Diffserv
markings are visible to SP, allowing some QoS services markings are visible to the SP, allowing some QoS services
2) Provider edge-to-edge (PE-to-PE) 2) Provider edge-to-edge (PE-to-PE)
Link eavesdropping - vulnerable on CE-PE links; protected on SP's Link eavesdropping or tampering - vulnerable on CE-PE links;
network links protected on SP's network links
Device compromise - vulnerable to CE or PE compromise Device compromise - vulnerable to CE or PE compromise
Complexity - single administration, Npe devices to configure. Complexity - single administration, Npe devices to configure.
(Multiple sites may share a PE device so Npe is typically much (Multiple sites may share a PE device so Npe is typically much
less than Nce.) Scalability of the overall configuration less than Nce.) Scalability of the overall configuration
depends on the PPVPN type: If the encryption is separate per depends on the PPVPN type: If the cryptographic protection is
VPN context, it scales as Npe**2 per customer VPN. If the separate per VPN context, it scales as Npe**2 per customer VPN.
encryption is per-PE, it scales as Npe**2 for all customer VPNs If it is per-PE, it scales as Npe**2 for all customer VPNs
combined. combined.
Processing load - on each of two PEs, each packet is either Processing load - on each of two PEs, each packet is
encrypted or decrypted (2P) cryptographically processed (2P). Note that this 2P is a
different 2P from case (1), because only PEs are in
consideration here.
Enhanced services - full; SP can apply any enhancements based on Enhanced services - full; SP can apply any enhancements based on
detailed view of traffic detailed view of traffic
3) Access link (CE-to-PE) 3) Access link (CE-to-PE)
Link eavesdropping - protected on CE-PE link; vulnerable on SP's Fang, et al. Informational 25
network links MPLS/GMPLS Security framework
Link eavesdropping or tampering - protected on CE-PE link;
vulnerable on SP's network links
Device compromise - vulnerable to CE or PE compromise Device compromise - vulnerable to CE or PE compromise
Complexity - two administrations (customer and SP) with device Complexity - two administrations (customer and SP) with device
configuration on each side (Nce + Npe devices to configure) but configuration on each side (Nce + Npe devices to configure) but
since there is no mesh the overall configuration scales as Nce. because there is no mesh the overall configuration scales as
Processing load - on each of two CEs, each packet is either Nce.
encrypted or decrypted, plus on each of two PEs, each packet is Processing load - on each of two CEs, each packet is
either encrypted or decrypted (4P) cryptographically processed, plus on each of two PEs, each
packet is cryptographically processed (4P)
Enhanced services - full; SP can apply any enhancements based on Enhanced services - full; SP can apply any enhancements based on
detailed view of traffic detailed view of traffic
4) Combined Access link and PE-to-PE (essentially hop-by-hop) 4) Combined Access link and PE-to-PE (essentially hop-by-hop)
Link eavesdropping - protected on all links Link eavesdropping or tampering - protected on all links
Fang, et al. Informational 22
MPLS/GMPLS Security framework
February 2007
Device compromise - vulnerable to CE or PE compromise Device compromise - vulnerable to CE or PE compromise
Complexity - two administrations (customer and SP) with device Complexity - two administrations (customer and SP) with device
configuration on each side (Nce + Npe devices to configure). configuration on each side (Nce + Npe devices to configure).
Scalability of the overall configuration depends on the PPVPN Scalability of the overall configuration depends on the PPVPN
type: If the encryption is separate per VPN context, it scales type: If the cryptographic processing is separate per VPN
as Npe**2 per customer VPN. If the encryption is per-PE, it context, it scales as Npe**2 per customer VPN. If it is per-
scales as Npe**2 for all customer VPNs combined. PE, it scales as Npe**2 for all customer VPNs combined.
Processing load - on each of two CEs, each packet is either Processing load - on each of two CEs, each packet is
encrypted or decrypted, plus on each of two PEs, each packet is cryptographically processed, plus on each of two PEs, each
both encrypted and decrypted (6P) packet is cryptographically processed twice (6P)
Enhanced services - full; SP can apply any enhancements based on Enhanced services - full; SP can apply any enhancements based on
detailed view of traffic detailed view of traffic
Given the tradeoffs discussed above, a few conclusions can be made: Given the tradeoffs discussed above, a few conclusions can be made:
- Configurations 2 and 3 are subsets of 4 that may be appropriate - Configurations 2 and 3 are subsets of 4 that may be appropriate
alternatives to 4 under certain threat models; the remainder of alternatives to 4 under certain threat models; the remainder of
these conclusions compare 1 (CE-to-CE) vs. 4 (combined access links these conclusions compare 1 (CE-to-CE) versus 4 (combined access
and PE-to-PE). links and PE-to-PE).
- If protection from link eavesdropping is most important, then - If protection from link eavesdropping or tampering is all that is
configurations 1 and 4 are equivalent. important, then configurations 1 and 4 are equivalent.
- If protection from device compromise is most important and the - If protection from device compromise is most important and the
threat is to the CE devices, both cases are equivalent; if the threat is to the CE devices, both cases are equivalent; if the
threat is to the PE devices, configuration 1 is best. threat is to the PE devices, configuration 1 is better.
- If reducing complexity is most important, and the size of the - If reducing complexity is most important, and the size of the
network is very small, configuration 1 is the best. Otherwise network is small, configuration 1 is better. Otherwise
configuration 4 is the best because rather than a mesh of CE configuration 4 is better because rather than a mesh of CE devices
devices it requires a smaller mesh of PE devices. Also under some it requires a smaller mesh of PE devices. Also, under some PPVPN
PPVPN approaches the scaling of 4 is further improved by sharing
the same PE-PE mesh across all VPN contexts. The scaling advantage
of 4 may be increased or decreased in any given situation if the CE
devices are simpler to configure than the PE devices, or vice-
versa.
- If the overall processing load is a key factor, then 1 is best. Fang, et al. Informational 26
MPLS/GMPLS Security framework
approaches the scaling of 4 is further improved by sharing the same
PE-PE mesh across all VPN contexts. The scaling advantage of 4 may
be increased or decreased in any given situation if the CE devices
are simpler to configure than the PE devices, or vice-versa.
- If the overall processing load is a key factor, then 1 is better,
unless the PEs come with a hardware encryption accelerator and the
CEs do not.
- If the availability of enhanced services support from the SP is - If the availability of enhanced services support from the SP is
most important, then 4 is best. most important, then 4 is best.
As a quick overall conclusion, CE-to-CE encryption provides greater As a quick overall conclusion, CE-to-CE protection is better
protection against device compromise but this comes at the cost of against device compromise, but this comes at the cost of enhanced
enhanced services and at the cost of operational complexity due to services and at the cost of operational complexity due to the
the Order(n**2) scaling of a larger mesh. Order(n**2) scaling of a larger mesh.
Fang, et al. Informational 23
MPLS/GMPLS Security framework
February 2007
This analysis of site-to-site vs. hop-by-hop encryption tradeoffs This analysis of site-to-site vs. hop-by-hop tradeoffs does not
does not explicitly include cases of multiple providers cooperating explicitly include cases of multiple providers cooperating to
to provide a PPVPN service, public Internet VPN connectivity, or provide a PPVPN service, public Internet VPN connectivity, or
remote access VPN service, but many of the tradeoffs will be remote access VPN service, but many of the tradeoffs will be
similar. similar.
5.2. Authentication In addition to the simplified models, the following should also be
considered:
In order to prevent security issues from some Denial-of-Service - There are reasons, perhaps, to protect a specific P-to-P or PE-
attacks or from malicious misconfiguration, it is critical that to-P.
devices in the MPLS/GMPLS should only accept connections or control - There may be reasons to do multiple encryptions over certain
messages from valid sources. Authentication refers to methods to segments. One may be using an encrypted wireless link under our
ensure that message sources are properly identified by the IPsec VPN to access a SSL-secured web site to download encrypted
MPLS/GMPLS devices with which they communicate. This section email attachments: four layers.)
focuses on identifying the scenarios in which sender authentication - It may be that, for example, cryptographic integrity checks are
is required, and recommends authentication mechanisms for these applied end to end, and confidentiality over a shorter span.
scenarios. - Different cryptographic protection may be required for control
protocols and data traffic.
Cryptographic techniques (authentication and encryption) do not - Attention needs to be given to how auxiliary traffic is
protect against some types of denial of service attacks, protected, e.g., the ICMPv6 packets that flow back during PMTU
specifically resource exhaustion attacks based on CPU or bandwidth discovery, among other examples.
exhaustion. In fact, the processing required to decrypt and/or
check authentication may in some cases increase the effect of these
resource exhaustion attacks. Cryptographic techniques may however,
be useful against resource exhaustion attacks based on exhaustion
of state information (e.g., TCP SYN attacks).
The MPLS user plane, as presently defined, is not amenable to
source authentication as there are no source identifiers in the
MPLS packet to authenticate. The MPLS label is only locally
meaningful, and identifies a downstream semantic rather than an
upstream source.
When the MPLS payload carries identifiers that may be authenticated
(e.g., IP packets), authentication may be carried out at the client
level, but this does not help the MPLS service provider as these
client identifiers belong to an external non-trusted network.
5.2.1. Management System Authentication
Management system authentication includes the authentication of a
PE to a centrally-managed directory server, when directory-based
Fang, et al. Informational 24
MPLS/GMPLS Security framework
February 2007
"auto-discovery" is used. It also includes authentication of a CE
to the configuration server, when a configuration server system is
used.
5.2.2. Peer-to-peer Authentication
Peer-to-peer authentication includes peer authentication for
network control protocols (e.g. LDP, BGP, etc.), and other peer
authentication (i.e. authentication of one IPsec security gateway
by another).
5.2.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 Certificate Authority system to provide digital
certificates.
This section describes or provides references to the specific
cryptographic approaches for authenticating identity. These
approaches provide secure mechanisms for most of the authentication
scenarios required in securing a MPLS/GMPLS network.
5.3. Access Control techniques 5.3. Access Control techniques
Access control techniques include packet-by-packet or packet-flow- Access control techniques include packet-by-packet or packet-flow-
by-packet-flow access control by means of filters and firewalls, as by-packet-flow access control by means of filters and firewalls, as
well as by means of admitting a "session" for a well as by means of admitting a "session" for a control, signaling,
control/signaling/management protocol. Enforcement of access or management protocol. Enforcement of access control by isolated
control by isolated infrastructure addresses is discussed in infrastructure addresses is discussed in another section of this
another section of this document. document.
Fang, et al. Informational 27
MPLS/GMPLS Security framework
In this document, we distinguish between filtering and firewalls In this document, we distinguish between filtering and firewalls
based primarily on the direction of traffic flow. We define based primarily on the direction of traffic flow. We define
filtering as being applicable to unidirectional traffic, while a filtering as being applicable to unidirectional traffic, while a
firewall can analyze and control both sides of a conversation. firewall can analyze and control both sides of a conversation.
There are two significant corollaries of this definition: The definition has two significant corollaries:
- Routing or traffic flow symmetry: A firewall typically requires - Routing or traffic flow symmetry: A firewall typically requires
routing symmetry, which is usually enforced by locating a firewall routing symmetry, which is usually enforced by locating a firewall
where the network topology assures that both sides of a where the network topology assures that both sides of a
Fang, et al. Informational 25
MPLS/GMPLS Security framework
February 2007
conversation will pass through the firewall. A filter can operate conversation will pass through the firewall. A filter can operate
upon traffic flowing in one direction, without considering traffic upon traffic flowing in one direction, without considering traffic
in the reverse direction. in the reverse direction. Beware that this concept could result in
- Statefulness: Since it receives both sides of a conversation, a a single point of failure.
- Statefulness: Because it receives both sides of a conversation, a
firewall may be able to interpret a significant amount of firewall may be able to interpret a significant amount of
information concerning the state of that conversation, and use this information concerning the state of that conversation and use this
information to control access. A filter can maintain some limited information to control access. A filter can maintain some limited
state information on a unidirectional flow of packets, but cannot state information on a unidirectional flow of packets, but cannot
determine the state of the bi-directional conversation as precisely determine the state of the bi-directional conversation as precisely
as a firewall. as a firewall.
5.3.1. Filtering 5.3.1. Filtering
It is relatively common for routers to filter data packets. That It is relatively common for routers to filter data packets. That
is, routers can look for particular values in certain fields of the is, routers can look for particular values in certain fields of the
IP or higher level (e.g., TCP or UDP) headers. Packets which match IP or higher level (e.g., TCP or UDP) headers. Packets which
the criteria associated with a particular filter may either be matching the criteria associated with a particular filter may
discarded or given special treatment. either be discarded or given special treatment. Today, not only
routers, most end hosts today have filters and every instance of
IPsec is also a filter [RFC4301].
In discussing filters, it is useful to separate the Filter In discussing filters, it is useful to separate the Filter
Characteristics which may be used to determine whether a packet Characteristics that may be used to determine whether a packet
matches a filter from the Packet Actions which are applied to those matches a filter from the Packet Actions applied to those packets
packets which match a particular filter. which matching a particular filter.
o Filter Characteristics o Filter Characteristics
Filter characteristics are used to determine whether a particular Filter characteristics or rules are used to determine whether a
packet or set of packets matches a particular filter. particular packet or set of packets matches a particular filter.
In many cases filter characteristics may be stateless. A stateless In many cases filter characteristics may be stateless. A stateless
filter is one which determines whether a particular packet matches filter determines whether a particular packet matches a filter
a filter based solely on the filter definition, normal forwarding based solely on the filter definition, normal forwarding
information (such as the next hop for a packet), and the information (such as the next hop for a packet), and the contents
characteristics of that individual packet. Typically stateless of that individual packet. Typically stateless filters may consider
filters may consider the incoming and outgoing logical or physical the incoming and outgoing logical or physical interface,
interface, information in the IP header, and information in higher information in the IP header, and information in higher layer
layer headers such as the TCP or UDP header. Information in the IP
header to be considered may for example include source and Fang, et al. Informational 28
destination IP address, Protocol field, Fragment Offset, and TOS MPLS/GMPLS Security framework
field. Filters also may consider fields in the TCP or UDP header headers such as the TCP or UDP header. Information in the IP header
such as the Port fields as well as the SYN field in the TCP header. to be considered may for example include source and destination IP
addresses, Protocol field, Fragment Offset, and TOS field in IPv4,
Next Header, Extension Headers, Flow label, etc. in IPv6. Filters
also may consider fields in the TCP or UDP header such as the Port
fields, the SYN field in the TCP header, as well as ICMP and ICMPv6
type.
Stateful filtering maintains packet-specific state information, to Stateful filtering maintains packet-specific state information, to
aid in determining whether a filter has been met. For example, a aid in determining whether a filter has been met. For example, a
device might apply stateless filters to the first fragment of a device might apply stateless filters to the first fragment of a
fragmented IP packet. If the filter matches, then the data unit ID fragmented IP packet. If the filter matches, then the data unit ID
may be remembered and other fragments of the same packet may then may be remembered and other fragments of the same packet may then
be considered to match the same filter. Stateful filtering is more be considered to match the same filter. Stateful filtering is more
Fang, et al. Informational 26
MPLS/GMPLS Security framework
February 2007
commonly done in firewalls, although firewall technology may be commonly done in firewalls, although firewall technology may be
added to routers. added to routers. Data unit ID can also be Fragmentation Extension
Header in IPv6.
o Actions based on Filter Results o Actions based on Filter Results
If a packet, or a series of packets, matches a specific filter, If a packet, or a series of packets, matches a specific filter,
then there are a variety of actions which may be taken based on then a variety of actions which may be taken based on that match.
that filter match. Examples of such actions include: Examples of such actions include:
- Discard - Discard
In many cases filters may be set to catch certain undesirable In many cases, filters are set to catch certain undesirable
packets. Examples may include packets with forged or invalid source packets. Examples may include packets with forged or invalid source
addresses, packets which are part of a DOS or DDOS attack, or addresses, packets that are part of a DOS or Distributed DoS (DDOS)
packets which are trying to access resources which are not attack, or packets which are trying to access unallowed resources
permitted (such as network management packets from an unauthorized (such as network management packets from an unauthorized source).
source). Where such filters are activated, it is common to silently Where such filters are activated, it is common to discard the
discard the packet or set of packets matching the filter. The packet or set of packets matching the filter silently. The
discarded packets may of course also be counted and/or logged. discarded packets may of course also be counted or logged.
- Set CoS - Set CoS
A filter may be used to set the Class of Service associated with A filter may be used to set the Class of Service associated with
the packet. the packet.
- Count packets and/or bytes - Count packets or bytes
- Rate Limit - Rate Limit
In some cases the set of packets which match a particular filter In some cases the set of packets matching a particular filter may
may be limited to a specified bandwidth. In this case packets be limited to a specified bandwidth. In this case, packets or bytes
and/or bytes would be counted, and would be forwarded normally up would be counted, and would be forwarded normally up to the
to the specified limit. Excess packets may be discarded, or may be specified limit. Excess packets may be discarded or may be marked
marked (for example by setting a "discard eligible" bit in the IP
ToS field or the MPLS EXP field). Fang, et al. Informational 29
MPLS/GMPLS Security framework
(for example by setting a "discard eligible" bit in the IP ToS
field or the MPLS EXP field).
- Forward and Copy - Forward and Copy
It is useful in some cases to forward some set of packets normally, It is useful in some cases to forward some set of packets normally,
but to also send a copy to a specified other address or interface. but also to send a copy to a specified other address or interface.
For example, this may be used to implement a lawful intercept For example, this may be used to implement a lawful intercept
capability, or to feed selected packets to an Intrusion Detection capability or to feed selected packets to an Intrusion Detection
System. System.
o Other Issues related to Use of Packet Filters o Other Issues related to Use of Packet Filters
There may be a very wide variation in the performance impact of Filtering performance may vary widely according to implementation
filtering. This may occur both due to differences between and the types and number of rules. Without acceptable performance,
filtering is not useful.
Fang, et al. Informational 27
MPLS/GMPLS Security framework
February 2007
implementations, and also due to differences between types or
numbers of filters deployed. For filtering to be useful, the
performance of the equipment has to be acceptable in the presence
of filters.
The precise definition of "acceptable" may vary from service The precise definition of "acceptable" may vary from SP to SP, and
provider to service provider, and may depend upon the intended use may depend upon the intended use of the filters. For example, for
of the filters. For example, for some uses a filter may be turned some uses a filter may be turned on all the time to set CoS, to
on all the time in order to set CoS, to prevent an attack, or to prevent an attack, or to mitigate the effect of a possible future
mitigate the effect of a possible future attack. In this case it is attack. In this case it is likely that the SP will want the filter
likely that the service provider will want the filter to have to have minimal or no impact on performance. In other cases, a
minimal or no impact on performance. In other cases, a filter may filter may be turned on only in response to a major attack (such as
be turned on only in response to a major attack (such as a major a major DDoS attack). In this case a greater performance impact may
DDOS attack). In this case a greater performance impact may be be acceptable to some service providers.
acceptable to some service providers.
A key consideration with the use of packet filters is that they can A key consideration with the use of packet filters is that they can
provide few options for filtering packets carrying encrypted data. provide few options for filtering packets carrying encrypted data.
Since the data itself is not accessible, only packet header Because the data itself is not accessible, only packet header
information or other unencrypted fields can be used for filtering. information or other unencrypted fields can be used for filtering.
5.3.2. Firewalls 5.3.2. Firewalls
Firewalls provide a mechanism for control over traffic passing Firewalls provide a mechanism for control over traffic passing
between different trusted zones in the MPLS/GMPLS model, or between between different trusted zones in the MPLS/GMPLS model, or between
a trusted zone and an untrusted zone. Firewalls typically provide a trusted zone and an untrusted zone. Firewalls typically provide
much more functionality than filters, since they may be able to much more functionality than filters, because they may be able to
apply detailed analysis and logical functions to flows, and not apply detailed analysis and logical functions to flows, and not
just to individual packets. They may offer a variety of complex just to individual packets. They may offer a variety of complex
services, such as threshold-driven denial-of-service attack services, such as threshold-driven denial-of-service attack
protection, virus scanning, acting as a TCP connection proxy, etc. protection, virus scanning, acting as a TCP connection proxy, etc.
As with other access control techniques, the value of firewalls As with other access control techniques, the value of firewalls
depends on a clear understanding of the topologies of the depends on a clear understanding of the topologies of the
MPLS/GMPLS core network, the user networks, and the threat model. MPLS/GMPLS core network, the user networks, and the threat model.
Their effectiveness depends on a topology with a clearly defined Their effectiveness depends on a topology with a clearly defined
inside (secure) and outside (not secure). inside (secure) and outside (not secure).
Fang, et al. Informational 30
MPLS/GMPLS Security framework
Firewalls may be applied to help protect MPLS/GMPLS core network Firewalls may be applied to help protect MPLS/GMPLS core network
functions from attacks originating from the Internet or from functions from attacks originating from the Internet or from
MPLS/GMPLS user sites, but typically other defensive techniques MPLS/GMPLS user sites, but typically other defensive techniques
will be used for this purpose. will be used for this purpose.
Where firewalls are employed as a service to protect user VPN sites Where firewalls are employed as a service to protect user VPN sites
from the Internet, different VPN users, and even different sites of from the Internet, different VPN users, and even different sites of
a single VPN user, may have varying firewall requirements. The a single VPN user, may have varying firewall requirements. The
Fang, et al. Informational 28
MPLS/GMPLS Security framework
February 2007
overall PPVPN logical and physical topology, along with the overall PPVPN logical and physical topology, along with the
capabilities of the devices implementing the firewall services, capabilities of the devices implementing the firewall services, has
will have a significant effect on the feasibility and manageability a significant effect on the feasibility and manageability of such
of such varied firewall service offerings. varied firewall service offerings.
Another consideration with the use of firewalls is that they can Another consideration with the use of firewalls is that they can
provide few options for handling packets carrying encrypted data. provide few options for handling packets carrying encrypted data.
Since the data itself is not accessible, only packet header Because the data itself is not accessible, only packet header
information, other unencrypted fields, or analysis of the flow of information, other unencrypted fields, or analysis of the flow of
encrypted packets can be used for making decisions on accepting or encrypted packets can be used for making decisions on accepting or
rejecting encrypted traffic. rejecting encrypted traffic.
5.3.3. Access Control to management interfaces Two approaches are to move the firewall outside of the encrypted
part of the path or to register and pre-approve the encrypted
session with the firewall.
Handling DoS attacks has become increasingly important. Useful
guidelines include the following:
1. Perform ingress filtering everywhere. Upstream prevention is
better.
2. Be able to filter DoS attack packets at line speed.
3. Do not allow oneself to amplify attacks.
4. Continue processing legitimate traffic. Over provide for heavy
loads. Use diverse locations, technologies, etc.
5.3.3. Access Control to management interfaces
Most of the security issues related to management interfaces can be Most of the security issues related to management interfaces can be
addressed through the use of authentication techniques as described addressed through the use of authentication techniques as described
in the section on authentication. However, additional security may in the section on authentication. However, additional security may
be provided by controlling access to management interfaces in other be provided by controlling access to management interfaces in other
ways. ways.
The Optical Internetworking Forum has done good 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.
Fang, et al. Informational 31
MPLS/GMPLS Security framework
Management interfaces, especially console ports on MPLS/GMPLS Management interfaces, especially console ports on MPLS/GMPLS
devices, may be configured so they are only accessible out-of-band, devices, may be configured so they are only accessible out-of-band,
through a system which is physically and/or logically separated through a system which is physically or logically separated from
from the rest of the MPLS/GMPLS infrastructure. the rest of the MPLS/GMPLS infrastructure.
Where management interfaces are accessible in-band within the Where management interfaces are accessible in-band within the
MPLS/GMPLS domain, filtering or firewalling techniques can be used MPLS/GMPLS domain, filtering or firewalling techniques can be used
to restrict unauthorized in-band traffic from having access to to restrict unauthorized in-band traffic from having access to
management interfaces. Depending on device capabilities, these management interfaces. Depending on device capabilities, these
filtering or firewalling techniques can be configured either on filtering or firewalling techniques can be configured either on
other devices through which the traffic might pass, or on the other devices through which the traffic might pass, or on the
individual MPLS/GMPLS devices themselves. individual MPLS/GMPLS devices themselves.
5.4. Use of Isolated Infrastructure 5.4. Use of Isolated Infrastructure
One way to protect the infrastructure used for support of One way to protect the infrastructure used for support of
MPLS/GMPLS is to separate the resources for support of MPLS/GMPLS MPLS/GMPLS is to separate the resources for support of MPLS/GMPLS
services from the resources used for other purposes (such as services from the resources used for other purposes (such as
support of Internet services). In some cases this may make use of support of Internet services). In some cases this may use
physically separate equipment for VPN services, or even a physically separate equipment for VPN services, or even a
physically separate network. physically separate network.
For example, PE-based L3 VPNs may be run on a separate backbone not For example, PE-based L3 VPNs may be run on a separate backbone not
connected to the Internet, or may make use of separate edge routers connected to the Internet, or may make use of separate edge routers
from those used to support Internet service. Private IP addresses from those used to support Internet service. Private IP addresses
Fang, et al. Informational 29
MPLS/GMPLS Security framework
February 2007
(local to the provider and non-routable over the Internet) are (local to the provider and non-routable over the Internet) are
sometimes used to provide additional separation. sometimes used to provide additional separation.
5.5. Use of Aggregated Infrastructure 5.5. Use of Aggregated Infrastructure
In general it is not feasible to use a completely separate set of 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 resources for support of each service. In fact, one of the main
reasons for MPLS/GMPLS enabled services is to allow sharing of reasons for MPLS/GMPLS enabled services is to allow sharing of
resources between multiple users, including multiple VPNs, etc. resources between multiple users, including multiple VPNs, etc.
Thus even if certain services make use of a separate network from Thus, even if certain services make use of a separate network from
Internet services, nonetheless there will still be multiple Internet services, nonetheless there will still be multiple
MPLS/GMPLS users sharing the same network resources. In some cases MPLS/GMPLS users sharing the same network resources. In some cases
MPLS/GMPLS services will share the use of network resources with MPLS/GMPLS services will share the use of network resources with
Internet services or other services. Internet services or other services.
It is therefore important for MPLS/GMPLS services to provide It is therefore important for MPLS/GMPLS services to provide
protection between resource utilization by different users. Thus a protection between resources used by different parties. Thus a
well-behaved MPLS/GMPLS user should be protected from possible well-behaved MPLS/GMPLS user should be protected from possible
misbehavior by other users. This requires that limits are placed on misbehavior by other users. This requires that limits are placed on
the amount of resources which can be used by any one VPN. For
example, both control traffic and user data traffic may be rate
limited. In some cases or in some parts of the network where a
sufficiently large number of queues are available each VPN (and
optionally each VPN and CoS within the VPN) may make use of a
separate queue. Control-plane resources such as link bandwidth as
well as CPU and memory resources may be reserved on a per-VPN
basis.
The techniques which are used to provision resource protection Fang, et al. Informational 32
between multiple users served by the same infrastructure can also MPLS/GMPLS Security framework
be used to protect MPLS/GMPLS networks and services from Internet the amount of resources used by any one VPN. For example, both
services. control traffic and user data traffic may be rate limited. In some
cases or in some parts of the network where a sufficiently large
number of queues are available, each VPN (and optionally each VPN
and CoS within the VPN) may make use of a separate queue. Control-
plane resources such as link bandwidth as well as CPU and memory
resources may be reserved on a per-VPN basis.
In general the use of aggregated infrastructure allows the service The techniques used to provide resource protection between multiple
users served by the same infrastructure can also be used to protect
MPLS/GMPLS networks and services from Internet services.
In general, the use of aggregated infrastructure allows the service
provider to benefit from stochastic multiplexing of multiple bursty provider to benefit from stochastic multiplexing of multiple bursty
flows, and also may in some cases thwart traffic pattern analysis flows, and also may in some cases thwart traffic pattern analysis
by combining the data from multiple users. by combining the data from multiple users.
5.6. Service Provider Quality Control Processes 5.6. Service Provider Quality Control Processes
Deployment of provider-provisioned VPN services in general requires Deployment of provider-provisioned VPN services in general requires
a relatively large amount of configuration by the service provider. a relatively large amount of configuration by the SP. For example,
For example, the service provider needs to configure which VPN each the SP needs to configure which VPN each site belongs to, as well
site belongs to, as well as QoS and SLA guarantees. This large as QoS and SLA guarantees. This large amount of required
amount of required configuration leads to the possibility of configuration leads to the possibility of misconfiguration.
misconfiguration.
Fang, et al. Informational 30
MPLS/GMPLS Security framework
February 2007
It is important for the service provider to have operational It is important for the SP to have operational processes in place
processes in place to reduce the potential impact of to reduce the potential impact of misconfiguration. CE-to-CE
misconfiguration. CE to CE authentication may also be used to authentication may also be used to detect misconfiguration when it
detect misconfiguration when it occurs. occurs.
5.7. Deployment of Testable MPLS/GMPLS Service. 5.7. Deployment of Testable MPLS/GMPLS Service.
This refers to solutions that can be readily tested to make sure This refers to solutions that can be readily tested to make sure
they are configured correctly. E.g. for a point-point connection, they are configured correctly. For example, for a point-point
checking that the intended connectivity is working pretty much connection, checking that the intended connectivity is working
ensures that there is not connectivity to some unintended site. pretty much ensures that there is not connectivity to some
unintended site.
6. Monitoring, Detection, and Reporting of Security Attacks 6. Monitoring, Detection, and Reporting of Security Attacks
MPLS/GMPLS network and service may be subject to attacks from a MPLS/GMPLS network and service may be subject to attacks from a
variety of security threats. Many threats are described in another variety of security threats. Many threats are described in another
part of this document. Many of the defensive techniques described part of this document. Many of the defensive techniques described
in this document and elsewhere provide significant levels of in this document and elsewhere provide significant levels of
protection from a variety of threats. However, in addition to protection from a variety of threats. However, in addition to
silently employing defensive techniques to protect against attacks, silently employing defensive techniques to protect against attacks,
MPLS/GMPLS services can also add value for both providers and MPLS/GMPLS services can also add value for both providers and
customers by implementing security monitoring systems which detect
and report on any security attacks which occur, regardless of Fang, et al. Informational 33
whether the attacks are effective. MPLS/GMPLS Security framework
customers by implementing security monitoring systems to detect and
report on any security attacks which occur, regardless of whether
the attacks are effective.
Attackers often begin by probing and analyzing defenses, so systems Attackers often begin by probing and analyzing defenses, so systems
which can detect and properly report these early stages of attacks that can detect and properly report these early stages of attacks
can provide significant benefits. can provide significant benefits.
Information concerning attack incidents, especially if available Information concerning attack incidents, especially if available
quickly, can be useful in defending against further attacks. It quickly, can be useful in defending against further attacks. It
can be used to help identify attackers and/or their specific can be used to help identify attackers or their specific targets at
targets at an early stage. This knowledge about attackers and an early stage. This knowledge about attackers and targets can be
targets can be used to further strengthen defenses against specific used to strengthen defenses against specific attacks or attackers,
attacks or attackers, or improve the defensive services for or improve the defensive services for specific targets on an as-
specific targets on an as-needed basis. Information collected on needed basis. Information collected on attacks may also be useful
attacks may also be useful in identifying and developing defenses in identifying and developing defenses against novel attack types.
against novel attack types.
Monitoring systems used to detect security attacks in MPLS/GMPLS Monitoring systems used to detect security attacks in MPLS/GMPLS
will typically operate by collecting information from the Provider typically operate by collecting information from the Provider Edge
Edge (PE), Customer Edge (CE), and/or Provider backbone (P) (PE), Customer Edge (CE), and/or Provider backbone (P) devices.
devices. Security monitoring systems should have the ability to Security monitoring systems should have the ability to actively
actively retrieve information from devices (e.g., SNMP get) or to retrieve information from devices (e.g., SNMP get) or to passively
passively receive reports from devices (e.g., SNMP notifications). receive reports from devices (e.g., SNMP notifications). The
The specific information exchanged will depend on the capabilities specific information exchanged depends on the capabilities of the
of the devices and on the type of VPN technology. Particular care devices and on the type of VPN technology. Particular care should
be given to securing the communications channel between the
Fang, et al. Informational 31 monitoring systems and the MPLS/GMPLS devices. Syslog WG is
MPLS/GMPLS Security framework specifying "Logging Capabilities for IP Network Infrastructure".
February 2007 (The specific references will be made only if the draft(s) became
RFC before this draft.)
should be given to securing the communications channel between the
monitoring systems and the MPLS/GMPLS devices.
The CE, PE, and P devices should employ efficient methods to The CE, PE, and P devices should employ efficient methods to
acquire and communicate the information needed by the security acquire and communicate the information needed by the security
monitoring systems. It is important that the communication method monitoring systems. It is important that the communication method
between MPLS/GMPLS devices and security monitoring systems be between MPLS/GMPLS devices and security monitoring systems be
designed so that it will not disrupt network operations. As an designed so that it will not disrupt network operations. As an
example, multiple attack events may be reported through a single example, multiple attack events may be reported through a single
message, rather than allowing each attack event to trigger a message, rather than allowing each attack event to trigger a
separate message, which might result in a flood of messages, separate message, which might result in a flood of messages,
essentially becoming a denial-of-service attack against the essentially becoming a denial-of-service attack against the
monitoring system or the network. monitoring system or the network.
The mechanisms for reporting security attacks should be flexible The mechanisms for reporting security attacks should be flexible
enough to meet the needs of MPLS/GMPLS service providers, enough to meet the needs of MPLS/GMPLS service providers,
MPLS/GMPLS customers, and regulatory agencies, if applicable. The MPLS/GMPLS customers, and regulatory agencies, if applicable. The
specific reports will depend on the capabilities of the devices, specific reports should depend on the capabilities of the devices,
the security monitoring system, the type of VPN, and the service the security monitoring system, the type of VPN, and the service
level agreements between the provider and customer. level agreements between the provider and customer.
Fang, et al. Informational 34
MPLS/GMPLS Security framework
7. Service Provider General Security Requirements 7. Service Provider General Security Requirements
In this section, we discuss the security requirements that the This section covers security requirements the provider may have for
provider may have in order to secure its MPLS/GMPLS network securing its MPLS/GMPLS network infrastructure including LDP and
infrastructure, including LDP and RSVP-TE specific requirements. RSVP-TE specific requirements.
The MPLS/GMPLS service provider requirements defined here are the The MPLS/GMPLS service provider's requirements defined here are for
requirements for the MPLS/GMPLS core in the reference model. The the MPLS/GMPLS core in the reference model. The core network can
core network can be implemented with different types of network be implemented with different types of network technologies, and
technologies, and each core network may use different technologies each core network may use different technologies to provide the
to provide the various services to users with different levels of various services to users with different levels of offered
offered security. Therefore, a MPLS/GMPLS service provider may security. Therefore, a MPLS/GMPLS service provider may fulfill any
fulfill any number of the security requirements listed in this number of the security requirements listed in this section. This
section. This document does not state that a MPLS/GMPLS network document does not state that a MPLS/GMPLS network must fulfill all
must fulfill all of these requirements to be secure. of these requirements to be secure.
These requirements are focused on: 1) how to protect the MPLS/GMPLS These requirements are focused on: 1) how to protect the MPLS/GMPLS
core from various attacks outside the core including network users, core from various attacks outside the core including network users,
both accidentally and maliciously, 2) how to protect the end users. both accidentally and maliciously, 2) how to protect the end users.
7.1. Protection within the Core Network 7.1. Protection within the Core Network
7.1.1. Control Plane Protection - General 7.1.1. Control Plane Protection - General
- Protocol authentication within the core: - Protocol authentication within the core:
Fang, et al. Informational 32
MPLS/GMPLS Security framework
February 2007
The network infrastructure must support mechanisms for The network infrastructure must support mechanisms for
authentication of the control plane. In MPLS/GMPLS core is used, authentication of the control plane. If MPLS/GMPLS core is used,
LDP sessions may be authenticated by use TCP MD5, in addition, IGP LDP sessions may be authenticated by use TCP MD5, in addition, IGP
and BGP authentication should also be considered. For a core and BGP authentication should also be considered. For a core
providing Layer 2 services, PE to PE authentication may also be providing Layer 2 services, PE-to-PE authentication may also be
used via IPsec. performed via IPsec. See the above discussion of protocol security
services: authentication, integrity (with replay detection),
confidentiality. Protocols need to provide a complete set of
security services from which the SP can choose. Also, the hard part
is key management.
With the cost of authentication coming down rapidly, the With the cost of authentication coming down rapidly, the
application of control plane authentication may not increase the application of control plane authentication may not increase the
cost of implementation for providers significantly, and will help cost of implementation for providers significantly, and will help
to improve the security of the core. If the core is dedicated to to improve the security of the core. If the core is dedicated to
MPLS/GMPLS enabled services and without any interconnects to third MPLS/GMPLS enabled services and without any interconnects to third
parties then this may reduce the requirement for authentication of parties then this may reduce the requirement for authentication of
the core control plane. the core control plane.
- Elements protection - Infrastructure Hiding
Fang, et al. Informational 35
MPLS/GMPLS Security framework
Here we discuss means to hide the provider's infrastructure nodes. Here we discuss means to hide the provider's infrastructure nodes.
A MPLS/GMPLS provider may make the infrastructure routers (P and PE A MPLS/GMPLS provider may make its infrastructure routers (P and PE
routers) unreachable from outside users and unauthorized internal routers) unreachable from outside users and unauthorized internal
users. For example, separate address space may be used for the users. For example, separate address space may be used for the
infrastructure loopbacks. infrastructure loopbacks.
Normal TTL propagation may be altered to make the backbone look Normal TTL propagation may be altered to make the backbone look
like one hop from the outside, but caution needs to be taken for like one hop from the outside, but caution needs to be taken for
loop prevention. This prevents the backbone addresses from being loop prevention. This prevents the backbone addresses from being
exposed through trace route; however this must also be assessed exposed through trace route; however this must also be assessed
against operational requirements for end to end fault tracing. against operational requirements for end-to-end fault tracing.
An Internet backbone core may be re-engineered to make Internet An Internet backbone core may be re-engineered to make Internet
routing an edge function, for example, using MPLS label switching routing an edge function, for example, by using MPLS label
for all traffic within the core and possibly make the Internet a switching for all traffic within the core and possibly make the
VPN within the PPVPN core itself. This helps to detach Internet Internet a VPN within the PPVPN core itself. This helps to detach
access from PPVPN services. Internet access from PPVPN services.
Separating control plane, data plane, and management plane Separating control plane, data plane, and management plane
functionality in terms of hardware and software may be implemented functionality in hardware and software may be implemented on the PE
on the PE devices to improve security. This may help to limit the devices to improve security. This may help to limit the problems
problems when attacked in one particular area, and may allow each when attacked in one particular area, and may allow each plane to
plane to implement additional security measurement separately. implement additional security measures separately.
PEs are often more vulnerable to attack than P routers, since PEs PEs are often more vulnerable to attack than P routers, because PEs
cannot be made unreachable to outside users by their very nature. cannot be made unreachable from outside users by their very nature.
Access to core trunk resources can be controlled on a per user Access to core trunk resources can be controlled on a per user
basis by the application of inbound rate-limiting/shaping, this can basis by using of inbound rate-limiting or traffic shaping; this
can be further enhanced on a per Class of Service basis (see
Fang, et al. Informational 33 Section 8.2.3)
MPLS/GMPLS Security framework
February 2007
be further enhanced on a per Class of Service basis (see section
8.2.3)
In the PE, using separate routing processes for different services, In the PE, using separate routing processes for different services,
for example, Internet and PPVPN service may help to improve the for example, Internet and PPVPN service, may help to improve the
PPVPN security and better protect VPN customers. Furthermore, if PPVPN security and better protect VPN customers. Furthermore, if
the resources, such as CPU and Memory, may be further separated resources, such as CPU and Memory, can be further separated based
based on applications, or even individual VPNs, it may help to on applications, or even individual VPNs, it may help to provide
provide improved security and reliability to individual VPN improved security and reliability to individual VPN customers.
customers.
7.1.2. Control plane protection with RSVP-TE 7.1.2. Control plane protection with RSVP-TE
- RSVP Security Tools - RSVP Security Tools
Isolation of the trusted domain is an important security mechanism Isolation of the trusted domain is an important security mechanism
with respect to RSVP, to ensure that an untrusted element cannot for RSVP, to ensure that an untrusted element cannot access a
access a router of the trusted domain. Though isolation is limited router of the trusted domain. However, isolation is limited by the
by the need to allow ASBR-ASBR communication for inter-AS LSPs. need to allow ASBR-ASBR communication for inter-AS LSPs. Isolation
Isolation mechanisms might be bypassed by Router Alert IP packets.
- A solution would consists in disabling the RSVP router alert mode Fang, et al. Informational 36
and dropping all IP packets with the router alert option, or also MPLS/GMPLS Security framework
to drop on an interface all incoming IP packets with port 46, which mechanisms might also be bypassed by Router Alert IP packets. A
solution could consists of disabling the RSVP router alert mode and
dropping all IP packets with the router alert option, or also to
drop all incoming IP packets on an interface with port 46, which
requires an access-list at the IP port level) or spoofed IP packets requires an access-list at the IP port level) or spoofed IP packets
if anti-spoofing is not activated. if anti-spoofing is not otherwise activated.
RSVP security can be strengthened by deactivating RSVP on RSVP security can be strengthened by deactivating RSVP on
interfaces with neighbors who are not authorized to use RSVP, to interfaces with neighbors who are not authorized to use RSVP, to
protect against adjacent CE-PE attacks. However, this does not protect against adjacent CE-PE attacks. However, this does not
really protect against DoS attacks, and does not protect against really protect against DoS attacks or attacks on non-adjacent
attacks on non-adjacent routers. It has been demonstrated that routers. It has been demonstrated that substantial CPU resources
substantial CPU resources are consumed simply by processing are consumed simply by processing received RSVP packets, even if
received RSVP packets, even if the RSVP process is deactivated for the RSVP process is deactivated for the specific interface on which
the specific interface on which the RSVP message is received. the RSVP packets are received.
RSVP neighbor filtering at the protocol level, to restrict the set RSVP neighbor filtering at the protocol level, to restrict the set
of neighbors that can send RSVP messages to a given router, of neighbors that can send RSVP messages to a given router,
protects against non-adjacent attacks. However, this does not protects against non-adjacent attacks. However, this does not
protect against DoS attacks, and does not effectively protect protect against DoS attacks and does not effectively protect
against spoofing of the source address of RSVP packets, if the against spoofing of the source address of RSVP packets, if the
filter relies on the neighbor's address within the RSVP message. filter relies on the neighbor's address within the RSVP message.
RSVP neighbor filtering at the data plane level (access list to RSVP neighbor filtering at the data plane level (with an access
accept IP packet with port 46, only for specific neighbors). This list to accept IP packets with port 46, only for specific
requires Router Alert mode to be deactivated. This does not protect neighbors). This requires Router Alert mode to be deactivated and
against spoofing. does not protect against spoofing.
- Authentication for RSVP messages - Authentication for RSVP messages
Fang, et al. Informational 34
MPLS/GMPLS Security framework
February 2007
One of the most powerful tools for protection against RSVP-based One of the most powerful tools for protection against RSVP-based
attacks is the use of authentication for RSVP messages, based on a attacks is the use of authentication for RSVP messages, based on a
secure message hash using a key shared by RSVP neighbors. This secure message hash using a key shared by RSVP neighbors. This
protects against LSP creation attacks, at the expense of consuming protects against LSP creation attacks, at the expense of consuming
significant CPU resources for digest computation. In addition, if significant CPU resources for digest computation. In addition, if
the neighboring RSVP speaker is compromised, it could be used to the neighboring RSVP speaker is compromised, it could be used to
launch attacks using authenticated RSVP messages. launch attacks using authenticated RSVP messages. These methods,
and certain other aspects of RSVP security, are explained in detail
in RFC 4230 [RFC4230]. Key management must be implemented. Logging
and auditing as well as multiple layers of crypto protection can
help here. IPsec can also be used.
Another valuable tool is RSVP message pacing, to limit the number Another valuable tool is RSVP message pacing, to limit the number
of RSVP messages sent to a given neighbor during a given period. of RSVP messages sent to a given neighbor during a given period.
This allows blocking DoS attack propagation. This allows blocking DoS attack propagation.
In order to ensure continued effective operation of the MPLS router The trick with DoS is to let the good packet through and keep
even in the case of an attack which is able to bypass packet operating. Rate limiting by itself needs to be selective do this.
filtering mechanisms such as Access Control Lists in the data
plane, it is important that routers have some mechanisms to limit
the impact of the attack. There should be a mechanism to rate
limit the amount of control plane traffic addressed to the router,
per interface. This should be configurable on a per-protocol
basis, (and, ideally, on a per sender basis) to avoid an attacked
protocol, or a given sender blocking all communications. This
requires the ability to filter and limit the rate of incoming
messages of particular protocols, such as RSVP (filtering at the IP
port level), and particular senders). In addition, there should be
a mechanism to limit CPU and memory capacity allocated to RSVP, so
as to protect other control plane elements. In order to limit the
memory allocation, it will probably be necessary to limit the
number of LSPs which can be set up.
Fang, et al. Informational 37
MPLS/GMPLS Security framework
- limit the impact of an attack on control plane resources - limit the impact of an attack on control plane resources
In order to ensure continued effective operation of the MPLS router To ensure continued effective operation of the MPLS router even in
even in the case of an attack which is able to bypass packet the case of an attack that bypasses packet filtering mechanisms
filtering mechanisms such as Access Control Lists in the data such as Access Control Lists in the data plane, it is important
plane, it is important that routers have some mechanisms to limit that routers have some mechanisms to limit the impact of the
the impact of the attack. There should be a mechanism to rate attack. There should be a mechanism to rate limit the amount of
limit the amount of control plane traffic addressed to the router, control plane traffic addressed to the router, per interface. This
per interface. This should be configurable on a per-protocol should be configurable on a per-protocol basis, (and, ideally, on a
basis, (and, ideally, on a per sender basis) to avoid an attacked per-sender basis) to avoid letting an attacked protocol or a given
protocol, or a given sender blocking all communications. This sender blocking all communications. This requires the ability to
requires the ability to filter and limit the rate of incoming filter and limit the rate of incoming messages of particular
messages of particular protocols, such as RSVP (filtering at the IP protocols, such as RSVP (filtering at the IP protocol level), and
port level, and particular senders). In addition, there should be particular senders. In addition, there should be a mechanism to
a mechanism to limit CPU and memory capacity allocated to RSVP, so limit CPU and memory capacity allocated to RSVP, so as to protect
as to protect other control plane elements. In order to limit the other control plane elements. To limit the memory allocation, it
memory allocation, it will probably be necessary to limit the will probably be necessary to limit the number of LSPs that can be
number of LSPs which can be set up. set up.
Fang, et al. Informational 35
MPLS/GMPLS Security framework
February 2007
7.1.3. Control plane protection with LDP 7.1.3. Control plane protection with LDP
The approaches to protect MPLS routers against LDP-based attacks The approaches to protect MPLS routers against LDP-based attacks
are very similar to those for RSVP, including isolation, protocol are similar to those for RSVP, including isolation, protocol
deactivation on specific interfaces, filtering of LDP neighbors at deactivation on specific interfaces, filtering of LDP neighbors at
the protocol level, filtering of LDP neighbors at the data plane the protocol level, filtering of LDP neighbors at the data plane
level (access list that filter the TCP & UDP LDP ports), level (access list that filter the TCP & UDP LDP ports),
authentication with message digest, rate limiting of LDP messages authentication with message digest, rate limiting of LDP messages
per protocol per sender and limiting all resources which might be per protocol per sender and limiting all resources allocated to
allocated to LDP-related tasks. LDP-related tasks.
7.1.4. Data Plane Protection 7.1.4. Data Plane Protection
IPsec technologies can provide - encryption of secure provider or IPsec can provide authentication, integrity, confidentiality, and
user data. replay detection for provider or user data. It also has an
associated key management protocol.
In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is
not provided as a basic feature. Mechanisms described in section 5 not provided as a basic feature. Mechanisms described in section 5
can be used to secure the MPLS data plane to secure the data can be used to secure the MPLS data plane traffic carried over MPLS
carried over MPLS core. core. Both the Frame Relay Forum and the ATM Forum standardized
cryptographic security services in the late 1990s, but these
standards are not widely implemented.
Fang, et al. Informational 38
MPLS/GMPLS Security framework
7.2. Protection on the User Access Link 7.2. Protection on the User Access Link
Peer / Neighbor protocol authentication may be used to enhance Peer or neighbor protocol authentication may be used to enhance
security. For example, BGP MD5 authentication may be used to security. For example, BGP MD5 authentication may be used to
enhance security on PE-CE links using eBGP. In the case of Inter- enhance security on PE-CE links using eBGP. In the case of Inter-
provider connection, authentication / encryption mechanisms between provider connection, cryptographic protection mechanisms between
ASes, such as IPsec, may be used. ASes, such as IPsec, may be used.
WAN link address space separation for different services (e.g. VPN If multiple services are provided on the same PE platform,
and non-VPN) may be implemented to improve security in order to different WAN link layer address spaces may be used for different
protect each service if multiple services are provided on the same services (e.g., VPN and non-VPN) to enhance isolation.
PE platform.
Firewall / Filtering: access control mechanisms can be used to Firewall and Filtering: access control mechanisms can be used to
filter out any packets destined for the service provider's filter any packets destined for the service provider's
infrastructure prefix or eliminate routes identified as infrastructure prefix or eliminate routes identified as
illegitimate routes. illegitimate.
Rate limiting may be applied to the user interface/logical Rate limiting may be applied to the user interface/logical
interfaces against DDOS bandwidth attack. This is very helpful when interfaces against DDoS bandwidth attack. This is helpful when the
the PE device is supporting both multi-services, especially when PE device is supporting both multi-services, especially VPN and
supporting VPN and Internet Services on the same physical Internet Services, on the same physical interfaces through
interfaces through different logical interfaces. different logical interfaces.
Fang, et al. Informational 36
MPLS/GMPLS Security framework
February 2007
7.2.1. Link Authentication 7.2.1. Link Authentication
Authentication mechanisms can be employed to validate site access Authentication can be used to validate site access to the network
to the network via fixed or logical (e.g. L2TP, IPsec) connections. via fixed or logical connections, e.g. L2TP, IPsec, respectively.
Where the user wishes to hold the 'secret' associated to acceptance If the user wishes to hold the authentication credentials for
of the access and site into the VPN, then provider solutions access to the VPN, then provider solutions require the flexibility
require the flexibility for either direct authentication by the PE for either direct authentication by the PE itself or interaction
itself or interaction with a customer authentication server. with a customer authentication server. Mechanisms are required in
Mechanisms are required in the latter case to ensure that the the latter case to ensure that the interaction between the PE and
interaction between the PE and the customer authentication server the customer authentication server is appropriately secured.
is controlled e.g. limiting it simply to an exchange in relation to
the authentication phase and with other attributes e.g. RADIUS
optionally being filtered.
7.2.2. Access Routing 7.2.2. Access Routing
Mechanisms may be used to provide control at a routing protocol Routing protocol level e.g., RIP, OSPF, or BGP, may be used to
level e.g. RIP, OSPF, BGP between the CE and PE. Per neighbor and provide control access between a CE and PE. Per neighbor and per
per VPN routing policies may be established to enhance security and VPN routing policies may be established to enhance security and
reduce the impact of a malicious or non-malicious attack on the PE, reduce the impact of a malicious or non-malicious attack on the PE;
in particular the following mechanisms should be considered: the following mechanisms, in particular, should be considered:
- Limiting the number of prefixes that may be advertised on - Limiting the number of prefixes that may be advertised on
a per access basis into the PE. Appropriate action may be a per access basis into the PE. Appropriate action may be
taken should a limit be exceeded e.g. the PE shutting taken should a limit be exceeded, e.g., the PE shutting
down the peer session to the CE down the peer session to the CE
- Applying route dampening at the PE on received routing - Applying route dampening at the PE on received routing
updates updates
Fang, et al. Informational 39
MPLS/GMPLS Security framework
- Definition of a per VPN prefix limit after which - Definition of a per VPN prefix limit after which
additional prefixes will not be added to the VPN routing additional prefixes will not be added to the VPN routing
table. table.
In the case of Inter-provider connection, access protection, link In the case of Inter-provider connection, access protection, link
authentication, and routing policies as described above may be authentication, and routing policies as described above may be
applied. Both inbound and outbound firewall/filtering mechanism applied. Both inbound and outbound firewall or filtering mechanism
between ASes may be applied. Proper security procedures must be between ASes may be applied. Proper security procedures must be
implemented in Inter-provider VPN interconnection to protect the implemented in Inter-provider VPN interconnection to protect the
providers' network infrastructure and their customer VPNs. This may providers' network infrastructure and their customers' VPNs. This
be custom designed for each Inter-Provider VPN peering connection, may be custom designed for each Inter-Provider VPN peering
and must be agreed by both providers. connection, and must be agreed upon by both providers.
7.2.3. Access QoS 7.2.3. Access QoS
MPLS/GMPLS providers offering QoS enabled services require MPLS/GMPLS providers offering QoS-enabled services require
mechanisms to ensure that individual accesses are validated against mechanisms to ensure that individual accesses are validated against
their subscribed QOS profile and as such gain access to core their subscribed QOS profile and as such gain access to core
resources that match their service profile. Mechanisms such as per resources that match their service profile. Mechanisms such as per
Class of service rate limiting/traffic shaping on ingress to the Class of Service rate limiting or traffic shaping on ingress to the
MPLS/GMPLS core are one option in providing this level of control. MPLS/GMPLS core are one option for providing this level of control.
Fang, et al. Informational 37
MPLS/GMPLS Security framework
February 2007
Such mechanisms may require the per Class of Service profile to be Such mechanisms may require the per Class of Service profile to be
enforced either by marking, remarking or discard of traffic outside enforced either by marking, or remarking or discard of traffic
of profile. outside of the profile.
7.2.4. Customer service monitoring tools 7.2.4. Customer service monitoring tools
End users requiring visibility of the specific statistics on the End users requiring specific statistics on the core, e.g., routing
core e.g. routing table, interface status, QoS statistics, impose table, interface status, or QoS statistics, requirements for
requirements for mechanisms at the PE to both validate the incoming mechanisms at the PE both to validate the incoming user and limit
user and limit the views available to that particular user. the views available to that particular user. Mechanisms should
Mechanisms should also be considered to ensure that such access also be considered to ensure that such access cannot be used a
cannot be used a means of a DOS attack (either malicious or means of a DoS attack (either malicious or accidental) on the PE
accidental) on the PE itself. This could be accomplished through itself. This could be accomplished through either separation of
either separation of these resources within the PE itself or via these resources within the PE itself or via the capability to rate-
the capability to rate-limit on a per physical/logical connection limit on a per physical or logical connection basis such traffic.
basis such traffic.
7.3. General Requirements for MPLS/GMPLS Providers 7.3. General Requirements for MPLS/GMPLS Providers
The MPLS/GMPLS providers must support the users' security MPLS/GMPLS providers must support users' security requirements as
requirements as listed in Section 7. Depending on the technologies listed in Section 7. Depending on the technologies used, these
used, these requirements may include: requirements may include:
- User control plane separation - routing isolation - User control plane separation - routing isolation
- Protection against intrusion, DOS attacks and spoofing - Protection against intrusion, DoS attacks and spoofing
- Access Authentication - Access Authentication
- Techniques highlighted through this document identify
methodologies for the protection of resources and Fang, et al. Informational 40
MPLS/GMPLS Security framework
- Techniques highlighted through this document that identify
methodologies for the protection of resources and the
MPLS/GMPLS infrastructure. MPLS/GMPLS infrastructure.
Equipment hardware/software bugs leading to breaches in security Hardware or software errors in equipment leading to breaches in
are not within the scope of this document. security are not within the scope of this document.
8. Inter-provider Security Requirements 8. Inter-provider Security Requirements
This section discusses security capabilities that are important at This section discusses security capabilities that are important at
the MPLS/GMPLS Inter-provider connections, and at devices the MPLS/GMPLS Inter-provider connections and at devices (including
(including ASBR routers) which support the Inter-provider ASBR routers) supporting these connections. The security
connections. The security capabilities stated in this section capabilities stated in this section should be considered as
should be considered as complementary to security considerations complementary to security considerations addressed in individual
addressed in the individual protocol specifications and/or security protocol specifications or security frameworks.
frameworks.
Security vulnerabilities and exposures may be propagated across Security vulnerabilities and exposures may be propagated across
multiple networks because of security vulnerabilities arising in multiple networks because of security vulnerabilities arising in
one peer's network. Threats to security originate from accidental, one peer's network. Threats to security originate from accidental,
administrative, and intentional sources. Intentional threats
Fang, et al. Informational 38 include events such as spoofing and Denial of Service (DoS)
MPLS/GMPLS Security framework attacks.
February 2007
administrative and intentional sources. Intentional threats include
events such as spoofing and Denial of Service (DoS) attacks.
The level and nature of threats, as well as security and The level and nature of threats, as well as security and
availability requirements, may vary over time and from network to availability requirements, may vary over time and from network to
network. This section therefore discusses capabilities that need to network. This section therefore discusses capabilities that need to
be available in equipment deployed for support of the MPLS-ICI. be available in equipment deployed for support of the MPLS
Whether any particular capability is used in any one specific InterCarrier Interconnect (MPLS-ICI). Whether any particular
instance of the ICI is up to the service providers managing the capability is used in any one specific instance of the ICI is up to
provider edge equipment offering/using the ICI services. the service providers managing the PE equipment offering/using the
ICI services.
8.1. Control Plane Protection 8.1. Control Plane Protection
This section discusses capabilities for control plane protection, This section discusses capabilities for control plane protection,
including protection of routing, signaling, and OAM capabilities. including protection of routing, signaling, and OAM capabilities.
8.1.1. Authentication of Signaling Sessions 8.1.1. Authentication of Signaling Sessions
Authentication of signaling sessions (i.e., BGP, LDP and RSVP-TE) Authentication is needed for signaling sessions (i.e., BGP, LDP and
and routing sessions (e.g., BGP) as well as OAM sessions across RSVP-TE) and routing sessions (e.g., BGP) as well as OAM sessions
domain boundaries. Equipment must be able to support exchange of across domain boundaries. Equipment must be able to support
all protocol messages over a single IPsec tunnel, with NULL exchange of all protocol messages over a single IPsec tunnel, with
encryption and authentication, between the peering ASBRs. Support NULL encryption and authentication, between the peering ASBRs.
for TCP MD5 authentication for LDP and BGP and for RSVP-TE Support for TCP MD5 authentication for LDP and BGP and for RSVP-TE
authentication must also be provided. authentication must also be provided. Manual keying of IPsec should
not be used. IKEv2 with pre-shared secrets or public key methods
should be used. Replay detection should be used.
Fang, et al. Informational 41
MPLS/GMPLS Security framework
Mechanisms to authenticate and validate a dynamic setup request Mechanisms to authenticate and validate a dynamic setup request
MUST be available. For instance, if dynamic signaling of a TE-LSP MUST be available. For instance, if dynamic signaling of a TE-LSP
or PW is crossing a domain boundary, there must be a way to detect or PW is crossing a domain boundary, there must be a way to detect
whether the LSP source is who he claims to be and that he is whether the LSP source is who it claims to be and that he is
allowed to connect to the destination. allowed to connect to the destination.
MD5 authentication support for all TCP-based protocols within the MD5 authentication support for all TCP-based protocols within the
scope of the MPLS-ICI (i.e., LDP signaling, and BGP routing) and scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and MD5
MD5 authentication for the RSVP-TE Integrity Object MUST be authentication for the RSVP-TE Integrity Object MUST be provided to
provided to interoperate with current practices. interoperate with current practices.
Equipment SHOULD be able to support exchange of all signaling and Equipment SHOULD be able to support exchange of all signaling and
routing (LDP, RSVP-TE, and BGP) protocol messages over a single routing (LDP, RSVP-TE, and BGP) protocol messages over a single
IPSec in tunnel or transport mode with authentication but with NULL IPSec security association pair in tunnel or transport mode with
encryption, between the peering ASBRs. IPSec, if supported, must be authentication but with NULL encryption, between the peering ASBRs.
supported with HMAC-MD-5 and optionally SHA-1. It is expected that IPSec, if supported, must be supported with HMAC-MD5 and optionally
authentication algorithms will evolve over time and support can be SHA-1. It is expected that authentication algorithms will evolve
updated as needed. over time and support can be updated as needed.
OAM Operations across the MPLS-ICI could also be the source of OAM Operations across the MPLS-ICI could also be the source of
security threats on the provider infrastructure as well as the security threats on the provider infrastructure as well as the
service offered over the MPLS-ICI. A large volume of OAM messages service offered over the MPLS-ICI. A large volume of OAM messages
could overwhelm the processing capabilities of an ASBR if the ASBR could overwhelm the processing capabilities of an ASBR if the ASBR
is not probably protected. Maliciously-generated OAM messages could is not properly protected. Maliciously generated OAM messages could
Fang, et al. Informational 39
MPLS/GMPLS Security framework
February 2007
also be used to bring down an otherwise healthy service (e.g., MPLS also be used to bring down an otherwise healthy service (e.g., MPLS
Pseudo Wire), and therefore effecting service security. MPLS-ping Pseudo Wire), and therefore affect service security. MPLS-ping does
does not support authentication today and that support should be not support authentication today, and that support should be
subject for future considerations. Bidirectional Forwarding subject for future considerations. Bidirectional Forwarding
Detection (BFD) however, does have support for carrying an Detection (BFD), however, does have support for carrying an
authentication object. It also supports Time-To-Live (TTL) authentication object. It also supports Time-To-Live (TTL)
processing as anti-replay measure. Implementations conformant to processing as an anti-replay measure. Implementations conformant
this MPLS-ICI should support BFD authentication using MD-5 and must with this MPLS-ICI should support BFD authentication using MD5 and
support the procedures for TTL processing. must support the procedures for TTL processing.
8.1.2. Protection against DoS attacks in the Control Plane 8.1.2. Protection against DoS attacks in the Control Plane
Ability to prevent signaling and routing DOS attacks on the control Implementation must have the ability to prevent signaling and
plane per interface and provider. Such prevention may be provided routing DoS attacks on the control plane per interface and
by rate-limiting signaling and routing messages that can be sent by provider. Such prevention may be provided by rate-limiting
a peer provider according to a traffic profile and by guarding signaling and routing messages that can be sent by a peer provider
against malformed packets. according to a traffic profile and by guarding against malformed
packets.
Equipment MUST provide the ability to filter signaling, routing, Equipment MUST provide the ability to filter signaling, routing,
and OAM packets destined for the device, and MUST provide the and OAM packets destined for the device, and MUST provide the
ability to rate limit such packets. Packet filters SHOULD be ability to rate limit such packets. Packet filters SHOULD be
capable of being separately applied per interface, and SHOULD have capable of being separately applied per interface, and SHOULD have
minimal or no performance impact. For example, this allows an minimal or no performance impact. For example, this allows an
Fang, et al. Informational 42
MPLS/GMPLS Security framework
operator to filter or rate-limit signaling, routing, and OAM operator to filter or rate-limit signaling, routing, and OAM
messages that can be sent by a peer provider and limit such traffic messages that can be sent by a peer provider and limit such traffic
to a traffic profile. to a given profile.
In the presence of a control plane DoS attack against an ASBR, the During a control plane DoS attack against an ASBR, the router
router SHOULD guarantee sufficient resources to allow network SHOULD guarantee sufficient resources to allow network operators to
operators to execute network management commands to take corrective execute network management commands to take corrective action, such
action, such as turning on additional filters or disconnecting an as turning on additional filters or disconnecting an interface
interface which is under attack. DoS attacks on the control plane under attack. DoS attacks on the control plane SHOULD NOT adversely
SHOULD NOT adversely affect data plane performance. affect data plane performance.
Equipment which supports BGP MUST support the ability to limit the Equipment running BGP MUST support the ability to limit the number
number of BGP routes received from any particular peer. of BGP routes received from any particular peer. Furthermore, in
Furthermore, in the case of IPVPN, a router MUST be able to limit the case of IPVPN, a router MUST be able to limit the number of
the number of routes learned from a BGP peer per IPVPN. In the case routes learned from a BGP peer per IPVPN. In the case that a device
that a device has multiple BGP peers, it SHOULD be possible for the has multiple BGP peers, it SHOULD be possible for the limit to vary
limit to vary between peers. between peers.
8.1.3. Protection against Malformed Packets 8.1.3. Protection against Malformed Packets
Equipment SHOULD be robust in the presence of malformed protocol Equipment SHOULD be robust in the presence of malformed protocol
packets. For example, malformed routing, signaling, and OAM packets packets. For example, malformed routing, signaling, and OAM packets
should be treated in accordance to the relevant protocol should be treated in accordance to the relevant protocol
specification. specification.
Fang, et al. Informational 40 8.1.4. Ability to Enable/Disable Specific Protocols
MPLS/GMPLS Security framework
February 2007
8.1.4. Ability to Enable/Disable Specific Protocols
Ability to drop any signaling or routing protocol messages when Ability to drop any signaling or routing protocol messages when
these messages are to be processed by the ASBR but the these messages are to be processed by the ASBR but the
corresponding protocol is not enabled on that interface. corresponding protocol is not enabled on that interface.
Equipment must allow an administrator to enable or disable a Equipment must allow an administrator to enable or disable a
protocol (default protocol is disabled unless administratively protocol (default protocol is disabled unless administratively
enable) on an interface basis. enable) on an interface basis.
Equipment MUST be able to drop any signaling or routing protocol Equipment MUST be able to drop any signaling or routing protocol
messages when these messages are to be processed by the ASBR but messages when these messages are to be processed by the ASBR but
the corresponding protocol is not enabled on that interface. This the corresponding protocol is not enabled on that interface. This
dropping SHOULD NOT adversely affect data plane or control plane dropping SHOULD NOT adversely affect data plane or control plane
performance. performance.
8.1.5. Protection Against Incorrect Cross Connection 8.1.5. Protection Against Incorrect Cross Connection
Capability of detecting and locating faults in an LSP cross-connect The capability of detecting and locating faults in a LSP cross-
MUST be provided. Such faults cause security violations as they connect MUST be provided. Such faults may cause security violations
result in directing traffic to the wrong destinations. This as they result in directing traffic to the wrong destinations. This
capability may rely on OAM functions. capability may rely on OAM functions.
Fang, et al. Informational 43
MPLS/GMPLS Security framework
Equipment MUST support MPLS LSP Ping [RFC4379]. This MAY be used to Equipment MUST support MPLS LSP Ping [RFC4379]. This MAY be used to
verify end to end connectivity for the LSP (e.g., PW, TE Tunnel, verify end to end connectivity for the LSP (e.g., PW, TE Tunnel,
VPN LSP, etc), and to verify PE to PE connectivity for L3 VPN VPN LSP, etc.), and to verify PE-to-PE connectivity for L3 VPN
services. services.
When routing information is advertised from one domain to the When routing information is advertised from one domain to the
other, there MUST be mechanisms that enable operators to guard other, operators must be able to guard against situations that
against situations that result in traffic hijacking, black-holing, result in traffic hijacking, black-holing, resource stealing (e.g.,
resource stealing (e.g., number of routes), etc. For instance, in number of routes), etc. For instance, in the IPVPN case, an
the IPVPN case, an operator must be able to block routes based on operator must be able to block routes based on associated route
associated route target attributes. In addition, mechanisms must target attributes. In addition, mechanisms must exist to verify
exist to verify whether a route advertised by a peer for a given whether a route advertised by a peer for a given VPN is actually a
VPN is actually a valid route and whether the VPN has a site valid route and whether the VPN has a site attached or reachable
attached or reachable through that domain. through that domain.
Equipment (ASBRs and RRs) which supports operation of BGP MUST
allow a means to restrict which Route Target attributes are sent to
and accepted from a BGP peer across an ICI. Equipment (ASBRs, RRs)
SHOULD also be able to inform the peer regarding which Route Target
attributes it will accept from the peer. This is due to the fact
that a peer which sends an incorrect Route Target can result in
incorrect cross-connection of VPNs. Also, sending inappropriate
route targets to a peer may disclose confidential information.
Further Security Consideration for inter-provider BGP/MPLS IPVPN
operations are discussed in the IPVPN Annex.
Fang, et al. Informational 41 Equipment (ASBRs and Route Reflectors (RRs)) supporting operation
MPLS/GMPLS Security framework of BGP MUST be able to restrict which Route Target attributes are
February 2007 sent to and accepted from a BGP peer across an ICI. Equipment
(ASBRs, RRs) SHOULD also be able to inform the peer regarding which
Route Target attributes it will accept from a peer, because sending
an incorrect Route Target can result in incorrect cross-connection
of VPNs. Also, sending inappropriate route targets to a peer may
disclose confidential information. Further Security Consideration
for inter-provider BGP/MPLS IPVPN operations are discussed in the
IPVPN Annex.
8.1.6. Protection Against Spoofed Updates and Route 8.1.6. Protection Against Spoofed Updates and Route Advertisements
Advertisements
Equipment MUST support signaling and routing.
Equipment MUST support route filtering of routes received via a BGP Equipment MUST support route filtering of routes received via a BGP
peer sessions by applying policies that include one or more the peer sessions by applying policies that include one or more the
following: AS path, BGP next hop, standard community and/or following: AS path, BGP next hop, standard community or extended
extended community. community.
8.1.7. Protection of Confidential Information 8.1.7. Protection of Confidential Information
Ability to identify and prohibit messages that can reveal Ability to identify and prohibit messages that can reveal
confidential information about network operation (e.g., performance confidential information about network operation (e.g., performance
OAM messages, MPLS-ping messages). Service Providers must have the OAM messages or MPLS-ping messages) is required. Service Providers
flexibility of handling these messages at the ASBR. must have the flexibility of handling these messages at the ASBR.
Equipment SHOULD provide the ability to identify and prohibit Equipment SHOULD provide the ability to identify and restrict where
messages that can reveal confidential information about network it sends messages or that can reveal confidential information about
operation (e.g., performance OAM messages, LSP Traceroute network operation (e.g., performance OAM messages, LSP Traceroute
messages). Service Providers must have the flexibility of handling messages). Service Providers must have the flexibility of handling
these messages at the ASBR. For example, equipment supporting LSP these messages at the ASBR. For example, equipment supporting LSP
Traceroute MAY limit which addresses replies can be sent to. Traceroute MAY limit to which addresses replies can be sent.
Note: This capability should be used with care. For example, if a Note: This capability should be used with care. For example, if a
service provider chooses to prohibit the exchange of LSP PING service provider chooses to prohibit the exchange of LSP PING
Fang, et al. Informational 44
MPLS/GMPLS Security framework
messages at the ICI, it may make it more difficult to debug messages at the ICI, it may make it more difficult to debug
incorrect cross-connection of LSPs or other problems. incorrect cross-connection of LSPs or other problems.
A provider may decide to progress these messages if they are A provider may decide to progress these messages if they are
incoming from a trusted provider and are targeted to specific incoming from a trusted provider and are targeted to specific
agreed-on addresses. Another provider may decide to traffic police, agreed-on addresses. Another provider may decide to traffic police,
reject or apply policies to these messages. Solutions must enable reject, or apply policies to these messages. Solutions must enable
providers to control the information that is relayed to another providers to control the information that is relayed to another
provider about the path that an LSP takes. For example, in RSVP-TE provider about the path that a LSP takes. For example, in RSVP-TE
record route object or MPLS-ping trace, a provider must be able to record route object or MPLS-ping trace, a provider must be able to
control the information contained in corresponding messages when control the information contained in corresponding messages when
sent to another provider. sent to another provider.
8.1.8. Protection Against over-provisioned number of RSVP-TE 8.1.8. Protection Against over-provisioned number of RSVP-TE LSPs
LSPs and bandwidth reservation and bandwidth reservation
In addition to the control plane protection mechanisms listed in In addition to the control plane protection mechanisms listed in
the previous section on Control plane protection with RSVP-TE, the the previous section on Control plane protection with RSVP-TE, the
ASBR needs mechanisms to both limit the number of LSPs that can be ASBR must be able both to limit the number of LSPs that can be set
set up by other domains and to limit the amount of bandwidth that up by other domains and to limit the amount of bandwidth that can
can be reserved. A provider's ASBR may deny the LSPs set up request be reserved. A provider's ASBR may deny a LSP set up request or a
or the bandwidth reservation request sent by another provider's the bandwidth reservation request sent by another provider's whose the
limits are reached. limits have been reached.
Fang, et al. Informational 42
MPLS/GMPLS Security framework
February 2007
8.2. Data Plane Protection 8.2. Data Plane Protection
8.2.1. Protection against DoS in the Data Plane 8.2.1. Protection against DoS in the Data Plane
This is provided earlier in this document. This is described earlier in this document.
8.2.2. Protection against Label Spoofing 8.2.2. Protection against Label Spoofing
Verification that a label received across an interconnect was Verification that a label received across an interconnect was
actually assigned to the provider across the interconnect. If the actually assigned to the provider across the interconnect. If the
label was not assigned to the provider, the packet MUST be dropped. label was not assigned to the provider, the packet MUST be dropped.
Equipment MUST be able to verify that a label received across an Equipment MUST be able to verify that a label received across an
interconnect was actually assigned to an LSP arriving from the interconnect was actually assigned to a LSP arriving from the
provider across that interconnect. If the label was not assigned to provider across that interconnect. If the label was not assigned to
an LSP which arrives at this router from the correct neighboring a LSP which arrives at this router from the correct neighboring
provider, the packet MUST be dropped. This verification can be provider, the packet MUST be dropped. This verification can be
applied to the top label only. The top label is the received top applied to the top label only. The top label is the received top
label and every label that is exposed by label popping to be used label and every label that is exposed by label popping to be used
for forwarding decisions. for forwarding decisions.
Equipment MUST provide the capability of dropping MPLS-labeled Equipment MUST provide the capability of dropping MPLS-labeled
packets if all labels in the stack are not processed. This packets if all labels in the stack are not processed. This lets
provides carriers the capability of guaranteeing that every label carriers guarantee that every label that enters its domain from
that enters its domain from another carrier was actually assigned another carrier was actually assigned to that carrier.
to that carrier.
Fang, et al. Informational 45
MPLS/GMPLS Security framework
The following requirements are not directly reflected in this The following requirements are not directly reflected in this
document but must be used as guidance for addressing further work. document but must be used as guidance for addressing further work.
Solutions MUST NOT force operators to reveal reachability Solutions MUST NOT force operators to reveal reachability
information to routers within their domains. <note, it is believed information to routers within their domains. <note, it is believed
that this requirement is met via other requirements specified in that this requirement is met via other requirements specified in
this section plus the normal operation of IP routing, which does this section plus the normal operation of IP routing, which does
not reveal individual hosts. not reveal individual hosts.
Mechanisms to authenticate and validate a dynamic setup request Mechanisms to authenticate and validate a dynamic setup request
MUST be available. For instance, if dynamic signaling of a TE-LSP MUST be available. For instance, if dynamic signaling of a TE-LSP
or PW is crossing a domain boundary, there must be a way to detect or PW is crossing a domain boundary, there must be a way to detect
whether the LSP source is who he claims to be and that he is whether the LSP source is who it claims to be and that he is
allowed to connect to the destination. allowed to connect to the destination.
8.2.3. Protection using ingress traffic policing and enforcement 8.2.3. Protection using ingress traffic policing and enforcement
In the following diagram, we use a simple diagram to illustrate a The following simple diagram illustrates a potential security issue
potential security issue on the data plane issue across the MPLS on the data plane issue across a MPLS interconnect:
interconnect:
SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1 SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1
Fang, et al. Informational 43
MPLS/GMPLS Security framework
February 2007
| | | | | | | |
|< AS2 >|<MPLS interconnect>|< AS1 >| |< AS2 >|<MPLS interconnect>|< AS1 >|
Traffic flow direction is from SP2 to SP1 Traffic flow direction is from SP2 to SP1
Usually, the transit label used by ASBR2 is allocated by ASBR1 Usually, the transit label used by ASBR2 is allocated by ASBR1,
which in turn advertises to ASB2 (downstream unsolicited or on- which in turn advertises it to ASB2 (downstream unsolicited or on-
demand) and this label is used for a service context (VPN label, PW demand), and this label is used for a service context (VPN label,
VC label, etc.) and this LSP is normally terminated at a forwarding PW VC label, etc.), and this LSP is normally terminated at a
table belonging to the service instance on PE (PE1) in SP1. forwarding table belonging to the service instance on PE (PE1) in
SP1.
In the example above, ASBR1 would not know if the label of an In the example above, ASBR1 would not know whether the label of an
incoming packet from ASBR2 over the interconnect is VPN label or incoming packet from ASBR2 over the interconnect is a VPN label or
PSN label for AS1. So it is possible (though rare) that ASBR2 can PSN label for AS1. So it is possible (though rare) that ASBR2 can
be tempered such that the incoming label could match a PSN label be tempered such that the incoming label could match a PSN label
(e.g., LDP) in AS1 - then this LSP would end up on the global plane (e.g., LDP) in AS1. Then, this LSP would end up on the global plane
of an infrastructure router (P or PE1) - this could invite a of an infrastructure router (P or PE1), and this could invite a
unidirectional attack on that P or PE1 the LSP terminates. unidirectional attack on that P or PE1 where the LSP terminates.
To mitigate this threat, we SHOULD be able to do a forwarding path To mitigate this threat, implementations SHOULD be able to do a
look-up for the label on an incoming packet from a interconnect in forwarding path look-up for the label on an incoming packet from an
a LFIB space that is only intended for its own service context or interconnect in a Label Forwarding Information Base (LFIB) space
provide a mechanism on the data plane that would ensure the that is only intended for its own service context or provide a
incoming labels are what ASBR1 has allocated and advertised. mechanism on the data plane that would ensure the incoming labels
are what ASBR1 has allocated and advertised.
Similar concept has been proposed in "Requirements for Multi- Fang, et al. Informational 46
MPLS/GMPLS Security framework
A similar concept has been proposed in "Requirements for Multi-
Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [PW-REQ]. Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [PW-REQ].
9. Security Considerations 9. Security Considerations
Security considerations constitute the sole subject of this memo Security considerations constitute the sole subject of this memo
and hence are discussed throughout. Here we recap what has been and hence are discussed throughout. Here we recap what has been
presented and explain at a very high level the role of each type of presented and explain at a high level the role of each type of
consideration in an overall secure MPLS/GMPLS system. consideration in an overall secure MPLS/GMPLS system.
The document describes a number of potential security threats. The document describes a number of potential security threats.
Some of these threats have already been observed occurring in Some of these threats have already been observed occurring in
running networks; others are largely theoretical at this time. DOS running networks; others are largely theoretical at this time.
attacks and intrusion
Attacks from the Internet against service provider infrastructure
have been seen to occur. DOS "attacks" (typically not malicious)
have also been seen in which CE equipment overwhelms PE equipment
with high quantities or rates of packet traffic or routing
Fang, et al. Informational 44
MPLS/GMPLS Security framework
February 2007
information. Operational/provisioning errors are cited by service DoS attacks and intrusion attacks from the Internet against service
providers as one of their prime concerns. providers' infrastructure have been seen. DOS "attacks" (typically
not malicious) have also been seen in which CE equipment overwhelms
PE equipment with high quantities or rates of packet traffic or
routing information. Operational or provisioning errors are cited
by service providers as one of their prime concerns.
The document describes a variety of defensive techniques that may The document describes a variety of defensive techniques that may
be used to counter the suspected threats. All of the techniques be used to counter the suspected threats. All of the techniques
presented involve mature and widely implemented technologies that presented involve mature and widely implemented technologies that
are practical to implement. are practical to implement.
The document describes the importance of detecting, monitoring, and The document describes the importance of detecting, monitoring, and
reporting attacks, both successful and unsuccessful. These reporting attacks, both successful and unsuccessful. These
activities are essential for "understanding one's enemy", activities are essential for "understanding one's enemy",
mobilizing new defenses, and obtaining metrics about how secure the mobilizing new defenses, and obtaining metrics about how secure the
MPLS/GMPLS network is. As such they are vital components of any MPLS/GMPLS network is. As such, they are vital components of any
complete PPVPN security system. complete PPVPN security system.
The document evaluates MPLS/GMPLS security requirements from a The document evaluates MPLS/GMPLS security requirements from a
customer perspective as well as from a service provider customer's perspective as well as from a service provider's
perspective. These sections re-evaluate the identified threats perspective. These sections re-evaluate the identified threats
from the perspectives of the various stakeholders and are meant to from the perspectives of the various stakeholders and are meant to
assist equipment vendors and service providers, who must ultimately assist equipment vendors and service providers, who must ultimately
decide what threats to protect against in any given equipment or decide what threats to protect against in any given configuration
service offering. or service offering.
10. IANA Considerations 10. IANA Considerations
TBD. TBD.
Fang, et al. Informational 47
MPLS/GMPLS Security framework
11. Normative References 11. Normative References
[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001. Switching Architecture", RFC 3031, January 2001.
[RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3036] Andersson, et al., "LDP Specification", January 2001. [RFC3036] Andersson, et al., "LDP Specification", January 2001.
[RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", December 2001. Tunnels", December 2001.
[RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet
Protocol," December 2005. Protocol," December 2005.
[RFC4302] S. Kent, "IP Authentication Header," December 2005. [RFC4302] S. Kent, "IP Authentication Header," December 2005.
Fang, et al. Informational 45 [RFC4835] V. Manral, "Cryptographic Algorithm Implementation
MPLS/GMPLS Security framework
February 2007
[RFC4305] D. Eastlake 3rd, "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", December 2005. Authentication Header (AH)", April 2007.
[RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2)
Protocol",December 2005. Protocol",December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES)
CCM Mode with IPsec Encapsulating Security Payload (ESP)", December
2005.
[RFC4346] T. Dierks and E. Rescorla, "The Transport Layer Security [RFC4346] T. Dierks and E. Rescorla, "The Transport Layer Security
(TLS) Protocol, Version 1.1," April 2006. (TLS) Protocol, Version 1.1," April 2006.
[RFC4379] K. Kompella and G. Swallow, "Detecting Multi-Protocol [RFC4379] K. Kompella and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", February 2006. Label Switched (MPLS) Data Plane Failures", February 2006.
[RFC4447] Martini, et al., "Pseudowire Setup and Maintenance Using [RFC4447] Martini, et al., "Pseudowire Setup and Maintenance Using
the Label Distribution Protocol (LDP)", April 2006. the Label Distribution Protocol (LDP)", April 2006.
[STD62] "Simple Network Management Protocol, Version 3," RFCs 3411- [STD62] "Simple Network Management Protocol, Version 3,", December
3418, December 2002. 2002.
[STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification", [STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification",
STD 8, May 1983. STD 8, May 1983.
Fang, et al. Informational 48
MPLS/GMPLS Security framework
12. Informational References 12. Informational References
[AES-CCM] Housley, R., "Using AES CCM Mode With IPsec ESP", draft-
ietf-ipsec-ciph-aes-ccm-05.txt, work in progress, November 2003.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 Requirement Levels", BCP 14, RFC 2119, March 1997
[Beard] D. Beard and Y. Yang, "Known Threats to Routing Protocols," [Beard] D. Beard and Y. Yang, "Known Threats to Routing Protocols,"
draft-beard-rpsec-routing-threats-00.txt, Oct. 2002. (Note, this is draft-beard-rpsec-routing-threats-01.txt, Feb. 2003. (Note, this is
now approved as RFC, no number yet, http://www.ietf.org/internet- now approved as RFC, no number yet, http://www.ietf.org/internet-
drafts/draft-ietf-rpsec-routing-threats-06.txt. drafts/draft-ietf-rpsec-routing-threats-06.txt.
[OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces
to Network Elements", Optical Internetworking Forum, Sept. 2003.
[OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for
Management Interfaces to Network Elements", Optical Internetworking
Forum, March 2006.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication," February 1997. for Message Authentication," February 1997.
[RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document
Roadmap," November 1998. Roadmap," November 1998.
[RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm
1 (SHA1)," September 2001. 1 (SHA1)," September 2001.
Fang, et al. Informational 46 [RFC3562] M. Leech, "Key Management Considerations for the TCP MD5
MPLS/GMPLS Security framework Signature Option", July 2003.
February 2007
[RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security
Mechanisms for the Internet," December 2003.
[RFC3985] S. Bryant and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] S. Bryant and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", March 2005. Edge (PWE3) Architecture", March 2005.
[RFC4103] G. Hellstrom and P. Jones, "RTP Payload for Text
Conversation", June 2005.
[RFC4107] S. Bellovin, R. Housley, "Guidelines for Cryptographic
Key Management", June 2005.
[RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)", July 2005.
Fang, et al. Informational 49
MPLS/GMPLS Security framework
[RFC4111] L. Fang, "Security Framework of Provider Provisioned [RFC4111] L. Fang, "Security Framework of Provider Provisioned
VPN", RFC 4111, July 2005. VPN", RFC 4111, July 2005.
[RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security [RFC4230] H. Tschofenig and R. Graveman, "RSVP Security
Mechanisms for the Internet," December 2003. Properties", December 2005.
[RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 [RFC4308] P. Hoffman, "Cryptographic Suites for IPsec", December
Provider-Provisioned Virtual Private Networks (PPVPNs), July 2005. 2005.
[RFC4808] S. Bellovin, "Key Change Strategies for TCP-MD5", March
2007.
[RFC4869] L. Law and J. Solinas, "Suite B Cryptographic Suites for
IPsec", April 2007.
[MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical [MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical
Specification", MFA2006.109.01, August 2006. Specification", MFA2006.109.01, August 2006.
[opsec efforts] C. Lonvick and D. Spak, "Security Best Practices [opsec efforts] C. Lonvick and D. Spak, "Security Best Practices
Efforts and Documents", draft-ietf-opsec-efforts-05.txt, December Efforts and Documents", draft-ietf-opsec-efforts-05.txt, December
2006. 2006.
[PW-REQ] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi- [PW-REQ] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi-
Segment Pseudowire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw- Segment Pseudowire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-
requirements-04.txt. requirements-05.txt, March 2007.
13. Author's Addresses 13. Author's Addresses
Luyuan Fang Luyuan Fang
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
EMail: lufang@cisco.com Email: lufang@cisco.com
Michael Behringer Michael Behringer
Cisco Systems, Inc. Cisco Systems, Inc.
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3 400, Avenue Roumanille, Batiment T 3
06410 Biot, Sophia Antipolis 06410 Biot, Sophia Antipolis
FRANCE FRANCE
Fang, et al. Informational 50
MPLS/GMPLS Security framework
Email: mbehring@cisco.com Email: mbehring@cisco.com
Ross Callon Ross Callon
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
Fang, et al. Informational 47
MPLS/GMPLS Security framework
February 2007
USA USA
Email: rcallon@juniper.net Email: rcallon@juniper.net
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FRANCE FRANCE
skipping to change at line 2408 skipping to change at line 2467
2160 E. Grand Ave. El Segundo, CA 90025 2160 E. Grand Ave. El Segundo, CA 90025
USA USA
Email: raymond.zhang@bt.com Email: raymond.zhang@bt.com
Paul Knight Paul Knight
Nortel Nortel
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821 Billerica, MA 01821
EMail: paul.knight@nortel.com Email: paul.knight@nortel.com
Yaakov (Jonathan) Stein Yaakov (Jonathan) Stein
RAD Data Communications RAD Data Communications
24 Raoul Wallenberg St., Bldg C 24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719 Tel Aviv 69719
ISRAEL ISRAEL
Email: yaakov_s@rad.com Email: yaakov_s@rad.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com
Fang, et al. Informational 51
MPLS/GMPLS Security framework
Richard Graveman
RFG Security
15 Park Avenue
Morristown, NJ 07960
Email: rfg@acm.org
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Fang, et al. Informational 48
MPLS/GMPLS Security framework
February 2007
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
skipping to change at line 2454 skipping to change at line 2524
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Disclaimer Fang, et al. Informational 52
MPLS/GMPLS Security framework
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
14. Acknowledgement Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
14. Acknowledgements
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Fang, et al. Informational 49 The author and contributors would also like to acknowledge the
helpful comments and suggestions from Sam Hartman and Adrian Farrel.
Fang, et al. Informational 53
 End of changes. 399 change blocks. 
1206 lines changed or deleted 1300 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/