--- 1/draft-ietf-mpls-tp-security-framework-03.txt 2012-07-15 00:14:10.761841866 +0200 +++ 2/draft-ietf-mpls-tp-security-framework-04.txt 2012-07-15 00:14:10.809842238 +0200 @@ -1,23 +1,23 @@ Internet Engineering Task Force L. Fang, Ed. Internet-Draft Cisco Systems Intended status: Informational B. Niven-Jenkins, Ed. -Expires: September 25, 2012 Velocix +Expires: January 14, 2013 Velocix S. Mansfield, Ed. Ericsson R. Graveman, Ed. RFG Security - March 26, 2012 + July 14, 2012 MPLS-TP Security Framework - draft-ietf-mpls-tp-security-framework-03 + draft-ietf-mpls-tp-security-framework-04 Abstract This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new OAM capabilities, a transport- oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats, @@ -46,21 +46,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 25, 2012. + This Internet-Draft will expire on January 15, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, @@ -82,32 +82,32 @@ 2.1. Security Reference Model 1 . . . . . . . . . . . . . . . . 7 2.2. Security Reference Model 2 . . . . . . . . . . . . . . . . 9 2.3. Security Reference Model 3 . . . . . . . . . . . . . . . . 12 2.4. Trusted Zone Boundaries . . . . . . . . . . . . . . . . . 13 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Attacks on the Control Plane . . . . . . . . . . . . . . . 16 3.2. Attacks on the Data Plane . . . . . . . . . . . . . . . . 17 4. Security Requirements for MPLS-TP . . . . . . . . . . . . . 17 5. Defensive Techniques for MPLS-TP Networks . . . . . . . . . . 19 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 19 - 5.1.1. Management System Authentication . . . . . . . . . . . 19 + 5.1.1. Management System Authentication . . . . . . . . . . . 20 5.1.2. Peer-to-Peer Authentication . . . . . . . . . . . . . 20 5.1.3. Cryptographic Techniques for Authenticating Identity . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Access Control Techniques . . . . . . . . . . . . . . . . 20 5.3. Use of Isolated Infrastructure . . . . . . . . . . . . . . 21 5.4. Use of Aggregated Infrastructure . . . . . . . . . . . . . 21 - 5.5. Protection against Denial of Service . . . . . . . . 21 + 5.5. Mitigation of Denial of Service Attacks . . . . . . . . . 21 5.6. Verification of Connectivity . . . . . . . . . . . . . . . 21 - 6. Monitoring, Detection, and Reporting of Security Attacks . . . 21 + 6. Monitoring, Detection, and Reporting of Security Attacks . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction 1.1. Background and Motivation This document provides a security framework for Multiprotocol Label @@ -166,21 +166,21 @@ operations security considerations. This document does not define the specific mechanisms or methods that must be implemented to satisfy the security requirements. The issues and areas addressed with respect to MPLS-TP security are: o Attacks against G-Ach integrity, availability, or confidentiality o Misuse of G-Ach to attack data plane resources -o ID Spoofing attacks +o ID spoofing attacks o Attacks against the loopback mechanism and Authentication TLV o Attacks against the network management system (NMS) o NMS and CP interaction vulnerabilities o MIP and MEP assignment and attacks on these mechanisms o Topology discovery vulnerabilities @@ -564,34 +564,34 @@ + In the case in which dynamic provisioning is used, the attacks occur on the dynamic control plane. Most aspects of these are addressed in [RFC5920]. b. Attacks against user's connectivity. These are similar to PE/CE attacks against access in typical MPLS networks and are addressed in [RFC5920]. 4. Probes of a provider's network to determine its configuration, - capacity, or usage. This can occur through attacks against an + capacity, or usage. These can occur through attacks against an NMS in the case of static provisioning or attacks against the - control plane in dynamic MPLS-TP networks. It can also result + control plane in dynamic MPLS-TP networks. They can also result from combined attacks. It is helpful to consider that threats, whether resulting from malicious behavior or accidental errors, may come from different sources or categories of attackers. For example, they may come from: o Users of the MPLS-TP network itself, who may attack the network or other users. These other users' services may be provided by the same or a different MPLS-TP core. -o The MPLS-TP SP its employees. +o The MPLS-TP SP or its employees. o Other persons who obtain physical access to a MPLS-TP SP's site. o Other persons who use social engineering to influence the behavior of a SP's personnel. o Outsiders, e.g., attackers from the other sources, including the Internet (if connectivity can be obtained). o Other SPs in the case of MPLS-TP inter-provider connection. The @@ -599,48 +599,48 @@ o Those who create, deliver, install, and maintain hardware or software for network equipment. Security is a tradeoff between cost and risk, so it is useful to consider the likelihood of different attacks, the cost of preventing them, and the possible damage resulting from their occurrence. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as: -o A MPLS-TP network inter-connected with another provider's core +o An MPLS-TP network inter-connected with another provider's core -o A MPLS-TP configuration inter-connected with the public Internet, +o An MPLS-TP configuration inter-connected with the public Internet, e.g., for control or management functions Most types of attacks become easier to mount and hence more likely as the shared infrastructure via which service is provided expands from a single SP to multiple cooperating SPs to the global Internet. Attacks that may not be of sufficient likeliness to warrant concern in a closely controlled environment often merit defensive measures in broader, more open environments. Even though surveys show that 40% to 60% of attacks originate from insiders, in closed communities, it is often practical to identify and to deal with misbehavior after the fact: -an employee can be disciplined, for example. +employee misbehavoir can be corrected, for example. The following sections list specific types of exploits that threaten MPLS-TP networks. 3.1. Attacks on the Control Plane This category includes attacks that may compromise the availability of control plane capabilities, the integrity of these operations, and, potentially, the confidentiality of these operations for either in- band (G-ACh) or out-of-band (GMPLS) configurations. Attacks against GMPLS include attacks against its constituent protocols (i.e., RSVP-TE, LDP, OSPFv2, or PCEP). Attacks against G-ACh may be directed against the label mechanism (GAL) or any of the encapsulated signaling or management -protocols (SCC, MCC, or OAM, or protection). The following attacks may +protocols (SCC, MCC, OAM, or protection). The following attacks may target the provisioning, management, or survivability functions of the control plane: o Improper MPLS-TP LSP or PW creation or deletion. This may result from a failure of control plane authentication or authorization mechanisms or compromise of control plane traffic. One result might be improper cross-connection of different users' traffic. o Improper use of MPLS-TP protection and restoration capabilities. This also may result from a failure of control plane authentication or @@ -652,34 +652,37 @@ o Denial of service attacks on the control plane or use of the control plane to carry out denial of service attacks against the data plane. o Attacks on the SP's MPLS-TP equipment or software. These may occur during the normal lifecycle of the equipment and software or via management interfaces or other points of entry. These include social engineering attacks on the SP's infrastructure. 3.2. Attacks on the Data Plane - This category encompasses attacks on the SP's or end user's data. -Note that from the MPLS-TP network end user's point of view, some of -this may be control plane traffic, e.g. a routing protocol running -from user's site A to site B via IP or non-IP connections, e.g., a VPN. + The general MPLS data plane attacks apply to MPLS-TP as well. These +include the following: o Denial of service, misconnection, loss of bandwidth, or other service disruptions. -o Unauthorized observation of data traffic, includes LSP or PW +o Unauthorized observation of data traffic, including LSP or PW message interception and traffic pattern analysis. o Modification or deletion of data traffic, which may include insertion of inauthentic data traffic (spoofing or replay). + MPLS-TP supports data plane switching (e.g., from working to +protect-path when a failure is detected) without the involvement of +control plane or management system. Therefore, data plane attacks can +potentially cause serious network instability. + 4. Security Requirements for MPLS-TP This section covers requirements for securing an MPLS-TP network infrastructure. The MPLS-TP network can be operated without a control plane or via dynamic control plane protocols. The security requirements related to MPLS-TP OAM, recovery mechanisms, MPLS-TP interconnection with other technologies, and operations specific to MPLS-TP are addressed in this section. A service provider may deploy the security options best fitting @@ -701,47 +704,48 @@ R02: MPLS-TP MUST support static provisioning of MPLS-TP LSPs and PWs without using control protocols (with or without a NMS). This is particularly important in cases where components of the provisioning process are not in the trusted zone (security model 2(a) and security model 2(b), where some or all T-PEs are not in the trusted zone and the inter-provider cases in security model 2(c), where the connecting S-PE is not in the trusted zone; see Figures 3, 4, and 5). -R03: MPLS-TP MUST support non-IP path options in addition to the IP - loopback option. +R03: MPLS-TP MUST support the IP loopback and non-IP path options that + use the path ID compatible with ITU-T transport-based operations. R04: MPLS-TP MUST support authentication, integrity, and replay protection for any control protocol used in an MPLS-TP network. R05: MPLS-TP SHOULD support confidentiality, algorithm agility, and key management for any control protocol used in an MPLS-TP network. R06: MPLS-TP MUST support authentication, integrity, and replay protection for dynamic MPLS network inter-connection protocols. R07: MPLS-TP SHOULD support confidentiality, algorithm agility, and key management for dynamic MPLS network inter-connection protocols. -R08: MPLS-TP MUST support mechanisms to prevent denial of service +R08: MPLS-TP MUST support mechanisms to mitigate denial of service (DoS) attacks carried out over any control plane protocol or management protocol, including OAM and G-ACh, whether in-band or out-of band. This applies to denial-of-service attacks against the control or management protocol itself or against the data channel. -R09: MPLS-TP MUST support hiding of the Service Provider's - infrastructure for all reference models whether using static - configuration or a dynamic control plane. +R09: MPLS-TP MUST provide secure ways to support Service Providers' + requirements for hiding their infrastructure in all reference + models using static configuration or a dynamic control plane, help + to reduce risk of SP networks be attacked, (e.g. DoS attack). -R10: MPLS-TP MUST provide protection from operational errors. The +R10: MPLS-TP SHOULD provide protection from operational errors. The extensive use of static provisioning with or without a NMS increases the likelihood of operational errors that result in misconfigurations that may compromise user's data, system security, or network security is greater. R11: MPLS-TP MUST support event logging and auditing. Logging and auditing capabilities provide critical resources for tracking down problems and repairing the damage after a security incident. Management security requirements are covered in [RFC5951]. This document @@ -875,21 +879,21 @@ there will still be multiple MPLS-TP users sharing the same network resources. In general, the use of aggregated infrastructure allows the service provider to benefit from stochastic multiplexing of multiple bursty flows, and also may in some cases thwart traffic pattern analysis by combining the data from multiple users. However, service providers must minimize security risks introduced from any individual service or individual users. -5.5. Protection against Denial of Service +5.5. Mitigatoion of Denial of Service Attacks It is possible to lessen the potential and impact of denial-of-service attacks by using secure protocols, turning off unnecessary processes, logging and monitoring, and using ingress filtering. See [RFC4732] for background on denial-of-service attacks in the context of the Internet. 5.6. Verification of Connectivity To protect against deliberate or accidental misconnection, @@ -988,86 +992,75 @@ [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. [opsec-efforts] "Security Best Practices Efforts and Documents", - IETF draft-ietf-opsec-efforts-08.txt, June 2008. + IETF draft-ietf-opsec-efforts-18.txt, April 2012. Authors' Addresses Luyuan Fang (editor) Cisco Systems 111 Wood Ave. South Iselin, NJ 08830 US - Email: lufang@cisco.com Ben Niven-Jenkins (editor) Velocix 326 Cambridge Science Park Milton Road Cambridge CB4 0WG UK - Email: ben@niven-jenkins.co.uk Scott Mansfield (editor) Ericsson 300 Holger Way San Jose, CA 95134 US - Email: scott.mansfield@ericsson.com Richard F. Graveman (editor) RFG Security, LLC 15 Park Avenue - Morristown, NJ 07960 US - + Morristown, NJ 07960 + US Email: rfg@acm.org - Raymond Zhang - British Telecom - BT Center - 81 Newgate Street - London EC1A 7AJ - UK + Alcatel-Lucent + 701 Middlefield Road + Mountain View, CA 94043 + US + Email: raymond.zhang@alcatel-lucent.com - Email: raymond.zhang@bt.com Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 US - Email: nabil.bitar@verizon.com Masahiro Daikoku KDDI Corporation - 3-11-11 Iidabashi, Chiyodaku + 3-11-11 Iidabashi, Chiyodaku, Tokyo Japan - Email: ms-daikoku@kddi.com Lei Wang - Telenor - Telenor Norway - Office Snaroyveien - 1331 Fornedbu + Lime Networks + Strandveien 30, 1366 Lysaker Norway - - Email: lei.wang@telenor.com + Email: lei.wang@limenetworks.no Henry Yu TW Telecom 10475 Park Meadow Drive Littleton, CO 80124 US - Email: henry.yu@twtelecom.com