RFC 5920
Security Framework for MPLS and GMPLS Networks
Pages: 66
Informational
Informational
Part 3 of 3 – Pages 42 to 66
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
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
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.
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
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.
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.
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
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
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
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.
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.
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.
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.
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
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 Service9.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
10) Quality control processes 11) Testable MPLS/GMPLS service 12) End-to-end connectivity verification 13) Hop-by-hop resource configuration verification and discovery9.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
- 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].
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.
[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.
[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.
[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.
[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.
[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
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
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.ukEditor's Address
Luyuan Fang (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: lufang@cisco.com