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.
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]. 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.
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.
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.
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.
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. 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.
Section 5 of this document.
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.
10) Quality control processes 11) Testable MPLS/GMPLS service 12) End-to-end connectivity verification 13) Hop-by-hop resource configuration verification and discovery
- 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. 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].
[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. [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. 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.
Paul Knight 39 N. Hancock St. Lexington, MA 02420 EMail: email@example.com Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL EMail: firstname.lastname@example.org Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 EMail: email@example.com Monique Morrow Glatt-com CH-8301 Glattzentrum Switzerland EMail: firstname.lastname@example.org Adrian Farrel Old Dog Consulting EMail: email@example.com