Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5920

Security Framework for MPLS and GMPLS Networks

Pages: 66
Part 3 of 3 – Pages 42 to 66
First   Prev   None

Top   ToC   RFC5920 - Page 42   prevText

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   ToC   RFC5920 - 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

   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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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

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   ToC   RFC5920 - 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

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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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

   [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   ToC   RFC5920 - 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   ToC   RFC5920 - 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   ToC   RFC5920 - 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

   [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

   [MFA-MPLS-ICI]    N. Bitar, "MPLS InterCarrier Interconnect Technical
                     Specification," IP/MPLS Forum 19.0.0, April 2008.
Top   ToC   RFC5920 - 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   ToC   RFC5920 - 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: Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA EMail: Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 EMail: Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: Raymond Zhang British Telecom BT Center 81 Newgate Street London, EC1A 7AJ United Kingdom EMail:
Top   ToC   RFC5920 - Page 66
   Paul Knight
   39 N. Hancock St.
   Lexington, MA 02420

   Yaakov (Jonathan) Stein
   RAD Data Communications
   24 Raoul Wallenberg St., Bldg C
   Tel Aviv  69719

   Nabil Bitar
   40 Sylvan Road
   Waltham, MA 02145

   Monique Morrow
   CH-8301 Glattzentrum

   Adrian Farrel
   Old Dog Consulting

Editor's Address

Luyuan Fang (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: