--- 1/draft-ietf-mpls-mpls-and-gmpls-security-framework-08.txt 2010-03-09 00:11:23.000000000 +0100 +++ 2/draft-ietf-mpls-mpls-and-gmpls-security-framework-09.txt 2010-03-09 00:11:23.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group Luyuan Fang, Ed. Internet Draft Cisco Systems, Inc. Category: Informational - Expires: September 1, 2010 + Expires: September 8, 2010 - March 1, 2010 + March 8, 2010 Security Framework for MPLS and GMPLS Networks - draft-ietf-mpls-mpls-and-gmpls-security-framework-08.txt + draft-ietf-mpls-mpls-and-gmpls-security-framework-09.txt Abstract This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as Inter-AS and @@ -36,21 +36,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 8, 2009. + This Internet-Draft will expire on September 8, 2010. Copyright Notice MPLS/GMPLS Security framework Copyright (c) 2010 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 @@ -335,21 +335,21 @@ control protocols, runs one or more routing protocols, and is capable of forwarding packets based on labels. A MPLS node may optionally be also capable of forwarding native IP packets. MultiProtocol Label Switching (MPLS): An IETF working group and the effort associated with the working group. P: Provider Router. A Provider Router is a router in the Service Provider's core network that does not have interfaces directly towards the customer. A P router is used to interconnect the PE - routers. + routers and/or other P routers within the core network. PE: Provider Edge device. A Provider Edge device is the equipment in the Service Provider's network that interfaces with the equipment in the customer's network. PPVPN: Provider-Provisioned Virtual Private Network, including Layer 2 VPNs and Layer 3 VPNs. VPN: Virtual Private Network, which restricts communication between a set of sites, making use of an IP backbone shared by traffic not @@ -370,20 +370,22 @@ +------------+ / \ +------------+ | MPLS/GMPLS +---/ \--------+ MPLS/GMPLS | | user | MPLS/GMPLS Core | user | | site +---\ /XXX-----+ site | +------------+ \ / XXX +------------+ \-------------/ | | | | | +------\ +--------/ "Internet" + |<- Trusted zone ->| + MPLS/GMPLS Core with user connections and Internet connection Figure 1: The MPLS/GMPLS trusted zone model. The trusted zone is the MPLS/GMPLS core in a single AS within a single Service Provider. A trusted zone contains elements and users with similar security properties, such as exposure and risk level. In the MPLS context, an organization is typically considered as one trusted zone. @@ -403,24 +405,24 @@ A key requirement of MPLS and GMPLS networks is that the security of the trusted zone not be compromised by interconnecting the MPLS/GMPLS core infrastructure with another provider's core (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users. In addition, neighbors may be trusted or untrusted. Neighbors may be authorized or unauthorized. Authorized neighbor is the neighbor one established peering relationship with. Even though a neighbor may be authorized for communication, it may not be trusted. For example, when connecting with another provider's ASBRs to set up + MPLS/GMPLS Security framework inter-AS LSPs, the other provider is considered an untrusted but authorized neighbor. - MPLS/GMPLS Security framework +---------------+ +----------------+ | | | | | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS | CE1--PE1 Network | | Network PE2--CE2 | Provider A ASBR2----ASBR4 Provider B | | | | | +---------------+ +----------------+ InterCarrier Interconnect (ICI) @@ -434,23 +436,21 @@ All aspects of network security independent of whether a network is a MPLS/GMPLS network are out of scope. For example, attacks from the Internet to a user's web-server connected through the MPLS/GMPLS network are not considered here, unless the way the MPLS/GMPLS network is provisioned could make a difference to the security of this user's server. 4. Security Threats This section discusses the various network security threats that - may endanger MPLS/GMPLS networks. The discussion is limited to - those threats that are unique to MPLS/GMPLS networks or that affect - MPLS/GMPLS network in unique ways. RFC 4778 [RFC4778] provided the + may endanger MPLS/GMPLS networks. RFC 4778 [RFC4778] provided the best current operational security practices in Internet Service Provider environments. A successful attack on a particular MPLS/GMPLS network or on a SP's MPLS/GMPLS infrastructure may cause one or more of the following ill effects: - Observation, modification, or deletion of a provider's or user's data. - Replay of a provider's or user's data. @@ -1614,22 +1614,23 @@ the packet. - Count packets or bytes - Rate Limit In some cases the set of packets matching a particular filter may be limited to a specified bandwidth. In this case, packets or bytes would be counted, and would be forwarded normally up to the specified limit. Excess packets may be discarded or may be marked - (for example by setting a "discard eligible" bit in the IPv4 ToS - field or the MPLS EXP field). + (for example, by setting a "discard eligible" bit in the IPv4 ToS + field, or change the EXP value to identify as out of contract + traffic). - Forward and Copy It is useful in some cases to forward some set of packets normally, but also to send a copy to a specified other address or interface. For example, this may be used to implement a lawful intercept capability or to feed selected packets to an Intrusion Detection System. o Other Packet Filters Issues @@ -1774,21 +1775,21 @@ share network resources with Internet services or other services. It is therefore important for MPLS/GMPLS services to provide protection between resources used by different parties. Thus, a well-behaved MPLS/GMPLS user should be protected from possible misbehavior by other users. This requires several security measurements to be implemented. Resource limits can be placed on a per service and per user basis. Possibilities include, for example, using virtual router or logical router to define hardware or software resource limits per service or per individual user; using - rate limiting per VPN or per Internet connection to provide + rate limiting per VRF or per Internet connection to provide bandwidth protection; or using resource reservation for control plane traffic. In addition to bandwidth protection, separate resource allocation can be used to limit security attacks only to directly impacted service(s) or customer(s). Strict, separate, and clearly defined engineering rules and provisioning procedures can reduce the risks of network-wide impact of a control plane attack, DoS attack, or mis-configuration. In general, the use of aggregated infrastructure allows the service provider to benefit from stochastic multiplexing of multiple bursty @@ -1859,29 +1860,29 @@ or to improve the defenses for specific targets on an as-needed basis. Information collected on attacks may also be useful in identifying and developing defenses against novel attack types. Monitoring systems used to detect security attacks in MPLS/GMPLS typically operate by collecting information from the Provider Edge (PE), Customer Edge (CE), and/or Provider backbone (P) devices. Security monitoring systems should have the ability to actively retrieve information from devices (e.g., SNMP get) or to passively receive reports from devices (e.g., SNMP notifications). The - Security monitoring systems may actively retrieve information from - devices (e.g., SNMP get) or passively receive reports from devices - (e.g., SNMP notifications). The specific information exchanged - depends on the capabilities of the devices and on the type of VPN - technology. Particular care should be given to securing the - communications channel between the monitoring systems and the - MPLS/GMPLS devices. Syslog WG is specifying "Logging Capabilities - for IP Network Infrastructure". (The specific references will be - made only if the draft(s) became RFC before this draft.) + systems may actively retrieve information from devices (e.g., SNMP + get) or passively receive reports from devices (e.g., SNMP + notifications). The specific information exchanged depends on the + capabilities of the devices and on the type of VPN technology. + Particular care should be given to securing the communications + channel between the monitoring systems and the MPLS/GMPLS devices. + Syslog WG is specifying "Logging Capabilities for IP Network + Infrastructure". (The specific references will be made only if the + draft(s) became RFC before this draft.) The CE, PE, and P devices should employ efficient methods to acquire and communicate the information needed by the security monitoring systems. It is important that the communication method between MPLS/GMPLS devices and security monitoring systems be designed so that it will not disrupt network operations. As an example, multiple attack events may be reported through a single message, rather than allowing each attack event to trigger a separate message, which might result in a flood of messages, essentially becoming a DoS attack against the monitoring system or @@ -1971,21 +1972,21 @@ 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), confidentiality. Protocols need to provide a complete set of security services from which the SP can choose. Also, the important but often harder part is key management. Considerations, guidelines, and strategies regarding key management are discussed in [RFC3562], [RFC4107], [RFC4808]. - With today's processors, applying cryptograpgic authentication to + 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. @@ -2718,21 +2719,21 @@ decide what threats to protect against in any given configuration or service offering. 11. IANA Considerations This document contains no new IANA considerations. 12. Normative References [RFC2747] F. Baker, et al., "RSVP Cryptographic Authentication", - EFC 2741, January 2000. + RFC 2747, January 2000. [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3097] R. Braden and L. Zhang, "RSVP Cryptographic Authentication - Updated Message Type Value", RFC 3097, April 2001. [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001. @@ -2962,16 +2963,17 @@ Old Dog Consulting Email: adrian@olddog.co.uk 15. Acknowledgements Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). The authors and contributors would also like to acknowledge the helpful comments and suggestions from Sam Hartman, Dimitri - Papadimitriou, Kannan Varadhan, Stephen Farrell, Scott Brim in - particular for his comments and discussion through GEN-ART review, - 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. + 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.