draft-ietf-opsec-protect-control-plane-06.txt   rfc6192.txt 
OPSEC D. Dugal Internet Engineering Task Force (IETF) D. Dugal
Internet-Draft Juniper Networks Request for Comments: 6192 Juniper Networks
Intended status: Informational C. Pignataro Category: Informational C. Pignataro
Expires: June 18, 2011 R. Dunn ISSN: 2070-1721 R. Dunn
Cisco Systems Cisco Systems
December 15, 2010 March 2011
Protecting The Router Control Plane Protecting the Router Control Plane
draft-ietf-opsec-protect-control-plane-06
Abstract Abstract
This memo provides a method for protecting a router's control plane This memo provides a method for protecting a router's control plane
from undesired or malicious traffic. In this approach, all from undesired or malicious traffic. In this approach, all
legitimate router control plane traffic is identified. Once legitimate router control plane traffic is identified. Once
legitimate traffic has been identified, a filter is deployed in the legitimate traffic has been identified, a filter is deployed in the
router's forwarding plane. That filter prevents traffic not router's forwarding plane. That filter prevents traffic not
specifically identified as legitimate from reaching the router's specifically identified as legitimate from reaching the router's
control plane, or rate limits such traffic to an acceptable level. control plane, or rate-limits such traffic to an acceptable level.
Status of this Memo Note that the filters described in this memo are applied only to
traffic that is destined for the router, and not to all traffic that
is passing through the router.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on June 18, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6192.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 2. Applicability Statement .........................................4
3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Method ..........................................................4
3.1. Legitimate Traffic . . . . . . . . . . . . . . . . . . . . 5 3.1. Legitimate Traffic .........................................5
3.2. Filter Design . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Filter Design ..............................................6
3.3. Design Trade-offs . . . . . . . . . . . . . . . . . . . . 7 3.3. Design Trade-Offs ..........................................7
3.4. Additional Protection Considerations . . . . . . . . . . . 9 3.4. Additional Protection Considerations ......................10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations ........................................10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements ...............................................11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. Informative References .........................................12
7. Informative References . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Configuration Examples ................................13
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 12 A.1. Cisco Configuration .......................................13
A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 12 A.2. Juniper Configuration .....................................17
A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Modern router architecture design maintains a strict separation of Modern router architecture design maintains a strict separation of
forwarding and router control plane hardware and software. The forwarding and router control plane hardware and software. The
router control plane supports routing and management functions. It router control plane supports routing and management functions. It
is generally described as the router architecture hardware and is generally described as the router architecture hardware and
software components for handling packets destined to the device software components for handling packets destined to the device
itself as well as building and sending packets originated locally on itself as well as building and sending packets originated locally on
the device. The forwarding plane is typically described as the the device. The forwarding plane is typically described as the
router architecture hardware and software components responsible for router architecture hardware and software components responsible for
receiving a packet on an incoming interface, performing a lookup to receiving a packet on an incoming interface, performing a lookup to
identify the packet's IP next hop and determine the best outgoing identify the packet's IP next hop and determine the best outgoing
interface towards the destination, and forwarding the packet out interface towards the destination, and forwarding the packet out
through the appropriate outgoing interface. through the appropriate outgoing interface.
Visually this architecture can be represented as the router's control Visually, this architecture can be represented as the router's
plane hardware sitting on top of, and interfacing with, the control plane hardware sitting on top of, and interfacing with, the
forwarding plane hardware with interfaces connecting to other network forwarding plane hardware with interfaces connecting to other network
devices. See Figure 1. devices. See Figure 1.
+----------------+ +----------------+
| Router Control | | Router Control |
| Plane | | Plane |
+------+ +-------+ +------+ +-------+
| | | |
Router Control Router Control
Plane Protection Plane Protection
skipping to change at page 3, line 43 skipping to change at page 3, line 23
+------+ +-------+ +------+ +-------+
| Forwarding | | Forwarding |
Interface X ==[ Plane ]== Interface Y Interface X ==[ Plane ]== Interface Y
+----------------+ +----------------+
Figure 1: Router Control Plane Protection Figure 1: Router Control Plane Protection
Typically, forwarding plane functionality is realized in high- Typically, forwarding plane functionality is realized in high-
performance Application Specific Integrated Circuits (ASICs) that are performance Application Specific Integrated Circuits (ASICs) that are
capable of handling very high packet rates. By contrast, the router capable of handling very high packet rates. By contrast, the router
control plane is generally realized in software on general purpose control plane is generally realized in software on general-purpose
processors. While software instructions run on both planes, the processors. While software instructions run on both planes, the
router control plane software is usually not optimized for high speed router control plane hardware is usually not optimized for high-speed
packet handling. Given their differences in packet handling packet handling. Given their differences in packet-handling
capabilities, the router's control plane hardware is more susceptible capabilities, the router's control plane hardware is more susceptible
to being overwhelmed by a Denial of Service (DoS) attack than the to being overwhelmed by a Denial-of-Service (DoS) attack than the
forwarding plane's ASICs. It is imperative that the router control forwarding plane's ASICs. It is imperative that the router control
plane remains stable regardless of traffic load to and from the plane remain stable regardless of traffic load to and from the device
device because the router control plane is what drives the because the router control plane is what drives the programming of
programming of the forwarding plane. the forwarding plane.
The router control plane also processes traffic destined to the The router control plane also processes traffic destined to the
router, and because of the wider range of functionality is more router, and because of the wider range of functionality is more
susceptible to security vulnerabilities and a more likely target for susceptible to security vulnerabilities and a more likely target for
a DoS attack than the forwarding plane. a DoS attack than the forwarding plane.
It is advisable to protect the router control plane by implementing It is advisable to protect the router control plane by implementing
mechanisms to filter completely or rate limit traffic not required at mechanisms to filter completely or rate-limit traffic not required at
the control plane level (i.e., unwanted traffic). Router Control the control plane level (i.e., unwanted traffic). "Router control
Plane Protection is the concept of filtering or rate limiting plane protection" is the concept of filtering or rate-limiting
unwanted traffic which would be diverted from the forwarding plane up unwanted traffic that would be diverted from the forwarding plane up
to the router control plane. The closer to the forwarding plane and to the router control plane. The closer the filters and rate
line-rate hardware the filters and rate-limiters are, the more limiters are to the forwarding plane and line-rate hardware, the more
effective the protection is and the more resistant the system is to effective the protection is and the more resistant the system is to
DoS attacks. This memo demonstrates one example of how to deploy a DoS attacks. This memo demonstrates one example of how to deploy a
policy filter that satisfies a set of sample traffic matching, policy filter that satisfies a set of sample traffic-matching,
filtering and rate limiting criteria. filtering, and rate-limiting criteria.
Note that the filters described in this memo are applied only to
traffic that is destined for the router, and not to all traffic that
is passing through the router.
2. Applicability Statement 2. Applicability Statement
The method described in Section 3 and depicted in Figure 1 The method described in Section 3 and depicted in Figure 1
illustrates how to protect the router control plane from unwanted illustrates how to protect the router control plane from unwanted
traffic. Recognizing that deployment scenarios will vary, the exact traffic. Recognizing that deployment scenarios will vary, the exact
implementation is not generally applicable in all situations. The implementation is not generally applicable in all situations. The
categorization of legitimate router control plane traffic is categorization of legitimate router control plane traffic is
critically important in a successful implementation. critically important in a successful implementation.
The examples given in this memo are simplified and minimalistic, The examples given in this memo are simplified and minimalistic,
designed to illustrate the concept of protecting the router's control designed to illustrate the concept of protecting the router's control
plane. From them, operators can extrapolate specifics based on their plane. From them, operators can extrapolate specifics based on their
unique configuration and environment. This document is about unique configuration and environment. This document is about
semantics and Appendix A exemplifies syntax. For additional router semantics, and Appendix A exemplifies syntax. For additional router
vendor implementations, or other converged devices, the syntax should vendor implementations, or other converged devices, the syntax should
be translated to the respective language in a manner that preserves be translated to the respective language in a manner that preserves
the semantics. the semantics.
Additionally, the need to provide the router control plane with Additionally, the need to provide the router control plane with
isolation, stability and protection against rogue packets has been isolation, stability, and protection against rogue packets has been
incorporated into router designs for some time. Consequently, there incorporated into router designs for some time. Consequently, there
may be other vendor or implementation specific router control plane may be other vendor or implementation specific router control plane
protection mechanisms that are active by default or always active. protection mechanisms that are active by default or always active.
Those approaches may apply in conjunction with or in addition to the Those approaches may apply in conjunction with, or in addition to,
method described in Section 3 and illustrated in Appendices A.1 and the method described in Section 3 and illustrated in Appendices A.1
A.2. Those implementations should be considered as part of an and A.2. Those implementations should be considered as part of an
overall traffic management plan but are outside the scope of this overall traffic management plan but are outside the scope of this
document. document.
This method is applicable for IPv4 as well as IPv6 address families, This method is applicable for IPv4 as well as IPv6 address families,
and the legitimate traffic example in Section 3.1 provides examples and the legitimate traffic example in Section 3.1 provides examples
for both. for both.
3. Method 3. Method
In this memo, the authors demonstrate how a filter protecting the In this memo, the authors demonstrate how a filter protecting the
router control plane can be deployed. In Section 3.1, a sample router control plane can be deployed. In Section 3.1, a sample
router is introduced and all traffic that its control plane must router is introduced, and all traffic that its control plane must
process is identified. In Section 3.2, filter design concepts are process is identified. In Section 3.2, filter design concepts are
discussed. Cisco (Cisco IOS software) and Juniper (JUNOS) discussed. Cisco (Cisco IOS software) and Juniper (JUNOS)
implementations are provided in Appendices A.1 and A.2, respectively. implementations are provided in Appendices A.1 and A.2, respectively.
3.1. Legitimate Traffic 3.1. Legitimate Traffic
In this example, the router control plane must process traffic per In this example, the router control plane must process traffic (i.e.,
the following criteria: traffic destined to the router and not through the router) per the
following criteria:
o Drop all IP packets that are fragments (see Section 3.3) o Drop all IP packets that are fragments (see Section 3.3)
o Permit ICMP and ICMPv6 traffic from any source, rate-limited to o Permit ICMP and ICMPv6 traffic from any source, rate-limited to
500 kbps for each category 500 kbps for each category
o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and
OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10) OSPFv3 traffic from IPv6 Link-Local unicast addresses (fe80::/10)
o Permit iBGP traffic from routers within subnets 192.0.2.0/24 and o Permit internal BGP (iBGP) traffic from routers within subnets
2001:DB8:1::/48 192.0.2.0/24 and 2001:db8:1::/48
o Permit eBGP traffic from eBGP peers 198.51.100.25, 198.51.100.27, o Permit external BGP (eBGP) traffic from eBGP peers 198.51.100.25,
198.51.100.29, and 198.51.100.31 and IPv6 peers 2001:DB8:100::25, 198.51.100.27, 198.51.100.29, and 198.51.100.31; and IPv6 peers
2001:DB8:100::27, 2001:DB8:100::29, 2001:DB8:100::31 2001:db8:100::25, 2001:db8:100::27, 2001:db8:100::29, and
2001:db8:100::31
o Permit DNS traffic from DNS servers within subnet 198.51.100.0/30 o Permit DNS traffic from DNS servers within subnet 198.51.100.0/30
and 2001:DB8:100:1::/64 and 2001:db8:100:1::/64
o Permit NTP traffic from NTP servers within subnet 198.51.100.4/30 o Permit NTP traffic from NTP servers within subnet 198.51.100.4/30
and 2001:DB8:100:2::/64 and 2001:db8:100:2::/64
o Permit SSH traffic from network management stations within subnet o Permit Secure SHell (SSH) traffic from network management stations
198.51.100.128/25 and 2001:DB8:100:3::/64 within subnet 198.51.100.128/25 and 2001:db8:100:3::/64
o Permit SNMP traffic from network management stations within subnet o Permit Simple Network Management Protocol (SNMP) traffic from
198.51.100.128/25 and 2001:DB8:100:3::/64 network management stations within subnet 198.51.100.128/25 and
2001:db8:100:3::/64
o Permit RADIUS authentication and accounting replies from RADIUS o Permit RADIUS authentication and accounting replies from RADIUS
servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: servers 198.51.100.9, 198.51.100.10, 2001:db8:100::9, and
DB8:100::10 that are listening on UDP ports 1812 and 1813 2001:db8:100::10 that are listening on UDP ports 1812 and 1813
(Internet Assigned Numbers Authority (IANA) RADIUS ports). Note (Internet Assigned Numbers Authority (IANA) RADIUS ports). Note
that this does not accomodate a server using the original UDP that this does not accommodate a server using the original UDP
ports of 1645 and 1646. ports of 1645 and 1646
o Permit all other IPv4 and IPv6 traffic that was not explicitly o Permit all other IPv4 and IPv6 traffic that was not explicitly
matched in a class above, rate-limited to 500 kbps, and drop above matched in a class above, rate-limited to 500 kbps, and drop above
that rate for each category that rate for each category
o Permit non-IP traffic (e.g., CLNS, IPX, PPP LCP, etc.), rate- o Permit non-IP traffic (e.g., Connectionless Network Service
limited to rate of 250 kbps, and drop all remaining traffic above (CLNS), Internetwork Packet Exchange (IPX), PPP Link Control
that rate Protocol (LCP), etc.), rate-limited to 250 kbps, and drop all
remaining traffic above that rate
The characteristics of legitimate traffic will vary from network to The characteristics of legitimate traffic will vary from network to
network. To illustrate this, a router implementing the DHCP relay network. To illustrate this, a router implementing the DHCP relay
function can rate limit inbound DHCP traffic from clients and function can rate-limit inbound DHCP traffic from clients and
restrict traffic from servers to a list of known DHCP servers. The restrict traffic from servers to a list of known DHCP servers. The
list of criteria above is provided for example only. list of criteria above is provided for example only.
3.2. Filter Design 3.2. Filter Design
A filter is installed on the forwarding plane. This filter counts A filter is installed on the forwarding plane. This filter counts
and applies the actions to the categories of traffic described in and applies the actions to the categories of traffic described in
Section 3.1. Because the filter is enforced in the forwarding plane, Section 3.1. Because the filter is enforced in the forwarding plane,
it prevents traffic from consuming bandwidth on the interface that it prevents traffic from consuming bandwidth on the interface that
connects the forwarding plane to the router control plane. The connects the forwarding plane to the router control plane. The
counters serve as an important forensic tool for the analysis of counters serve as an important forensic tool for the analysis of
potential attacks, and as an invaluable debugging and troubleshooting potential attacks, and as an invaluable debugging and troubleshooting
aid. By adjusting the granularity and order of the filters, more aid. By adjusting the granularity and order of the filters, more
granular forensics can be performed (i.e., create a filter that granular forensics can be performed (i.e., create a filter that
matches only traffic allowed from a group of IP addresses for a given matches only traffic allowed from a group of IP addresses for a given
protocol followed by a filter that denies all traffic for that protocol followed by a filter that denies all traffic for that
protocol). This would allow for counters to be monitored for the protocol). This would allow for counters to be monitored for the
allowed protocol filter as well as any traffic matching the specific allowed protocol filter, as well as any traffic matching the specific
protocol that didn't originate from the explicitly allowed hosts. protocol that didn't originate from the explicitly allowed hosts.
In addition to the filters, rate-limiters for certain classes of In addition to the filters, rate limiters for certain classes of
traffic are also installed in the forwarding plane as defined in traffic are also installed in the forwarding plane as defined in
Section 3.1. These rate limiters help further control the traffic Section 3.1. These rate limiters help further control the traffic
that will reach the router control plane for each filtered class as that will reach the router control plane for each filtered class as
well as all traffic not matching an explicit class. The actual rates well as all traffic not matching an explicit class. The actual rates
selected for various classes is network deployment specific; analysis selected for various classes are network deployment specific;
of the rates required for stability should be done periodically. It analysis of the rates required for stability should be done
is important to note that the most significant factor to consider periodically. It is important to note that the most significant
regarding the traffic profile going to the router control plane is factor to consider regarding the traffic profile going to the router
the packets per second (pps) rate. Therefore, careful consideration control plane is the packets per second (pps) rate. Therefore,
must be given to determine the maximum packets per second rate that careful consideration must be given to determine the maximum pps rate
could be generated from a given set of packet size and bandwidth that could be generated from a given set of packet size and bandwidth
usage scenarios. usage scenarios.
Syntactically, these filters explicitly define "allowed" traffic Syntactically, these filters explicitly define "allowed" traffic
(including IP addresses, protocols, and ports), define acceptable (including IP addresses, protocols, and ports), define acceptable
actions for these acceptable traffic profiles (e.g., rate-limit or actions for these acceptable traffic profiles (e.g., rate-limit or
simply permit the traffic), and then discard all traffic destined to simply permit the traffic), and then discard all traffic destined to
the router control plane that is not within the specifications of the the router control plane that is not within the specifications of the
policy definition. policy definition.
In an actual production environment, predicting a complete and In an actual production environment, predicting a complete and
exhaustive list of traffic necessary to reach the router's control exhaustive list of traffic necessary to reach the router's control
plane for day-to-day operation may not be as obvious as the example plane for day-to-day operation may not be as obvious as the example
described herein. One recommended method to gauge this set of described herein. One recommended method to gauge this set of
traffic is to allow all traffic initially, and audit the traffic that traffic is to allow all traffic initially, and audit the traffic that
reaches the router control plane before applying any explicit filters reaches the router control plane before applying any explicit filters
or rate limits. See the Section 3.3 section below for more or rate limits. See Section 3.3 below for more discussion of this
discussion of this topic. topic.
The filter design provided in this document is intentionally limited The filter design provided in this document is intentionally limited
to attachment at the local router in question (e.g., a 'service- to attachment at the local router in question (e.g., a "service-
policy' attached to the 'control-plane' in Cisco IOS, or a firewall policy" attached to the "control-plane" in Cisco IOS, or a firewall
filter attached to the 'lo0' interface in JUNOS). While virtually filter attached to the "lo0" interface in JUNOS). While virtually
all production environments utilize and rely heavily upon edge all production environments utilize and rely heavily upon edge
protection or interface filtering, these methods of router protection protection or interface filtering, these methods of router protection
are beyond the intended scope of this document. Additionally, the are beyond the intended scope of this document. Additionally, the
protocols themselves that are allowed to reach the router control protocols themselves that are allowed to reach the router control
plane (e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH, plane (e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH,
TLS, ESP, etc.) may have cryptographic security methods applied to TLS, ESP, etc.) may have cryptographic security methods applied to
them, and the method of router control plane protection provided them, and the method of router control plane protection provided
herein is not a replacement for those cryptographic methods. herein is not a replacement for those cryptographic methods.
3.3. Design Trade-offs 3.3. Design Trade-Offs
In designing the protection method, there are two independent parts In designing the protection method, there are two independent parts
to consider: the classification of traffic (i.e., which traffic is to consider: the classification of traffic (i.e., which traffic is
matched by the filters), and the policy actions taken on the matched by the filters), and the policy actions taken on the
classified traffic (i.e., drop, permit, rate limit, etc.). classified traffic (i.e., drop, permit, rate-limit, etc.).
There are different levels of granularity utilized for traffic There are different levels of granularity utilized for traffic
classification. For example, allowing all traffic from specific classification. For example, allowing all traffic from specific
source IP addresses versus allowing only a specific set of protocols source IP addresses versus allowing only a specific set of protocols
from those specific source IP addresses will each affect a different from those specific source IP addresses will each affect a different
subset of traffic. subset of traffic.
Similarly, the policy actions taken on the classified traffic have Similarly, the policy actions taken on the classified traffic have
degrees of impact that may not become immediately obvious. For degrees of impact that may not become immediately obvious. For
example, discarding all ICMP traffic will have a negative impact on example, discarding all ICMP traffic will have a negative impact on
the operational use of ICMP tools such as ping or traceroute to debug the operational use of ICMP tools such as ping or traceroute to debug
network issues or to test deployment of a new circuit. Expanding on network issues or to test deployment of a new circuit. Expanding on
this, in a real production network, an astute operator could define this, in a real production network, an astute operator could define
varying rate limits for ICMP such that internal traffic is granted varying rate limits for ICMP such that internal traffic is granted
uninhibited access to the router control plane, while traffic from uninhibited access to the router control plane, while traffic from
external addresses is rate limited. Operators should pay special external addresses is rate-limited. Operators should pay special
attention to the new functionality and roles that ICMPv6 has in the attention to the new functionality and roles that ICMPv6 has in the
overall operation of IPv6 when designing the rate limit policies. overall operation of IPv6 when designing the rate-limit policies.
Example functions include Neighbor Discovery (ND) and Multicast Example functions include Neighbor Discovery (ND) and Multicast
Listener Discovery version 2 (MLDv2). Listener Discovery version 2 (MLDv2).
It is important to note that both classification and policy action It is important to note that both classification and policy action
decisions are accompanied by respective trade-offs. Two examples of decisions are accompanied by respective trade-offs. Two examples of
these trade-off decisions are, operational complexity at the expense these trade-off decisions are operational complexity at the expense
of policy and statistics gathering detail, and tighter protection at of policy and statistics-gathering detail, and tighter protection at
the expense of network supportability and troubleshooting ability. the expense of network supportability and troubleshooting ability.
Two types of traffic that need special consideration are IP fragments Two types of traffic that need special consideration are IP fragments
and IP optioned packets: and IP optioned packets:
For network deployments where IP fragmentation is necessary, a o For network deployments where IP fragmentation is necessary, a
blanket policy of dropping all fragments may not be feasible. blanket policy of dropping all fragments destined to the router
However, many deployments allow network configurations such that control plane may not be feasible. However, many deployments
the router control plane should never see a fragmented datagram. allow network configurations such that the router control plane
Since many attacks rely on IP fragmentation, the example policy should never see a fragmented datagram. Since many attacks rely
included herein drops all fragments. on IP fragmentation, the example policy included herein drops all
fragments destined to the router control plane.
Similarly, some deployments may chose to drop all IP optioned o Similarly, some deployments may choose to drop all IP optioned
packets. Others may need to loosen the constraint to allow for packets. Others may need to loosen the constraint to allow for
protocols that require IP optioned packets such as Resource protocols that require IP optioned packets such as the Resource
Reservation Protocol (RSVP). The design trade-off is that Reservation Protocol (RSVP). The design trade-off is that
dropping all IP optioned packets protects the router from attacks dropping all IP optioned packets protects the router from attacks
that leverage malformed options, as well as attacks that rely on that leverage malformed options, as well as attacks that rely on
the slow-path processing (i.e., software processing path) of IP the slow-path processing (i.e., software processing path) of IP
optioned packets. For network deployments where the protocols optioned packets. For network deployments where the protocols do
used do not rely on IP options, the filter is simpler to design in not use IP options, the filter is simpler to design in that it can
that it can drop all packets with any IP option set. However for drop all packets with any IP option set. However, for networks
networks utilizing protocols relying on IP options, then the utilizing protocols relying on IP options, the filter to identify
filter to identify the legitimate packets is more complex. If the the legitimate packets is more complex. If the filter is not
filter is not designed correctly, it could result in the designed correctly, it could result in the inadvertent blackholing
inadvertent blackholing of traffic for those protocols. This of traffic for those protocols. This document does not include
document does not include IP options filter configurations; filter configurations for IP optioned packets; additional
additional IP options filtering explanations can be found at explanations regarding the filtering of packets based on the IP
[I-D.gont-opsec-ip-options-filtering]. options they contain can be found in [IP-OPTIONS-FILTER].
The goal of the method for protecting the router control plane is to The goal of the method for protecting the router control plane is to
minimize the possibility for disruptions by reducing the vulnerable minimize the possibility for disruptions by reducing the vulnerable
surface. The latter is inversely proportional to the granularity of surface, which is inversely proportional to the granularity of the
the filter design. The finer the granularity of the filter design filter design. The finer the granularity of the filter design (e.g.,
(e.g., filtering a more targeted subset of traffic from the rest of filtering a more targeted subset of traffic from the rest of the
the policed traffic, or isolating valid source addresses into a policed traffic, or isolating valid source addresses into a different
different class or classes) the smaller the probability of class or classes), the smaller the probability of disruption.
disruption.
In addition to the traffic matching explicit classes, care should be In addition to the traffic that matches explicit classes, care should
taken on the policy decision that governs the handling of traffic be taken on the policy decision that governs the handling of traffic
that would fall through the classification. Typically that traffic that would fall through the classification. Typically, that traffic
is referred to as traffic that gets matched in a default class. It is referred to as traffic that gets matched in a default class. It
may also be traffic that matches a blanket protocol specific class may also be traffic that matches a blanket protocol specific class
where previous classes that have more granular classification did not where previous classes that have more granular classification did not
match all packets for that specific protocol. The ideal policy would match all packets for that specific protocol. The ideal policy would
have explicit classes to match only the traffic specifically required have explicit classes to match only the traffic specifically required
at the router control plane and drop all other traffic that does not at the router control plane and would drop all other traffic that
match a predefined class. As most vendor implementations permit all does not match a predefined class. As most vendor implementations
traffic hitting the default class, an explicit drop action would need permit all traffic hitting the default class, an explicit drop action
to be configured in the policy such that the traffic hitting that would need to be configured in the policy such that the traffic
default class would be dropped versus permitted and delivered to the hitting that default class would be dropped, versus being permitted
router control plane. This approach requires rigorous traffic and delivered to the router control plane. This approach requires
pattern identification such that a default drop policy does not break rigorous traffic pattern identification such that a default drop
existing device functionality. The approach defined in this document policy does not break existing device functionality. The approach
allows the default traffic and rate limits it as opposed to dropping defined in this document allows the default traffic and rate-limits
it. This approach was chosen as a way to give time for the operator it as opposed to dropping it. This approach was chosen as a way to
to evaluate and characterize traffic in a production scenario prior give the operator time to evaluate and characterize traffic in a
to dropping all traffic not explicitly matched and permitted. production scenario prior to dropping all traffic not explicitly
However, it is highly recommended that after monitoring the traffic matched and permitted. However, it is highly recommended that after
matching the default class that explicit classes be defined to catch monitoring the traffic matching the default class, explicit classes
the legitimate traffic. After all legitimate traffic has been be defined to catch the legitimate traffic. After all legitimate
identified and explicitly allowed the default class should be traffic has been identified and explicitly allowed, the default class
configured to drop any remaining traffic. should be configured to drop any remaining traffic.
Additionally, the baselining and monitoring of traffic flows to the Additionally, the baselining and monitoring of traffic flows to the
router's control plane are critical in determining both the rates and router's control plane are critical in determining both the rates and
granularity of the policies being applied. It is also important to granularity of the policies being applied. It is also important to
validate the existing policies and rules or update them as the validate the existing policies and rules or update them as the
network evolves and its traffic dynamics change. Some possible ways network evolves and its traffic dynamics change. Some possible ways
to achieve this include individual policy counters that can be to achieve this include individual policy counters that can be
exported or retrieved for example via SNMP, and logging of filtering exported or retrieved, for example via SNMP, and logging of filtering
actions. actions.
Finally, the use of flow-based behavioral analysis or CLI functions Finally, the use of flow-based behavioral analysis or command-line
to identify what client/server functions a given router's control interface (CLI) functions to identify what client/server functions a
plane handles would be very useful during initial policy development given router's control plane handles would be very useful during
phases, and certainly for ongoing forensic analysis. initial policy development phases, and certainly for ongoing forensic
analysis.
3.4. Additional Protection Considerations 3.4. Additional Protection Considerations
In addition to the design described in this document of defining In addition to the design described in this document of defining
"allowed" traffic (i.e., identifying traffic that the control plane "allowed" traffic (i.e., identifying traffic that the control plane
must process) and limiting (e.g., rate-limiting or blocking) the must process) and limiting (e.g., rate-limiting or blocking) the
rest, the router control plane protection method can be applied to rest, the router control plane protection method can be applied to
thwart specific attacks. In particular, it can be used to protect thwart specific attacks. In particular, it can be used to protect
against TCP SYN flooding attacks and other denial-of-service attacks against TCP SYN flooding attacks and other Denial-of-Service attacks
that starve router control plane resources. that starve router control plane resources.
4. Security Considerations 4. Security Considerations
The filter above leaves the router susceptible to discovery from any The filters described in this document leave the router susceptible
host in the Internet. If network operators find this risk to discovery from any host in the Internet. If network operators
objectionable, they can reduce the exposure by restricting the sub- find this risk objectionable, they can reduce the exposure to
networks from which ICMP Echo requests or traceroute packets are discovery with ICMP by restricting the sub-networks from which ICMP
accepted. A similar concern exists for ICMPv6 traffic but on a Echo requests and potential traceroute packets (i.e., packets that
broader level due to the additional functionalities implemented in would trigger an ICMP Time Exceeded reply) are accepted, and
ICMPv6. Filtering recommendations for ICMPv6 can be found in therefore to which sub-networks ICMP responses (ICMP Echo Reply and
[RFC4890]. Moreover, different rate-limiting policies may be defined Time Exceeded) are sent. A similar concern exists for ICMPv6 traffic
for internally (e.g., from the NOC) versus externally sourced but on a broader level due to the additional functionalities
traffic. Note that this document is not targeted at the specifics of implemented in ICMPv6. Filtering recommendations for ICMPv6 can be
ICMP filtering or traffic filtering designed to prevent device found in [RFC4890]. Moreover, different rate-limiting policies may
discovery. be defined for internally (e.g., from the Network Operations Center
(NOC)) versus externally sourced traffic. Note that this document is
not targeted at the specifics of ICMP filtering or traffic filtering
designed to prevent device discovery.
The filter above does not block unwanted traffic having spoofed The filters described in this document do not block unwanted traffic
source addresses that match a defined traffic profile in Section 3.1. having spoofed source addresses that match a defined traffic profile
Network operators can mitigate this risk by preventing source address as discussed in Section 3.1. Network operators can mitigate this
spoofing with filters applied at the network edge. Refer to Section risk by preventing source address spoofing with filters applied at
5.3.8 of [RFC1812] for more information regarding source address the network edge. Refer to Section 5.3.8 of [RFC1812] for more
validation. Other methods also exist for limiting exposure to packet information regarding source address validation. Other methods also
spoofing such as the Generalized TTL Security Mechanism (GTSM) exist for limiting exposure to packet spoofing, such as the
[RFC5082] and Ingress Filtering [RFC2827] [RFC3704]. Generalized Time to Live (TTL) Security Mechanism (GTSM) [RFC5082]
and Ingress Filtering [RFC2827] [RFC3704].
The ICMP rate limiter specified in this filter protects the router The ICMP rate limiter specified for the filters described in this
from floods of ICMP traffic. However, during an ICMP flood, some document protects the router from floods of ICMP traffic; see
legitimate ICMP traffic may be dropped. Because of this, when Sections 3.1 and 3.3 for details. 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 operators discover a flood of ICMP traffic, they are highly motivated
to stop it at the source where the traffic is being originated. to stop it at the source where the traffic is being originated.
Additional considerations pertaining to the usage and handling of Additional considerations pertaining to the usage and handling of
traffic that utilizes the IP Router Alert Options can be found at traffic that utilizes the IP Router Alert Options can be found in
[I-D.ietf-intarea-router-alert-considerations], and additional IP [RTR-ALERT-CONS], and additional IP options filtering explanations
options filtering explanations can be found at can be found in [IP-OPTIONS-FILTER].
[I-D.gont-opsec-ip-options-filtering].
The treatment of exception traffic in the forwarding plane and the The treatment of exception traffic in the forwarding plane and the
generation of specific messages by the router control plane also generation of specific messages by the router control plane also
requires protection from a DoS attack. Specifically, the generation require protection from a DoS attack. Specifically, the generation
of ICMP Unreachable messages by the router control plane needs to be of ICMP Unreachable messages by the router control plane needs to be
rate-limited, either implicitly within the router's architecture or rate-limited, either implicitly within the router's architecture or
explicitly through configuration. When possible, different ICMP explicitly through configuration. When possible, different ICMP
Destination Unreachable codes (e.g., "fragmentation needed and DF Destination Unreachable codes (e.g., "fragmentation needed and DF
set") or "Packet Too Big" messages can receive a different rate- set") or "Packet Too Big" messages can receive a different rate-
limiting treatment. Continuous benchmarking of router generated ICMP limiting treatment. Continuous benchmarking of router-generated ICMP
traffic should be done before applying rate limits such that traffic should be done before applying rate limits such that
sufficient headroom is included to prevent inadvertent Path Maximum sufficient headroom is included to prevent inadvertent Path Maximum
Transmission Unit Discovery (PMTUD) blackhole scenarios during normal Transmission Unit Discovery (PMTUD) blackhole scenarios during normal
operation. It is also recommended to deploy explicit rate limiters operation. It is also recommended to deploy explicit rate limiters
where possible to improve troubleshooting and monitoring capability. where possible to improve troubleshooting and monitoring capability.
The explicit rate limiters in a class allow for monitoring tools to The explicit rate limiters in a class allow for monitoring tools to
detect and report when these rate limiters become active (i.e., when detect and report when these rate limiters become active (i.e., when
traffic is policed). This in turn serves as an indicator that either traffic is policed). This in turn serves as an indicator that either
the normal traffic rates have increased or out of policy traffic the normal traffic rates have increased or "out of policy" traffic
rates have been detected. More thorough analysis of the traffic rates have been detected. More thorough analysis of the traffic
flows and rate-limited traffic is needed to identify which of these flows and rate-limited traffic is needed to identify which of these
two cases triggered the rate limiters. For additional information two cases triggered the rate limiters. For additional information
regarding specific ICMP rate limiting see Section 4.3.2.8 of regarding specific ICMP rate-limiting, see Section 4.3.2.8 of
[RFC1812]. [RFC1812].
Additionally, the handling of TTL / Hop Limit expired traffic needs Additionally, the handling of TTL / Hop Limit expired traffic needs
protection. This traffic is not necessarily addressed to the device, protection. This traffic is not necessarily addressed to the device,
but it can get sent to the router control plane to process the TTL / but it can get sent to the router control plane to process the TTL /
Hop Limit expiration. For example, rate limiting the TTL / Hop Limit Hop Limit expiration. For example, rate-limiting the TTL / Hop Limit
expired traffic before sending the packets to the router control expired traffic before sending the packets to the router control
plane component that will generate the ICMP error, and distributing plane component that will generate the ICMP error, and distributing
the sending of ICMP errors to Line Card CPUs are protection the sending of ICMP errors to Line Card CPUs, are protection
mechanisms that mitigate attacks before they can negatively affect a mechanisms that mitigate attacks before they can negatively affect a
rate-limited router control plane component. rate-limited router control plane component.
5. IANA Considerations 5. Acknowledgements
[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 and The authors would like to thank Ron Bonica for providing initial and
ongoing review, suggestions, and valuable input. Pekka Savola, ongoing review, suggestions, and valuable input. Pekka Savola,
Warren Kumari, and Xu Chen provided very thorough and useful feedback Warren Kumari, and Xu Chen provided very thorough and useful feedback
that improved the document. Many thanks to John Kristoff, that improved the document. Many thanks to John Kristoff,
Christopher Morrow, and Donald Smith for a fruitful discussion around Christopher Morrow, and Donald Smith for a fruitful discussion around
the operational and manageability aspects of router control plane the operational and manageability aspects of router control plane
protection techniques. The authors would also like to thank Joel protection techniques. The authors would also like to thank
Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie Joel Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie
Parra, Seo Boon Ng, Manav Bhatia, German Martinez, Wen Zhang, Roni Parra, Seo Boon Ng, Manav Bhatia, German Martinez, Wen Zhang, Roni
Even, Acee Lindem, Glen Zorn, Joe Abley, Ralph Droms, and Stewart Even, Acee Lindem, Glen Zorn, Joe Abley, Ralph Droms, and Stewart
Bryant for providing thorough review, useful suggestions, and Bryant for providing thorough review, useful suggestions, and
valuable input. Many thanks to Jim Bailey and Raphan Han for valuable input. Assistance from Jim Bailey and Raphan Han in
providing technical direction and sample configuration guidance on providing technical direction and sample configuration guidance on
the IPv6 sections. Many thanks also go to Andrew Yourtchenko for his the IPv6 sections was also very much appreciated. Finally, the
review, comments, and willingness to present on behalf of the authors extend kudos to Andrew Yourtchenko for his review, comments,
authors. and willingness to present this document at IETF 78 (July 2010,
Maastricht, The Netherlands) on behalf of the authors.
7. Informative References 6. Informative References
[I-D.gont-opsec-ip-options-filtering] [IP-OPTIONS-FILTER]
Gont, F. and S. Fouant, "IP Options Filtering Gont, F. and S. Fouant, "IP Options Filtering
Recommendations", draft-gont-opsec-ip-options-filtering-00 Recommendations", Work in Progress, February 2010.
(work in progress), March 2010.
[I-D.ietf-intarea-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage",
draft-ietf-intarea-router-alert-considerations-02 (work in
progress), October 2010.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[RTR-ALERT-CONS]
Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", Work in Progress, March 2011.
Appendix A. Configuration Examples Appendix A. Configuration Examples
The configurations provided below are syntactical representations of The configurations provided below are syntactical representations of
the semantics described in the document and should be treated as non- the semantics described in the document and should be treated as
normative. non-normative.
A.1. Cisco Configuration A.1. Cisco Configuration
Refer to the Control Plane Policing (CoPP) document in the Cisco IOS Refer to the Control Plane Policing (CoPP) document in the Cisco IOS
Software Feature Guides for more information on the syntax and Software Feature Guides (available at <http://www.cisco.com/>) for
options available when configuring Control Plane Policing, available more information on the syntax and options available when configuring
at <http://www.cisco.com/>. Control Plane Policing.
!Start: Protecting The Router Control Plane !Start: Protecting The Router Control Plane
! !
!Control Plane Policing (CoPP) Configuration !Control Plane Policing (CoPP) Configuration
! !
!Access Control List Definitions !Access Control List Definitions
! !
ip access-list extended ICMP ip access-list extended ICMP
permit icmp any any permit icmp any any
ipv6 access-list ICMPv6 ipv6 access-list ICMPv6
skipping to change at page 16, line 24 skipping to change at page 17, line 8
!Control Plane Configuration !Control Plane Configuration
! !
control-plane control-plane
service-policy input COPP service-policy input COPP
! !
!End: Protecting The Router Control Plane !End: Protecting The Router Control Plane
A.2. Juniper Configuration A.2. Juniper Configuration
Refer to the Firewall Filter Configuration section of the Junos Refer to the Firewall Filter Configuration section of the Junos
Software Policy Framework Configuration Guide for more information on Software Policy Framework Configuration Guide (available at
the syntax and options available when configuring Junos firewall <http://www.juniper.net/>) for more information on the syntax and
filters, available at <http://www.juniper.net/>. options available when configuring Junos firewall filters.
policy-options { policy-options {
prefix-list IBGP-NEIGHBORS { prefix-list IBGP-NEIGHBORS {
192.0.2.0/24; 192.0.2.0/24;
} }
prefix-list EBGP-NEIGHBORS { prefix-list EBGP-NEIGHBORS {
198.51.100.25/32; 198.51.100.25/32;
198.51.100.27/32; 198.51.100.27/32;
198.51.100.29/32; 198.51.100.29/32;
198.51.100.31/32; 198.51.100.31/32;
skipping to change at page 23, line 43 skipping to change at page 25, line 28
} }
Authors' Addresses Authors' Addresses
Dave Dugal Dave Dugal
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
US US
Email: dave@juniper.net EMail: dave@juniper.net
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: cpignata@cisco.com EMail: cpignata@cisco.com
Rodney Dunn Rodney Dunn
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: rodunn@cisco.com EMail: rodunn@cisco.com
 End of changes. 80 change blocks. 
218 lines changed or deleted 225 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/