< draft-ietf-mpls-mpls-and-gmpls-security-framework-03.txt   draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt >
Network Working Group Luyuan Fang, Ed. Network Working Group Luyuan Fang, Ed.
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Category: Informational Category: Informational
Expires: January 2009 Expires: May 2009
July 12, 2008 November 2, 2008
Security Framework for MPLS and GMPLS Networks Security Framework for MPLS and GMPLS Networks
draft-ietf-mpls-mpls-and-gmpls-security-framework-03.txt draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 2, line 4 skipping to change at page 1, line 50
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 emphasizes mechanisms for detection and reporting. This document emphasizes
RSVP-TE and LDP security considerations, as well as Inter-AS and RSVP-TE and LDP security considerations, as well as Inter-AS and
Inter-provider security considerations for building and maintaining Inter-provider security considerations for building and maintaining
MPLS/GMPLS Security framework
MPLS and GMPLS networks across different domains or different MPLS and GMPLS networks across different domains or different
Service Providers. Service Providers.
MPLS/GMPLS Security framework
November 2008
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. Authors and Contributors...................................4 1.2. Authors and Contributors...................................4
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.....................................8 3. Security Reference Models.....................................8
4. Security Threats.............................................10 4. Security Threats.............................................10
4.1. Attacks on the Control Plane..............................11 4.1. Attacks on the Control Plane..............................11
4.2. Attacks on the Data Plane.................................14 4.2. Attacks on the Data Plane.................................14
5. Defensive Techniques for MPLS/GMPLS Networks.................16 5. Defensive Techniques for MPLS/GMPLS Networks.................16
5.1. Authentication............................................17 5.1. Authentication............................................17
5.2. Cryptographic Techniques..................................18 5.2. Cryptographic Techniques..................................19
5.3. Access Control Techniques.................................28 5.3. Access Control Techniques.................................29
5.4. Use of Isolated Infrastructure............................33 5.4. Use of Isolated Infrastructure............................33
5.5. Use of Aggregated Infrastructure..........................33 5.5. Use of Aggregated Infrastructure..........................34
5.6. Service Provider Quality Control Processes................34 5.6. Service Provider Quality Control Processes................34
5.7. Deployment of Testable MPLS/GMPLS Service.................34 5.7. Deployment of Testable MPLS/GMPLS Service.................35
6. Monitoring, Detection, and Reporting of Security Attacks.....34 5.8. Verification of Connectivity..............................35
7. Service Provider General Security Requirements...............35 6. Monitoring, Detection, and Reporting of Security Attacks.....35
7.1. Protection within the Core Network........................36 7. Service Provider General Security Requirements...............36
7.2. Protection on the User Access Link........................39 7.1. Protection within the Core Network........................37
7.3. General User Requirements for MPLS/GMPLS Providers........41 7.2. Protection on the User Access Link........................40
8. Inter-provider Security Requirements.........................42 7.3. General User Requirements for MPLS/GMPLS Providers........42
8.1. Control Plane Protection..................................42 8. Inter-provider Security Requirements.........................43
8.2. Data Plane Protection.....................................46 8.1. Control Plane Protection..................................43
9. Summary of MPLS and GMPLS Security...........................48 8.2. Data Plane Protection.....................................47
9.1. MPLS and GMPLS Specific Security Threats..................48 9. Summary of MPLS and GMPLS Security...........................49
9.2. Defense Techniques........................................49 9.1. MPLS and GMPLS Specific Security Threats..................49
9.3. Service Provider MPLS and GMPLS Best Practice Outlines....49 9.2. Defense Techniques........................................50
10. Security Considerations....................................50 9.3. Service Provider MPLS and GMPLS Best Practice Outlines....50
11. IANA Considerations........................................51 10. Security Considerations....................................51
12. Normative References.......................................51 11. IANA Considerations........................................52
13. Informational References...................................52 12. Normative References.......................................52
14. Author's Addresses.........................................54 13. Informational References...................................53
14. Author's Addresses.........................................55
15. Acknowledgements...........................................57 15. Acknowledgements...........................................57
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
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
skipping to change at page 4, line 4 skipping to change at page 3, line 52
must protect their network infrastructure and make it secure to the must protect their network infrastructure and make it secure to the
level required to provide services over their MPLS or GMPLS level required to provide services over their MPLS or GMPLS
networks. networks.
Inter-AS and Inter-provider security are discussed with special Inter-AS and Inter-provider security are discussed with special
emphasis, because the security risk factors are higher with inter- emphasis, because the security risk factors are higher with inter-
provider connections. provider connections.
Depending on different MPLS or GMPLS techniques used, the degree of Depending on different MPLS or GMPLS techniques used, the degree of
risk and the mitigation methodologies vary. This document discusses risk and the mitigation methodologies vary. This document discusses
MPLS/GMPLS Security framework
the security aspects and requirements for certain basic MPLS and the security aspects and requirements for certain basic MPLS and
MPLS/GMPLS Security framework
November 2008
GMPLS techniques and inter-connection models. This document does GMPLS techniques and inter-connection models. This document does
not attempt to cover all current and future MPLS and GMPLS not attempt to cover all current and future MPLS and GMPLS
technologies, as it is not within the scope of this document to technologies, as it is not within the scope of this document to
analyze the security properties of specific technologies. analyze the security 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
skipping to change at page 5, line 4 skipping to change at page 4, line 53
1.2. Authors and Contributors 1.2. Authors and Contributors
Authors: Authors:
Luyuan Fang, Ed., Cisco Systems, Inc. Luyuan Fang, Ed., Cisco Systems, Inc.
Michael Behringer, Cisco Systems, Inc. Michael Behringer, Cisco Systems, Inc.
Ross Callon, Juniper Networks Ross Callon, Juniper Networks
J. L. Le Roux, France Telecom J. L. Le Roux, France Telecom
Raymond Zhang, British Telecom Raymond Zhang, British Telecom
Paul Knight, Nortel Paul Knight, Nortel
MPLS/GMPLS Security framework
Yaakov Stein, RAD Data Communications Yaakov Stein, RAD Data Communications
MPLS/GMPLS Security framework
November 2008
Nabil Bitar, Verizon Nabil Bitar, Verizon
Richard Graveman, RFC Security, LLC Richard Graveman, RFC Security, LLC
Monique Morrow, Cisco Systems, Inc. Monique Morrow, Cisco Systems, Inc.
Adrian Farrel, Old Dog Consulting Adrian Farrel, Old Dog Consulting
As a design team member for the MPLS Security Framework, Jerry Ash As a design team member for the MPLS Security Framework, Jerry Ash
also made significant contributions to this document. also made significant contributions to this document.
2. Terminology 2. Terminology
skipping to change at page 6, line 5 skipping to change at page 5, line 49
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 capable of forwarding Label Switching Router (LSR): An MPLS node capable of forwarding
native IP packets. native IP packets.
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.
MPLS/GMPLS Security framework
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.
MPLS/GMPLS Security framework
November 2008
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 that perform MPLS routing MPLS Domain: A contiguous set of nodes that perform MPLS routing
and forwarding and are also in one Routing or Administrative and forwarding and are also in one Routing or Administrative
Domain. Domain.
MPLS Edge Node: A MPLS node that connects a MPLS domain with a node MPLS Edge Node: A MPLS node that connects a MPLS domain with a node
outside of the domain, either because it does not run MPLS, or outside of the domain, either because it does not run MPLS, or
skipping to change at page 7, line 4 skipping to change at page 6, line 52
routers. routers.
PE: Provider Edge device. A Provider Edge device is the equipment PE: Provider Edge device. A 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.
Core network: A MPLS/GMPLS core network is defined as the central Core network: A MPLS/GMPLS core network is defined as the central
network infrastructure which consists of P and PE routers. A network infrastructure which consists of P and PE routers. A
MPLS/GMPLS core network may consist of one or more networks belong MPLS/GMPLS core network may consist of one or more networks belong
to a single SP. to a single SP.
MPLS/GMPLS Security framework
VPN: Virtual Private Network, which restricts communication between VPN: Virtual Private Network, which restricts communication between
a set of sites, making use of an IP backbone shared by traffic not a set of sites, making use of an IP backbone shared by traffic not
going to or not coming from those sites ([RFC4110]). going to or not coming from those sites ([RFC4110]).
MPLS/GMPLS Security framework
November 2008
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
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
CE Customer-Edge device CE Customer-Edge device
CoS Class of Service CoS Class of Service
CPU Central Processor Unit CPU Central Processor Unit
skipping to change at page 7, line 34 skipping to change at page 7, line 32
GRE Generic Routing Encapsulation GRE Generic Routing Encapsulation
ICI InterCarrier Interconnect ICI InterCarrier Interconnect
ICMP Internet Control Message Protocol ICMP Internet Control Message Protocol
ICMPv6 ICMP in IP Version 6 ICMPv6 ICMP in IP Version 6
IGP Interior Gateway Protocol IGP Interior Gateway Protocol
IKE Internet Key Exchange IKE Internet Key Exchange
IP Internet Protocol IP Internet Protocol
IPsec IP Security IPsec IP Security
IPVPN IP-based VPN IPVPN IP-based VPN
LDP Label Distribution Protocol LDP Label Distribution Protocol
L2TP Layer 2 Tunneling Protocol L2TP Layer 2 Tunneling Protocol
LMP Link Management Protocol LMP Link Management Protocol
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
MD5 Message Digest Algorithm MD5 Message Digest Algorithm
MPLS MultiProtocol Label Switching MPLS MultiProtocol Label Switching
MP-BGP Multi-Protocol BGP MP-BGP Multi-Protocol BGP
NTP Network Time Protocol NTP Network Time Protocol
OAM Operations, Administration, and Management OAM Operations, Administration, and Management
PCE Path Computation Element PCE Path Computation Element
PE Provider-Edge device PE Provider-Edge device
PPVPN Provider-Provisioned Virtual Private Network PPVPN Provider-Provisioned Virtual Private Network
PSN Packet-Switched Network PSN Packet-Switched Network
PW Pseudowire PW Pseudowire
QoS Quality of Service QoS Quality of Service
RR Route Reflector RR Route Reflector
RSVP Resource Reservation Protocol RSVP Resource Reservation Protocol
MPLS/GMPLS Security framework
RSVP-TE Resource Reservation Protocol with Traffic Engineering RSVP-TE Resource Reservation Protocol with Traffic Engineering
Extensions Extensions
SLA Service Level Agreement SLA Service Level Agreement
SNMP Simple Network Management Protocol SNMP Simple Network Management Protocol
SP Service Provider SP Service Provider
SSH Secure Shell SSH Secure Shell
MPLS/GMPLS Security framework
November 2008
SSL Secure Sockets Layer SSL Secure Sockets Layer
SYN Synchronize packet in TCP SYN Synchronize packet in TCP
TCP Transmission Control Protocol TCP Transmission Control Protocol
TDM Time Division Multiplexing TDM Time Division Multiplexing
TE Traffic Engineering TE Traffic Engineering
TLS Transport Layer Security TLS Transport Layer Security
ToS Type of Service ToS Type of Service
TTL Time-To-Live TTL Time-To-Live
UDP User Datagram Protocol UDP User Datagram Protocol
VC Virtual Circuit VC Virtual Circuit
skipping to change at page 9, line 5 skipping to change at page 8, line 43
+------------+ / \ +------------+ +------------+ / \ +------------+
| MPLS/GMPLS +---/ \--------+ MPLS/GMPLS | | MPLS/GMPLS +---/ \--------+ MPLS/GMPLS |
| user | MPLS/GMPLS Core | user | | user | MPLS/GMPLS Core | user |
| site +---\ /XXX-----+ site | | site +---\ /XXX-----+ site |
+------------+ \ / XXX +------------+ +------------+ \ / XXX +------------+
\-------------/ | | \-------------/ | |
| | | |
| +------\ | +------\
+--------/ "Internet" +--------/ "Internet"
MPLS/GMPLS Security framework
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 is the MPLS/GMPLS core in a single AS within a The trusted zone is the MPLS/GMPLS core in a single AS within a
single Service Provider. single Service Provider.
The boundaries of a trust domain should be carefully defined when The boundaries of a trust domain should be carefully defined when
analyzing the security property of each individual network, e.g., analyzing the security property of each individual network, e.g.,
MPLS/GMPLS Security framework
November 2008
the boundaries can be at the link termination, remote peers, areas, the boundaries can be at the link termination, remote peers, areas,
or quite commonly, ASes. or quite commonly, ASes.
In principle, the trusted zones should be separate; however, 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 Figure 1) is defined. In case a transit point (marked with "XXX" in Figure 1) is defined. In
the case of MPLS/GMPLS inter-provider connections, the trusted zone the case of MPLS/GMPLS inter-provider connections, the trusted zone
of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for
Provider A, ASBR3 and ASBR4 for Provider B). Provider A, ASBR3 and ASBR4 for Provider B).
skipping to change at page 10, line 4 skipping to change at page 9, line 38
+---------------+ +----------------+ +---------------+ +----------------+
| | | | | | | |
| 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:
MPLS/GMPLS Security framework
Trusted Zone: Provider A MPSL/GMPLS network Trusted Zone: Provider A MPSL/GMPLS network
Trusted neighbors: PE1, ASBR1, ASBR2 Trusted neighbors: PE1, ASBR1, ASBR2
Authorized but untrusted neighbor: provider B Authorized but untrusted neighbor: provider B
Unauthorized neighbors: CE1, CE2 Unauthorized neighbors: CE1, CE2
Figure 2. MPLS/GMPLS trusted zone and authorized neighbor. Figure 2. MPLS/GMPLS trusted zone and authorized neighbor.
All aspects of network security independent of whether a network is All aspects of network security independent of whether a network is
a MPLS/GMPLS network are out of scope. For example, attacks from a MPLS/GMPLS network are out of scope. For example, attacks from
the Internet to a user's web-server connected through the the Internet to a user's web-server connected through the
MPLS/GMPLS network are not considered here, unless the way the MPLS/GMPLS network are not considered here, unless the way the
MPLS/GMPLS network is provisioned could make a difference to the MPLS/GMPLS network is provisioned could make a difference to the
security of this user's server. security of this user's server.
MPLS/GMPLS Security framework
November 2008
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 affect those threats that are unique to MPLS/GMPLS networks or that 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 SP's A successful attack on a particular MPLS/GMPLS network or on a SP's
MPLS/GMPLS infrastructure may cause one or more of the following MPLS/GMPLS infrastructure may cause one or more of the following
ill effects: ill effects:
skipping to change at page 11, line 4 skipping to change at page 10, line 41
- 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 SP or persons working for it. - The MPLS/GMPLS SP or persons working for it.
- Other persons who obtain physical access to a MPLS/GMPLS SP's - Other persons who obtain physical access to a MPLS/GMPLS SP's
site. site.
- Other persons who use social engineering methods to influence - Other persons who use social engineering methods to influence
the behavior of a SP's personnel. the behavior of a SP's personnel.
- Users of the MPLS/GMPLS network itself, e.g., 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.)
MPLS/GMPLS Security framework
- Others, e.g., attackers from the Internet at large. - Others, e.g., attackers from the Internet at large.
- Other SPs in the case of MPLS/GMPLS Inter- - Other SPs in the case of MPLS/GMPLS Inter-
provider connection. The core of the other provider may or may provider connection. The core of the other provider may or may
not be using MPLS/GMPLS. not be using MPLS/GMPLS.
- Those who create, deliver, install, and maintain software for - Those who create, deliver, install, and maintain software for
network equipment. network equipment.
Given that security is generally a tradeoff 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:
MPLS/GMPLS Security framework
November 2008
- A MPLS/GMPLS core inter-connecting with another provider's core - A MPLS/GMPLS core inter-connecting with another provider's core
- A MPLS/GMPLS configuration 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 SP to multiple cooperating SPs to the global from a single SP to multiple cooperating SPs to the global
Internet. Attacks that may not be of sufficient likeliness to Internet. Attacks that may not be of sufficient likeliness to
warrant concern in a closely controlled environment often merit warrant concern in a closely controlled environment often merit
defensive measures in broader, more open environments. In closed defensive measures in broader, more open environments. In closed
communities, it is often practical to deal with misbehavior after communities, it is often practical to deal with misbehavior after
the fact: an employee can be disciplined, for example. the fact: an employee can be disciplined, for example.
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 SP with MPLS/GMPLS cores. operated by the SP with MPLS/GMPLS cores.
It should be noted that while connectivity in the MPLS control plane
uses the same links and network resources as are used by the data
plane, the GMPLS control plane may be provided by separate resources
from those used in the data plane. That is, the GMPLS control plane
may be physically diverse from the data plane.
The different cases of physically congruent and physically diverse
control/data planes lead to slightly different possibilities of
attack, although most of the cases are the same. Note that, for
example, the data plane cannot be directly congested by an attack on
a physically diverse control plane as it could be if the control and
data planes shared network resources. Note also that if the control
plane uses diverse resources from the data plane, no assumptions
should be made about the security of the control plane based on the
security of the data plane resources.
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. This may also result in theft of service or reserved unnecessarily. This may also result in theft of service or
even compromise the entire network. even compromise the entire network.
4.1.2. LSP message interception 4.1.2. LSP message interception
MPLS/GMPLS Security framework
November 2008
This threat might be accomplished by monitoring network traffic, This threat might be accomplished by monitoring network traffic,
for example, after a physical intrusion. Without physical for example, after a physical intrusion. Without physical
intrusion, it could be accomplished with an unauthorized software intrusion, it could be accomplished with an unauthorized software
MPLS/GMPLS Security framework
modification. Also many technologies such as terrestrial microwave, modification. Also many technologies such as terrestrial microwave,
satellite, or free-space optical could be intercepted without satellite, or free-space optical could be intercepted without
physical intrusion. If successful, it could provide information physical intrusion. If successful, it could provide information
leading to label spoofing attacks. It also raises confidentiality leading to label spoofing attacks. It also raises confidentiality
issues. 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.
skipping to change at page 12, line 49 skipping to change at page 13, line 5
DoS attack in the form of a storm of LDP Hello messages or LDP TCP DoS attack in the form of a storm of LDP Hello messages or LDP TCP
Syn messages, leading to high CPU utilization on the target router. Syn messages, leading to high CPU utilization on the target router.
4.1.5. Denial of Service Attacks on the Network 4.1.5. Denial of Service Attacks on the Network
Infrastructure Infrastructure
DoS attacks could be accomplished through a 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.
MPLS/GMPLS Security framework
November 2008
Control plane DoS attacks can be mounted specifically against the Control plane DoS attacks can be mounted specifically against the
mechanisms the SP uses to provide various services, or against the mechanisms the SP uses to provide various services, or against the
general infrastructure of the service provider, e.g., P routers or general infrastructure of the service provider, e.g., P routers or
MPLS/GMPLS Security framework
shared aspects of PE routers. (An attack against the general shared aspects of PE routers. (An attack against the general
infrastructure is within the scope of this document only if the infrastructure is within the scope of this document only if the
attack can occur in relation with the MPLS/GMPLS infrastructure; attack can occur in relation with the MPLS/GMPLS infrastructure;
otherwise is not a 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 SP's MPLS/GMPLS Equipment via 4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via
skipping to change at page 13, line 48 skipping to change at page 14, line 5
- Two or more VPNs being improperly merged together - Two or more VPNs being improperly merged together
- A point-to-point VPN connecting the wrong two points - 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 (e.g., improper device configuration). connected) or logical (e.g., improper device configuration).
MPLS/GMPLS Security framework
November 2008
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).
MPLS/GMPLS Security framework
4.1.9. Attacks against 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 SP and that directly support the MPLS/GMPLS core. are run by the SP and that directly support the MPLS/GMPLS core.
(Attacks against the use of routing protocols for the distribution (Attacks against the use of routing protocols for the distribution
of backbone routes are beyond the scope of this document.) of backbone routes are beyond the scope of this document.)
Specific attacks against popular routing protocols have been widely Specific attacks against popular routing protocols have been widely
studied and described in [RFC4593]. studied and described in [RFC4593].
4.1.10. Other Attacks on Control Traffic 4.1.10. Other Attacks on Control Traffic
skipping to change at page 14, line 40 skipping to change at page 14, line 45
- Other protocols that may be important to the control - Other protocols that may be important to the control
infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE. infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE.
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. for example via impersonation or DoS.
Note that all of the data plane attacks can also be done on the Note that all of the data plane attacks can also be done on the
packets of the control and management planes: insertion, spoofing, packets of the control and management planes: insertion, spoofing,
replay, deletion, pattern analysis, and other attacks mentioned replay, deletion, pattern analysis, and other attacks mentioned
above. above.
4.2. Attacks on the Data Plane 4.2. Attacks on the Data Plane
This category encompasses attacks on the provider's 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 user site A to user site B via an IP or non- protocols running from user site A to user site B via an IP or non-
IP connections, which may be some type of VPN. IP connections, which may be some type of VPN.
MPLS/GMPLS Security framework
November 2008
4.2.1. Unauthorized Observation of Data Traffic 4.2.1. Unauthorized Observation of Data Traffic
This refers to "sniffing" provider or end user packets and This refers to "sniffing" provider or end user packets and
examining their contents. This can result in exposure of examining their contents. This can result in exposure of
confidential information. It can also be a first step in other confidential information. It can also be a first step in other
MPLS/GMPLS Security framework
attacks (described below) in which the recorded data is modified attacks (described below) in which the recorded data is modified
and re-inserted, or simply replayed later. 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 Inauthentic Data Traffic: Spoofing 4.2.3. Insertion of Inauthentic Data Traffic: Spoofing
and Replay and Replay
skipping to change at page 15, line 48 skipping to change at page 16, line 4
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
MPLS/GMPLS Security framework
November 2008
the network, e.g., link bandwidth, packet forwarding capacity, the network, e.g., link bandwidth, packet forwarding capacity,
session capacity for various protocols, CPU power, table size, session capacity for various protocols, CPU power, table size,
storage overflows, and so on. storage overflows, and so on.
MPLS/GMPLS Security framework
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 inauthentic data to insert (spoofing) an overwhelming quantity of inauthentic data
into the provider or end user network from the outside of the into the provider or end user network from the outside of the
trusted zone. Potential results might be to exhaust the bandwidth trusted zone. Potential results might be to exhaust the bandwidth
available to that provider or end user or to overwhelm the available to that provider or end user or to overwhelm the
cryptographic authentication mechanisms of the provider or end cryptographic authentication mechanisms of the provider or end
user. user.
Data plane resource exhaustion attacks can also be mounted by Data plane resource exhaustion attacks can also be mounted by
skipping to change at page 16, line 30 skipping to change at page 16, line 35
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 Many DoS attacks use amplification, whereby the attacker co-opts
otherwise innocent parties to increase the effect of the attack. otherwise innocent parties to increase the effect of the attack.
The attacker may, for example, send packets to a broadcast or The attacker may, for example, send packets to a broadcast or
multicast address with the spoofed source address of the victim, multicast address with the spoofed source address of the victim,
and all of the recipients may then respond to the victim. and all of the recipients may then respond to the victim.
4.2.7. Misconnection
Misconnection may arise through deliberate attack, or through
misconfiguration or misconnection of the network resources. The
result is likely to be delivery of data to the wrong destination or
black-holing of the data.
In GMPLS with physically diverse control and data planes, it may be
possible for data plane misconnection to go undetected by the
control plane.
In optical networks under GMPLS control, misconnection may give rise
to physical safety risks as unprotected lasers may be activated
without warning.
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.
MPLS/GMPLS Security framework
November 2008
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
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. The these techniques to the user's service requirements. The
operational environment determines the security requirements. operational environment determines the security requirements.
Therefore, protocol designers need to provide a full set of Therefore, protocol designers need to provide a full set of
security services, which can be used where appropriate. 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 Often, security is achieved by careful protocol design, rather than
by adding a security method. For example, one method of mitigating by adding a security method. For example, one method of mitigating
DoS attacks is to make sure that innocent parties cannot be used to DoS attacks is to make sure that innocent parties cannot be used to
amplify the attack. Security works better when it is "designed in" amplify the attack. Security works better when it is "designed in"
rather than "added on." rather than "added on."
MPLS/GMPLS Security framework
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 or that have against those attacks that are most likely to occur or that have
the most direct consequences if successful. For those attacks that the most direct consequences if successful. For those attacks that
are protected against, absolute protection is seldom achievable; are protected against, absolute protection is seldom achievable;
more often it is sufficient just to make the cost of a successful more often it is sufficient just to make the cost of a successful
attack greater than what the adversary will be willing or able to attack greater than what the adversary will be willing or able 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
skipping to change at page 17, line 34 skipping to change at page 18, line 5
To prevent security issues arising from some Denial-of-Service To prevent security issues arising from some Denial-of-Service
attacks or from malicious or accidental misconfiguration, it is attacks or from malicious or accidental misconfiguration, it is
critical that devices in the MPLS/GMPLS should only accept critical that devices in the MPLS/GMPLS should only accept
connections or control messages from valid sources. Authentication connections or control messages from valid sources. Authentication
refers to methods to ensure that message sources are properly refers to methods to ensure that message sources are properly
identified by the MPLS/GMPLS devices with which they communicate. identified by the MPLS/GMPLS devices with which they communicate.
This section focuses on identifying the scenarios in which sender This section focuses on identifying the scenarios in which sender
authentication is required and recommends authentication mechanisms authentication is required and recommends authentication mechanisms
for these scenarios. for these scenarios.
MPLS/GMPLS Security framework
November 2008
Cryptographic techniques (authentication, integrity, and Cryptographic techniques (authentication, integrity, and
encryption) do not protect against some types of denial of service encryption) do not protect against some types of denial of service
attacks, specifically resource exhaustion attacks based on CPU or attacks, specifically resource exhaustion attacks based on CPU or
bandwidth exhaustion. In fact, the processing required to decrypt bandwidth exhaustion. In fact, the processing required to decrypt
or check authentication may, in the case of software-based or check authentication may, in the case of software-based
cryptographic processing, in some cases increase the effect of cryptographic processing, in some cases increase the effect of
these resource exhaustion attacks. With a hardware cryptographic these resource exhaustion attacks. With a hardware cryptographic
accelerator, attack packets can be dropped at line speed without a accelerator, attack packets can be dropped at line speed without a
cost of software cycles. Cryptographic techniques may, however, be cost of software cycles. Cryptographic techniques may, however, be
useful against resource exhaustion attacks based on exhaustion of useful against resource exhaustion attacks based on exhaustion of
state information (e.g., TCP SYN attacks). state information (e.g., TCP SYN attacks).
The MPLS data plane, as presently defined, is not amenable to The MPLS data plane, as presently defined, is not amenable to
source authentication as there are no source identifiers in the source authentication as there are no source identifiers in the
MPLS packet to authenticate. The MPLS label is only locally MPLS packet to authenticate. The MPLS label is only locally
meaningful. It may be assigned by a downstream node or upstream meaningful. It may be assigned by a downstream node or upstream
node for multicast support. node for multicast support.
MPLS/GMPLS Security framework
When the MPLS payload carries identifiers that may be authenticated When the MPLS payload carries identifiers that may be authenticated
(e.g., IP packets), authentication may be carried out at the client (e.g., IP packets), authentication may be carried out at the client
level, but this does not help the MPLS SP, as these client level, but this does not help the MPLS SP, as these client
identifiers belong to an external, untrusted network. identifiers belong to an external, untrusted network.
5.1.1. Management System Authentication 5.1.1. Management System Authentication
Management system authentication includes the authentication of a Management system authentication includes the authentication of a
PE to a centrally-managed network management or directory server PE to a centrally-managed network management or directory server
when directory-based "auto-discovery" is used. It also includes when directory-based "auto-discovery" is used. It also includes
authentication of a CE to the configuration server, when a authentication of a CE to the configuration server, when a
configuration server system is used. configuration server system is used.
5.1.2. Authentication should be bi-directional, 5.1.2. Peer-to-Peer Authentication
including PE or CE to configuration
server authentication for PE or CE to be certain i
t
is communicating with the
r
ight server.Peer-to-Peer Authentication
Peer-to-peer authentication includes peer authentication for Peer-to-peer authentication includes peer authentication for
network control protocols (e.g., LDP, BGP, etc.), and other peer network control protocols (e.g., LDP, BGP, etc.), and other peer
authentication (i.e., authentication of one IPsec security gateway authentication (i.e., authentication of one IPsec security gateway
by another). by another).
Authentication should be bi-directional, including PE or CE to
configuration server authentication for PE or CE to be certain it
is communicating with the right server.
MPLS/GMPLS Security framework
November 2008
5.1.3. Cryptographic techniques for authenticating identity 5.1.3. Cryptographic techniques for authenticating identity
Cryptographic techniques offer several mechanisms for Cryptographic techniques offer several mechanisms for
authenticating the identity of devices or individuals. These authenticating the identity of devices or individuals. These
include the use of shared secret keys, one-time keys generated by include the use of shared secret keys, one-time keys generated by
accessory devices or software, user-ID and password pairs, and a accessory devices or software, user-ID and password pairs, and a
range of public-private key systems. Another approach is to use a range of public-private key systems. Another approach is to use a
hierarchical Certification Authority system to provide digital hierarchical Certification Authority system to provide digital
certificates. certificates.
This section describes or provides references to the specific This section describes or provides references to the specific
cryptographic approaches for authenticating identity. These cryptographic approaches for authenticating identity. These
approaches provide secure mechanisms for most of the authentication approaches provide secure mechanisms for most of the authentication
scenarios required in securing a MPLS/GMPLS network. scenarios required in securing a MPLS/GMPLS network.
5.2. Cryptographic Techniques 5.2. Cryptographic Techniques
MPLS/GMPLS Security framework
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 that 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, can authenticate 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
skipping to change at page 19, line 33 skipping to change at page 20, line 4
configuring encryption services on devices adds to the complexity configuring encryption services on devices adds to the complexity
of their configuration and adds labor cost. Some key management of their configuration and adds labor cost. Some key management
system is usually needed. Packet sizes are typically increased when system is usually needed. Packet sizes are typically increased when
the packets are encrypted or have integrity checks or replay the packets are encrypted or have integrity checks or replay
counters added, increasing the network traffic load and adding to counters added, increasing the network traffic load and adding to
the likelihood of packet fragmentation with its increased overhead. the likelihood of packet fragmentation with its increased overhead.
(This packet length increase can often be mitigated to some extent (This packet length increase can often be mitigated to some extent
by data compression techniques, but at the expense of additional by data compression techniques, but at the expense of additional
computational burden.) Finally, some providers may employ enough computational burden.) Finally, some providers may employ enough
other defensive techniques, such as physical isolation or filtering other defensive techniques, such as physical isolation or filtering
MPLS/GMPLS Security framework
November 2008
and firewall techniques, that they may not perceive additional and firewall techniques, that they may not perceive additional
benefit from encryption techniques. benefit from encryption techniques.
Users may wish to provide confidentiality end to end. Generally, Users may wish to provide confidentiality end to end. Generally,
encrypting for confidentiality must be accompanied with encrypting for confidentiality must be accompanied with
cryptographic integrity checks to prevent certain active attacks cryptographic integrity checks to prevent certain active attacks
against the encrypted communications. On today's processors, against the encrypted communications. On today's processors,
encryption and integrity checks run extremely quickly, but key encryption and integrity checks run extremely quickly, but key
management may be more demanding in terms of both computational and management may be more demanding in terms of both computational and
administrative overhead. 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 major element in determining and other parts of the network is a major element in determining
the applicability of cryptographic protection for any specific the applicability of cryptographic protection for any specific
MPLS/GMPLS implementation. In particular, it determines where MPLS/GMPLS implementation. In particular, it determines where
cryptographic protection 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 it may be used on the provider's PE is not trusted, then it may be used on the
PE-CE link. PE-CE link.
MPLS/GMPLS Security framework
- 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 across the Internet or multiple providers' networks, then
the PE-PE traffic may be cryptographically protected. One the PE-PE traffic may be cryptographically protected. One
also should consider cases where L1 technology may be also should consider cases where L1 technology may be
vulnerable to eavesdropping. vulnerable to eavesdropping.
- 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 cryptographic premises, it may require end-to-end or CE-CE cryptographic
protection. This fits within the scope of this MPLS/GMPLS protection. This fits within the scope of this MPLS/GMPLS
security framework when the CE is provisioned by the security framework when the CE is provisioned by the
skipping to change at page 20, line 35 skipping to change at page 21, line 5
access control services for the remote users. These access access control services for the remote users. These access
control services are usually protected cryptographically, control services are usually protected cryptographically,
as well. as well.
Access control usually starts with authentication of the Access control usually starts with authentication of the
entity. If cryptographic services are part of the scenario, entity. If cryptographic services are part of the scenario,
then it is important to bind the authentication to the key then it is important to bind the authentication to the key
management. Otherwise the protocol is vulnerable to being management. Otherwise the protocol is vulnerable to being
hijacked between the authentication and key management. hijacked between the authentication and key management.
MPLS/GMPLS Security framework
November 2008
Although CE-CE cryptographic protection can provide integrity and Although CE-CE cryptographic protection can provide integrity and
confidentiality against third parties, if the MPLS/GMPLS provider confidentiality against third parties, if the MPLS/GMPLS provider
has complete management control over the CE (encryption) devices, has complete management control over the CE (encryption) devices,
then it may be possible for the provider to gain access to the then it may be possible for the provider to gain access to the
user's traffic or internal network. Encryption devices could user's traffic or internal network. Encryption devices could
potentially be reconfigured to use null encryption, bypass potentially be reconfigured to use null encryption, bypass
cryptographic processing altogether, reveal internal configuration, cryptographic processing altogether, reveal internal configuration,
or provide some means of sniffing or diverting unencrypted traffic. 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 provides 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
cryptographic protection on the CE devices. The demarcation may cryptographic protection on the CE devices. The demarcation may
also be affected by the capabilities of the CE devices. For also be affected by the capabilities of the CE devices. For
example, the CE might support some partitioning of management, a example, the CE might support some partitioning of management, a
configuration lock-down ability, or shared capability to verify the configuration lock-down ability, or shared capability to verify the
configuration. In general, the MPLS/GMPLS user needs to have a configuration. In general, the MPLS/GMPLS user needs to have a
fairly high level of trust that the MPLS/GMPLS provider will fairly high level of trust that the MPLS/GMPLS provider will
MPLS/GMPLS Security framework
properly provision and manage the CE devices, if the managed CE-CE properly provision and manage the CE devices, if the managed CE-CE
model is used. model is used.
5.2.1. IPsec in MPLS/GMPLS 5.2.1. IPsec in MPLS/GMPLS
IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC2411] is the IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC2411] is the
security protocol of choice for encryption at the IP layer. IPsec security protocol of choice for encryption at the IP layer. IPsec
provides robust security for IP traffic between pairs of devices. provides robust security for IP traffic between pairs of devices.
Non-IP traffic such as IS-IS routing must be converted to IP (e.g., Non-IP traffic such as IS-IS routing must be converted to IP (e.g.,
by encapsulation) in order to use IPsec. by encapsulation) in order to use IPsec.
skipping to change at page 21, line 31 skipping to change at page 22, line 4
document, because it is simply handled as user data by the document, because it is simply handled as user data by the
MPLS/GMPLS core. However, if the SP performs compression, pre- MPLS/GMPLS core. However, if the SP performs compression, pre-
encryption will have a major effect on that operation. 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 integrity or confidentiality algorithms (or even a variety of integrity or confidentiality algorithms (or even
combined integrity and confidentiality algorithms), with various combined integrity and confidentiality algorithms), with various
key lengths, such as AES encryption or AES message integrity key lengths, such as AES encryption or AES message integrity
checks. There are trade-offs between key length, computational checks. There are trade-offs between key length, computational
burden, and the level of security of the encryption. A full burden, and the level of security of the encryption. A full
MPLS/GMPLS Security framework
November 2008
discussion of these trade-offs is beyond the scope of this discussion of these trade-offs is beyond the scope of this
document. In practice, any currently recommended IPsec protection document. In practice, any currently recommended IPsec protection
offers enough security to reduce the likelihood of its being offers enough security to reduce the likelihood of its being
directly targeted by an attacker substantially; other weaker links directly targeted by an attacker substantially; other weaker links
in the chain of security are likely to be attacked first. in the chain of security are likely to be attacked first.
MPLS/GMPLS users may wish to use a Service Level Agreement (SLA) MPLS/GMPLS users may wish to use a Service Level Agreement (SLA)
specifying the SP's responsibility for ensuring data integrity and 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 Encryption algorithms generally come with two parameters: mode such
as Cipher Block Chaining and key length such as AES-192. (This as Cipher Block Chaining and key length such as AES-192. (This
should not be confused with two other senses in which the word should not be confused with two other senses in which the word
"mode" is used: IPsec itself can be used in Tunnel Mode or "mode" is used: IPsec itself can be used in Tunnel Mode or
Transport Mode, and IKE [version 1] uses Main Mode, Aggressive Transport Mode, and IKE [version 1] uses Main Mode, Aggressive
Mode, or Quick Mode). It should be stressed that IPsec encryption Mode, or Quick Mode). It should be stressed that IPsec encryption
without an integrity check is a state of sin. without an integrity check is a state of sin.
MPLS/GMPLS Security framework
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
appropriate 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 NULL encryption. the Encapsulating Security Protocol (ESP) with NULL encryption.
Where control messages require integrity but do not use IPsec, Where control messages require integrity but do not use IPsec,
other cryptographic authentication methods are often 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]
skipping to change at page 22, line 36 skipping to change at page 23, line 4
origin authentication, and connectionless integrity is the use of origin authentication, and connectionless integrity is the use of
AES in CCM (Counter with CBC-MAC) mode (RFC 4309) [RFC4309], with AES in CCM (Counter with CBC-MAC) mode (RFC 4309) [RFC4309], with
an explicit initialization vector (IV), as the IPsec ESP. Recently, an explicit initialization vector (IV), as the IPsec ESP. Recently,
GCM is rapidly replacing CCM as the preferred method: [RFC4103]. GCM is rapidly replacing CCM as the preferred method: [RFC4103].
5.2.2. MPLS / GMPLS DiffServ and IPsec 5.2.2. MPLS / GMPLS DiffServ and IPsec
MPLS and GMPLS, which provide differentiated services based on MPLS and GMPLS, which provide differentiated services based on
traffic type, may encounter some conflicts with IPsec encryption of traffic type, may encounter some conflicts with IPsec encryption of
traffic. Because encryption hides the content of the packets, it traffic. Because encryption hides the content of the packets, it
MPLS/GMPLS Security framework
November 2008
may not be possible to differentiate the encrypted traffic in the may not be possible to differentiate the encrypted traffic in the
same manner as unencrypted traffic. Although DiffServ markings are same manner as unencrypted traffic. Although DiffServ markings are
copied to the IPsec header and can provide some differentiation, copied to the IPsec header and can provide some differentiation,
not all traffic types can be accommodated by this mechanism. Using not all traffic types can be accommodated by this mechanism. Using
IPsec without IKE or IKEv2 (the better choice) is not advisable. IPsec without IKE or IKEv2 (the better choice) is not advisable.
IKEv2 provides IPsec Security Association creation and management, IKEv2 provides IPsec Security Association creation and management,
entity authentication, key agreement, and key update. It works with entity authentication, key agreement, and key update. It works with
a variety of authentication methods including pre-shared keys, a variety of authentication methods including pre-shared keys,
public key certificates, and EAP. If DoS attacks against IKEv2 are public key certificates, and EAP. If DoS attacks against IKEv2 are
considered an important threat to mitigate, the cookie-based anti- considered an important threat to mitigate, the cookie-based anti-
spoofing feature of IKEv2 should be used. IKEv2 has its own set of spoofing feature of IKEv2 should be used. IKEv2 has its own set of
cryptographic methods, but any of the default suites specified in cryptographic methods, but any of the default suites specified in
[RFC4308] or [RFC4869] provides more than adequate security. [RFC4308] or [RFC4869] provides more than adequate security.
5.2.3. Encryption for device configuration and management 5.2.3. Encryption for device configuration and management
MPLS/GMPLS Security framework
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.
- SNMPv3 [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) [RFC5246] 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.
- Since 2004, there has been 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 integrity and confidentiality - IPsec provides the services with integrity and confidentiality
at 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 - There are recent work in ISMS WG (Integrated Security Model for
SNMP Working Group) to define how to use SSH to secure SNMP, due SNMP Working Group) to define how to use SSH to secure SNMP, due
to the limited deployment of SNMPv3; and the possibility of to the limited deployment of SNMPv3; and the possibility of
using Kerberos, particularly for interfaces like TELNET, where using Kerberos, particularly for interfaces like TELNET, where
client code exists. client code exists.
MPLS/GMPLS Security framework
November 2008
5.2.4. Security Considerations for MPLS Pseudowires 5.2.4. 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
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].
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.
MPLS/GMPLS Security framework
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.
skipping to change at page 24, line 36 skipping to change at page 25, line 5
protect the traffic passing between them. The devices may be protect the traffic passing between them. The devices may be
directly connected (over a single "hop"), or intervening devices directly connected (over a single "hop"), or intervening devices
may transport the protected traffic between the pair of devices. may transport the protected traffic between the pair of devices.
The extreme cases involve using protection between every adjacent The extreme cases involve using protection between every 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
protection 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.
MPLS/GMPLS Security framework
November 2008
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).
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.
Within this simplified topology, and assuming that the P devices Within this simplified topology, and assuming that the P devices
are not involved with cryptographic protection, four basic, are not involved with cryptographic protection, four basic,
MPLS/GMPLS Security framework
feasible configurations exist for protecting connections among the feasible configurations exist for protecting connections among the
devices: devices:
1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity 1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity
services between the two CE devices, so that traffic will be services between the two CE devices, so that traffic will be
protected throughout the SP's network. protected throughout the SP's network.
2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or 2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or
integrity services between the two PE devices. Unprotected traffic integrity services between the two PE devices. Unprotected traffic
is received at one PE from the customer's CE, then it is protected is received at one PE from the customer's CE, then it is protected
skipping to change at page 25, line 37 skipping to change at page 26, line 4
considering encryption include: considering encryption include:
- Vulnerability to link eavesdropping or tampering - assuming an - Vulnerability to link eavesdropping or tampering - assuming an
attacker can attacker can
observe or modify data in transit on the links, would it be observe or modify data in transit on the links, would it be
protected by encryption? 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?
MPLS/GMPLS Security framework
November 2008
- 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 cryptographic operations - Processing load on devices - how many cryptographic operations
must be performed given N packets? - This raises considerations of must be performed given N packets? - This raises considerations of
device capacity and perhaps end-to-end delay. device capacity and perhaps end-to-end delay.
- Ability of the SP to provide enhanced services (QoS, firewall, - Ability of the SP to provide enhanced services (QoS, firewall,
intrusion detection, etc.) - Can the SP inspect the data to provide intrusion detection, etc.) - Can the SP inspect the data to provide
these services? these services?
These tradeoffs are discussed for each configuration, below: These tradeoffs are discussed for each configuration, below:
MPLS/GMPLS Security framework
1) Site-to-site (CE-to-CE) 1) Site-to-site (CE-to-CE)
Link eavesdropping or tampering - 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 Though the complexity may be reduced: 1) In practice, as Nce
grows, the number of VPNs falls off from being a full clique; grows, the number of VPNs falls off from being a full clique;
2) If the CEs run an automated key management protocol, then 2) If the CEs run an automated key management protocol, then
skipping to change at page 26, line 38 skipping to change at page 27, line 4
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 cryptographic protection is depends on the PPVPN type: If the cryptographic protection is
separate per VPN context, it scales as Npe**2 per customer VPN. separate per VPN context, it scales as Npe**2 per customer VPN.
If it 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 Processing load - on each of two PEs, each packet is
cryptographically processed (2P). Note that this 2P is a cryptographically processed (2P). Note that this 2P is a
MPLS/GMPLS Security framework
November 2008
different 2P from case (1), because only PEs are in different 2P from case (1), because only PEs are in
consideration here. 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 or tampering - protected on CE-PE link; Link eavesdropping or tampering - protected on CE-PE link;
vulnerable on SP's network links 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
because there is no mesh the overall configuration scales as because there is no mesh the overall configuration scales as
Nce. Nce.
MPLS/GMPLS Security framework
Processing load - on each of two CEs, each packet is Processing load - on each of two CEs, each packet is
cryptographically processed, plus on each of two PEs, each cryptographically processed, plus on each of two PEs, each
packet is cryptographically processed (4P) 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 or tampering - protected on all links Link eavesdropping or tampering - protected on all links
Device compromise - vulnerable to CE or PE compromise Device compromise - vulnerable to CE or PE compromise
skipping to change at page 27, line 39 skipping to change at page 28, line 5
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) versus 4 (combined access these conclusions compare 1 (CE-to-CE) versus 4 (combined access
links and PE-to-PE). links and PE-to-PE).
- If protection from link eavesdropping or tampering is all that is - If protection from link eavesdropping or tampering is all that is
important, then configurations 1 and 4 are equivalent. important, then configurations 1 and 4 are equivalent.
MPLS/GMPLS Security framework
November 2008
- 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 better. 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 small, configuration 1 is better. Otherwise network is small, configuration 1 is better. Otherwise
configuration 4 is better because rather than a mesh of CE devices configuration 4 is better because rather than a mesh of CE devices
it requires a smaller mesh of PE devices. Also, under some PPVPN it requires a smaller mesh of PE devices. Also, under some PPVPN
approaches the scaling of 4 is further improved by sharing the same 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 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 be increased or decreased in any given situation if the CE devices
are simpler to configure than the PE devices, or vice-versa. are simpler to configure than the PE devices, or vice-versa.
- If the overall processing load is a key factor, then 1 is better, - If the overall processing load is a key factor, then 1 is better,
unless the PEs come with a hardware encryption accelerator and the unless the PEs come with a hardware encryption accelerator and the
CEs do not. CEs do not.
MPLS/GMPLS Security framework
- 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 protection is better As a quick overall conclusion, CE-to-CE protection is better
against device compromise, but this comes at the cost of enhanced against device compromise, but this comes at the cost of enhanced
services and at the cost of operational complexity due to the services and at the cost of operational complexity due to the
Order(n**2) scaling of a larger mesh. Order(n**2) scaling of a larger mesh.
This analysis of site-to-site vs. hop-by-hop tradeoffs does not This analysis of site-to-site vs. hop-by-hop tradeoffs does not
explicitly include cases of multiple providers cooperating to explicitly include cases of multiple providers cooperating to
skipping to change at page 28, line 36 skipping to change at page 29, line 5
IPsec VPN to access a SSL-secured web site to download encrypted IPsec VPN to access a SSL-secured web site to download encrypted
email attachments: four layers.) email attachments: four layers.)
- It may be that, for example, cryptographic integrity checks are - It may be that, for example, cryptographic integrity checks are
applied end to end, and confidentiality over a shorter span. applied end to end, and confidentiality over a shorter span.
- Different cryptographic protection may be required for control - Different cryptographic protection may be required for control
protocols and data traffic. protocols and data traffic.
- Attention needs to be given to how auxiliary traffic is - Attention needs to be given to how auxiliary traffic is
protected, e.g., the ICMPv6 packets that flow back during PMTU protected, e.g., the ICMPv6 packets that flow back during PMTU
discovery, among other examples. discovery, among other examples.
MPLS/GMPLS Security framework
November 2008
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 on by-packet-flow access control by means of filters and firewalls on
IPv4/IPv6 packets, as well as by means of admitting a "session" for IPv4/IPv6 packets, as well as by means of admitting a "session" for
a control, signaling, or management protocol. Enforcement of access a control, signaling, or management protocol. Enforcement of access
control by isolated infrastructure addresses is discussed in control by isolated infrastructure addresses is discussed in
another section of this document. another section of this document.
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.
The definition has two significant corollaries: 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
MPLS/GMPLS Security framework
where the network topology assures that both sides of a where the network topology assures that both sides of a
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. Beware that this concept could result in in the reverse direction. Beware that this concept could result in
a single point of failure. a single point of failure.
- Statefulness: Because it receives both sides of a conversation, a - 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
skipping to change at page 29, line 34 skipping to change at page 30, line 4
either be discarded or given special treatment. Today, not only either be discarded or given special treatment. Today, not only
routers, most end hosts today have filters and every instance of routers, most end hosts today have filters and every instance of
IPsec is also a filter [RFC4301]. 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 that 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 applied to those packets matches a filter from the Packet Actions applied to those packets
which matching a particular filter. which matching a particular filter.
o Filter Characteristics o Filter Characteristics
MPLS/GMPLS Security framework
November 2008
Filter characteristics or rules are used to determine whether a Filter characteristics or rules are used to determine whether a
particular 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 determines whether a particular packet matches a filter filter determines whether a particular packet matches 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 contents information (such as the next hop for a packet), and the contents
of that individual packet. Typically stateless filters may consider of that individual packet. Typically stateless filters may consider
the incoming and outgoing logical or physical interface, the incoming and outgoing logical or physical interface,
information in the IP header, and information in higher layer information in the IP header, and information in higher layer
headers such as the TCP or UDP header. Information in the IP header headers such as the TCP or UDP header. Information in the IP header
to be considered may for example include source and destination IP to be considered may for example include source and destination IP
addresses, Protocol field, Fragment Offset, and TOS field in IPv4, addresses, Protocol field, Fragment Offset, and TOS field in IPv4,
Next Header, Extension Headers, Flow label, etc. in IPv6. Filters Next Header, Extension Headers, Flow label, etc. in IPv6. Filters
also may consider fields in the TCP or UDP header such as the Port 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 fields, the SYN field in the TCP header, as well as ICMP and ICMPv6
type. type.
MPLS/GMPLS Security framework
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
commonly done in firewalls, although firewall technology may be commonly done in firewalls, although firewall technology may be
added to routers. Data unit ID can also be Fragmentation Extension added to routers. Data unit ID can also be Fragmentation Extension
Header in IPv6. Header in IPv6.
skipping to change at page 30, line 35 skipping to change at page 31, line 5
packets. Examples may include packets with forged or invalid source packets. Examples may include packets with forged or invalid source
addresses, packets that are part of a DOS or Distributed DoS (DDOS) addresses, packets that are part of a DOS or Distributed DoS (DDOS)
attack, or packets which are trying to access unallowed resources attack, or packets which are trying to access unallowed resources
(such as network management packets from an unauthorized source). (such as network management packets from an unauthorized source).
Where such filters are activated, it is common to discard the Where such filters are activated, it is common to discard the
packet or set of packets matching the filter silently. The packet or set of packets matching the filter silently. The
discarded packets may of course also be counted or logged. discarded packets may of course also be counted or logged.
- Set CoS - Set CoS
MPLS/GMPLS Security framework
November 2008
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 or bytes - Count packets or bytes
- Rate Limit - Rate Limit
In some cases the set of packets matching a particular filter may In some cases the set of packets matching a particular filter may
be limited to a specified bandwidth. In this case, packets or bytes be limited to a specified bandwidth. In this case, packets or bytes
would be counted, and would be forwarded normally up to the would be counted, and would be forwarded normally up to the
specified limit. Excess packets may be discarded or may be marked specified limit. Excess packets may be discarded or may be marked
(for example by setting a "discard eligible" bit in the IP ToS (for example by setting a "discard eligible" bit in the IP ToS
field or the MPLS EXP field). 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 also to 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
MPLS/GMPLS Security framework
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
Filtering performance may vary widely according to implementation Filtering performance may vary widely according to implementation
and the types and number of rules. Without acceptable performance, and the types and number of rules. Without acceptable performance,
filtering is not useful. filtering is not useful.
The precise definition of "acceptable" may vary from SP to SP, and The precise definition of "acceptable" may vary from SP to SP, and
skipping to change at page 31, line 34 skipping to change at page 32, line 4
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.
Because 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
MPLS/GMPLS Security framework
November 2008
much more functionality than filters, because 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).
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
MPLS/GMPLS Security framework
a single VPN user, may have varying firewall requirements. The a single VPN user, may have varying firewall requirements. The
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, has capabilities of the devices implementing the firewall services, has
a significant effect on the feasibility and manageability of such a significant effect on the feasibility and manageability 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.
Because 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
skipping to change at page 32, line 32 skipping to change at page 33, line 4
Handling DoS attacks has become increasingly important. Useful Handling DoS attacks has become increasingly important. Useful
guidelines include the following: guidelines include the following:
1. Perform ingress filtering everywhere. Upstream prevention is 1. Perform ingress filtering everywhere. Upstream prevention is
better. better.
2. Be able to filter DoS attack packets at line speed. 2. Be able to filter DoS attack packets at line speed.
3. Do not allow oneself to amplify attacks. 3. Do not allow oneself to amplify attacks.
4. Continue processing legitimate traffic. Over provide for heavy 4. Continue processing legitimate traffic. Over provide for heavy
loads. Use diverse locations, technologies, etc. loads. Use diverse locations, technologies, etc.
5.3.3. Access Control to management interfaces 5.3.3. Access Control to management interfaces
MPLS/GMPLS Security framework
November 2008
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 The Optical Internetworking Forum has done good work on protecting
such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. See OIF- such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. See OIF-
SMI-01.0 "Security for Management Interfaces to Network Elements" SMI-01.0 "Security for Management Interfaces to Network Elements"
skipping to change at page 33, line 4 skipping to change at page 33, line 27
Interfaces to Network Elements" [OIF-SMI-02.1]. See also the work Interfaces to Network Elements" [OIF-SMI-02.1]. See also the work
in the ISMS WG. in the ISMS WG.
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 or logically separated from through a system which is physically or logically separated 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
MPLS/GMPLS Security framework
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
skipping to change at page 33, line 26 skipping to change at page 33, line 48
support of Internet services). In some cases this may use 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 IP VPNs may be run on a separate backbone not For example, PE-based IP 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
(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.
In a GMPLS network it is possible to operate the control plane using
physically separate resources form those used for the data plane.
This means that the data plane resources can be physically protected
and isolated from other equipment to protect the data while the
control and management traffic uses network resources that can be
accessed by operators so as to configure the network. Conversely,
MPLS/GMPLS Security framework
November 2008
the separation of control and data traffic may lead the operator to
consider that the network is secure because the data plane resources
are physically secure - but this is not the case if the control
plane can be attacked through a shared or open network, and control
plane protection techniques must still be applied.
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 services and multiple users. Thus, even resources between multiple services and multiple users. Thus, even
if certain services make use of a separate network from Internet if certain services make use of a separate network from Internet
services, nonetheless there will still be multiple MPLS/GMPLS users services, nonetheless there will still be multiple MPLS/GMPLS users
sharing the same network resources. In some cases MPLS/GMPLS sharing the same network resources. In some cases MPLS/GMPLS
services will share the use of network resources with Internet services will share the use of network resources with Internet
skipping to change at page 34, line 4 skipping to change at page 34, line 38
misbehavior by other users. This requires several security misbehavior by other users. This requires several security
measurements to be implemented. Resource limits can be placed on measurements to be implemented. Resource limits can be placed on
per service and per user basis. For example, using virtual router per service and per user basis. For example, using virtual router
or logical router to define hardware or software resource limits or logical router to define hardware or software resource limits
per service or per individual user; using rate limiting per VPN or per service or per individual user; using rate limiting per VPN or
per Internet connection to provide bandwidth protection; using per Internet connection to provide bandwidth protection; using
resource reservation for control plane traffic. In addition to resource reservation for control plane traffic. In addition to
bandwidth protection, separate resource allocation can be used to bandwidth protection, separate resource allocation can be used to
limit security attacks only to directly impacted service(s) or limit security attacks only to directly impacted service(s) or
customer(S). Strict, separate, and clearly defined engineering customer(S). Strict, separate, and clearly defined engineering
MPLS/GMPLS Security framework
rules and provisioning procedures can reduce the risks of network rules and provisioning procedures can reduce the risks of network
wide impact through control plane attack, DoS attack, or mis- wide impact through control plane attack, DoS attack, or mis-
configurations. configurations.
In general, the use of aggregated infrastructure allows the service 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. However, service by combining the data from multiple users. However, service
providers must minimize security risks introduced from any providers must minimize security risks introduced from any
individual service or individual users. individual service or individual 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 SP. For example, a relatively large amount of configuration by the SP. For example,
the SP needs to configure which VPN each site belongs to, as well the SP needs to configure which VPN each site belongs to, as well
MPLS/GMPLS Security framework
November 2008
as QoS and SLA guarantees. This large amount of required as QoS and SLA guarantees. This large amount of required
configuration leads to the possibility of misconfiguration. configuration leads to the possibility of misconfiguration.
It is important for the SP to have operational processes in place It is important for the SP to have operational processes in place
to reduce the potential impact of misconfiguration. CE-to-CE to reduce the potential impact of misconfiguration. CE-to-CE
authentication may also be used to detect misconfiguration when it authentication may also be used to 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. For example, for a point-point they are configured correctly. For example, for a point-point
connection, checking that the intended connectivity is working connection, checking that the intended connectivity is working
pretty much ensures that there is not connectivity to some pretty much ensures that there is not connectivity to some
unintended site. unintended site.
5.8. Verification of Connectivity
In order to protect against deliberate or accidental misconnection,
mechanisms can be put in place to verify both end-to-end
connectivity and hop-by-hop resources. These mechanisms can trace
the routes of LSPs in both the control plane and the data plane.
It should be noted that where there is an attack on the control
plane it may be that data plane connectivity test mechanisms that
utilize the control plane can also be attacked to hide faults
through false positives, or to disrupt functioning services through
false negatives.
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 to detect and customers by implementing security monitoring systems to detect and
report on any security attacks which occur, regardless of whether report on any security attacks which occur, regardless of whether
the attacks are effective. the attacks are effective.
MPLS/GMPLS Security framework
Attackers often begin by probing and analyzing defenses, so systems Attackers often begin by probing and analyzing defenses, so systems
that 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
MPLS/GMPLS Security framework
November 2008
can be used to help identify attackers or their specific targets at can be used to help identify attackers or their specific targets at
an early stage. This knowledge about attackers and targets can be an early stage. This knowledge about attackers and targets can be
used to strengthen defenses against specific attacks or attackers, used to strengthen defenses against specific attacks or attackers,
or improve the defensive services for specific targets on an as- or improve the defensive services for specific targets on an as-
needed basis. Information collected on attacks may also be useful needed basis. Information collected on attacks may also be useful
in identifying and developing defenses against novel attack types. in identifying and developing defenses against novel attack types.
Monitoring systems used to detect security attacks in MPLS/GMPLS Monitoring systems used to detect security attacks in MPLS/GMPLS
typically operate by collecting information from the Provider Edge typically operate by collecting information from the Provider Edge
(PE), Customer Edge (CE), and/or Provider backbone (P) devices. (PE), Customer Edge (CE), and/or Provider backbone (P) devices.
skipping to change at page 36, line 4 skipping to change at page 36, line 47
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 should 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.
7. Service Provider General Security Requirements 7. Service Provider General Security Requirements
MPLS/GMPLS Security framework
This section covers security requirements the provider may have for This section covers security requirements the provider may have for
securing its MPLS/GMPLS network infrastructure including LDP and securing its MPLS/GMPLS network infrastructure including LDP and
RSVP-TE specific requirements. RSVP-TE specific requirements.
The MPLS/GMPLS service provider's requirements defined here are for The MPLS/GMPLS service provider's requirements defined here are for
the MPLS/GMPLS core in the reference model. The core network can the MPLS/GMPLS core in the reference model. The core network can
be implemented with different types of network technologies, and be implemented with different types of network technologies, and
MPLS/GMPLS Security framework
November 2008
each core network may use different technologies to provide the each core network may use different technologies to provide the
various services to users with different levels of offered various services to users with different levels of offered
security. Therefore, a MPLS/GMPLS service provider may fulfill any security. Therefore, a MPLS/GMPLS service provider may fulfill any
number of the security requirements listed in this section. This number of the security requirements listed in this section. This
document does not state that a MPLS/GMPLS network must fulfill all document does not state that a MPLS/GMPLS network 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.
skipping to change at page 37, line 4 skipping to change at page 37, line 46
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.
- Infrastructure Hiding - Infrastructure Hiding
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 its 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.
MPLS/GMPLS Security framework
November 2008
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, by using MPLS label routing an edge function, for example, by using MPLS label
switching for all traffic within the core and possibly make the switching for all traffic within the core and possibly make the
Internet a VPN within the PPVPN core itself. This helps to detach Internet a VPN within the PPVPN core itself. This helps to detach
skipping to change at page 37, line 46 skipping to change at page 38, line 42
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
resources, such as CPU and Memory, can be further separated based resources, such as CPU and Memory, can be further separated based
on applications, or even individual VPNs, it may help to provide on applications, or even individual VPNs, it may help to provide
improved security and reliability to individual VPN customers. improved security and reliability to individual VPN customers.
7.1.2. Control plane protection with RSVP-TE 7.1.2. Control plane protection with RSVP-TE
- RSVP Security Tools - General RSVP Security Tools
Isolation of the trusted domain is an important security mechanism Isolation of the trusted domain is an important security mechanism
for RSVP, to ensure that an untrusted element cannot access a for RSVP, to ensure that an untrusted element cannot access a
router of the trusted domain. However, isolation is limited by the router of the trusted domain. However, ASBR-ASBR communication for
need to allow ASBR-ASBR communication for inter-AS LSPs. Isolation inter-AS LSPs needs to be secured specifically. Isolation
mechanisms might also be bypassed by Router Alert IP packets. A mechanisms might also be bypassed by Router Alert IP packets. A
solution could consists of disabling the processing of IP options.
This drops or ignores all IP packets with IP options, including the
router alert option used by RSVP; however, this may have an impact
on other protocols using IP options. An alternative is to configure
access-lists on all incoming interfaces dropping IP protocol 46
(RSVP).
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
solution could consists of disabling the RSVP router alert mode and November 2008
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
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 or attacks on non-adjacent really protect against DoS attacks or attacks on non-adjacent
routers. It has been demonstrated that substantial CPU resources routers. It has been demonstrated that substantial CPU resources
are consumed simply by processing received RSVP packets, even if are consumed simply by processing received RSVP packets, even if
the RSVP process is deactivated for the specific interface on which the RSVP process is deactivated for the specific interface on which
the RSVP packets are received. the RSVP packets are received.
skipping to change at page 38, line 32 skipping to change at page 39, line 29
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 - with an access RSVP neighbor filtering at the data plane level - with an access
list to accept IP packets with port 46, only for specific list to accept IP packets with port 46, only for specific
neighbors. This requires Router Alert mode to be deactivated and neighbors. This requires Router Alert mode to be deactivated and
does not protect against spoofing. does not protect against spoofing.
- Authentication for RSVP messages
One of the most powerful tools for protection against RSVP-based
attacks is the use of authentication for RSVP messages, based on a
secure message hash using a key shared by RSVP neighbors. This
protects against LSP creation attacks, at the expense of consuming
significant CPU resources for digest computation. In addition, if
the neighboring RSVP speaker is compromised, it could be used to
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.
The trick with DoS is to let the good packet through and keep
operating. Rate limiting by itself needs to be selective do this.
MPLS/GMPLS Security framework
- limit the impact of an attack on control plane resources - limit the impact of an attack on control plane resources
To ensure continued effective operation of the MPLS router even in To ensure continued effective operation of the MPLS router even in
the case of an attack that bypasses packet filtering mechanisms the case of an attack that bypasses packet filtering mechanisms
such as Access Control Lists in the data plane, it is important such as Access Control Lists in the data plane, it is important
that routers have some mechanisms to limit the impact of the that routers have some mechanisms to limit the impact of the
attack. There should be a mechanism to rate limit the amount of attack. There should be a mechanism to rate limit the amount of
control plane traffic addressed to the router, per interface. This control plane traffic addressed to the router, per interface. This
should be configurable on a per-protocol basis, (and, ideally, on a should be configurable on a per-protocol basis, (and, ideally, on a
per-sender basis) to avoid letting an attacked protocol or a given per-sender basis) to avoid letting an attacked protocol or a given
sender blocking all communications. This requires the ability to sender blocking all communications. This requires the ability to
filter and limit the rate of incoming messages of particular filter and limit the rate of incoming messages of particular
protocols, such as RSVP (filtering at the IP protocol level), and protocols, such as RSVP (filtering at the IP protocol level), and
particular senders. In addition, there should be a mechanism to particular senders. In addition, there should be a mechanism to
limit CPU and memory capacity allocated to RSVP, so as to protect limit CPU and memory capacity allocated to RSVP, so as to protect
other control plane elements. To limit the memory allocation, it other control plane elements. To limit the memory allocation, it
will probably be necessary to limit the number of LSPs that can be will probably be necessary to limit the number of LSPs that can be
set up. set up.
- Authentication for RSVP messages
RSVP message authentication is described in RFC 2747 [RFC2747] and
RFC 3097 [RFC3097]. It is one of the most powerful tools for
MPLS/GMPLS Security framework
November 2008
protection against RSVP-based attacks is the use of authentication
for RSVP messages, based on a secure message hash using a key
shared by RSVP neighbors. This protects against LSP creation
attacks, at the expense of consuming significant CPU resources for
digest computation. In addition, if the neighboring RSVP speaker
is compromised, it could be used to 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.
One challenge using RSVP message authentication arises in many
cases where non-RSVP nodes are present in the network. In such
cases the RSVP neighbor may not be known up front, thus neighbor
based keying approaches fail, unless the same key is used
everywhere, which is not recommended for security reasons. Group
keying may help in such cases. The security properties of various
keying approaches are discussed in detail in [RSVP-key].
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 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 allocated to per protocol per sender and limiting all resources allocated to
LDP-related tasks. LDP-related tasks.
skipping to change at page 40, line 5 skipping to change at page 41, line 5
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 traffic carried over MPLS can be used to secure the MPLS data plane traffic carried over MPLS
core. Both the Frame Relay Forum and the ATM Forum standardized core. Both the Frame Relay Forum and the ATM Forum standardized
cryptographic security services in the late 1990s, but these cryptographic security services in the late 1990s, but these
standards are not widely implemented. standards are not widely implemented.
7.2. Protection on the User Access Link 7.2. Protection on the User Access Link
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
Peer or 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, cryptographic protection mechanisms between provider connection, cryptographic protection mechanisms between
ASes, such as IPsec, may be used. ASes, such as IPsec, may be used.
If multiple services are provided on the same PE platform, If multiple services are provided on the same PE platform,
different WAN address spaces may be used for different services different WAN address spaces may be used for different services
(e.g., VPN and non-VPN) to enhance isolation. (e.g., VPN and non-VPN) to enhance isolation.
skipping to change at page 41, line 6 skipping to change at page 42, line 6
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
- 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.
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
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 or 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 interconnection to protect the implemented in Inter-provider interconnection to protect the
providers' network infrastructure and their customers. This may be providers' network infrastructure and their customers. This may be
custom designed for each Inter-Provider peering connection, and custom designed for each Inter-Provider peering connection, and
must be agreed upon by both providers. must be agreed upon by both providers.
skipping to change at page 42, line 6 skipping to change at page 43, line 6
- User control plane separation - routing isolation when - User control plane separation - routing isolation when
applicable, for example, in the case of MPLS VPNs. applicable, for example, in the case of MPLS VPNs.
- Protection against intrusion, DoS attacks and spoofing - Protection against intrusion, DoS attacks and spoofing
- Access Authentication - Access Authentication
- Techniques highlighted through this document that identify - Techniques highlighted through this document that identify
methodologies for the protection of resources and the methodologies for the protection of resources and the
MPLS/GMPLS infrastructure. MPLS/GMPLS infrastructure.
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
Hardware or software errors in equipment leading to breaches in Hardware or software errors in equipment leading to breaches in
security 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 (including the MPLS/GMPLS Inter-provider connections and at devices (including
ASBR routers) supporting these connections. The security ASBR routers) supporting these connections. The security
capabilities stated in this section should be considered as capabilities stated in this section should be considered as
skipping to change at page 42, line 41 skipping to change at page 43, line 42
the service providers managing the PE equipment offering/using the the service providers managing the PE equipment offering/using the
ICI services. 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 is needed for signaling sessions (i.e., BGP, LDP and Authentication may be needed for signaling sessions (i.e., BGP, LDP
RSVP-TE) and routing sessions (e.g., BGP) as well as OAM sessions and RSVP-TE) and routing sessions (e.g., BGP) as well as OAM
across domain boundaries. Equipment must be able to support sessions across domain boundaries. Equipment must be able to
exchange of all protocol messages over a single IPsec tunnel, with support exchange of all protocol messages over IPsec, with NULL
NULL encryption and authentication, between the peering ASBRs. encryption and authentication, between the peering ASBRs. Support
Support for TCP MD5 authentication for LDP and BGP and for RSVP-TE for message authentication for LDP, BGP and RSVP-TE authentication
authentication must also be provided. Manual keying of IPsec should must also be provided. Manual keying of IPsec should not be used.
not be used. IKEv2 with pre-shared secrets or public key methods IKEv2 with pre-shared secrets or public key methods should be used.
should be used. Replay detection should be used. Replay detection should be used.
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
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
whether the LSP source is who it 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 Message authentication support for all TCP-based protocols within
scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and MD5 the scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and
authentication for the RSVP-TE Integrity Object MUST be provided to Message authentication with the RSVP-TE Integrity Object MUST be
interoperate with current practices. provided to 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 security association pair in tunnel or transport mode with IPSec security association pair in tunnel or transport mode with
authentication but with NULL encryption, between the peering ASBRs. authentication but with NULL encryption, between the peering ASBRs.
IPSec, if supported, must be supported with HMAC-MD5 and optionally IPSec, if supported, must be supported with HMAC-MD5 and optionally
SHA-1. It is expected that authentication algorithms will evolve SHA-1. It is expected that authentication algorithms will evolve
over time and support can be 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
skipping to change at page 44, line 6 skipping to change at page 45, line 6
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
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 given profile. to a given profile.
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
During a control plane DoS attack against an ASBR, the router During a control plane DoS attack against an ASBR, the router
SHOULD guarantee sufficient resources to allow network operators to SHOULD guarantee sufficient resources to allow network operators to
execute network management commands to take corrective action, such execute network management commands to take corrective action, such
as turning on additional filters or disconnecting an interface as turning on additional filters or disconnecting an interface
under attack. DoS attacks on the control plane SHOULD NOT adversely under attack. DoS attacks on the control plane SHOULD NOT adversely
affect data plane performance. affect data plane performance.
Equipment running BGP MUST support the ability to limit the number Equipment running BGP MUST support the ability to limit the number
of BGP routes received from any particular peer. Furthermore, in of BGP routes received from any particular peer. Furthermore, in
the case of IPVPN, a router MUST be able to limit the number of the case of IPVPN, a router MUST be able to limit the number of
routes learned from a BGP peer per IPVPN. In the case that a device routes learned from a BGP peer per IPVPN. In the case that a device
skipping to change at page 45, line 6 skipping to change at page 46, line 6
The capability of detecting and locating faults in a LSP cross- The capability of detecting and locating faults in a LSP cross-
connect MUST be provided. Such faults may cause security violations connect MUST be provided. Such faults may cause security violations
as they 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. Equipment MUST support MPLS capability may rely on OAM functions. Equipment MUST support MPLS
LSP ping [RFC4379]. This MAY be used to verify end to end LSP ping [RFC4379]. This MAY be used to verify end to end
connectivity for the LSP (e.g., PW, TE Tunnel, VPN LSP, etc.), and connectivity for the LSP (e.g., PW, TE Tunnel, VPN LSP, etc.), and
to verify PE-to-PE connectivity for IP VPN services. to verify PE-to-PE connectivity for IP VPN services.
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
When routing information is advertised from one domain to the When routing information is advertised from one domain to the
other, operators must be able to guard against situations that other, operators must be able to guard against situations that
result in traffic hijacking, black-holing, resource stealing (e.g., result in traffic hijacking, black-holing, resource stealing (e.g.,
number of routes), etc. For instance, in the IPVPN case, an number of routes), etc. For instance, in the IPVPN case, an
operator must be able to block routes based on associated route operator must be able to block routes based on associated route
target attributes. In addition, mechanisms must exist to verify target attributes. In addition, mechanisms must exist to verify
whether a route advertised by a peer for a given VPN is actually a whether a route advertised by a peer for a given VPN is actually a
valid route and whether the VPN has a site attached or reachable valid route and whether the VPN has a site attached or reachable
through that domain. through that domain.
skipping to change at page 45, line 35 skipping to change at page 46, line 37
8.1.6. Protection Against Spoofed Updates and Route 8.1.6. Protection Against Spoofed Updates and Route
Advertisements Advertisements
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 or extended following: AS path, BGP next hop, standard community or 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 block messages with confidential
information from leaving the trusted domain that can reveal
confidential information about network operation (e.g., performance confidential information about network operation (e.g., performance
OAM messages or MPLS-ping messages) is required. Service Providers OAM messages or MPLS-ping messages) is required. Service Providers
must have the 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 restrict where Equipment SHOULD provide the ability to identify and restrict where
it sends messages or that can reveal confidential information about it sends messages or that can reveal confidential information about
network 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 to which addresses replies can be sent. 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
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
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
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 a 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 8.1.8. Protection Against over-provisioned number of
RSVP-TE LSPs and bandwidth reservation RSVP-TE LSPs and bandwidth reservation
In addition to the control plane protection mechanisms listed in In addition to the control plane protection mechanisms listed in
skipping to change at page 46, line 52 skipping to change at page 48, line 4
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 lets packets if all labels in the stack are not processed. This lets
carriers guarantee that every label that enters its domain from carriers guarantee that every label that enters its domain from
another carrier was actually assigned to that carrier. another carrier was actually assigned to that carrier.
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
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
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 it 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 8.2.3. Protection using ingress traffic policing and
skipping to change at page 47, line 50 skipping to change at page 48, line 53
PE1 where the LSP terminates. PE1 where the LSP terminates.
To mitigate this threat, implementations SHOULD be able to do a To mitigate this threat, implementations SHOULD be able to do a
forwarding path look-up for the label on an incoming packet from an forwarding path look-up for the label on an incoming packet from an
interconnect in a Label Forwarding Information Base (LFIB) space interconnect in a Label Forwarding Information Base (LFIB) space
that is only intended for its own service context or provide a that is only intended for its own service context or provide a
mechanism on the data plane that would ensure the incoming labels mechanism on the data plane that would ensure the incoming labels
are what ASBR1 has allocated and advertised. are what ASBR1 has allocated and advertised.
A similar concept has been proposed in "Requirements for Multi- 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)" [RFC5254].
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
November 2008
When using upstream label assignment, the upstream source must be When using upstream label assignment, the upstream source must be
identified and authenticated so the labels can be accepted as from identified and authenticated so the labels can be accepted as from
trusted source. trusted source.
9. Summary of MPLS and GMPLS Security 9. Summary of MPLS and GMPLS Security
The following summary provides a quick check list of MPLS and GMPLS The following summary provides a quick check list of MPLS and GMPLS
security threats, defense techniques, and the best practice guide security threats, defense techniques, and the best practice guide
outlines for MPLS and GMPLS deployment. outlines for MPLS and GMPLS deployment.
skipping to change at page 48, line 44 skipping to change at page 49, line 46
infrastructure elements. infrastructure elements.
In general, control protocols may be attacked by: In general, control protocols may be attacked by:
- MPLS signaling (LDP, RSVP-TE) - MPLS signaling (LDP, RSVP-TE)
- PCE signaling - PCE signaling
- IPsec signaling (IKE and IKEv2) - IPsec signaling (IKE and IKEv2)
- ICMP and ICMPv6 - ICMP and ICMPv6
- L2TP - L2TP
- BGP-based membership discovery - BGP-based membership discovery
- Database-based membership discovery (e.g., RADIUS) - Database-based membership discovery (e.g., RADIUS)
- OAM and diagnostic protocol such as MPLS-ping and LMP
- Other protocols that may be important to the control - Other protocols that may be important to the control
infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE. infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE.
9.1.2. Data plane attacks 9.1.2. Data plane attacks
- Unauthorized observation of data traffic - Unauthorized observation of data traffic
MPLS/GMPLS Security framework
November 2008
- Data traffic modification - Data traffic modification
- Spoofing and replay - Spoofing and replay
- Unauthorized Deletion - Unauthorized Deletion
MPLS/GMPLS Security framework
- Unauthorized Traffic Pattern Analysis - Unauthorized Traffic Pattern Analysis
- Denial of Service Attacks - Denial of Service Attacks
9.2. Defense Techniques 9.2. Defense Techniques
1) Authentication: 1) Authentication:
- Identity authentication - Key management - Identity authentication - Key management
- Management System Authentication - Management System Authentication
- Peer-to-peer authentication - Peer-to-peer authentication
skipping to change at page 49, line 32 skipping to change at page 50, line 37
7) Access Control techniques 7) Access Control techniques
- Filtering - Filtering
- Firewalls - Firewalls
- Access Control to management interfaces - Access Control to management interfaces
8) Infrastructure isolation 8) Infrastructure isolation
9) Use of aggregation infrastructure 9) Use of aggregation infrastructure
10) Quality Control Processes 10) Quality Control Processes
11) Testable MPLS/GMPLS Service 11) Testable MPLS/GMPLS Service
12) End-to-end connectivity verification techniques
13) Hop-by-hop resource configuration verification and discovery
techniques
9.3. Service Provider MPLS and GMPLS Best Practice Outlines 9.3. Service Provider MPLS and GMPLS Best Practice Outlines
9.3.1. SP infrastructure protection 9.3.1. SP infrastructure protection
1) General control plane protection 1) General control plane protection
- Protocol authentication within the core - Protocol authentication within the core
- Infrastructure Hiding (e.g. disable TTL propagation) - Infrastructure Hiding (e.g. disable TTL propagation)
2) RSVP control plane protection 2) RSVP control plane protection
- Using RSVP security tools - Using RSVP security tools
- Isolation of the trusted domain - Isolation of the trusted domain
- Deactivating RSVP on interfaces with neighbors who are not - Deactivating RSVP on interfaces with neighbors who are not
authorized to use RSVP authorized to use RSVP
- RSVP neighbor filtering at the protocol level and data plane - RSVP neighbor filtering at the protocol level and data plane
level level
MPLS/GMPLS Security framework
November 2008
- Authentication for RSVP messages - Authentication for RSVP messages
- RSVP message pacing - RSVP message pacing
3) LDP control plane protection (similar techniques as for RSVP) 3) LDP control plane protection (similar techniques as for RSVP)
4) Data plane protection 4) Data plane protection
- User Access link protection - User Access link protection
- Link Authentication - Link Authentication
MPLS/GMPLS Security framework
- Access routing control (e.g. prefix limits, route dampening, - Access routing control (e.g. prefix limits, route dampening,
routing table limits (e.g. VRF limits) routing table limits (e.g. VRF limits)
- Access QoS control - Access QoS control
- Using customer service monitoring tools - Using customer service monitoring tools
- Use of MPLS-ping (with its own control plane security) to
verify end-to-end connectivity of MPLS LSPs
- LMP (with its own security) to verify hop-by-hop
connectivity
9.3.2. Inter-provider Security 9.3.2. Inter-provider Security
Inter-provider connections are high security risk areas. Similar Inter-provider connections are high security risk areas. Similar
techniques and procedures as described in for SP general core techniques and procedures as described in for SP general core
protection are listed below for inter-provider connections. protection are listed below for inter-provider connections.
1) Control plane protection at the inter-provider connections 1) Control plane protection at the inter-provider connections
- Authentication of Signaling Sessions - Authentication of Signaling Sessions
- Protection against DoS attacks in the Control Plane - Protection against DoS attacks in the Control Plane
skipping to change at page 50, line 42 skipping to change at page 52, line 5
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 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. running networks; others are largely theoretical at this time.
MPLS/GMPLS Security framework
November 2008
DoS attacks and intrusion attacks from the Internet against service DoS attacks and intrusion attacks from the Internet against service
providers' infrastructure have been seen. DoS "attacks" (typically providers' infrastructure have been seen. DoS "attacks" (typically
not malicious) have also been seen in which CE equipment overwhelms not malicious) have also been seen in which CE equipment overwhelms
PE equipment with high quantities or rates of packet traffic or PE equipment with high quantities or rates of packet traffic or
routing information. Operational or provisioning errors are cited routing information. Operational or provisioning errors are cited
by service providers as one of their prime concerns. 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
MPLS/GMPLS Security framework
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.
skipping to change at page 51, line 29 skipping to change at page 52, line 41
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 configuration decide what threats to protect against in any given configuration
or service offering. or service offering.
11. IANA Considerations 11. IANA Considerations
No new IANA considerations. No new IANA considerations.
12. Normative References 12. Normative References
[RFC2747] F. Baker, et al., "RSVP Cryptographic Authentication",
EFC 2741, January 2000.
[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.
[RFC3097] R. Braden and L. Zhang, "RSVP Cryptographic
Authentication - Updated Message Type Value", RFC 3097, April 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.
MPLS/GMPLS Security framework
November 2008
[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.
[RFC4835] V. Manral, "Cryptographic Algorithm Implementation [RFC4835] V. Manral, "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", April 2007. 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.
MPLS/GMPLS Security framework
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES)
CCM Mode with IPsec Encapsulating Security Payload (ESP)", December CCM Mode with IPsec Encapsulating Security Payload (ESP)", December
2005. 2005.
[RFC4346] T. Dierks and E. Rescorla, "The Transport Layer Security [RFC5246] T. Dierks and E. Rescorla, "The Transport Layer Security
(TLS) Protocol, Version 1.1," April 2006. (TLS) Protocol, Version 1.2," August 2008.
[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.
[RFC5036] Andersson, et al., "LDP Specification", October 2007. [RFC5036] Andersson, et al., "LDP Specification", October 2007.
[STD62] "Simple Network Management Protocol, Version 3,", December [STD62] "Simple Network Management Protocol, Version 3,", December
skipping to change at page 52, line 36 skipping to change at page 54, line 5
STD 8, May 1983. STD 8, May 1983.
13. Informational References 13. Informational References
[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
[OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces [OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces
to Network Elements", Optical Internetworking Forum, Sept. 2003. to Network Elements", Optical Internetworking Forum, Sept. 2003.
MPLS/GMPLS Security framework
November 2008
[OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for [OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for
Management Interfaces to Network Elements", Optical Internetworking Management Interfaces to Network Elements", Optical Internetworking
Forum, March 2006. 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.
[RFC3562] M. Leech, "Key Management Considerations for the TCP MD5 [RFC3562] M. Leech, "Key Management Considerations for the TCP MD5
Signature Option", July 2003. Signature Option", July 2003.
MPLS/GMPLS Security framework
[RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security [RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security
Mechanisms for the Internet," December 2003. 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 [RFC4103] G. Hellstrom and P. Jones, "RTP Payload for Text
Conversation", June 2005. Conversation", June 2005.
[RFC4107] S. Bellovin, R. Housley, "Guidelines for Cryptographic [RFC4107] S. Bellovin, R. Housley, "Guidelines for Cryptographic
skipping to change at page 53, line 40 skipping to change at page 55, line 5
[RFC4593] A. Barbir, S. Murphy, Y. Yang, "Generic Threats to Routing [RFC4593] A. Barbir, S. Murphy, Y. Yang, "Generic Threats to Routing
Protocols", October 2006. Protocols", October 2006.
[RFC4808] S. Bellovin, "Key Change Strategies for TCP-MD5", March [RFC4808] S. Bellovin, "Key Change Strategies for TCP-MD5", March
2007. 2007.
[RFC4869] L. Law and J. Solinas, "Suite B Cryptographic Suites for [RFC4869] L. Law and J. Solinas, "Suite B Cryptographic Suites for
IPsec", April 2007. IPsec", April 2007.
MPLS/GMPLS Security framework
November 2008
[RFC5254] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi-
Segment Pseudowire Emulation Edge-to-Edge (PWE3)", October 2008.
[MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical [MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical
Specification", mpls2007.017, August 2006. Specification", IP/MPLS Forum 19.0.0, April 2008.
[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-07.txt, December Efforts and Documents", draft-ietf-opsec-efforts-08.txt, June 2008.
2007.
[PW-REQ] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi-
Segment Pseudowire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-
requirements-07.txt, June 2007.
MPLS/GMPLS Security framework [RSVP-key] M. Behringer, F. Le Faucheur, "Applicability of Keying
Methods for RSVP Security", draft-ietf-tsvwg-rsvp-security-
groupkeying-01.txt, July 2008
14. Author's Addresses 14. 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
skipping to change at page 54, line 39 skipping to change at page 56, line 4
Westford, MA 01886 Westford, MA 01886
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
MPLS/GMPLS Security framework
November 2008
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@francetelecom.com
Raymond Zhang Raymond Zhang
British Telecom British Telecom
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
MPLS/GMPLS Security framework
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 Nabil Bitar
Verizon Verizon
skipping to change at page 55, line 33 skipping to change at page 56, line 51
Email: rfg@acm.org Email: rfg@acm.org
Monique Morrow Monique Morrow
Glatt-com Glatt-com
CH-8301 Glattzentrum CH-8301 Glattzentrum
Switzerland Switzerland
Email: mmorrow@cisco.com Email: mmorrow@cisco.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk Email: adrian@olddog.co.uk
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
MPLS/GMPLS Security framework MPLS/GMPLS Security framework
attempt made to obtain a general license or permission for the use November 2008
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.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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.
This document and the information contained herein are provided on This document and the information contained herein are provided on
skipping to change at page 57, line 5 skipping to change at page 57, line 42
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.
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.
MPLS/GMPLS Security framework
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
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
15. Acknowledgements 15. 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).
MPLS/GMPLS Security framework
November 2008
The authors and contributors would also like to acknowledge the The authors and contributors would also like to acknowledge the
helpful comments and suggestions from Sam Hartman, Dimitri helpful comments and suggestions from Sam Hartman, Dimitri
Papadimitriou, Kannan Varadhan, Stephen Farrell, and Scott Brim in Papadimitriou, Kannan Varadhan, Stephen Farrell, and Scott Brim in
particular for his comments and discussion through GEN-ART review. particular for his comments and discussion through GEN-ART review.
 End of changes. 134 change blocks. 
169 lines changed or deleted 325 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/