tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5920

 
 
 

Security Framework for MPLS and GMPLS Networks

Part 3 of 3, p. 42 to 66
Prev RFC Part

 


prevText      Top      Up      ToC       Page 42 
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

Top      Up      ToC       Page 43 
   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

Top      Up      ToC       Page 44 
   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.

Top      Up      ToC       Page 45 
   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

Top      Up      ToC       Page 46 
   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.

Top      Up      ToC       Page 47 
   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.

Top      Up      ToC       Page 48 
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

Top      Up      ToC       Page 49 
   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

Top      Up      ToC       Page 50 
   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

Top      Up      ToC       Page 51 
   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.

Top      Up      ToC       Page 52 
   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.

Top      Up      ToC       Page 53 
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.

Top      Up      ToC       Page 54 
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.

Top      Up      ToC       Page 55 
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

Top      Up      ToC       Page 56 
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

Top      Up      ToC       Page 57 
   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

Top      Up      ToC       Page 58 
      -  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].

Top      Up      ToC       Page 59 
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.

Top      Up      ToC       Page 60 
   [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.

Top      Up      ToC       Page 61 
   [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.

Top      Up      ToC       Page 62 
   [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.

Top      Up      ToC       Page 63 
   [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.

Top      Up      ToC       Page 64 
   [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

Top      Up      ToC       Page 65 
   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

Top      Up      ToC       Page 66 
   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