OPSEC D. Dugal Internet-Draft Juniper Networks Intended status: Informational C. Pignataro Expires: August 27, 2010 R. Dunn Cisco Systems February 23, 2010 Protecting The Router Control Plane draft-dugal-opsec-protect-control-plane-02 Abstract This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate control plane traffic is identifed. Once legitimate traffic has been identified, a filter is deployed on the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." 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 August 27, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Dugal, et al. Expires August 27, 2010 [Page 1] Internet-Draft Protect Control Plane February 2010 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, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Legitimate Traffic . . . . . . . . . . . . . . . . . . . . 4 3.2. Filter Design . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Design Trade-offs . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Cisco Configuration . . . . . . . . . . . . . . . . . 8 Appendix B. Juniper Configuration . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Dugal, et al. Expires August 27, 2010 [Page 2] Internet-Draft Protect Control Plane February 2010 1. Introduction Modern core router architecture design maintains a strict separation of forwarding and control plane hardware and software. Forwarding plane is typically described as router architecture hardware and software components responsible for taking a packet coming in one interface, performing a lookup to identify the packet's IP next hop and determine the outgoing interface towards the destination, and forwarding the packet through the correct outgoing interface. Control plane supports routing and management functions, and is generally described as as router architecture hardware and software components for handling packets destined to the device itself as well as building and sending packets originated locally on the device. Visually it can be represented as the control plane hardware sitting on top of and interfacing with the forwarding plane hardware, with interfaces connecting to other network devices. See Figure 1. +---------------+ | Control Plane | +------+ +------+ | | Router Control Plane Protection | | +------+ +------+ | Forwarding | Interface X ==[ Plane ]== Interface Y +---------------+ Figure 1: Router Control Plane Protection Typically, forwarding plane functionality is realized in high- performance Application Specific Integrated Circuits (ASICs) that are capable of handling very high packet rates. By contrast, the control plane is generally realized in software on general purpose processors. While software instructions run on both planes, the control plane software is usually not optimized for high speed packet handling. Given their differences in packet handling capabilities, control plane hardware is more suceptible to be overwhelmed by a DoS attack than forwarding plane ASICs. It is imperative that the control plane remain stable regardless of traffic load to and from the device because the control plane is what drives the programming of the forwarding plane. The control plane processes traffic destined to the router, and because of the wider range of functionality is more suceptible to security vulnerabilities and a more likely target for a DoS attack Dugal, et al. Expires August 27, 2010 [Page 3] Internet-Draft Protect Control Plane February 2010 than the forwarding plane. It is advisable to protect the control plane by implementing mechanisms to filter completely or rate limit traffic not required at the control plane level (i.e., unwanted traffic). Control Plane Protection is the concept of filtering traffic unwanted traffic which would be diverted out of the forwarding plane up to the control plane. The closer to the forwarding plane and line-rate hardware the filters and rate-limiters are, the more effective the protection is and the more resistent the system is to DoS attacks. This memo demonstrates how to deploy such a filter. 2. Applicability Statement The method described in Section 3 is a sample illustration to demonstrate how to protect the router control plane from unwanted traffic. Recognizing that deployment scenarios will vary, the exact implementation is not generally applicable in all situations. The cateorization of legitimate control plane traffic is critically important in a successul implementation. The examples given in this memo are simplified and minimalistic, designed to illustrate the concept of protecting the router's control plane. From them, operators can extrapolate specifics based on their unique configuration and environment. This method is applicable for IPv4 as well as IPv6 traffic. The sample legitimate traffic in Section 3.1 uses IPv4 addresses, but can be expanded to IPv6 as well. 3. Method In this memo, the authors demonstrate how a filter protecting the control plane can be deployed. In Section 3.1, a sample router introduced and all traffic that its control plane must process is identified. In Section 3.2, filter design concepts are discussed. Cisco (Cisco IOS software) and Juniper (JUNOS) implementations are provided in Appendices A and B, respectively. 3.1. Legitimate Traffic In this example, the router control plane must process traffic from the following sources: Dugal, et al. Expires August 27, 2010 [Page 4] Internet-Draft Protect Control Plane February 2010 o ICMP traffic from any source, rate-limited to 2 Mbps o OSPF traffic from routers within own network (network mask 192.0.2.0/24) o iBGP traffic from routers within own network (network mask 192.0.2.0/24) o eBGP traffic from known eBGP peers (network addresses 198.51.100.25, 198.51.100.27, 198.51.100.29, 198.51.100.31) o DNS traffic from local DNS resolvers (198.51.100.0/30) o NTP traffic from local NTP (198.51.100.4/30) o SSH traffic from network management stations (198.51.100.128/25) o SNMP traffic from network management stations (198.51.100.128/25) The characteristics of legitimate traffic will vary from network to network. The list provided above is for example only. 3.2. Filter Design A filter is installed on the forwarding plane. This filter counts and silently discards all traffic not matching the profile provided in Section 3.1. Because the filter is enforced on the forwarding plane, it prevents unwanted traffic from consuming bandwidth on the interface that connects the forwarding plane to the control plane. The counters serve as an important forensic tool for the analysis of potential attacks, and as an invaluable debugging and troubleshooting aid. A rate limiter also is installed on the forwarding plane. The rate limiter restricts ICMP traffic bound for the control plane to some reasonable volume. In our example, we will rate limit to 2 Megabits per second (Mbps). Syntactically, these filters explicitly define "allowed" traffic (including IP addresses, protocols, and ports), define acceptable actions for these acceptable traffic profiles (e.g., rate-limit or simply permit the traffic), and then drop to the bit bucket all traffic destined to the control plane but not explicitly allowed. 3.3. Design Trade-offs In designing the protection method, there are two independent parts to consider: the classification of traffic (i.e., which traffic is Dugal, et al. Expires August 27, 2010 [Page 5] Internet-Draft Protect Control Plane February 2010 matched by the filters), and the policy actions taken on the classified traffic. There are different levels of granularity utilized for traffic classification. For example, allowing all traffic from specific source IP addresses versus allowing only a specific set of protocols from those specific source IP addresses will each affect a different set of traffic. Similarly, the policy actions taken on the classified traffic have degrees of impact that may not become immediately obvious. For example, discarding all ICMP traffic may have a negative impact on the operational use of ICMP tools such as ping or traceroute to debug network issues or to test turn up of a new circuit. It is important to note that both classification and policy action decisions are accompanied by respective trade-offs. Two examples of these trade-off decisions are, operational complexity at the expense of policy (and statistics gathering) detail, and tighter protection at the expense of network supportability and troubleshooting ability. The goal of the method for protecting the router control plane is to minimize potential disruptions. The granularity of the filter design inversely correlates to the scope of the potential disruption. The finer the granularity of the filter design (e.g., isolating kinds of sub-traffic from the rest of the policed traffic, or isolating valid source addresses into a different class or classes) the smaller the scope of disruption. Additionally, the baselining and monitoring of traffic flows to the router's control plane are critical in determining both the rates and granularity of the policies being applied. This is important to validate the existing policies and rules or update them as the network evolves and its traffic dynamics change. Some possible ways to achieve this include individual policy counters that can be exported or retrieved for example via SNMP, and logging of filtering actions. 4. Security Considerations The filter above leaves the router susceptible to discovery from any host on the Internet. If network operators find this risk objectionable, they can mitigate it by restricting the sub-networks from which ICMP Echo requests are accepted. The filter above also leaves the router exposed to port scans from hosts spoofing the source addresses found in Section 3.1. Network Dugal, et al. Expires August 27, 2010 [Page 6] Internet-Draft Protect Control Plane February 2010 operators can mitigate this risk by preventing source address spoofing with filters applied at the network edge. Refer to Section 5.3.8 of [RFC1812] for more information regarding source address validation. Other methods also exist for limiting exposure to packet spoofing such as the Generalized TTL Security Mechanism (GTSM) [RFC5082] and Ingress Filtering [RFC3704]. The ICMP rate limiter specified in this filter protects the router from floods of ICMP traffic. However, during an ICMP flood, some legitimate ICMP traffic may be dropped. Because of this, when operators discover a flood of ICMP traffic, they are highly motivated to cut it off at its source. Additional considerations pertaining to the usage and handling of traffic that utilizes the IP Router Alert Options can be found at [I-D.rahman-rtg-router-alert-considerations]. The treatment of exception traffic in the forwarding plane, and the generation of specific messages by the control plane also requires protection from a DoS attack. Specifically, the generation of ICMP Unreachable messages by the control plane needs to be rate-limited, either implicitly within the router's architecture or explicitly through configuration. See Section 4.3.2.8 of [RFC1812]. Additionally, the handling of TTL / Hop Limit expired traffic needs protection. For example, rate limiting the TTL / Hop Limit expired traffic before sending the packets to the control plane component that will send the ICMP error, and distributing the sending of ICMP errors in a Line Card CPU are protection mechanisms that deter attacks before a rate limited in the main control plane component. 5. IANA Considerations [RFC Editor: please remove this section prior to publication.] This document has no IANA actions. 6. Acknowledgements The authors would like to thank Ron Bonica for providing initial review, suggestions, and valuable input. Pekka Savola, Warren Kumari and Xu Chen provided very thorough and useful feedback that improved the document. Many thanks to John Kristoff, Christopher Morrow, and Donald Smith for a fruitful discussion around operational and manegeability aspects of control plane protection techniques. Dugal, et al. Expires August 27, 2010 [Page 7] Internet-Draft Protect Control Plane February 2010 7. Informative References [I-D.rahman-rtg-router-alert-considerations] Faucheur, F., "IP Router Alert Considerations and Usage", draft-rahman-rtg-router-alert-considerations-03 (work in progress), October 2009. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. Appendix A. Cisco Configuration !Start: Protecting The Router Control Plane ! !Policy-map Configuration ! !Access-list Definitions ip access-list extended ICMP permit icmp any any ip access-list extended OSPF permit ospf 192.0.2.0 0.0.0.255 any ip access-list extended IBGP permit tcp 192.0.2.0 0.0.0.255 eq bgp any permit tcp 192.0.2.0 0.0.0.255 any eq bgp ip access-list extended EBGP permit tcp host 198.51.100.25 eq bgp any permit tcp host 198.51.100.25 any eq bgp permit tcp host 198.51.100.27 eq bgp any permit tcp host 198.51.100.27 any eq bgp permit tcp host 198.51.100.29 eq bgp any permit tcp host 198.51.100.29 any eq bgp permit tcp host 198.51.100.31 eq bgp any permit tcp host 198.51.100.31 any eq bgp ip access-list extended DNS permit udp 198.51.100.0 0.0.0.252 eq domain any ip access-list extended NTP permit udp 198.51.100.4 255.255.255.252 any eq ntp ip access-list extended SSH permit tcp 198.51.100.0 0.0.0.128 any eq 22 Dugal, et al. Expires August 27, 2010 [Page 8] Internet-Draft Protect Control Plane February 2010 ip access-list extended SNMP permit udp 198.51.100.128 0.0.0.125 eq snmp any permit udp 198.51.100.128 0.0.0.125 eq snmptrap any ! !Class Definitions ! class-map match-all ICMP match access-group name ICMP class-map match-all OSPF match access-group name OSPF class-map match-all IBGP match access-group name IBGP class-map match-all EBGP match access-group name EBGP class-map match-all DNS match access-group name DNS class-map match-all NTP match access-group name NTP class-map match-all SSH match access-group name SSH class-map match-all SNMP match access-group name SNMP ! !Policy Definition ! policy-map COPP class ICMP police 2000000 class OSPF class IBGP class EBGP class DNS class NTP class SSH class SNMP class class-default police cir 8000 conform-action drop exceed-action drop violate-action drop ! !Control Plane Configuration ! control-plane service-policy input COPP ! !End: Protecting The Router Control Plane Dugal, et al. Expires August 27, 2010 [Page 9] Internet-Draft Protect Control Plane February 2010 Appendix B. Juniper Configuration policy-options { prefix-list IBGP-NEIGHBORS { 192.0.2.0/24; } prefix-list EBGP-NEIGHBORS { 198.51.100.25/32; 198.51.100.27/32; 198.51.100.29/32; 198.51.100.31/32; } } firewall { policer 2Mbps { if-exceeding { bandwidth-limit 2m; burst-size-limit 2k; } then discard; } family inet { filter protect-control-plane { term icmp { from { protocol icmp; } policer 2Mbps; then accept; } term ospf { from { source-address { 192.0.2.0/24; } protocol ospf; } then accept; } term ibgp-connect { from { source-prefix-list { IBGP-NEIGHBORS; } protocol tcp; destination-port bgp; } Dugal, et al. Expires August 27, 2010 [Page 10] Internet-Draft Protect Control Plane February 2010 then accept; } term ibgp-reply { from { source-prefix-list { IBGP-NEIGHBORS; } protocol tcp; port bgp; } then accept; } term ebgp-connect { from { source-prefix-list { EBGP-NEIGHBORS; } protocol tcp; destination-port bgp; } then accept; } term ebgp-reply { from { source-prefix-list { EBGP-NEIGHBORS; } protocol tcp; port bgp; } then accept; } term dns { from { source-address { 198.51.100.0/30; } protocol udp; port domain; } then accept; } term ntp { from { source-address { 198.51.100.4/30; } protocol udp; Dugal, et al. Expires August 27, 2010 [Page 11] Internet-Draft Protect Control Plane February 2010 destination-port ntp; } then accept; } term ssh { from { source-address { 198.51.100.128/25; } protocol tcp; destination-port ssh; } then accept; } term snmp { from { source-address { 198.51.100.128/25; } protocol udp; port [snmp snmptrap]; } then accept; } term default-term { then { count copp-discards; log; discard; } } } } } interfaces { lo0 { unit 0 { family inet { filter input protect-control-plane; } } } } Dugal, et al. Expires August 27, 2010 [Page 12] Internet-Draft Protect Control Plane February 2010 Authors' Addresses David Dugal Juniper Networks 10 Technology Park Drive Westford, MA 01886 US Email: ddugal@juniper.net Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: cpignata@cisco.com Rodney Dunn Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: rodunn@cisco.com Dugal, et al. Expires August 27, 2010 [Page 13]