| TOC |
|
This memo provides a recommendation for protecting a router's control plane from undesired or malicious traffic. In this recommendation, 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. The examples given are simplified and minimalistic, designed to illustrate the concept of protecting the router's control plane.
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 July 8, 2010.
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 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.
1.
Introduction
2.
Method
3.
Legitimate Traffic
4.
Filter Design
5.
Security Considerations
6.
IANA Considerations
7.
Acknowledgements
8.
Informative References
Appendix A.
Cisco Configuration
Appendix B.
Juniper Configuration
§
Authors' Addresses
| TOC |
One of the primary goals of modern core router architecture design is to maintain a strict separation of forwarding and control plane hardware and software. Forwarding plane is defined 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 defined 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 (Router Control Plane Protection).
+---------------+
| 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 frames transit the device at multiple levels of magnitude greater load than the control plane hardware. By contrast, the control plane is generally realized in software on general purpose processors. And while software instructions run on both planes, the control plane software is usually not optimized for high speed packet handling. ASICs perform well even with high offered load, but in most cases control plane hardware can be overwhelmed by a DoS attack. Additionally, the control plane is what drives the programming of the forwarding plane. Therefore, it is imperative that the control plane remain stable regardless of traffic load to and from the device.
When compared to forwarding plane functionality, control plane functionality is more complex as it has to fully process protocol constructs in packets to and from the device versus simply rewriting the header of a transit frame to move it from one interface to another along the path towards the destination. The full processing of the contents of packets and the function of keeping protocol states and machineries result in more potential security vulnerabilities as well as a more likely target for a DoS attack given the lesser processing power at the control plane level.
Because the control plane is more susceptible to attacks, 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.
| TOC |
In this memo, the authors demonstrate how a filter protecting the control plane can be deployed. In Section 3 (Legitimate Traffic), a sample router introduced and all traffic that its control plane must process is identified. In Section 4 (Filter Design), filter design concepts are discussed. Cisco (Cisco IOS software) and Juniper (JUNOS) implementations are provided in Appendices A (Cisco Configuration) and B (Juniper Configuration), respectively.
| TOC |
In this example, the router control plane must process traffic from the following sources:
The characteristics of legitimate traffic will vary from network to network. The list provided above is for example only.
| TOC |
A filter is installed on the forwarding plane. This filter counts and silently discards all traffic not matching the profile provided in Section 3 (Legitimate Traffic). 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.
| TOC |
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 (Legitimate Traffic). Network 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) for more information regarding source address validation.
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.
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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.). 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.
| TOC |
[RFC Editor: please remove this section prior to publication.]
This document has no IANA actions.
| TOC |
The authors would like to thank Ron Bonica for providing review, suggestions, and valuable input.
| TOC |
| [RFC1812] | Baker, F., “Requirements for IP Version 4 Routers,” RFC 1812, June 1995 (TXT). |
| TOC |
!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
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
| TOC |
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-address {
192.0.2.0/24;
}
protocol tcp;
destination-port bgp;
}
then accept;
}
term ibgp-reply {
from {
source-address {
192.0.2.0/24;
}
protocol tcp;
port bgp;
}
then accept;
}
term ebgp-connect {
from {
source-address {
198.51.100.25;
198.51.100.27;
198.51.100.29;
198.51.100.31;
}
protocol tcp;
destination-port bgp;
}
then accept;
}
term ebgp-reply {
from {
source-address {
198.51.100.25;
198.51.100.27;
198.51.100.29;
198.51.100.31;
}
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;
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;
}
}
}
}
| TOC |
| 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 |