summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5920.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5920.txt')
-rw-r--r--doc/rfc/rfc5920.txt3699
1 files changed, 3699 insertions, 0 deletions
diff --git a/doc/rfc/rfc5920.txt b/doc/rfc/rfc5920.txt
new file mode 100644
index 0000000..18bada2
--- /dev/null
+++ b/doc/rfc/rfc5920.txt
@@ -0,0 +1,3699 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Fang, Ed.
+Request for Comments: 5920 Cisco Systems, Inc.
+Category: Informational July 2010
+ISSN: 2070-1721
+
+
+ Security Framework for MPLS and GMPLS Networks
+
+Abstract
+
+ This document provides a security framework for Multiprotocol Label
+ Switching (MPLS) and Generalized Multiprotocol Label Switching
+ (GMPLS) Networks. This document addresses the security aspects that
+ are relevant in the context of MPLS and GMPLS. It describes the
+ security threats, the related defensive techniques, and the
+ mechanisms for detection and reporting. This document emphasizes
+ RSVP-TE and LDP security considerations, as well as inter-AS and
+ inter-provider security considerations for building and maintaining
+ MPLS and GMPLS networks across different domains or different
+ Service Providers.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5920.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fang Informational [Page 1]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fang Informational [Page 2]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Terminology .....................................................5
+ 2.1. Acronyms and Abbreviations .................................5
+ 2.2. MPLS and GMPLS Terminology .................................6
+ 3. Security Reference Models .......................................8
+ 4. Security Threats ...............................................10
+ 4.1. Attacks on the Control Plane ..............................12
+ 4.2. Attacks on the Data Plane .................................15
+ 4.3. Attacks on Operation and Management Plane .................17
+ 4.4. Insider Attacks Considerations ............................19
+ 5. Defensive Techniques for MPLS/GMPLS Networks ...................19
+ 5.1. Authentication ............................................20
+ 5.2. Cryptographic Techniques ..................................22
+ 5.3. Access Control Techniques .................................33
+ 5.4. Use of Isolated Infrastructure ............................38
+ 5.5. Use of Aggregated Infrastructure ..........................38
+ 5.6. Service Provider Quality Control Processes ................39
+ 5.7. Deployment of Testable MPLS/GMPLS Service .................39
+ 5.8. Verification of Connectivity ..............................40
+ 6. Monitoring, Detection, and Reporting of Security Attacks .......40
+ 7. Service Provider General Security Requirements .................42
+ 7.1. Protection within the Core Network ........................42
+ 7.2. Protection on the User Access Link ........................46
+ 7.3. General User Requirements for MPLS/GMPLS Providers ........48
+ 8. Inter-Provider Security Requirements ...........................48
+ 8.1. Control-Plane Protection ..................................49
+ 8.2. Data-Plane Protection .....................................53
+ 9. Summary of MPLS and GMPLS Security .............................54
+ 9.1. MPLS and GMPLS Specific Security Threats ..................55
+ 9.2. Defense Techniques ........................................56
+ 9.3. Service Provider MPLS and GMPLS Best-Practice Outlines ....57
+ 10. Security Considerations .......................................59
+ 11. References ....................................................59
+ 11.1. Normative References .....................................59
+ 11.2. Informative References ...................................62
+ 12. Acknowledgements ..............................................64
+ 13. Contributors' Contact Information .............................65
+
+
+
+
+
+
+
+
+
+
+
+
+Fang Informational [Page 3]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+1. Introduction
+
+ Security is an important aspect of all networks, MPLS and GMPLS
+ networks being no exception.
+
+ MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Various
+ security considerations have been addressed in each of the many RFCs
+ on MPLS and GMPLS technologies, but no single document covers general
+ security considerations. The motivation for creating this document
+ is to provide a comprehensive and consistent security framework for
+ MPLS and GMPLS networks. Each individual document may point to this
+ document for general security considerations in addition to providing
+ security considerations specific to the particular technologies the
+ document is describing.
+
+ In this document, we first describe the security threats relevant in
+ the context of MPLS and GMPLS and the defensive techniques to combat
+ those threats. We consider security issues resulting both from
+ malicious or incorrect behavior of users and other parties and from
+ negligent or incorrect behavior of providers. An important part of
+ security defense is the detection and reporting of a security attack,
+ which is also addressed in this document.
+
+ We then discuss possible service provider security requirements in an
+ MPLS or GMPLS environment. Users have expectations for the security
+ characteristics of MPLS or GMPLS networks. These include security
+ requirements for equipment supporting MPLS and GMPLS and operational
+ security requirements for providers. Service providers must protect
+ their network infrastructure and make it secure to the level required
+ to provide services over their MPLS or GMPLS networks.
+
+ Inter-AS and inter-provider security are discussed with special
+ emphasis, because the security risk factors are higher with inter-
+ provider connections. Note that inter-carrier MPLS security is also
+ considered in [MFA-MPLS-ICI].
+
+ Depending on different MPLS or GMPLS techniques used, the degree of
+ risk and the mitigation methodologies vary. This document discusses
+ the security aspects and requirements for certain basic MPLS and
+ GMPLS techniques and interconnection models. This document does not
+ attempt to cover all current and future MPLS and GMPLS technologies,
+ as it is not within the scope of this document to analyze the
+ security properties of specific technologies.
+
+ It is important to clarify that, in this document, we limit ourselves
+ to describing the providers' security requirements that pertain to
+ MPLS and GMPLS networks, not including the connected user sites.
+ Readers may refer to the "Security Best Practices Efforts and
+
+
+
+Fang Informational [Page 4]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Documents" [OPSEC-EFFORTS] and "Security Mechanisms for the Internet"
+ [RFC3631] for general network operation security considerations. It
+ is not our intention, however, to formulate precise "requirements"
+ for each specific technology in terms of defining the mechanisms and
+ techniques that must be implemented to satisfy such security
+ requirements.
+
+2. Terminology
+
+2.1. Acronyms and Abbreviations
+
+ AS Autonomous System
+ ASBR Autonomous System Border Router
+ ATM Asynchronous Transfer Mode
+ BGP Border Gateway Protocol
+ BFD Bidirectional Forwarding Detection
+ CE Customer-Edge device
+ CoS Class of Service
+ CPU Central Processing Unit
+ DNS Domain Name System
+ DoS Denial of Service
+ ESP Encapsulating Security Payload
+ FEC Forwarding Equivalence Class
+ GMPLS Generalized Multi-Protocol Label Switching
+ GCM Galois Counter Mode
+ GRE Generic Routing Encapsulation
+ ICI InterCarrier Interconnect
+ ICMP Internet Control Message Protocol
+ ICMPv6 ICMP in IP Version 6
+ IGP Interior Gateway Protocol
+ IKE Internet Key Exchange
+ IP Internet Protocol
+ IPsec IP Security
+ IPVPN IP-based VPN
+ LDP Label Distribution Protocol
+ L2TP Layer 2 Tunneling Protocol
+ LMP Link Management Protocol
+ LSP Label Switched Path
+ LSR Label Switching Router
+ MD5 Message Digest Algorithm
+ MPLS Multiprotocol Label Switching
+ MP-BGP Multiprotocol BGP
+ NTP Network Time Protocol
+ OAM Operations, Administration, and Maintenance
+ PCE Path Computation Element
+ PE Provider-Edge device
+ PPVPN Provider-Provisioned Virtual Private Network
+ PSN Packet-Switched Network
+
+
+
+Fang Informational [Page 5]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ PW Pseudowire
+ QoS Quality of Service
+ RR Route Reflector
+ RSVP Resource Reservation Protocol
+ RSVP-TE Resource Reservation Protocol with Traffic Engineering
+ Extensions
+ SLA Service Level Agreement
+ SNMP Simple Network Management Protocol
+ SP Service Provider
+ SSH Secure Shell
+ SSL Secure Sockets Layer
+ SYN Synchronize packet in TCP
+ TCP Transmission Control Protocol
+ TDM Time Division Multiplexing
+ TE Traffic Engineering
+ TLS Transport Layer Security
+ ToS Type of Service
+ TTL Time-To-Live
+ UDP User Datagram Protocol
+ VC Virtual Circuit
+ VPN Virtual Private Network
+ WG Working Group of IETF
+ WSS Web Services Security
+
+2.2. MPLS and GMPLS Terminology
+
+ This document uses MPLS- and GMPLS-specific terminology. Definitions
+ and details about MPLS and GMPLS terminology can be found in
+ [RFC3031] and [RFC3945]. The most important definitions are repeated
+ in this section; for other definitions, the reader is referred to
+ [RFC3031] and [RFC3945].
+
+ Core network: An MPLS/GMPLS core network is defined as the central
+ network infrastructure that consists of P and PE routers. An
+ MPLS/GMPLS core network may consist of one or more networks belonging
+ to a single SP.
+
+ Customer Edge (CE) device: A Customer Edge device is a router or a
+ switch in the customer's network interfacing with the Service
+ Provider's network.
+
+ Forwarding Equivalence Class (FEC): A group of IP packets that are
+ forwarded in the same manner (e.g., over the same path, with the same
+ forwarding treatment).
+
+ Label: A short, fixed length, physically contiguous identifier,
+ usually of local significance.
+
+
+
+
+Fang Informational [Page 6]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Label merging: the replacement of multiple incoming labels for a
+ particular FEC with a single outgoing label.
+
+ Label Switched Hop: A hop between two MPLS nodes, on which forwarding
+ is done using labels.
+
+ Label Switched Path (LSP): The path through one or more LSRs at one
+ level of the hierarchy followed by packets in a particular FEC.
+
+ Label Switching Routers (LSRs): An MPLS/GMPLS node assumed to have a
+ forwarding plane that is capable of (a) recognizing either packet or
+ cell boundaries, and (b) being able to process either packet headers
+ or cell headers.
+
+ 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, but
+ the loop is later detected.
+
+ Loop Prevention: A method of dealing with loops in which data is
+ never transmitted over a loop.
+
+ Label Stack: An ordered set of labels.
+
+ Merge Point: A node at which label merging is done.
+
+ MPLS Domain: A contiguous set of nodes that perform MPLS routing and
+ forwarding and are also in one Routing or Administrative Domain.
+
+ MPLS Edge Node: An MPLS node that connects an MPLS domain with a node
+ outside of the domain, either because it does not run MPLS, or
+ because it is in a different domain. Note that if an LSR has a
+ neighboring host not running MPLS, then that LSR is an MPLS edge
+ node.
+
+ MPLS Egress Node: An MPLS edge node in its role in handling traffic
+ as it leaves an MPLS domain.
+
+ MPLS Ingress Node: A MPLS edge node in its role in handling traffic
+ as it enters a MPLS domain.
+
+ MPLS Label: A label carried in a packet header, which represents the
+ packet's FEC.
+
+ MPLS Node: A node running MPLS. An MPLS node is aware of MPLS
+ control protocols, runs one or more routing protocols, and is capable
+ of forwarding packets based on labels. An MPLS node may optionally
+ be also capable of forwarding native IP packets.
+
+
+
+
+Fang Informational [Page 7]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Multiprotocol Label Switching (MPLS): MPLS is an architecture for
+ efficient data packet switching and routing. MPLS assigns data
+ packets with labels. Instead of performing the longest match for
+ each packet's destination as in conventional IP forwarding, MPLS
+ makes the packet-forwarding decisions solely on the contents of the
+ label without examining the packet itself. This allows the creation
+ of end-to-end circuits across any type of transport medium, using any
+ protocols.
+
+ P: Provider Router. A Provider Router is a router in the Service
+ Provider's core network that does not have interfaces directly
+ towards the customer. A P router is used to interconnect the PE
+ routers and/or other P routers within the core network.
+
+ PE: Provider Edge device. A Provider Edge device is the equipment in
+ the Service Provider's network that interfaces with the equipment in
+ the customer's network.
+
+ PPVPN: Provider-Provisioned Virtual Private Network, including Layer
+ 2 VPNs and Layer 3 VPNs.
+
+ VPN: Virtual Private Network, which restricts communication between a
+ set of sites, making use of an IP backbone shared by traffic not
+ going to or not coming from those sites [RFC4110].
+
+3. Security Reference Models
+
+ This section defines a reference model for security in MPLS/GMPLS
+ networks.
+
+ This document defines each MPLS/GMPLS core in a single domain to be a
+ trusted zone. A primary concern is about security aspects that
+ relate to breaches of security from the "outside" of a trusted zone
+ to the "inside" of this zone. Figure 1 depicts the concept of
+ trusted zones within the MPLS/GMPLS framework.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fang Informational [Page 8]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ /-------------\
+ +------------+ / \ +------------+
+ | MPLS/GMPLS +---/ \--------+ MPLS/GMPLS |
+ | user | MPLS/GMPLS Core | user |
+ | site +---\ /XXX-----+ site |
+ +------------+ \ / XXX +------------+
+ \-------------/ | |
+ | |
+ | +------\
+ +--------/ "Internet"
+
+ |<- Trusted zone ->|
+
+ MPLS/GMPLS Core with user connections and Internet connection
+
+ Figure 1: The MPLS/GMPLS Trusted Zone Model
+
+ The trusted zone is the MPLS/GMPLS core in a single AS within a
+ single Service Provider.
+
+ A trusted zone contains elements and users with similar security
+ properties, such as exposure and risk level. In the MPLS context, an
+ organization is typically considered as one trusted zone.
+
+ The boundaries of a trust domain should be carefully defined when
+ analyzing the security properties of each individual network, e.g.,
+ the boundaries can be at the link termination, remote peers, areas,
+ or quite commonly, ASes.
+
+ In principle, the trusted zones should be separate; however,
+ typically MPLS core networks also offer Internet access, in which
+ case a transit point (marked with "XXX" in Figure 1) is defined. In
+ the case of MPLS/GMPLS inter-provider connections or InterCarrier
+ Interconnect (ICI), the trusted zone of each provider ends at the
+ respective ASBRs (ASBR1 and ASBR2 for Provider A and ASBR3 and ASBR4
+ for Provider B in Figure 2).
+
+ A key requirement of MPLS and GMPLS networks is that the security of
+ the trusted zone not be compromised by interconnecting the MPLS/GMPLS
+ core infrastructure with another provider's core (MPLS/GMPLS or non-
+ MPLS/GMPLS), the Internet, or end users.
+
+ In addition, neighbors may be trusted or untrusted. Neighbors may be
+ authorized or unauthorized. An authorized neighbor is the neighbor
+ one establishes a peering relationship with. Even though a neighbor
+ may be authorized for communication, it may not be trusted. For
+ example, when connecting with another provider's ASBRs to set up
+
+
+
+
+Fang Informational [Page 9]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ inter-AS LSPs, the other provider is considered an untrusted but
+ authorized neighbor.
+
+ +---------------+ +----------------+
+ | | | |
+ | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS |
+ CE1--PE1 Network | | Network PE2--CE2
+ | Provider A ASBR2----ASBR4 Provider B |
+ | | | |
+ +---------------+ +----------------+
+ InterCarrier
+ Interconnect (ICI)
+ For Provider A:
+ Trusted Zone: Provider A MPLS/GMPLS network
+ Authorized but untrusted neighbor: provider B
+ Unauthorized neighbors: CE1, CE2
+
+ Figure 2: MPLS/GMPLS Trusted Zone and Authorized Neighbor
+
+ All aspects of network security independent of whether a network is
+ an MPLS/GMPLS network, are out of scope. For example, attacks from
+ 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 is provisioned could make a difference to the security of
+ this user's server.
+
+4. Security Threats
+
+ This section discusses the various network security threats that may
+ endanger MPLS/GMPLS networks. RFC 4778 [RFC4778] provided the best
+ current operational security practices in Internet Service Provider
+ environments.
+
+ A successful attack on a particular MPLS/GMPLS network or on an SP's
+ MPLS/GMPLS infrastructure may cause one or more of the following ill
+ effects:
+
+ - Observation, modification, or deletion of a provider's or user's
+ data.
+
+ - Replay of a provider's or user's data.
+
+ - Injection of inauthentic data into a provider's or user's traffic
+ stream.
+
+ - Traffic pattern analysis on a provider's or user's traffic.
+
+ - Disruption of a provider's or user's connectivity.
+
+
+
+Fang Informational [Page 10]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ - Degradation of a provider's service quality.
+
+ - Probing a provider's network to determine its configuration,
+ capacity, or usage.
+
+ It is useful to consider that threats, whether malicious or
+ accidental, may come from different categories of sources. For
+ example, they may come from:
+
+ - Other users whose services are provided by the same MPLS/GMPLS
+ core.
+
+ - The MPLS/GMPLS SP or persons working for it.
+
+ - Other persons who obtain physical access to an MPLS/GMPLS SP's
+ site.
+
+ - Other persons who use social engineering methods to influence the
+ behavior of an SP's personnel.
+
+ - Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats.
+ (Such threats are beyond the scope of this document.)
+
+ - Others, e.g., attackers from the Internet at large.
+
+ - Other SPs in the case of MPLS/GMPLS inter-provider connection.
+ The core of the other provider may or may not be using MPLS/GMPLS.
+
+ - Those who create, deliver, install, and maintain software for
+ network equipment.
+
+ Given that security is generally a tradeoff between expense and risk,
+ it is also useful to consider the likelihood of different attacks
+ occurring. There is at least a perceived difference in the
+ likelihood of most types of attacks being successfully mounted in
+ different environments, such as:
+
+ - An MPLS/GMPLS core interconnecting with another provider's core.
+
+ - An MPLS/GMPLS configuration transiting the public Internet.
+
+ Most types of attacks become easier to mount and hence more likely as
+ the shared infrastructure via which service is provided expands from
+ a single SP to multiple cooperating SPs to the global Internet.
+ Attacks that may not be of sufficient likeliness to warrant concern
+ in a closely controlled environment often merit defensive measures in
+ broader, more open environments. In closed communities, it is often
+
+
+
+
+Fang Informational [Page 11]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ practical to deal with misbehavior after the fact: an employee can be
+ disciplined, for example.
+
+ The following sections discuss specific types of exploits that
+ threaten MPLS/GMPLS networks.
+
+4.1. Attacks on the Control Plane
+
+ This category encompasses attacks on the control structures 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 separate from the data plane.
+
+ The different cases of physically congruent and physically separate
+ 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 separate 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.
+
+ This section is focused the outsider attack. The insider attack is
+ discussed in Section 4.4.
+
+4.1.1. LSP Creation by an Unauthorized Element
+
+ The unauthorized element can be a local CE or a router in another
+ domain. An unauthorized element can generate MPLS signaling
+ messages. At the least, this can result in extra control plane and
+ forwarding state, and if successful, network bandwidth could be
+ reserved unnecessarily. This may also result in theft of service or
+ even compromise the entire network.
+
+4.1.2. LSP Message Interception
+
+ This threat might be accomplished by monitoring network traffic, for
+ example, after a physical intrusion. Without physical intrusion, it
+ could be accomplished with an unauthorized software modification.
+ Also, many technologies such as terrestrial microwave, satellite, or
+ free-space optical could be intercepted without physical intrusion.
+ If successful, it could provide information leading to label spoofing
+ attacks. It also raises confidentiality issues.
+
+
+
+Fang Informational [Page 12]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+4.1.3. Attacks against RSVP-TE
+
+ RSVP-TE, described in [RFC3209], is the control protocol used to set
+ up GMPLS and traffic engineered MPLS tunnels.
+
+ There are two major types of denial-of-service (DoS) attacks against
+ an MPLS domain based on RSVP-TE. The attacker may set up numerous
+ unauthorized LSPs or may send a storm of RSVP messages. It has been
+ demonstrated that unprotected routers running RSVP can be effectively
+ disabled by both types of DoS attacks.
+
+ These attacks may even be combined, by using the unauthorized LSPs to
+ transport additional RSVP (or other) messages across routers where
+ they might otherwise be filtered out. RSVP attacks can be launched
+ against adjacent routers at the border with the attacker, or against
+ non-adjacent routers within the MPLS domain, if there is no effective
+ mechanism to filter them out.
+
+4.1.4. Attacks against LDP
+
+ LDP, described in [RFC5036], is the control protocol used to set up
+ MPLS tunnels without TE.
+
+ There are two significant types of attack against LDP. An
+ unauthorized network element can establish an LDP session by sending
+ LDP Hello and LDP Init messages, leading to the potential setup of an
+ LSP, as well as accompanying LDP state table consumption. Even
+ without successfully establishing LSPs, an attacker can launch a DoS
+ attack in the form of a storm of LDP Hello messages or LDP TCP SYN
+ messages, leading to high CPU utilization or table space exhaustion
+ on the target router.
+
+4.1.5. Denial-of-Service Attacks on the Network Infrastructure
+
+ DoS attacks could be accomplished through an MPLS signaling storm,
+ resulting in high CPU utilization and possibly leading to control-
+ plane resource starvation.
+
+ Control-plane DoS attacks can be mounted specifically against the
+ mechanisms the SP uses to provide various services, or against the
+ general infrastructure of the service provider, e.g., P routers or
+ shared aspects of PE routers. (An attack against the general
+ infrastructure is within the scope of this document only if the
+ attack can occur in relation with the MPLS/GMPLS infrastructure;
+ otherwise, it is not an MPLS/GMPLS-specific issue.)
+
+
+
+
+
+
+Fang Informational [Page 13]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ The attacks described in the following sections may each have denial
+ of service as one of their effects. Other DoS attacks are also
+ possible.
+
+4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via Management
+ Interfaces
+
+ This includes unauthorized access to an SP's infrastructure
+ equipment, for example, to reconfigure the equipment or to extract
+ information (statistics, topology, etc.) pertaining to the network.
+
+4.1.7. Cross-Connection of Traffic between Users
+
+ This refers to the event in which expected isolation between separate
+ users (who may be VPN users) is breached. This includes cases such
+ as:
+
+ - A site being connected into the "wrong" VPN.
+
+ - Traffic being replicated and sent to an unauthorized user.
+
+ - Two or more VPNs being improperly merged together.
+
+ - A point-to-point VPN connecting the wrong two points.
+
+ - Any packet or frame being improperly delivered outside the VPN to
+ which it belongs
+
+ Misconnection or cross-connection of VPNs may be caused by service
+ provider or equipment vendor error, or by the malicious action of an
+ attacker. The breach may be physical (e.g., PE-CE links
+ misconnected) or logical (e.g., improper device configuration).
+
+ Anecdotal evidence suggests that the cross-connection threat is one
+ of the largest security concerns of users (or would-be users).
+
+4.1.8. Attacks against Routing Protocols
+
+ This encompasses attacks against underlying routing protocols that
+ are run by the SP and that directly support the MPLS/GMPLS core.
+ (Attacks against the use of routing protocols for the distribution of
+ backbone routes are beyond the scope of this document.) Specific
+ attacks against popular routing protocols have been widely studied
+ and are described in [RFC4593].
+
+
+
+
+
+
+
+Fang Informational [Page 14]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+4.1.9. Other Attacks on Control Traffic
+
+ Besides routing and management protocols (covered separately in the
+ previous sections), a number of other control protocols may be
+ directly involved in delivering services by the MPLS/GMPLS core.
+ These include but may not be limited to:
+
+ - MPLS signaling (LDP, RSVP-TE) discussed above in subsections 4.1.4
+ and 4.1.3
+
+ - PCE signaling
+
+ - IPsec signaling (IKE and IKEv2)
+
+ - ICMP and ICMPv6
+
+ - L2TP
+
+ - BGP-based membership discovery
+
+ - Database-based membership discovery (e.g., RADIUS)
+
+ - Other protocols that may be important to the control
+ infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE.
+
+ Attacks might subvert or disrupt the activities of these protocols,
+ for example via impersonation or DoS.
+
+ Note that all of the data-plane attacks can also be carried out
+ against the packets of the control and management planes: insertion,
+ spoofing, replay, deletion, pattern analysis, and other attacks
+ mentioned above.
+
+4.2. Attacks on the Data Plane
+
+ This category encompasses attacks on the provider's or end-user's
+ data. Note that from the MPLS/GMPLS network end user's point of
+ view, some of this might be control-plane traffic, e.g., routing
+ protocols running from user site A to user site B via IP or non-IP
+ connections, which may be some type of VPN.
+
+4.2.1. Unauthorized Observation of Data Traffic
+
+ This refers to "sniffing" provider or end user packets and examining
+ their contents. This can result in exposure of confidential
+ information. It can also be a first step in other attacks (described
+ below) in which the recorded data is modified and re-inserted, or
+ simply replayed later.
+
+
+
+Fang Informational [Page 15]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+4.2.2. Modification of Data Traffic
+
+ This refers to modifying the contents of packets as they traverse the
+ MPLS/GMPLS core.
+
+4.2.3. Insertion of Inauthentic Data Traffic: Spoofing and Replay
+
+ Spoofing refers to sending a user packets or inserting packets into a
+ data stream that do not belong, with the objective of having them
+ accepted by the recipient as legitimate. Also included in this
+ category is the insertion of copies of once-legitimate packets that
+ have been recorded and replayed.
+
+4.2.4. Unauthorized Deletion of Data Traffic
+
+ This refers to causing packets to be discarded as they traverse the
+ MPLS/GMPLS networks. This is a specific type of denial-of-service
+ attack.
+
+4.2.5. Unauthorized Traffic Pattern Analysis
+
+ This refers to "sniffing" provider or user packets and examining
+ aspects or meta-aspects of them that may be visible even when the
+ packets themselves are encrypted. An attacker might gain useful
+ information based on the amount and timing of traffic, packet sizes,
+ source and destination addresses, etc. For most users, this type of
+ attack is generally considered to be significantly less of a concern
+ than the other types discussed in this section.
+
+4.2.6. Denial-of-Service Attacks
+
+ Denial-of-service (DoS) attacks are those in which an attacker
+ attempts to disrupt or prevent the use of a service by its legitimate
+ users. Taking network devices out of service, modifying their
+ configuration, or overwhelming them with requests for service are
+ several of the possible avenues for DoS attack.
+
+ Overwhelming the network with requests for service, otherwise known
+ as a "resource exhaustion" DoS attack, may target any resource in the
+ network, e.g., link bandwidth, packet forwarding capacity, session
+ capacity for various protocols, CPU power, table size, storage
+ overflows, and so on.
+
+ DoS attacks of the resource exhaustion type can be mounted against
+ the data plane of a particular provider or end user by attempting to
+ insert (spoofing) an overwhelming quantity of inauthentic data into
+ the provider or end-user's network from outside of the trusted zone.
+ Potential results might be to exhaust the bandwidth available to that
+
+
+
+Fang Informational [Page 16]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ provider or end user, or to overwhelm the cryptographic
+ authentication mechanisms of the provider or end user.
+
+ Data-plane resource exhaustion attacks can also be mounted by
+ overwhelming the service provider's general (MPLS/GMPLS-independent)
+ infrastructure with traffic. These attacks on the general
+ infrastructure are not usually an MPLS/GMPLS-specific issue, unless
+ the attack is mounted by another MPLS/GMPLS network user from a
+ privileged position. (For example, an MPLS/GMPLS network user might
+ be able to monopolize network data-plane resources and thus disrupt
+ other users.)
+
+ Many DoS attacks use amplification, whereby the attacker co-opts
+ otherwise innocent parties to increase the effect of the attack. The
+ attacker may, for example, send packets to a broadcast or multicast
+ address with the spoofed source address of the victim, and all of the
+ recipients may then respond to the victim.
+
+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.
+
+4.3. Attacks on Operation and Management Plane
+
+ Attacks on the Operation and Management plane have been discussed
+ extensively as general network security issues over the last 20
+ years. RFC 4778 [RFC4778] may serve as the best current operational
+ security practices in Internet Service Provider environments. RFC
+ 4377 [RFC4377] provided Operations and Management Requirements for
+ MPLS networks. See also the Security Considerations of RFC 4377 and
+ Section 7 of RFC 4378 [RFC4378].
+
+ Operation and Management across the MPLS-ICI could also be the source
+ of security threats on the provider infrastructure as well as the
+ service offered over the MPLS-ICI. A large volume of Operation and
+ Management messages could overwhelm the processing capabilities of an
+ ASBR if the ASBR is not properly protected. Maliciously generated
+
+
+
+Fang Informational [Page 17]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Operation and Management messages could also be used to bring down an
+ otherwise healthy service (e.g., MPLS Pseudowire), and therefore
+ affect service security. LSP ping does not support authentication
+ today, and that support should be a subject for future
+ considerations. Bidirectional Forwarding Detection (BFD), however,
+ does have support for carrying an authentication object. It also
+ supports Time-To-Live (TTL) processing as an anti-replay measure.
+ Implementations conformant with this MPLS-ICI should support BFD
+ authentication and must support the procedures for TTL processing.
+
+ Regarding GMPLS Operation and Management considerations in optical
+ interworking, there is a good discussion on security for management
+ interfaces to Network Elements [OIF-Sec-Mag].
+
+ Network elements typically have one or more (in some cases many)
+ Operation and Management interfaces used for network management,
+ billing and accounting, configuration, maintenance, and other
+ administrative activities.
+
+ Remote access to a network element through these Operation and
+ Management interfaces is frequently a requirement. Securing the
+ control protocols while leaving these Operation and Management
+ interfaces unprotected opens up a huge security vulnerability.
+ Network elements are an attractive target for intruders who want to
+ disrupt or gain free access to telecommunications facilities. Much
+ has been written about this subject since the 1980s. In the 1990s,
+ telecommunications facilities were identified in the U.S. and other
+ countries as part of the "critical infrastructure", and increased
+ emphasis was placed on thwarting such attacks from a wider range of
+ potentially well-funded and determined adversaries.
+
+ At one time, careful access controls and password management were a
+ sufficient defense, but are no longer. Networks using the TCP/IP
+ protocol suite are vulnerable to forged source addresses, recording
+ and later replay, packet sniffers picking up passwords, re-routing of
+ traffic to facilitate eavesdropping or tampering, active hijacking
+ attacks of TCP connections, and a variety of denial-of-service
+ attacks. The ease of forging TCP/IP packets is the main reason
+ network management protocols lacking strong security have not been
+ used to configure network elements (e.g., with the SNMP SET command).
+
+ Readily available hacking tools exist that let an eavesdropper on a
+ LAN take over one end of any TCP connection, so that the legitimate
+ party is cut off. In addition, enterprises and Service Providers in
+ some jurisdictions need to safeguard data about their users and
+ network configurations from prying. An attacker could eavesdrop and
+
+
+
+
+
+Fang Informational [Page 18]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ observe traffic to analyze usage patterns and map a network
+ configuration; an attacker could also gain access to systems and
+ manipulate configuration data or send malicious commands.
+
+ Therefore, in addition to authenticating the human user, more
+ sophisticated protocol security is needed for Operation and
+ Management interfaces, especially when they are configured over
+ TCP/IP stacks. Finally, relying on a perimeter defense, such as
+ firewalls, is insufficient protection against "insider attacks" or
+ against penetrations that compromise a system inside the firewall as
+ a launching pad to attack network elements. The insider attack is
+ discussed in the following session.
+
+4.4. Insider Attacks Considerations
+
+ The chain of trust model means that MPLS and GMPLS networks are
+ particularly vulnerable to insider attacks. These can be launched by
+ any malign person with access to any LSR in the trust domain.
+ Insider attacks could also be launched by compromised software within
+ the trust domain. Such attacks could, for example, advertise non-
+ existent resources, modify advertisements from other routers, request
+ unwanted LSPs that use network resources, or deny or modify
+ legitimate LSP requests.
+
+ Protection against insider attacks is largely for future study in
+ MPLS and GMPLS networks. Some protection can be obtained by
+ providing strict security for software upgrades and tight OAM access
+ control procedures. Further protection can be achieved by strict
+ control of user (i.e., operator) access to LSRs. Software change
+ management and change tracking (e.g., CVS diffs from text-based
+ configuration files) helps in spotting irregularities and human
+ errors. In some cases, configuration change approval processes may
+ also be warranted. Software tools could be used to check
+ configurations for consistency and compliance. Software tools may
+ also be used to monitor and report network behavior and activity in
+ order to quickly spot any irregularities that may be the result of an
+ insider attack.
+
+5. Defensive Techniques for MPLS/GMPLS Networks
+
+ The defensive techniques discussed in this document are intended to
+ describe methods by which some security threats can be addressed.
+ They are not intended as requirements for all MPLS/GMPLS
+ implementations. The MPLS/GMPLS provider should determine the
+ applicability of these techniques to the provider's specific service
+ offerings, and the end user may wish to assess the value of these
+ techniques to the user's service requirements. The operational
+ environment determines the security requirements. Therefore,
+
+
+
+Fang Informational [Page 19]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ protocol designers need to provide a full set of security services,
+ which can be used where appropriate.
+
+ The techniques discussed here include encryption, authentication,
+ filtering, firewalls, access control, isolation, aggregation, and
+ others.
+
+ Often, security is achieved by careful protocol design, rather than
+ by adding a security method. For example, one method of mitigating
+ DoS attacks is to make sure that innocent parties cannot be used to
+ amplify the attack. Security works better when it is "designed in"
+ rather than "added on".
+
+ Nothing is ever 100% secure. Defense therefore involves protecting
+ against those attacks that are most likely to occur or that have the
+ most direct consequences if successful. For those attacks that are
+ protected against, absolute protection is seldom achievable; 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 expend.
+
+ Successfully defending against an attack does not necessarily mean
+ the attack must be prevented from happening or from reaching its
+ target. In many cases, the network can instead be designed to
+ withstand the attack. For example, the introduction of inauthentic
+ packets could be defended against by preventing their introduction in
+ the first place, or by making it possible to identify and eliminate
+ them before delivery to the MPLS/GMPLS user's system. The latter is
+ frequently a much easier task.
+
+5.1. Authentication
+
+ To prevent security issues arising from some DoS attacks or from
+ malicious or accidental misconfiguration, it is critical that devices
+ in the MPLS/GMPLS should only accept connections or control messages
+ from valid sources. Authentication refers to methods to ensure that
+ message sources are properly identified by the MPLS/GMPLS devices
+ with which they communicate. This section focuses on identifying the
+ scenarios in which sender authentication is required and recommends
+ authentication mechanisms for these scenarios.
+
+ Cryptographic techniques (authentication, integrity, and encryption)
+ do not protect against some types of denial-of-service attacks,
+ specifically resource exhaustion attacks based on CPU or bandwidth
+ exhaustion. In fact, the software-based cryptographic processing
+ required to decrypt or check authentication may in some cases
+ increase the effect of these resource exhaustion attacks. With a
+ hardware cryptographic accelerator, attack packets can be dropped at
+ line speed without a cost to software cycles. Cryptographic
+
+
+
+Fang Informational [Page 20]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ techniques may, however, be useful against resource exhaustion
+ attacks based on the exhaustion of state information (e.g., TCP SYN
+ attacks).
+
+ The MPLS data plane, as presently defined, is not amenable to source
+ authentication, as there are no source identifiers in the MPLS packet
+ to authenticate. The MPLS label is only locally meaningful. It may
+ be assigned by a downstream node or upstream node for multicast
+ support.
+
+ When the MPLS payload carries identifiers that may be authenticated
+ (e.g., IP packets), authentication may be carried out at the client
+ level, but this does not help the MPLS SP, as these client
+ identifiers belong to an external, untrusted network.
+
+5.1.1. Management System Authentication
+
+ Management system authentication includes the authentication of a PE
+ to a centrally managed network management or directory server when
+ directory-based "auto-discovery" is used. It also includes
+ authentication of a CE to the configuration server, when a
+ configuration server system is used.
+
+ Authentication should be bidirectional, including PE or CE to
+ configuration server authentication for the PE or CE to be certain it
+ is communicating with the right server.
+
+5.1.2. Peer-to-Peer Authentication
+
+ Peer-to-peer authentication includes peer authentication for network
+ control protocols (e.g., LDP, BGP, etc.) and other peer
+ authentication (i.e., authentication of one IPsec security gateway by
+ another).
+
+ Authentication should be bidirectional, including PE or CE to
+ configuration server authentication for the PE or CE to be certain it
+ is communicating with the right server.
+
+ As indicated in Section 5.1.1, authentication should be
+ bidirectional.
+
+5.1.3. Cryptographic Techniques for Authenticating Identity
+
+ Cryptographic techniques offer several mechanisms for authenticating
+ the identity of devices or individuals. These include the use of
+ shared secret keys, one-time keys generated by accessory devices or
+ software, user-ID and password pairs, and a range of public-private
+
+
+
+
+Fang Informational [Page 21]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ key systems. Another approach is to use a hierarchical Certification
+ Authority system to provide digital certificates.
+
+ This section describes or provides references to the specific
+ cryptographic approaches for authenticating identity. These
+ approaches provide secure mechanisms for most of the authentication
+ scenarios required in securing an MPLS/GMPLS network.
+
+5.2. Cryptographic Techniques
+
+ MPLS/GMPLS defenses against a wide variety of attacks can be enhanced
+ by the proper application of cryptographic techniques. These same
+ cryptographic techniques are applicable to general network
+ communications and can provide confidentiality (encryption) of
+ communication between devices, authenticate the identities of the
+ devices, and detect whether the data being communicated has been
+ changed during transit or replayed from previous messages.
+
+ Several aspects of authentication are addressed in some detail in a
+ separate "Authentication" section (Section 5.1).
+
+ Cryptographic methods add complexity to a service and thus, for a few
+ reasons, may not be the most practical solution in every case.
+ Cryptography adds an additional computational burden to devices,
+ which may reduce the number of user connections that can be handled
+ on a device or otherwise reduce the capacity of the device,
+ potentially driving up the provider's costs. Typically, configuring
+ encryption services on devices adds to the complexity of their
+ configuration and adds labor cost. Some key management system is
+ usually needed. Packet sizes are typically increased when the
+ packets are encrypted or have integrity checks or replay counters
+ added, increasing the network traffic load and adding to the
+ likelihood of packet fragmentation with its increased overhead.
+ (This packet length increase can often be mitigated to some extent by
+ data compression techniques, but at the expense of additional
+ computational burden.) Finally, some providers may employ enough
+ other defensive techniques, such as physical isolation or filtering
+ and firewall techniques, that they may not perceive additional
+ benefit from encryption techniques.
+
+ Users may wish to provide confidentiality end to end. Generally,
+ encrypting for confidentiality must be accompanied with cryptographic
+ integrity checks to prevent certain active attacks against the
+ encrypted communications. On today's processors, encryption and
+ integrity checks run extremely quickly, but key management may be
+ more demanding in terms of both computational and administrative
+ overhead.
+
+
+
+
+Fang Informational [Page 22]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider,
+ and other parts of the network is a major element in determining the
+ applicability of cryptographic protection for any specific MPLS/GMPLS
+ implementation. In particular, it determines where cryptographic
+ protection should be applied:
+
+ - If the data path between the user's site and the provider's PE is
+ not trusted, then it may be used on the PE-CE link.
+
+ - If some part of the backbone network is not trusted, particularly
+ in implementations where traffic may travel across the Internet or
+ multiple providers' networks, then the PE-PE traffic may be
+ cryptographically protected. One also should consider cases where
+ L1 technology may be vulnerable to eavesdropping.
+
+ - If the user does not trust any zone outside of its premises, it
+ may require end-to-end or CE-CE cryptographic protection. This
+ fits within the scope of this MPLS/GMPLS security framework when
+ the CE is provisioned by the MPLS/GMPLS provider.
+
+ - If the user requires remote access to its site from a system at a
+ location that is not a customer location (for example, access by a
+ traveler), there may be a requirement for cryptographically
+ protecting the traffic between that system and an access point or
+ a customer's site. If the MPLS/GMPLS provider supplies the access
+ point, then the customer must cooperate with the provider to
+ handle the access control services for the remote users. These
+ access control services are usually protected cryptographically,
+ as well.
+
+ Access control usually starts with authentication of the entity. If
+ cryptographic services are part of the scenario, then it is important
+ to bind the authentication to the key management. Otherwise, the
+ protocol is vulnerable to being hijacked between the authentication
+ and key management.
+
+ Although CE-CE cryptographic protection can provide integrity and
+ confidentiality against third parties, if the MPLS/GMPLS provider has
+ complete management control over the CE (encryption) devices, then it
+ may be possible for the provider to gain access to the user's traffic
+ or internal network. Encryption devices could potentially be
+ reconfigured to use null encryption, bypass cryptographic processing
+ altogether, reveal internal configuration, or provide some means of
+ sniffing or diverting unencrypted traffic. Thus an implementation
+ using CE-CE encryption needs to consider the trust relationship
+ between the MPLS/GMPLS user and provider. MPLS/GMPLS users and
+ providers may wish to negotiate a service level agreement (SLA) for
+ CE-CE encryption that provides an acceptable demarcation of
+
+
+
+Fang Informational [Page 23]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ responsibilities for management of cryptographic protection on the CE
+ devices. The demarcation may also be affected by the capabilities of
+ the CE devices. For example, the CE might support some partitioning
+ of management, a configuration lock-down ability, or shared
+ capability to verify the configuration. In general, the MPLS/GMPLS
+ user needs to have a fairly high level of trust that the MPLS/GMPLS
+ provider will properly provision and manage the CE devices, if the
+ managed CE-CE model is used.
+
+5.2.1. IPsec in MPLS/GMPLS
+
+ IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411]
+ [IPSECME-ROADMAP] is the security protocol of choice for protection
+ at the IP layer. IPsec 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., by encapsulation) in order to use
+ IPsec. When the MPLS is encapsulating IP traffic, then IPsec covers
+ the encryption of the IP client layer; for non-IP client traffic, see
+ Section 5.2.4 (MPLS PWs).
+
+ In the MPLS/GMPLS model, IPsec can be employed to protect IP traffic
+ between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec
+ may be employed in either a provider-provisioned or a user-
+ provisioned model. Likewise, IPsec protection of data performed
+ within the user's site is outside the scope of this document, because
+ it is simply handled as user data by the MPLS/GMPLS core. However,
+ if the SP performs compression, pre-encryption will have a major
+ effect on that operation.
+
+ IPsec does not itself specify cryptographic algorithms. It can use a
+ variety of integrity or confidentiality algorithms (or even combined
+ integrity and confidentiality algorithms) with various key lengths,
+ such as AES encryption or AES message integrity checks. There are
+ trade-offs between key length, computational burden, and the level of
+ security of the encryption. A full discussion of these trade-offs is
+ beyond the scope of this document. In practice, any currently
+ recommended IPsec protection offers enough security to reduce the
+ likelihood of its being directly targeted by an attacker
+ substantially; other weaker links in the chain of security are likely
+ to be attacked first. MPLS/GMPLS users may wish to use a Service
+ Level Agreement (SLA) specifying the SP's responsibility for ensuring
+ data integrity and confidentiality, rather than analyzing the
+ specific encryption techniques used in the MPLS/GMPLS service.
+
+ Encryption algorithms generally come with two parameters: mode such
+ as Cipher Block Chaining and key length such as AES-192. (This
+ should not be confused with two other senses in which the word "mode"
+ is used: IPsec itself can be used in Tunnel Mode or Transport Mode,
+
+
+
+Fang Informational [Page 24]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ and IKE [version 1] uses Main Mode, Aggressive Mode, or Quick Mode).
+ It should be stressed that IPsec encryption without an integrity
+ check is a state of sin.
+
+ For many of the MPLS/GMPLS provider's network control messages and
+ some user requirements, cryptographic authentication of messages
+ without encryption of the contents of the message may provide
+ appropriate security. Using IPsec, authentication of messages is
+ provided by the Authentication Header (AH) or through the use of the
+ Encapsulating Security Protocol (ESP) with NULL encryption. Where
+ control messages require integrity but do not use IPsec, other
+ cryptographic authentication methods are often available. Message
+ authentication methods currently considered to be secure are based on
+ hashed message authentication codes (HMAC) [RFC2104] implemented with
+ a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1)
+ [RFC3174]. No attacks against HMAC SHA-1 are likely to play out in
+ the near future, but it is possible that people will soon find SHA-1
+ collisions. Thus, it is important that mechanisms be designed to be
+ flexible about the choice of hash functions and message integrity
+ checks. Also, many of these mechanisms do not include a convenient
+ way to manage and update keys.
+
+ A mechanism to provide a combination of confidentiality, data-origin
+ authentication, and connectionless integrity is the use of AES in GCM
+ (Counter with CBC-MAC) mode (RFC 4106) [RFC4106].
+
+5.2.2. MPLS / GMPLS Diffserv and IPsec
+
+ MPLS and GMPLS, which provide differentiated services based on
+ traffic type, may encounter some conflicts with IPsec encryption of
+ traffic. Because encryption hides the content of the packets, it may
+ not be possible to differentiate the encrypted traffic in the same
+ manner as unencrypted traffic. Although Diffserv markings are copied
+ to the IPsec header and can provide some differentiation, not all
+ traffic types can be accommodated by this mechanism. Using IPsec
+ without IKE or IKEv2 (the better choice) is not advisable. IKEv2
+ provides IPsec Security Association creation and management, entity
+ authentication, key agreement, and key update. It works with a
+ variety of authentication methods including pre-shared keys, public
+ key certificates, and EAP. If DoS attacks against IKEv2 are
+ considered an important threat to mitigate, the cookie-based anti-
+ spoofing feature of IKEv2 should be used. IKEv2 has its own set of
+ cryptographic methods, but any of the default suites specified in
+ [RFC4308] or [RFC4869] provides more than adequate security.
+
+
+
+
+
+
+
+Fang Informational [Page 25]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+5.2.3. Encryption for Device Configuration and Management
+
+ For configuration and management of MPLS/GMPLS devices, encryption
+ and authentication of the management connection at a level comparable
+ to that provided by IPsec is desirable.
+
+ Several methods of transporting MPLS/GMPLS device management traffic
+ offer authentication, integrity, and confidentiality.
+
+ - Secure Shell (SSH) offers protection for TELNET [STD8] or
+ terminal-like connections to allow device configuration.
+
+ - SNMPv3 [STD62] provides encrypted and authenticated protection for
+ SNMP-managed devices.
+
+ - Transport Layer Security (TLS) [RFC5246] and the closely-related
+ Secure Sockets Layer (SSL) are widely used for securing HTTP-based
+ communication, and thus can provide support for most XML- and
+ SOAP-based device management approaches.
+
+ - Since 2004, there has been extensive work proceeding in several
+ organizations (OASIS, W3C, WS-I, and others) on securing device
+ management traffic within a "Web Services" framework, using a wide
+ variety of security models, and providing support for multiple
+ security token formats, multiple trust domains, multiple signature
+ formats, and multiple encryption technologies.
+
+ - IPsec provides security services including integrity and
+ confidentiality at the network layer. With regards to device
+ management, its current use is primarily focused on in-band
+ management of user-managed IPsec gateway devices.
+
+ - There is recent work in the ISMS WG (Integrated Security Model for
+ SNMP Working Group) to define how to use SSH to secure SNMP, due
+ to the limited deployment of SNMPv3, and the possibility of using
+ Kerberos, particularly for interfaces like TELNET, where client
+ code exists.
+
+5.2.4. Security Considerations for MPLS Pseudowires
+
+ In addition to IP traffic, MPLS networks may be used to transport
+ other services such as Ethernet, ATM, Frame Relay, and TDM. This is
+ done by setting up pseudowires (PWs) that tunnel the native service
+ through the MPLS core by encapsulating at the edges. The PWE
+ architecture is defined in [RFC3985].
+
+
+
+
+
+
+Fang Informational [Page 26]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ PW tunnels may be set up using the PWE control protocol based on LDP
+ [RFC4447], and thus security considerations for LDP will most likely
+ be applicable to the PWE3 control protocol as well.
+
+ 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,
+ there is a four-byte control word (which is optional for some PW
+ types), followed by the native service payload. It must be stressed
+ that encapsulation of MPLS PW packets in IP for the purpose of
+ enabling use of IPsec mechanisms is not a valid option.
+
+ The following is a non-exhaustive list of PW-specific threats:
+
+ - Unauthorized setup of a PW (e.g., to gain access to a customer
+ network)
+
+ - Unauthorized teardown of a PW (thus causing denial of service)
+
+ - Malicious reroute of a PW
+
+ - Unauthorized observation of PW packets
+
+ - Traffic analysis of PW connectivity
+
+ - Unauthorized insertion of PW packets
+
+ - Unauthorized modification of PW packets
+
+ - Unauthorized deletion of PW packets replay of PW packets
+
+ - Denial of service or significant impact on PW service quality
+
+ These threats are not mutually exclusive, for example, rerouting can
+ be used for snooping or insertion/deletion/replay, etc. Multisegment
+ PWs introduce additional weaknesses at their stitching points.
+
+ The PW user plane suffers from the following inherent security
+ weaknesses:
+
+ - Since the PW label is the only identifier in the packet, there is
+ no authenticatable source address.
+
+ - Since guessing a valid PW label is not difficult, it is relatively
+ easy to introduce seemingly valid foreign packets.
+
+ - Since the PW packet is not self-describing, minor modification of
+ control-plane packets renders the data-plane traffic useless.
+
+
+
+
+Fang Informational [Page 27]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ - The control-word sequence number processing algorithm is
+ susceptible to a DoS attack.
+
+ The PWE control protocol introduces its own weaknesses:
+
+ - No (secure) peer autodiscovery technique has been standardized .
+
+ - PE authentication is not mandated, so an intruder can potentially
+ impersonate a PE; after impersonating a PE, unauthorized PWs may
+ be set up, consuming resources and perhaps allowing access to user
+ networks.
+
+ - Alternately, desired PWs may be torn down, giving rise to denial
+ of service.
+
+ The following characteristics of PWs can be considered security
+ strengths:
+
+ - The most obvious attacks require compromising edge or core routers
+ (although not necessarily those along the PW path).
+
+ - Adequate protection of the control-plane messaging is sufficient
+ to rule out many types of attacks.
+
+ - PEs are usually configured to reject MPLS packets from outside the
+ service provider network, thus ruling out insertion of PW packets
+ from the outside (since IP packets cannot masquerade as PW
+ packets).
+
+5.2.5. End-to-End versus Hop-by-Hop Protection Tradeoffs in MPLS/GMPLS
+
+ In MPLS/GMPLS, cryptographic protection could potentially be applied
+ to the MPLS/GMPLS traffic at several different places. This section
+ discusses some of the tradeoffs in implementing encryption in several
+ different connection topologies among different devices within an
+ MPLS/GMPLS network.
+
+ Cryptographic protection typically involves a pair of devices that
+ protect the traffic passing between them. The devices may be
+ directly connected (over a single "hop"), or intervening devices may
+ transport the protected traffic between the pair of devices. The
+ extreme cases involve using protection between every adjacent pair of
+ devices along a given path (hop-by-hop), or using protection only
+ between the end devices along a given path (end-to-end). To keep
+ this discussion within the scope of this document, the latter ("end-
+ to-end") case considered here is CE-to-CE rather than fully end-to-
+ end.
+
+
+
+
+Fang Informational [Page 28]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Figure 3 depicts a simplified topology showing the Customer Edge (CE)
+ devices, the Provider Edge (PE) devices, and a variable number (three
+ are shown) of Provider core (P) devices, which might be present along
+ the path between two sites in a single VPN operated by a single
+ service provider (SP).
+
+ Site_1---CE---PE---P---P---P---PE---CE---Site_2
+
+ Figure 3: Simplified Topology Traversing through MPLS/GMPLS Core
+
+ Within this simplified topology, and assuming that the P devices are
+ not involved with cryptographic protection, four basic, feasible
+ configurations exist for protecting connections among the devices:
+
+ 1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity
+ services between the two CE devices, so that traffic will be
+ protected throughout the SP's network.
+
+ 2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or
+ integrity services between the two PE devices. Unprotected
+ traffic is received at one PE from the customer's CE, then it is
+ protected for transmission through the SP's network to the other
+ PE, and finally it is decrypted or checked for integrity and sent
+ to the other CE.
+
+ 3) Access link (CE-to-PE) - Apply confidentiality or integrity
+ services between the CE and PE on each side or on only one side.
+
+ 4) Configurations 2 and 3 above can also be combined, with
+ confidentiality or integrity running from CE to PE, then PE to PE,
+ and then PE to CE.
+
+ Among the four feasible configurations, key tradeoffs in considering
+ encryption include:
+
+ - Vulnerability to link eavesdropping or tampering - assuming an
+ attacker can observe or modify data in transit on the links, would
+ it be protected by encryption?
+
+ - Vulnerability to device compromise - assuming an attacker can get
+ access to a device (or freely alter its configuration), would the
+ data be protected?
+
+ - Complexity of device configuration and management - given the
+ number of sites per VPN customer as Nce and the number of PEs
+ participating in a given VPN as Npe, how many device
+ configurations need to be created or maintained, and how do those
+ configurations scale?
+
+
+
+Fang Informational [Page 29]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ - Processing load on devices - how many cryptographic operations
+ must be performed given N packets? - This raises considerations of
+ device capacity and perhaps end-to-end delay.
+
+ - Ability of the SP to provide enhanced services (QoS, firewall,
+ intrusion detection, etc.) - Can the SP inspect the data to
+ provide these services?
+
+ These tradeoffs are discussed for each configuration, below:
+
+ 1) Site-to-site (CE-to-CE)
+
+ Link eavesdropping or tampering - protected on all links. Device
+ compromise - vulnerable to CE compromise.
+
+ Complexity - single administration, responsible for one device per
+ site (Nce devices), but overall configuration per VPN scales as
+ Nce**2.
+
+ Though the complexity may be reduced: 1) In practice, as Nce
+ grows, the number of VPNs falls off from being a full clique;
+ 2) If the CEs run an automated key management protocol, then
+ they should be able to set up and tear down secured VPNs
+ without any intervention.
+
+ Processing load - on each of the two CEs, each packet is
+ cryptographically processed (2P), though the protection may be
+ "integrity check only" or "integrity check plus encryption."
+
+ Enhanced services - severely limited; typically only Diffserv
+ markings are visible to the SP, allowing some QoS services.
+ The CEs could also use the IPv6 Flow Label to identify traffic
+ classes.
+
+ 2) Provider Edge-to-Edge (PE-to-PE)
+
+ Link eavesdropping or tampering - vulnerable on CE-PE links;
+ protected on SP's network links.
+
+ Device compromise - vulnerable to CE or PE compromise.
+
+ Complexity - single administration, Npe devices to configure.
+ (Multiple sites may share a PE device so Npe is typically much
+ smaller than Nce.) Scalability of the overall configuration
+ depends on the PPVPN type: if the cryptographic protection is
+ 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
+ combined.
+
+
+
+Fang Informational [Page 30]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Processing load - on each of the two PEs, each packet is
+ cryptographically processed (2P).
+
+ Enhanced services - full; SP can apply any enhancements based on
+ detailed view of traffic.
+
+ 3) Access Link (CE-to-PE)
+
+ Link eavesdropping or tampering - protected on CE-PE link;
+ vulnerable on SP's network links.
+
+ Device compromise - vulnerable to CE or PE compromise.
+
+ Complexity - two administrations (customer and SP) with device
+ configuration on each side (Nce + Npe devices to configure),
+ but because there is no mesh, the overall configuration scales
+ as Nce.
+
+ Processing load - on each of the two CEs, each packet is
+ cryptographically processed, plus on each of the two PEs, each
+ packet is cryptographically processed (4P).
+
+ Enhanced services - full; SP can apply any enhancements based on a
+ detailed view of traffic.
+
+ 4) Combined Access link and PE-to-PE (essentially hop-by-hop).
+
+ Link eavesdropping or tampering - protected on all links.
+
+ Device compromise - vulnerable to CE or PE compromise.
+
+ Complexity - two administrations (customer and SP) with device
+ configuration on each side (Nce + Npe devices to configure).
+ Scalability of the overall configuration depends on the PPVPN
+ type: If the cryptographic processing is 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 combined.
+
+ Processing load - on each of the two CEs, each packet is
+ cryptographically processed, plus on each of the two PEs, each
+ packet is cryptographically processed twice (6P).
+
+ Enhanced services - full; SP can apply any enhancements based on a
+ detailed view of traffic.
+
+
+
+
+
+
+
+Fang Informational [Page 31]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Given the tradeoffs discussed above, a few conclusions can be drawn:
+
+ - Configurations 2 and 3 are subsets of 4 that may be appropriate
+ alternatives to 4 under certain threat models; the remainder of
+ these conclusions compare 1 (CE-to-CE) versus 4 (combined access
+ links and PE-to-PE).
+
+ - If protection from link eavesdropping or tampering is all that is
+ important, then configurations 1 and 4 are equivalent.
+
+ - 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 PE devices, configuration 1 is better.
+
+ - If reducing complexity is most important, and the size of the
+ network is small, configuration 1 is better. Otherwise,
+ configuration 4 is better because rather than a mesh of CE
+ devices, it requires a smaller mesh of PE devices. Also, under
+ some PPVPN approaches, the scaling of 4 is further improved by
+ sharing the same PE-PE mesh across all VPN contexts. The scaling
+ advantage of 4 may be increased or decreased in any given
+ situation if the CE devices are simpler to configure than the PE
+ devices, or vice-versa.
+
+ - If the overall processing load is a key factor, then 1 is better,
+ unless the PEs come with a hardware encryption accelerator and the
+ CEs do not.
+
+ - If the availability of enhanced services support from the SP is
+ most important, then 4 is best.
+
+ - If users are concerned with having their VPNs misconnected with
+ other users' VPNs, then encryption with 1 can provide protection.
+
+ As a quick overall conclusion, CE-to-CE protection is better against
+ device compromise, but this comes at the cost of enhanced services
+ and at the cost of operational complexity due to the Order(n**2)
+ scaling of a larger mesh.
+
+ This analysis of site-to-site vs. hop-by-hop tradeoffs does not
+ explicitly include cases of multiple providers cooperating to provide
+ a PPVPN service, public Internet VPN connectivity, or remote access
+ VPN service, but many of the tradeoffs are similar.
+
+
+
+
+
+
+
+
+Fang Informational [Page 32]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ In addition to the simplified models, the following should also be
+ considered:
+
+ - There are reasons, perhaps, to protect a specific P-to-P or PE-
+ to-P.
+
+ - There may be reasons to do multiple encryptions over certain
+ segments. One may be using an encrypted wireless link under our
+ IPsec VPN to access an SSL-secured web site to download encrypted
+ email attachments: four layers.)
+
+ - It may be appropriate that, for example, cryptographic integrity
+ checks are applied end to end, and confidentiality is applied over
+ a shorter span.
+
+ - Different cryptographic protection may be required for control
+ protocols and data traffic.
+
+ - Attention needs to be given to how auxiliary traffic is protected,
+ e.g., the ICMPv6 packets that flow back during PMTU discovery,
+ among other examples.
+
+5.3. Access Control Techniques
+
+ Access control techniques include packet-by-packet or packet-flow-
+ 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 a
+ control, signaling, or management protocol. Enforcement of access
+ control by isolated infrastructure addresses is discussed in Section
+ 5.4 of this document.
+
+ In this document, we distinguish between filtering and firewalls
+ based primarily on the direction of traffic flow. We define
+ filtering as being applicable to unidirectional traffic, while a
+ firewall can analyze and control both sides of a conversation.
+
+ The definition has two significant corollaries:
+
+ - Routing or traffic flow symmetry: A firewall typically requires
+ routing symmetry, which is usually enforced by locating a firewall
+ where the network topology assures that both sides of a
+ conversation will pass through the firewall. A filter can operate
+ upon traffic flowing in one direction, without considering traffic
+ in the reverse direction. Beware that this concept could result
+ in a single point of failure.
+
+
+
+
+
+
+Fang Informational [Page 33]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ - Statefulness: Because it receives both sides of a conversation, a
+ firewall may be able to interpret a significant amount of
+ information concerning the state of that conversation and use this
+ information to control access. A filter can maintain some limited
+ state information on a unidirectional flow of packets, but cannot
+ determine the state of the bidirectional conversation as precisely
+ as a firewall.
+
+ For a general description on filtering and rate limiting for IP
+ networks, please also see [OPSEC-FILTER].
+
+5.3.1. Filtering
+
+ It is relatively common for routers to filter packets. That is,
+ routers can look for particular values in certain fields of the IP or
+ higher-level (e.g., TCP or UDP) headers. Packets matching the
+ criteria associated with a particular filter may either be discarded
+ or given special treatment. Today, not only routers, but most end
+ hosts have filters, and every instance of IPsec is also a filter
+ [RFC4301].
+
+ In discussing filters, it is useful to separate the filter
+ characteristics that may be used to determine whether a packet
+ matches a filter from the packet actions applied to those packets
+ matching a particular filter.
+
+ o Filter Characteristics
+
+ Filter characteristics or rules are used to determine whether a
+ particular packet or set of packets matches a particular filter.
+
+ In many cases, filter characteristics may be stateless. A stateless
+ filter determines whether a particular packet matches a filter based
+ solely on the filter definition, normal forwarding information (such
+ as the next hop for a packet), the interface on which a packet
+ arrived, and the contents of that individual packet. Typically,
+ stateless filters may consider the incoming and outgoing logical or
+ physical interface, information in the IP header, and information in
+ higher-layer headers such as the TCP or UDP header. Information in
+ the IP header to be considered may for example include source and
+ destination IP addresses; Protocol field, Fragment Offset, and TOS
+ field in IPv4; or Next Header, Extension Headers, Flow label, etc. in
+ IPv6. Filters also may consider fields in the TCP or UDP header such
+ as the Port numbers, the SYN field in the TCP header, as well as ICMP
+ and ICMPv6 type.
+
+
+
+
+
+
+Fang Informational [Page 34]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Stateful filtering maintains packet-specific state information to aid
+ in determining whether a filter rule has been met. For example, a
+ device might apply stateless filtering to the first fragment of a
+ fragmented IPv4 packet. If the filter matches, then the data unit ID
+ may be remembered and other fragments of the same packet may then be
+ considered to match the same filter. Stateful filtering is more
+ commonly done in firewalls, although firewall technology may be added
+ to routers. The data unit ID can also be a Fragment Extension Header
+ Identification field in IPv6.
+
+ o Actions based on Filter Results
+
+ If a packet, or a series of packets, matches a specific filter, then
+ a variety of actions may be taken based on that match. Examples of
+ such actions include:
+
+ - Discard
+
+ In many cases, filters are set to catch certain undesirable
+ packets. Examples may include packets with forged or invalid
+ source addresses, packets that are part of a DoS or Distributed
+ DoS (DDoS) attack, or packets trying to access unallowed
+ resources (such as network management packets from an
+ unauthorized source). Where such filters are activated, it is
+ common to discard the packet or set of packets matching the
+ filter silently. The discarded packets may of course also be
+ counted or logged.
+
+ - Set CoS
+
+ A filter may be used to set the class of service associated
+ with the packet.
+
+ - Count packets or bytes
+
+ - Rate Limit
+
+ In some cases, the set of packets matching a particular filter
+ may be limited to a specified bandwidth. In this case, packets
+ or bytes would be counted, and would be forwarded normally up
+ to the specified limit. Excess packets may be discarded or may
+ be marked (for example, by setting a "discard eligible" bit in
+ the IPv4 ToS field, or changing the EXP value to identify
+ traffic as being out of contract).
+
+
+
+
+
+
+
+Fang Informational [Page 35]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ - Forward and Copy
+
+ 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. For example, this may be used to implement a
+ lawful intercept capability or to feed selected packets to an
+ Intrusion Detection System.
+
+ o Other Packet Filters Issues
+
+ Filtering performance may vary widely according to implementation and
+ the types and number of rules. Without acceptable performance,
+ filtering is not useful.
+
+ The precise definition of "acceptable" may vary from SP to SP, and
+ may depend upon the intended use of the filters. For example, for
+ some uses, a filter may be turned on all the time to set CoS, to
+ prevent an attack, or to mitigate the effect of a possible future
+ attack. In this case, it is likely that the SP will want the filter
+ to have minimal or no impact on performance. In other cases, a
+ filter may be turned on only in response to a major attack (such as a
+ major DDoS attack). In this case, a greater performance impact may
+ be acceptable to some service providers.
+
+ A key consideration with the use of packet filters is that they can
+ provide few options for filtering packets carrying encrypted data.
+ Because the data itself is not accessible, only packet header
+ information or other unencrypted fields can be used for filtering.
+
+5.3.2. Firewalls
+
+ Firewalls provide a mechanism for controlling traffic passing between
+ different trusted zones in the MPLS/GMPLS model or between a trusted
+ zone and an untrusted zone. Firewalls typically provide much more
+ functionality than filters, because they may be able to apply
+ detailed analysis and logical functions to flows, and not just to
+ individual packets. They may offer a variety of complex services,
+ such as threshold-driven DoS attack protection, virus scanning,
+ acting as a TCP connection proxy, etc.
+
+ As with other access control techniques, the value of firewalls
+ depends on a clear understanding of the topologies of the MPLS/GMPLS
+ core network, the user networks, and the threat model. Their
+ effectiveness depends on a topology with a clearly defined inside
+ (secure) and outside (not secure).
+
+ Firewalls may be applied to help protect MPLS/GMPLS core network
+ functions from attacks originating from the Internet or from
+
+
+
+Fang Informational [Page 36]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ MPLS/GMPLS user sites, but typically other defensive techniques will
+ be used for this purpose.
+
+ Where firewalls are employed as a service to protect user VPN sites
+ from the Internet, different VPN users, and even different sites of a
+ single VPN user, may have varying firewall requirements. The overall
+ PPVPN logical and physical topology, along with the capabilities of
+ the devices implementing the firewall services, has a significant
+ effect on the feasibility and manageability of such varied firewall
+ service offerings.
+
+ Another consideration with the use of firewalls is that they can
+ provide few options for handling packets carrying encrypted data.
+ Because the data itself is not accessible, only packet header
+ information, other unencrypted fields, or analysis of the flow of
+ encrypted packets can be used for making decisions on accepting or
+ rejecting encrypted traffic.
+
+ Two approaches of using firewalls are to move the firewall outside of
+ the encrypted part of the path or to register and pre-approve the
+ encrypted session with the firewall.
+
+ Handling DoS attacks has become increasingly important. Useful
+ guidelines include the following:
+
+ 1. Perform ingress filtering everywhere.
+
+ 2. Be able to filter DoS attack packets at line speed.
+
+ 3. Do not allow oneself to amplify attacks.
+
+ 4. Continue processing legitimate traffic. Over provide for heavy
+ loads. Use diverse locations, technologies, etc.
+
+5.3.3. Access Control to Management Interfaces
+
+ Most of the security issues related to management interfaces can be
+ addressed through the use of authentication techniques as described
+ in the section on authentication (Section 5.1). However, additional
+ security may be provided by controlling access to management
+ interfaces in other ways.
+
+ The Optical Internetworking Forum has done relevant work on
+ protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc.
+ See "Security for Management Interfaces to Network Elements"
+ [OIF-SMI-01.0] and "Addendum to the Security for Management
+ Interfaces to Network Elements" [OIF-SMI-02.1]. See also the work in
+ the ISMS WG (http://datatracker.ietf.org/wg/isms/charter/).
+
+
+
+Fang Informational [Page 37]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Management interfaces, especially console ports on MPLS/GMPLS
+ devices, may be configured so they are only accessible out-of-band,
+ through a system that is physically or logically separated from the
+ rest of the MPLS/GMPLS infrastructure.
+
+ Where management interfaces are accessible in-band within the
+ MPLS/GMPLS domain, filtering or firewalling techniques can be used to
+ restrict unauthorized in-band traffic from having access to
+ management interfaces. Depending on device capabilities, these
+ filtering or firewalling techniques can be configured either on other
+ devices through which the traffic might pass, or on the individual
+ MPLS/GMPLS devices themselves.
+
+5.4. Use of Isolated Infrastructure
+
+ One way to protect the infrastructure used for support of MPLS/GMPLS
+ is to separate the resources for support of MPLS/GMPLS services from
+ the resources used for other purposes (such as support of Internet
+ services). In some cases, this may involve using physically separate
+ equipment for VPN services, or even a physically separate network.
+
+ For example, PE-based IPVPNs may be run on a separate backbone not
+ connected to the Internet, or may use separate edge routers from
+ those supporting Internet service. Private IPv4 addresses (local to
+ the provider and non-routable over the Internet) are sometimes used
+ to provide additional separation. For a discussion of comparable
+ techniques for IPv6, see "Local Network Protection for IPv6," RFC
+ 4864 [RFC4864].
+
+ In a GMPLS network, it is possible to operate the control plane using
+ physically separate resources from those used for the data plane.
+ This means that the data-plane resources can be physically protected
+ and isolated from other equipment to protect users' data while the
+ control and management traffic uses network resources that can be
+ accessed by operators to configure the network. Conversely, 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. However, 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
+
+ In general, it is not feasible to use a completely separate set of
+ resources for support of each service. In fact, one of the main
+ reasons for MPLS/GMPLS enabled services is to allow sharing of
+ resources between multiple services and multiple users. Thus, even
+ if certain services use a separate network from Internet services,
+
+
+
+Fang Informational [Page 38]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ nonetheless there will still be multiple MPLS/GMPLS users sharing the
+ same network resources. In some cases, MPLS/GMPLS services will
+ share network resources with Internet services or other services.
+
+ It is therefore important for MPLS/GMPLS services to provide
+ protection between resources used by different parties. Thus, a
+ well-behaved MPLS/GMPLS user should be protected from possible
+ misbehavior by other users. This requires several security
+ measurements to be implemented. Resource limits can be placed on a
+ per service and per user basis. Possibilities include, for example,
+ using a virtual router or logical router to define hardware or
+ software resource limits per service or per individual user; using
+ rate limiting per Virtual Routing and Forwarding (VRF) or per
+ Internet connection to provide bandwidth protection; or using
+ resource reservation for control-plane traffic. In addition to
+ bandwidth protection, separate resource allocation can be used to
+ limit security attacks only to directly impacted service(s) or
+ customer(s). Strict, separate, and clearly defined engineering rules
+ and provisioning procedures can reduce the risks of network-wide
+ impact of a control-plane attack, DoS attack, or misconfiguration.
+
+ In general, the use of aggregated infrastructure allows the service
+ provider to benefit from stochastic multiplexing of multiple bursty
+ flows, and also may in some cases thwart traffic pattern analysis by
+ combining the data from multiple users. However, service providers
+ must minimize security risks introduced from any individual service
+ or individual users.
+
+5.6. Service Provider Quality Control Processes
+
+ Deployment of provider-provisioned VPN services in general requires a
+ relatively large amount of configuration by the SP. For example, the
+ SP needs to configure which VPN each site belongs to, as well as QoS
+ and SLA guarantees. This large amount of required configuration
+ leads to the possibility of misconfiguration.
+
+ It is important for the SP to have operational processes in place to
+ reduce the potential impact of misconfiguration. CE-to-CE
+ authentication may also be used to detect misconfiguration when it
+ occurs. CE-to-CE encryption may also limit the damage when
+ misconfiguration occurs.
+
+5.7. Deployment of Testable MPLS/GMPLS Service
+
+ This refers to solutions that can be readily tested to make sure they
+ are configured correctly. For example, for a point-to-point
+ connection, checking that the intended connectivity is working pretty
+
+
+
+
+Fang Informational [Page 39]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ much ensures that there is no unintended connectivity to some other
+ 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 if there is an attack on the control plane,
+ data-plane connectivity test mechanisms that rely on the control
+ plane can also be attacked. This may hide faults through false
+ positives or disrupt functioning services through false negatives.
+
+6. Monitoring, Detection, and Reporting of Security Attacks
+
+ MPLS/GMPLS network and service may be subject to attacks from a
+ variety of security threats. Many threats are described in Section 4
+ of this document. Many of the defensive techniques described in this
+ document and elsewhere provide significant levels of protection from
+ a variety of threats. However, in addition to employing defensive
+ techniques silently to protect against attacks, MPLS/GMPLS services
+ can also add value for both providers and customers by implementing
+ security monitoring systems to detect and report on any security
+ attacks, regardless of whether the attacks are effective.
+
+ Attackers often begin by probing and analyzing defenses, so systems
+ that can detect and properly report these early stages of attacks can
+ provide significant benefits.
+
+ Information concerning attack incidents, especially if available
+ quickly, can be useful in defending against further attacks. It can
+ be used to help identify attackers or their specific targets at an
+ early stage. This knowledge about attackers and targets can be used
+ to strengthen defenses against specific attacks or attackers, or to
+ improve the defenses for specific targets on an as-needed basis.
+ Information collected on attacks may also be useful in identifying
+ and developing defenses against novel attack types.
+
+ Monitoring systems used to detect security attacks in MPLS/GMPLS
+ typically operate by collecting information from the Provider Edge
+ (PE), Customer Edge (CE), and/or Provider backbone (P) devices.
+ Security monitoring systems should have the ability to actively
+ retrieve information from devices (e.g., SNMP get) or to passively
+ receive reports from devices (e.g., SNMP notifications). The systems
+ may actively retrieve information from devices (e.g., SNMP get) or
+ passively receive reports from devices (e.g., SNMP notifications).
+
+
+
+Fang Informational [Page 40]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ The specific information exchanged depends on the capabilities of the
+ devices and on the type of VPN technology. Particular care should be
+ given to securing the communications channel between the monitoring
+ systems and the MPLS/GMPLS devices.
+
+ The CE, PE, and P devices should employ efficient methods to acquire
+ and communicate the information needed by the security monitoring
+ systems. It is important that the communication method between
+ MPLS/GMPLS devices and security monitoring systems be designed so
+ that it will not disrupt network operations. As an example, multiple
+ attack events may be reported through a single message, rather than
+ allowing each attack event to trigger a separate message, which might
+ result in a flood of messages, essentially becoming a DoS attack
+ against the monitoring system or the network.
+
+
+ The mechanisms for reporting security attacks should be flexible
+ enough to meet the needs of MPLS/GMPLS service providers, MPLS/GMPLS
+ customers, and regulatory agencies, if applicable. The specific
+ reports should depend on the capabilities of the devices, the
+ security monitoring system, the type of VPN, and the service level
+ agreements between the provider and customer.
+
+ While SNMP/syslog type monitoring and detection mechanisms can detect
+ some attacks (usually resulting from flapping protocol adjacencies,
+ CPU overload scenarios, etc.), other techniques, such as netflow-
+ based traffic fingerprinting, are needed for more detailed detection
+ and reporting.
+
+ With netflow-based traffic fingerprinting, each packet that is
+ forwarded within a device is examined for a set of IP packet
+ attributes. These attributes are the IP packet identity or
+ fingerprint of the packet and determine if the packet is unique or
+ similar to other packets.
+
+ The flow information is extremely useful for understanding network
+ behavior, and detecting and reporting security attacks:
+
+ - Source address allows the understanding of who is originating the
+ traffic.
+
+ - Destination address tells who is receiving the traffic.
+
+ - Ports characterize the application utilizing the traffic.
+
+ - Class of service examines the priority of the traffic.
+
+
+
+
+
+Fang Informational [Page 41]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ - The device interface tells how traffic is being utilized by the
+ network device.
+
+ - Tallied packets and bytes show the amount of traffic.
+
+ - Flow timestamps allow the understanding of the life of a flow;
+ timestamps are useful for calculating packets and bytes per
+ second.
+
+ - Next-hop IP addresses including BGP routing Autonomous Systems
+ (ASes).
+
+ - Subnet mask for the source and destination addresses are for
+ calculating prefixes.
+
+ - TCP flags are useful for examining TCP handshakes.
+
+7. Service Provider General Security Requirements
+
+ This section covers security requirements the provider may have for
+ securing its MPLS/GMPLS network infrastructure including LDP and
+ RSVP-TE-specific requirements.
+
+ The MPLS/GMPLS service provider's requirements defined here are for
+ the MPLS/GMPLS core in the reference model. The core network can be
+ implemented with different types of network technologies, and each
+ core network may use different technologies to provide the various
+ services to users with different levels of offered security.
+ Therefore, an MPLS/GMPLS service provider may fulfill any number of
+ the security requirements listed in this section. This document does
+ not state that an MPLS/GMPLS network must fulfill all of these
+ requirements to be secure.
+
+ These requirements are focused on: 1) how to protect the MPLS/GMPLS
+ core from various attacks originating outside the core including
+ those from network users, both accidentally and maliciously, and 2)
+ how to protect the end users.
+
+7.1. Protection within the Core Network
+
+7.1.1. Control-Plane Protection - General
+
+ - Filtering spoofed infrastructure IP addresses at edges
+
+ Many attacks on protocols running in a core involve spoofing a source
+ IP address of a node in the core (e.g., TCP-RST attacks). It makes
+ sense to apply anti-spoofing filtering at edges, e.g., using strict
+ unicast reverse path forwarding (uRPF) [RFC3704] and/or by preventing
+
+
+
+Fang Informational [Page 42]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ the use of infrastructure addresses as source. If this is done
+ comprehensively, the need to cryptographically secure these protocols
+ is smaller. See [BACKBONE-ATTKS] for more elaborate description.
+
+ - Protocol authentication within the core
+
+ The network infrastructure must support mechanisms for authentication
+ of the control-plane messages. If an MPLS/GMPLS core is used, LDP
+ sessions may be authenticated with TCP MD5. In addition, IGP and BGP
+ authentication should be considered. For a core providing various
+ IP, VPN, or transport services, PE-to-PE authentication may also be
+ performed via IPsec. See the above discussion of protocol security
+ services: authentication, integrity (with replay detection), and
+ confidentiality. Protocols need to provide a complete set of
+ security services from which the SP can choose. Also, the important
+ but often more difficult part is key management. Considerations,
+ guidelines, and strategies regarding key management are discussed in
+ [RFC3562], [RFC4107], [RFC4808].
+
+ With today's processors, applying cryptographic authentication to the
+ control plane may not increase the cost of deployment for providers
+ significantly, and will help to improve the security of the core. If
+ the core is dedicated to MPLS/GMPLS enabled services without any
+ interconnects to third parties, then this may reduce the requirement
+ for authentication of the core control plane.
+
+ - Infrastructure Hiding
+
+ Here we discuss means to hide the provider's infrastructure nodes.
+ An MPLS/GMPLS provider may make its infrastructure routers (P and PE)
+ unreachable from outside users and unauthorized internal users. For
+ example, separate address space may be used for the infrastructure
+ loopbacks.
+
+ Normal TTL propagation may be altered to make the backbone look like
+ one hop from the outside, but caution needs to be taken for loop
+ prevention. This prevents the backbone addresses from being exposed
+ through trace route; however, this must also be assessed against
+ operational requirements for end-to-end fault tracing.
+
+ An Internet backbone core may be re-engineered to make Internet
+ routing an edge function, for example, by using MPLS label switching
+ for all traffic within the core and possibly making the Internet a
+ VPN within the PPVPN core itself. This helps to detach Internet
+ access from PPVPN services.
+
+ Separating control-plane, data-plane, and management-plane
+ functionality in hardware and software may be implemented on the PE
+
+
+
+Fang Informational [Page 43]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ devices to improve security. This may help to limit the problems
+ when attacked in one particular area, and may allow each plane to
+ implement additional security measures separately.
+
+ PEs are often more vulnerable to attack than P routers, because PEs
+ cannot be made unreachable from outside users by their very nature.
+ Access to core trunk resources can be controlled on a per-user basis
+ by using of inbound rate limiting or traffic shaping; this can be
+ further enhanced on a per-class-of-service basis (see Section 8.2.3)
+
+ In the PE, using separate routing processes for different services,
+ for example, Internet and PPVPN service, may help to improve the
+ PPVPN security and better protect VPN customers. Furthermore, if
+ resources, such as CPU and memory, can be further separated based on
+ applications, or even individual VPNs, it may help to provide
+ improved security and reliability to individual VPN customers.
+
+7.1.2. Control-Plane Protection with RSVP-TE
+
+ - General RSVP Security Tools
+
+ Isolation of the trusted domain is an important security mechanism
+ for RSVP, to ensure that an untrusted element cannot access a router
+ of the trusted domain. However, ASBR-ASBR communication for inter-AS
+ LSPs needs to be secured specifically. Isolation mechanisms might
+ also be bypassed by an IPv4 Router Alert or IPv6 using Next Header 0
+ packets. A solution could consist of disabling the processing of IP
+ options. This drops or ignores all IP packets with IPv4 options,
+ including the router alert option used by RSVP; however, this may
+ have an impact on other protocols using IPv4 options. An alternative
+ is to configure access-lists on all incoming interfaces dropping IPv4
+ protocol or IPv6 next header 46 (RSVP).
+
+ RSVP security can be strengthened by deactivating RSVP on interfaces
+ with neighbors who are not authorized to use RSVP, to protect against
+ adjacent CE-PE attacks. However, this does not really protect
+ against DoS attacks or attacks on non-adjacent routers. It has been
+ demonstrated that substantial CPU resources are consumed simply by
+ processing received RSVP packets, even if the RSVP process is
+ deactivated for the specific interface on which the RSVP packets are
+ received.
+
+ RSVP neighbor filtering at the protocol level, to restrict the set of
+ neighbors that can send RSVP messages to a given router, protects
+ against non-adjacent attacks. However, this does not protect against
+ DoS attacks and does not effectively protect against spoofing of the
+ source address of RSVP packets, if the filter relies on the
+ neighbor's address within the RSVP message.
+
+
+
+Fang Informational [Page 44]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ RSVP neighbor filtering at the data-plane level, with an access list
+ to accept IP packets with port 46 only for specific neighbors,
+ requires Router Alert mode to be deactivated and does not protect
+ against spoofing.
+
+ Another valuable tool is RSVP message pacing, to limit the number of
+ RSVP messages sent to a given neighbor during a given period. This
+ allows blocking DoS attack propagation.
+
+ - Another approach is to limit the impact of an attack on control-
+ plane resources.
+
+ To ensure continued effective operation of the MPLS router even in
+ the case of an attack that bypasses packet filtering mechanisms such
+ as Access Control Lists in the data plane, it is important that
+ routers have some mechanisms to limit the impact of the attack.
+ There should be a mechanism to rate limit the amount of control-plane
+ traffic addressed to the router, per interface. This should be
+ configurable on a per-protocol basis, (and, ideally, on a per-sender
+ basis) to avoid letting an attacked protocol or a given sender block
+ all communications. This requires the ability to filter and limit
+ the rate of incoming messages of particular protocols, such as RSVP
+ (filtering at the IP protocol level), and particular senders. In
+ addition, there should be a mechanism to limit CPU and memory
+ capacity allocated to RSVP, so as to protect other control-plane
+ elements. To limit memory allocation, it will probably be necessary
+ to limit the number of LSPs that can be 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
+ protection against RSVP-based attacks. It applies cryptographic
+ authentication to 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 cryptographic protection can help here. IPsec can
+ also be used in some cases (see [RFC4230]).
+
+ 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
+
+
+
+Fang Informational [Page 45]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ 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
+
+ The approaches to protect MPLS routers against LDP-based attacks are
+ similar to those for RSVP, including isolation, protocol deactivation
+ on specific interfaces, filtering of LDP neighbors at the protocol
+ level, filtering of LDP neighbors at the data-plane level (with an
+ access list that filters the TCP and UDP LDP ports), authentication
+ with a message digest, rate limiting of LDP messages per protocol per
+ sender, and limiting all resources allocated to LDP-related tasks.
+ LDP protection could be considered easier in a certain sense. UDP
+ port matching may be sufficient for LDP protection. Router alter
+ options and beyond might be involved in RSVP protection.
+
+7.1.4. Data-Plane Protection
+
+ IPsec can provide authentication, integrity, confidentiality, and
+ replay detection for provider or user data. It also has an
+ associated key management protocol.
+
+ In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is
+ not provided as a basic feature. Mechanisms described in Section 5
+ can be used to secure the MPLS data-plane traffic carried over an
+ MPLS core. Both the Frame Relay Forum and the ATM Forum standardized
+ cryptographic security services in the late 1990s, but these
+ standards are not widely implemented.
+
+7.2. Protection on the User Access Link
+
+ Peer or neighbor protocol authentication may be used to enhance
+ security. For example, BGP MD5 authentication may be used to enhance
+ security on PE-CE links using eBGP. In the case of inter-provider
+ connections, cryptographic protection mechanisms, such as IPsec, may
+ be used between ASes.
+
+ If multiple services are provided on the same PE platform, different
+ WAN address spaces may be used for different services (e.g., VPN and
+ non-VPN) to enhance isolation.
+
+ Firewall and Filtering: access control mechanisms can be used to
+ filter any packets destined for the service provider's infrastructure
+ prefix or eliminate routes identified as illegitimate. Filtering
+ should also be applied to prevent sourcing packets with
+ infrastructure IP addresses from outside.
+
+
+
+
+Fang Informational [Page 46]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Rate limiting may be applied to the user interface/logical interfaces
+ as a defense against DDoS bandwidth attack. This is helpful when the
+ PE device is supporting both multiple services, especially VPN and
+ Internet Services, on the same physical interfaces through different
+ logical interfaces.
+
+7.2.1. Link Authentication
+
+ Authentication can be used to validate site access to the network via
+ fixed or logical connections, e.g., L2TP or IPsec, respectively. If
+ the user wishes to hold the authentication credentials for access,
+ then provider solutions require the flexibility for either direct
+ authentication by the PE itself or interaction with a customer
+ authentication server. Mechanisms are required in the latter case to
+ ensure that the interaction between the PE and the customer
+ authentication server is appropriately secured.
+
+7.2.2. Access Routing Control
+
+ Choice of routing protocols, e.g., RIP, OSPF, or BGP, may be used to
+ provide control access between a CE and a PE. Per-neighbor and per-
+ VPN routing policies may be established to enhance security and
+ reduce the impact of a malicious or non-malicious attack on the PE;
+ the following mechanisms, in particular, should be considered:
+
+ - Limiting the number of prefixes that may be advertised on a per-
+ access basis into the PE. Appropriate action may be taken should
+ a limit be exceeded, e.g., the PE shutting down the peer session
+ to the CE
+
+ - Applying route dampening at the PE on received routing updates
+
+ - Definition of a per-VPN prefix limit after which additional
+ prefixes will not be added to the VPN routing table.
+
+ In the case of inter-provider connection, access protection, link
+ authentication, and routing policies as described above may be
+ applied. Both inbound and outbound firewall or filtering mechanisms
+ between ASes may be applied. Proper security procedures must be
+ implemented in inter-provider interconnection to protect the
+ providers' network infrastructure and their customers. This may be
+ custom designed for each inter-provider peering connection, and must
+ be agreed upon by both providers.
+
+
+
+
+
+
+
+
+Fang Informational [Page 47]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+7.2.3. Access QoS
+
+ MPLS/GMPLS providers offering QoS-enabled services require mechanisms
+ to ensure that individual accesses are validated against their
+ subscribed QoS profile and as such gain access to core resources that
+ match their service profile. Mechanisms such as per-class-of-service
+ rate limiting or traffic shaping on ingress to the MPLS/GMPLS core
+ are two options for providing this level of control. Such mechanisms
+ may require the per-class-of-service profile to be enforced either by
+ marking, remarking, or discarding of traffic outside of the profile.
+
+7.2.4. Customer Service Monitoring Tools
+
+ End users needing specific statistics on the core, e.g., routing
+ table, interface status, or QoS statistics, place requirements on
+ mechanisms at the PE both to validate the incoming user and limit the
+ views available to that particular user. Mechanisms should also be
+ considered to ensure that such access cannot be used as means to
+ construct a DoS attack (either maliciously or accidentally) on the PE
+ itself. This could be accomplished either through separation of
+ these resources within the PE itself or via the capability to rate
+ limiting, which is performed on the basis of each physical interface
+ or each logical connection.
+
+7.3. General User Requirements for MPLS/GMPLS Providers
+
+ MPLS/GMPLS providers must support end users' security requirements.
+ Depending on the technologies used, these requirements may include:
+
+ - User control plane separation through routing isolation when
+ applicable, for example, in the case of MPLS VPNs.
+
+ - Protection against intrusion, DoS attacks, and spoofing
+
+ - Access Authentication
+
+ - Techniques highlighted throughout this document that identify
+ methodologies for the protection of resources and the MPLS/GMPLS
+ infrastructure.
+
+ Hardware or software errors in equipment leading to breaches in
+ security are not within the scope of this document.
+
+8. Inter-Provider Security Requirements
+
+ This section discusses security capabilities that are important at
+ the MPLS/GMPLS inter-provider connections and at devices (including
+ ASBR routers) supporting these connections. The security
+
+
+
+Fang Informational [Page 48]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ capabilities stated in this section should be considered as
+ complementary to security considerations addressed in individual
+ protocol specifications or security frameworks.
+
+ Security vulnerabilities and exposures may be propagated across
+ multiple networks because of security vulnerabilities arising in one
+ peer's network. Threats to security originate from accidental,
+ administrative, and intentional sources. Intentional threats include
+ events such as spoofing and denial-of-service (DoS) attacks.
+
+ The level and nature of threats, as well as security and availability
+ requirements, may vary over time and from network to network. This
+ section, therefore, discusses capabilities that need to be available
+ in equipment deployed for support of the MPLS InterCarrier
+ Interconnect (MPLS-ICI). Whether any particular capability is used
+ in any one specific instance of the ICI is up to the service
+ providers managing the PE equipment offering or using the ICI
+ services.
+
+8.1. Control-Plane Protection
+
+ This section discusses capabilities for control-plane protection,
+ including protection of routing, signaling, and OAM capabilities.
+
+8.1.1. Authentication of Signaling Sessions
+
+ Authentication may be needed for signaling sessions (i.e., BGP, LDP,
+ and RSVP-TE) and routing sessions (e.g., BGP), as well as OAM
+ sessions across domain boundaries. Equipment must be able to support
+ the exchange of all protocol messages over IPsec ESP, with NULL
+ encryption and authentication, between the peering ASBRs. Support
+ for message authentication for LDP, BGP, and RSVP-TE authentication
+ must also be provided. Manual keying of IPsec should not be used.
+ IKEv2 with pre-shared secrets or public key methods should be used.
+ Replay detection should be used.
+
+ Mechanisms to authenticate and validate a dynamic setup request 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 whether
+ the LSP source is who it claims to be and that it is allowed to
+ connect to the destination.
+
+ Message authentication support for all TCP-based protocols within the
+ scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and
+ Message authentication with the RSVP-TE Integrity Object must be
+ provided to interoperate with current practices. Equipment should be
+ able to support the exchange of all signaling and routing (LDP, RSVP-
+ TE, and BGP) protocol messages over a single IPsec association pair
+
+
+
+Fang Informational [Page 49]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ in tunnel or transport mode with authentication but with NULL
+ encryption, between the peering ASBRs. IPsec, if supported, must be
+ supported with HMAC-SHA-1 and alternatively with HMAC-SHA-2 and
+ optionally SHA-1. It is expected that authentication algorithms will
+ evolve over time and support can be updated as needed.
+
+ OAM operations across the MPLS-ICI could also be the source of
+ security threats on the provider infrastructure as well as the
+ service offered over the MPLS-ICI. A large volume of OAM messages
+ could overwhelm the processing capabilities of an ASBR if the ASBR is
+ not properly protected. Maliciously generated OAM messages could
+ also be used to bring down an otherwise healthy service (e.g., MPLS
+ Pseudowire), and therefore affect service security. LSP ping does
+ not support authentication today, and that support should be a
+ subject for future consideration. Bidirectional Forwarding Detection
+ (BFD), however, does have support for carrying an authentication
+ object. It also supports Time-To-Live (TTL) processing as an anti-
+ replay measure. Implementations conformant with this MPLS-ICI should
+ support BFD authentication and must support the procedures for TTL
+ processing.
+
+8.1.2. Protection Against DoS Attacks in the Control Plane
+
+ Implementations must have the ability to prevent signaling and
+ routing DoS attacks on the control plane per interface and provider.
+ Such prevention may be provided by rate limiting signaling and
+ routing messages that can be sent by a peer provider according to a
+ traffic profile and by guarding against malformed packets.
+
+ Equipment must provide the ability to filter signaling, routing, and
+ OAM packets destined for the device, and must provide the ability to
+ rate limit such packets. Packet filters should be capable of being
+ separately applied per interface, and should have minimal or no
+ performance impact. For example, this allows an operator to filter
+ or rate limit signaling, routing, and OAM messages that can be sent
+ by a peer provider and limit such traffic to a given profile.
+
+ During a control-plane DoS attack against an ASBR, the router should
+ guarantee sufficient resources to allow network operators to execute
+ network management commands to take corrective action, such as
+ turning on additional filters or disconnecting an interface under
+ attack. DoS attacks on the control plane should not adversely affect
+ data-plane performance.
+
+ Equipment running BGP must support the ability to limit the number of
+ BGP routes received from any particular peer. Furthermore, in the
+ case of IPVPN, a router must be able to limit the number of routes
+
+
+
+
+Fang Informational [Page 50]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ learned from a BGP peer per IPVPN. In the case that a device has
+ multiple BGP peers, it should be possible for the limit to vary
+ between peers.
+
+8.1.3. Protection against Malformed Packets
+
+ Equipment should be robust in the presence of malformed protocol
+ packets. For example, malformed routing, signaling, and OAM packets
+ should be treated in accordance with the relevant protocol
+ specification.
+
+8.1.4. Ability to Enable/Disable Specific Protocols
+
+ Equipment must have the ability to drop any signaling or routing
+ protocol messages when these messages are to be processed by the ASBR
+ but the corresponding protocol is not enabled on that interface.
+
+ Equipment must allow an administrator to enable or disable a protocol
+ (by default, the protocol is disabled unless administratively
+ enabled) on an interface basis.
+
+ Equipment must be able to drop any signaling or routing protocol
+ messages when these messages are to be processed by the ASBR but the
+ corresponding protocol is not enabled on that interface. This
+ dropping should not adversely affect data-plane or control-plane
+ performance.
+
+8.1.5. Protection against Incorrect Cross Connection
+
+ The capability to detect and locate faults in an LSP cross-connect
+ must be provided. Such faults may cause security violations as they
+ result in directing traffic to the wrong destinations. This
+ capability may rely on OAM functions. Equipment must support MPLS
+ LSP ping [RFC4379]. This may be used to verify end-to-end
+ connectivity for the LSP (e.g., PW, TE Tunnel, VPN LSP, etc.), and to
+ verify PE-to-PE connectivity for IPVPN services.
+
+ When routing information is advertised from one domain to the other,
+ operators must be able to guard against situations that result in
+ traffic hijacking, black-holing, resource stealing (e.g., number of
+ routes), etc. For instance, in the IPVPN case, an operator must be
+ able to block routes based on associated route target attributes. In
+ addition, mechanisms to defend against routing protocol attack must
+ exist to verify whether a route advertised by a peer for a given VPN
+ is actually a valid route and whether the VPN has a site attached to
+ or reachable through that domain.
+
+
+
+
+
+Fang Informational [Page 51]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Equipment (ASBRs and Route Reflectors (RRs)) supporting operation of
+ BGP must be able to restrict which route target attributes are sent
+ to and accepted from a BGP peer across an ICI. Equipment (ASBRs,
+ RRs) should also be able to inform the peer regarding which route
+ target attributes it will accept from a peer, because sending an
+ incorrect route target can result in an incorrect cross-connection of
+ VPNs. Also, sending inappropriate route targets to a peer may
+ disclose confidential information. This is another example of
+ defense against routing protocol attacks.
+
+8.1.6. Protection against Spoofed Updates and Route Advertisements
+
+ Equipment must support route filtering of routes received via a BGP
+ peer session by applying policies that include one or more of the
+ following: AS path, BGP next hop, standard community, or extended
+ community.
+
+8.1.7. Protection of Confidential Information
+
+ The 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
+ OAM messages or LSP ping messages) is required. SPs must have the
+ flexibility to handle these messages at the ASBR.
+
+ Equipment should be able to identify and restrict where it sends
+ messages that can reveal confidential information about network
+ operation (e.g., performance OAM messages, LSP Traceroute messages).
+ Service Providers must have the flexibility to handle these messages
+ at the ASBR. For example, equipment supporting LSP Traceroute may
+ limit to which addresses replies can be sent. Note that this
+ capability should be used with care. For example, if an SP chooses
+ to prohibit the exchange of LSP ping messages at the ICI, it may make
+ it more difficult to debug incorrect cross-connection of LSPs or
+ other problems.
+
+ An SP may decide to progress these messages if they arrive from a
+ trusted provider and are targeted to specific, agreed-on addresses.
+ Another provider may decide to traffic police, reject, or apply other
+ policies to these messages. Solutions must enable providers to
+ control the information that is relayed to another provider about the
+ path that an LSP takes. For example, when using the RSVP-TE record
+ route object or LSP ping / trace, a provider must be able to control
+ the information contained in corresponding messages when sent to
+ another provider.
+
+
+
+
+
+
+Fang Informational [Page 52]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+8.1.8. Protection against Over-provisioned Number of RSVP-TE
+ LSPs and Bandwidth Reservation
+
+ In addition to the control-plane protection mechanisms listed in the
+ previous section on control-plane protection with RSVP-TE, the ASBR
+ must be able both to limit the number of LSPs that can be set up by
+ other domains and to limit the amount of bandwidth that can be
+ reserved. A provider's ASBR may deny an LSP setup request or a
+ bandwidth reservation request sent by another provider's whose limits
+ have been reached.
+
+8.2. Data-Plane Protection
+
+8.2.1. Protection against DoS in the Data Plane
+
+ This is described in Section 5 of this document.
+
+8.2.2. Protection against Label Spoofing
+
+ Equipment must be able to verify that a label received across an
+ interconnect was actually assigned to an LSP arriving across that
+ interconnect. If a label not assigned to an LSP arrives at this
+ router from the correct neighboring provider, the packet must be
+ dropped. This verification can be applied to the top label only.
+ The top label is the received top label and every label that is
+ exposed by label popping is to be used for forwarding decisions.
+
+ Equipment must provide the capability to drop MPLS-labeled packets if
+ all labels in the stack are not processed. This lets SPs guarantee
+ that every label that enters its domain from another carrier is
+ actually assigned to that carrier.
+
+ The following requirements are not directly reflected in this
+ document but must be used as guidance for addressing further work.
+
+ Solutions must NOT force operators to reveal reachability information
+ to routers within their domains. Note that it is believed that this
+ requirement is met via other requirements specified in this section
+ plus the normal operation of IP routing, which does not reveal
+ individual hosts.
+
+ Mechanisms to authenticate and validate a dynamic setup request 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 whether
+ the LSP source is who it claims to be and that it is allowed to
+ connect to the destination.
+
+
+
+
+
+Fang Informational [Page 53]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+8.2.3. Protection Using Ingress Traffic Policing and Enforcement
+
+ The following simple diagram illustrates a potential security issue
+ on the data plane across an MPLS interconnect:
+
+ SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1
+ | | | |
+ |< AS2 >|<MPLS interconnect>|< AS1 >|
+
+ Traffic flow direction is from SP2 to SP1
+
+ In the case of downstream label assignment, the transit label used by
+ ASBR2 is allocated by ASBR1, which in turn advertises it to ASBR2
+ (downstream unsolicited or on-demand); this label is used for a
+ service context (VPN label, PW VC label, etc.), and this LSP is
+ normally terminated at a forwarding table belonging to the service
+ instance on PE (PE1) in SP1.
+
+ In the example above, ASBR1 would not know whether the label of an
+ incoming packet from ASBR2 over the interconnect is a VPN label or
+ PSN label for AS1. So it is possible (though unlikely) that ASBR2
+ can be accidentally or intentionally configured such that the
+ incoming label could match a PSN label (e.g., LDP) in AS1. Then,
+ this LSP would end up on the global plane of an infrastructure router
+ (P or PE1), and this could invite a unidirectional attack on that P
+ or PE1 where the LSP terminates.
+
+ To mitigate this threat, implementations should be able to do a
+ forwarding path look-up for the label on an incoming packet from an
+ interconnect in a Label Forwarding Information Base (LFIB) space that
+ is only intended for its own service context or provide a mechanism
+ on the data plane that would ensure the incoming labels are what
+ ASBR1 has allocated and advertised.
+
+ A similar concept has been proposed in "Requirements for Multi-
+ Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [RFC5254].
+
+ When using upstream label assignment, the upstream source must be
+ identified and authenticated so the labels can be accepted as from a
+ trusted source.
+
+9. Summary of MPLS and GMPLS Security
+
+ The following summary provides a quick checklist of MPLS and GMPLS
+ security threats, defense techniques, and the best-practice outlines
+ for MPLS and GMPLS deployment.
+
+
+
+
+
+Fang Informational [Page 54]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+9.1. MPLS and GMPLS Specific Security Threats
+
+9.1.1. Control-Plane Attacks
+
+ Types of attacks on the control plane:
+
+ - Unauthorized LSP creation
+
+ - LSP message interception
+
+ Attacks against RSVP-TE: DoS attacks that set up unauthorized LSP
+ and/or LSP messages.
+
+ Attacks against LDP: DoS attack with storms of LDP Hello messages or
+ LDP TCP SYN messages.
+
+ Attacks may be launched from external or internal sources, or through
+ an SP's management systems.
+
+ Attacks may be targeted at the SP's routing protocols or
+ infrastructure elements.
+
+ In general, control protocols may be attacked by:
+
+ - MPLS signaling (LDP, RSVP-TE)
+
+ - PCE signaling
+
+ - IPsec signaling (IKE and IKEv2)
+
+ - ICMP and ICMPv6
+
+ - L2TP
+
+ - BGP-based membership discovery
+
+ - Database-based membership discovery (e.g., RADIUS)
+
+ - OAM and diagnostic protocols such as LSP ping and LMP
+
+ - Other protocols that may be important to the control
+ infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE
+
+
+
+
+
+
+
+
+
+Fang Informational [Page 55]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+9.1.2. Data-Plane Attacks
+
+ - Unauthorized observation of data traffic
+
+ - Data-traffic modification
+
+ - Spoofing and replay
+
+ - Unauthorized deletion
+
+ - Unauthorized traffic-pattern analysis
+
+ - Denial of Service
+
+9.2. Defense Techniques
+
+ 1) Authentication:
+
+ - Bidirectional authentication
+
+ - Key management
+
+ - Management system authentication
+
+ - Peer-to-peer authentication
+
+ 2) Cryptographic techniques
+
+ 3) Use of IPsec in MPLS/GMPLS networks
+
+ 4) Encryption for device configuration and management
+
+ 5) Cryptographic techniques for MPLS pseudowires
+
+ 6) End-to-End versus Hop-by-Hop protection (CE-CE, PE-PE, PE-CE)
+
+ 7) Access control techniques
+
+ - Filtering
+
+ - Firewalls
+
+ - Access Control to management interfaces
+
+ 8) Infrastructure isolation
+
+ 9) Use of aggregated infrastructure
+
+
+
+
+Fang Informational [Page 56]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ 10) Quality control processes
+
+ 11) Testable MPLS/GMPLS service
+
+ 12) End-to-end connectivity verification
+
+ 13) Hop-by-hop resource configuration verification and discovery
+
+9.3. Service Provider MPLS and GMPLS Best-Practice Outlines
+
+9.3.1. SP Infrastructure Protection
+
+ 1) General control-plane protection
+
+ - Filtering out infrastructure source addresses at edges
+
+ - Protocol authentication within the core
+
+ - Infrastructure hiding (e.g., disable TTL propagation)
+
+ 2) RSVP control-plane protection
+
+ - RSVP security tools
+
+ - Isolation of the trusted domain
+
+ - Deactivating RSVP on interfaces with neighbors who are not
+ authorized to use RSVP
+
+ - RSVP neighbor filtering at the protocol level and data-plane
+ level
+
+ - Authentication for RSVP messages
+
+ - RSVP message pacing
+
+ 3) LDP control-plane protection (similar techniques as for RSVP)
+
+ 4) Data-plane protection
+
+ - User access link protection
+
+ - Link authentication
+
+ - Access routing control (e.g., prefix limits, route dampening,
+ routing table limits (such as VRF limits)
+
+ - Access QoS control
+
+
+
+Fang Informational [Page 57]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ - Customer service monitoring tools
+
+ - Use of LSP 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
+
+ Inter-provider connections are high security risk areas. Similar
+ techniques and procedures as described for SP's general core
+ protection are listed below for inter-provider connections.
+
+ 1) Control-plane protection at inter-provider connections
+
+ - Authentication of signaling sessions
+
+ - Protection against DoS attacks in the control plane
+
+ - Protection against malformed packets
+
+ - Ability to enable/disable specific protocols
+
+ - Protection against incorrect cross connection
+
+ - Protection against spoofed updates and route advertisements
+
+ - Protection of confidential information
+
+ - Protection against an over-provisioned number of RSVP-TE LSPs
+ and bandwidth reservation
+
+ 2) Data-plane protection at the inter-provider connections
+
+ - Protection against DoS in the data plane
+
+ - Protection against label spoofing
+
+ For MPLS VPN interconnections [RFC4364], in practice, inter-AS option
+ a), VRF-to-VRF connections at the AS (Autonomous System) border, is
+ commonly used for inter-provider connections. Option c), Multi-hop
+ EBGP redistribution of labeled VPN-IPv4 routes between source and
+ destination ASes with EBGP redistribution of labeled IPv4 routes from
+ AS to a neighboring AS, on the other hand, is not normally used for
+ inter-provider connections due to higher security risks. For more
+ details, please see [RFC4111].
+
+
+
+
+
+Fang Informational [Page 58]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+10. Security Considerations
+
+ Security considerations constitute the sole subject of this memo and
+ hence are discussed throughout. Here we recap what has been
+ presented and explain at a high level the role of each type of
+ consideration in an overall secure MPLS/GMPLS system.
+
+ The document describes a number of potential security threats. Some
+ of these threats have already been observed occurring in running
+ networks; others are largely hypothetical at this time.
+
+ DoS attacks and intrusion attacks from the Internet against an SPs'
+ infrastructure have been seen. DoS "attacks" (typically not
+ malicious) have also been seen in which CE equipment overwhelms PE
+ equipment with high quantities or rates of packet traffic or routing
+ information. Operational or provisioning errors are cited by SPs as
+ one of their prime concerns.
+
+ The document describes a variety of defensive techniques that may be
+ used to counter the suspected threats. All of the techniques
+ presented involve mature and widely implemented technologies that are
+ practical to implement.
+
+ The document describes the importance of detecting, monitoring, and
+ reporting attacks, both successful and unsuccessful. These
+ activities are essential for "understanding one's enemy", mobilizing
+ new defenses, and obtaining metrics about how secure the MPLS/GMPLS
+ network is. As such, they are vital components of any complete PPVPN
+ security system.
+
+ The document evaluates MPLS/GMPLS security requirements from a
+ customer's perspective as well as from a service provider's
+ perspective. These sections re-evaluate the identified threats from
+ the perspectives of the various stakeholders and are meant to assist
+ equipment vendors and service providers, who must ultimately decide
+ what threats to protect against in any given configuration or service
+ offering.
+
+11. References
+
+11.1. Normative References
+
+ [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
+ Cryptographic Authentication", RFC 2747, January
+ 2000.
+
+
+
+
+
+
+Fang Informational [Page 59]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
+ "Multiprotocol Label Switching Architecture", RFC
+ 3031, January 2001.
+
+ [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
+ Authentication -- Updated Message Type Value", RFC
+ 3097, April 2001.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
+ Srinivasan, V., and G. Swallow, "RSVP-TE:
+ Extensions to RSVP for LSP Tunnels", RFC 3209,
+ December 2001.
+
+ [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Architecture", RFC 3945, October
+ 2004.
+
+ [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter
+ Mode (GCM) in IPsec Encapsulating Security Payload
+ (ESP)", RFC 4106, June 2005.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
+ December 2005.
+
+ [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+ Protocol", RFC 4306, December 2005.
+
+ [RFC4309] Housley, R., "Using Advanced Encryption Standard
+ (AES) CCM Mode with IPsec Encapsulating Security
+ Payload (ESP)", RFC 4309, December 2005.
+
+ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
+ Private Networks (VPNs)", RFC 4364, February 2006.
+
+ [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
+ Protocol Label Switched (MPLS) Data Plane
+ Failures", RFC 4379, February 2006.
+
+ [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith,
+ T., and G. Heron, "Pseudowire Setup and Maintenance
+ Using the Label Distribution Protocol (LDP)", RFC
+ 4447, April 2006.
+
+
+
+
+
+
+Fang Informational [Page 60]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
+ Requirements for Encapsulating Security Payload
+ (ESP) and Authentication Header (AH)", RFC 4835,
+ April 2007.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246,
+ August 2008.
+
+ [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
+ Ed., "LDP Specification", RFC 5036, October 2007.
+
+ [STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An
+ Architecture for Describing Simple Network
+ Management Protocol (SNMP) Management Frameworks",
+ STD 62, RFC 3411, December 2002.
+
+ Case, J., Harrington, D., Presuhn, R., and B.
+ Wijnen, "Message Processing and Dispatching for the
+ Simple Network Management Protocol (SNMP)", STD 62,
+ RFC 3412, December 2002.
+
+ Levi, D., Meyer, P., and B. Stewart, "Simple
+ Network Management Protocol (SNMP) Applications",
+ STD 62, RFC 3413, December 2002.
+
+ Blumenthal, U. and B. Wijnen, "User-based Security
+ Model (USM) for version 3 of the Simple Network
+ Management Protocol (SNMPv3)", STD 62, RFC 3414,
+ December 2002.
+
+ Wijnen, B., Presuhn, R., and K. McCloghrie, "View-
+ based Access Control Model (VACM) for the Simple
+ Network Management Protocol (SNMP)", STD 62, RFC
+ 3415, December 2002.
+
+ Presuhn, R., Ed., "Version 2 of the Protocol
+ Operations for the Simple Network Management
+ Protocol (SNMP)", STD 62, RFC 3416, December 2002.
+
+ Presuhn, R., Ed., "Transport Mappings for the
+ Simple Network Management Protocol (SNMP)", STD 62,
+ RFC 3417, December 2002.
+
+ Presuhn, R., Ed., "Management Information Base
+ (MIB) for the Simple Network Management Protocol
+ (SNMP)", STD 62, RFC 3418, December 2002.
+
+
+
+
+Fang Informational [Page 61]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ [STD8] Postel, J. and J. Reynolds, "Telnet Protocol
+ Specification", STD 8, RFC 854, May 1983.
+
+ Postel, J. and J. Reynolds, "Telnet Option
+ Specifications", STD 8, RFC 855, May 1983.
+
+11.2. Informative References
+
+ [OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces
+ to Network Elements", Optical Internetworking
+ Forum, Sept. 2003.
+
+ [OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for
+ Management Interfaces to Network Elements", Optical
+ Internetworking Forum, March 2006.
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+ Keyed-Hashing for Message Authentication", RFC
+ 2104, February 1997.
+
+ [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP
+ Security Document Roadmap", RFC 2411, November
+ 1998.
+
+ [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash
+ Algorithm 1 (SHA1)", RFC 3174, September 2001.
+
+ [RFC3562] Leech, M., "Key Management Considerations for the
+ TCP MD5 Signature Option", RFC 3562, July 2003.
+
+ [RFC3631] Bellovin, S., Ed., Schiller, J., Ed., and C.
+ Kaufman, Ed., "Security Mechanisms for the
+ Internet", RFC 3631, December 2003.
+
+ [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
+ Multihomed Networks", BCP 84, RFC 3704, March 2004.
+
+ [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire
+ Emulation Edge-to-Edge (PWE3) Architecture", RFC
+ 3985, March 2005.
+
+ [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
+ Cryptographic Key Management", BCP 107, RFC 4107,
+ June 2005.
+
+ [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
+ Provider-Provisioned Virtual Private Networks
+ (PPVPNs)", RFC 4110, July 2005.
+
+
+
+Fang Informational [Page 62]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ [RFC4111] Fang, L., Ed., "Security Framework for Provider-
+ Provisioned Virtual Private Networks (PPVPNs)", RFC
+ 4111, July 2005.
+
+ [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
+ Properties", RFC 4230, December 2005.
+
+ [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC
+ 4308, December 2005.
+
+ [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and
+ S. Matsushima, "Operations and Management (OAM)
+ Requirements for Multi-Protocol Label Switched
+ (MPLS) Networks", RFC 4377, February 2006.
+
+ [RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework
+ for Multi-Protocol Label Switching (MPLS)
+ Operations and Management (OAM)", RFC 4378,
+ February 2006.
+
+ [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic
+ Threats to Routing Protocols", RFC 4593, October
+ 2006.
+
+ [RFC4778] Kaeo, M., "Operational Security Current Practices
+ in Internet Service Provider Environments", RFC
+ 4778, January 2007.
+
+ [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
+ RFC 4808, March 2007.
+
+ [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter,
+ B., and E. Klein, "Local Network Protection for
+ IPv6", RFC 4864, May 2007.
+
+ [RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic
+ Suites for IPsec", RFC 4869, May 2007.
+
+ [RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini,
+ Ed., "Requirements for Multi-Segment Pseudowire
+ Emulation Edge-to-Edge (PWE3)", RFC 5254, October
+ 2008.
+
+ [MFA-MPLS-ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical
+ Specification," IP/MPLS Forum 19.0.0, April 2008.
+
+
+
+
+
+
+Fang Informational [Page 63]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ [OIF-Sec-Mag] R. Esposito, R. Graveman, and B. Hazzard, "Security
+ for Management Interfaces to Network Elements,"
+ OIF-SMI-01.0, September 2003.
+
+ [BACKBONE-ATTKS] Savola, P., "Backbone Infrastructure Attacks and
+ Protections", Work in Progress, January 2007.
+
+ [OPSEC-FILTER] Morrow, C., Jones, G., and V. Manral, "Filtering
+ and Rate Limiting Capabilities for IP Network
+ Infrastructure", Work in Progress, July 2007.
+
+ [IPSECME-ROADMAP] Frankel, S. and S. Krishnan, "IP Security (IPsec)
+ and Internet Key Exchange (IKE) Document Roadmap",
+ Work in Progress, May 2010.
+
+ [OPSEC-EFFORTS] Lonvick, C. and D. Spak, "Security Best Practices
+ Efforts and Documents", Work in Progress, May 2010.
+
+ [RSVP-key] Behringer, M. and F. Le Faucheur, "Applicability of
+ Keying Methods for RSVP Security", Work in
+ Progress, June 2009.
+
+12. Acknowledgements
+
+ The authors and contributors would also like to acknowledge the
+ helpful comments and suggestions from Sam Hartman, Dimitri
+ Papadimitriou, Kannan Varadhan, Stephen Farrell, Mircea Pisica, Scott
+ Brim in particular for his comments and discussion through GEN-ART
+ review,as well as Suresh Krishnan for his GEN-ART review and
+ comments. The authors would like to thank Sandra Murphy and Tim Polk
+ for their comments and help through Security AD review, thank Pekka
+ Savola for his comments through ops-dir review, and Amanda Baber for
+ her IANA review.
+
+ This document has used relevant content from RFC 4111 "Security
+ Framework of Provider Provisioned VPN for Provider-Provisioned
+ Virtual Private Networks (PPVPNs)" [RFC4111]. We acknowledge the
+ authors of RFC 4111 for the valuable information and text.
+
+ Authors:
+
+ Luyuan Fang, Ed., Cisco Systems, Inc.
+ Michael Behringer, Cisco Systems, Inc.
+ Ross Callon, Juniper Networks
+ Richard Graveman, RFG Security, LLC
+ J. L. Le Roux, France Telecom
+ Raymond Zhang, British Telecom
+ Paul Knight, Individual Contributor
+
+
+
+Fang Informational [Page 64]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Yaakov Stein, RAD Data Communications
+ Nabil Bitar, Verizon
+ Monique Morrow, Cisco Systems, Inc.
+ Adrian Farrel, Old Dog Consulting
+
+ As a design team member for the MPLS Security Framework, Jerry Ash
+ also made significant contributions to this document.
+
+13. Contributors' Contact Information
+
+ Michael Behringer
+ Cisco Systems, Inc.
+ Village d'Entreprises Green Side
+ 400, Avenue Roumanille, Batiment T 3
+ 06410 Biot, Sophia Antipolis
+ FRANCE
+ EMail: mbehring@cisco.com
+
+ Ross Callon
+ Juniper Networks
+ 10 Technology Park Drive
+ Westford, MA 01886
+ USA
+ EMail: rcallon@juniper.net
+
+ Richard Graveman
+ RFG Security
+ 15 Park Avenue
+ Morristown, NJ 07960
+ EMail: rfg@acm.org
+
+ Jean-Louis Le Roux
+ France Telecom
+ 2, avenue Pierre-Marzin
+ 22307 Lannion Cedex
+ FRANCE
+ EMail: jeanlouis.leroux@francetelecom.com
+
+ Raymond Zhang
+ British Telecom
+ BT Center
+ 81 Newgate Street
+ London, EC1A 7AJ
+ United Kingdom
+ EMail: raymond.zhang@bt.com
+
+
+
+
+
+
+Fang Informational [Page 65]
+
+RFC 5920 MPLS/GMPLS Security Framework July 2010
+
+
+ Paul Knight
+ 39 N. Hancock St.
+ Lexington, MA 02420
+ EMail: paul.the.knight@gmail.com
+
+ Yaakov (Jonathan) Stein
+ RAD Data Communications
+ 24 Raoul Wallenberg St., Bldg C
+ Tel Aviv 69719
+ ISRAEL
+ EMail: yaakov_s@rad.com
+
+ Nabil Bitar
+ Verizon
+ 40 Sylvan Road
+ Waltham, MA 02145
+ EMail: nabil.bitar@verizon.com
+
+ Monique Morrow
+ Glatt-com
+ CH-8301 Glattzentrum
+ Switzerland
+ EMail: mmorrow@cisco.com
+
+ Adrian Farrel
+ Old Dog Consulting
+ EMail: adrian@olddog.co.uk
+
+Editor's Address
+
+ Luyuan Fang (editor)
+ Cisco Systems, Inc.
+ 300 Beaver Brook Road
+ Boxborough, MA 01719
+ USA
+ EMail: lufang@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fang Informational [Page 66]
+