draft-ietf-opsec-protect-control-plane-04.txt   draft-ietf-opsec-protect-control-plane-05.txt 
OPSEC D. Dugal OPSEC D. Dugal
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational C. Pignataro Intended status: Informational C. Pignataro
Expires: April 28, 2011 R. Dunn Expires: June 15, 2011 R. Dunn
Cisco Systems Cisco Systems
October 25, 2010 December 12, 2010
Protecting The Router Control Plane Protecting The Router Control Plane
draft-ietf-opsec-protect-control-plane-04 draft-ietf-opsec-protect-control-plane-05
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 limited to an acceptable level. control plane, or rate limits such traffic to an acceptable level.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on June 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 3.4. Additional Protection Considerations . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11 7. Informative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 12
A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 12 A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 12
A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 15 A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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 routing 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 it can be represented as the router's control plane hardware Visually this architecture can be represented as the router's control
sitting on top of, and interfacing with, the forwarding plane plane hardware sitting on top of, and interfacing with, the
hardware with interfaces connecting to other network devices. See forwarding plane hardware with interfaces connecting to other network
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 48 skipping to change at page 3, line 48
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 software 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 DoS attack than the forwarding plane's to being overwhelmed by a Denial of Service (DoS) attack than the
ASICs. It is imperative that the router control plane remain stable forwarding plane's ASICs. It is imperative that the router control
regardless of traffic load to and from the device because the router plane remains stable regardless of traffic load to and from the
control plane is what drives the programming of the forwarding plane. device because the router control plane is what drives the
programming of 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 out of the forwarding plane unwanted traffic which would be diverted from the forwarding plane up
up to the router control plane. The closer to the forwarding plane to the router control plane. The closer to the forwarding plane and
and line-rate hardware the filters and rate-limiters are, the more line-rate hardware the filters and rate-limiters are, 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.
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
skipping to change at page 4, line 41 skipping to change at page 4, line 41
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, there may be other vendor or implementation specific Additionally, there may be other vendor or implementation specific
protection mechanisms that are on by default or always on. Those protection mechanisms that are active by default or always active.
approaches may apply in conjunction with or in addition to the method Those approaches may apply in conjunction with or in addition to the
described in Section 3 and illustrated in Appendices A.1 and A.2. method described in Section 3 and illustrated in Appendices A.1 and
Those implementations should be considered as part of an overall A.2. Those implementations should be considered as part of an
traffic management plan but are outside the scope of this document. overall traffic management plan but are outside the scope of this
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 sample legitimate traffic 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.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
In this example, the router control plane must process traffic per In this example, the router control plane must process traffic per
the following criteria: the following criteria:
o Drop all IP packets that are fragments o Drop all IP packets that are fragments
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 subnet 2001:DB8:1::/48 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 iBGP traffic from routers within subnets 192.0.2.0/24 and
2001:DB8:1::/48 2001:DB8:1::/48
o Permit eBGP traffic from eBGP peers 198.51.100.25, 198.51.100.27, o Permit eBGP traffic from eBGP peers 198.51.100.25, 198.51.100.27,
198.51.100.29, and 198.51.100.31 and IPv6 peers 2001:DB8:100::25, 198.51.100.29, and 198.51.100.31 and IPv6 peers 2001:DB8:100::25,
2001:DB8:100::27, 2001:DB8:100::29, 2001:DB8:100::31 2001:DB8:100::27, 2001:DB8:100::29, 2001:DB8:100::31
o Permit DNS traffic from DNS resolvers within subnet o Permit DNS traffic from DNS servers within subnet 198.51.100.0/30
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 SSH traffic from network management stations within subnet
198.51.100.128/25 and 2001:DB8:100:3::/64 198.51.100.128/25 and 2001:DB8:100:3::/64
o Permit SNMP traffic from network management stations within subnet o Permit SNMP traffic from network management stations within subnet
198.51.100.128/25 and 2001:DB8:100:3::/64 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 2001:
DB8:100::10 that are listening on UDP ports 1645 and 1646. Note DB8:100::10 that are listening on UDP ports 1645 and 1646. Note
that this doesn't account for a server using Internet Assigned that this doesn't account for a server using Internet Assigned
Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. Numbers Authority (IANA) ports 1812 and 1813 for RADIUS.
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, rate-limited to rate of 250 kbps, and drop o Permit non-IP traffic (e.g., CLNS, IPX, PPP LCP, etc.), rate-
all remaining traffic above that rate limited to rate of 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. The list of criteria above is provided for example only. network. The 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 on traffic allowed from a group of IP addresses for a matches only traffic allowed from a group of IP addresses for a given
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 traffic for allowed protocol filter as well as any traffic matching the specific
the specific protocol that didn't originate from the explicitly protocol that didn't originate from the explicitly allowed hosts.
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 control plane for each filtered class as well as that will reach the router control plane for each filtered class 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 and selected for various classes is network deployment specific; analysis
analysis of required rates for stability should be done periodically. of the rates required for stability should be done periodically. It
It is important to note that the most significant factor to consider is important to note that the most significant factor to consider
regarding the traffic profile going to the router control plane is regarding the traffic profile going to the router control plane is
the packets per second (pps) rate. Therefore, careful consideration the packets per second (pps) rate. Therefore, careful consideration
must be given to determine the maximum packets per second rate that must be given to determine the maximum packets per second rate that
could be generated from a given set of packet size and bandwidth 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 this obvious. One plane for day-to-day operation may not be as obvious as the example
recommended method to gauge this set of traffic is to allow all described herein. One recommended method to gauge this set of
traffic initially, and audit the traffic that reaches the router traffic is to allow all traffic initially, and audit the traffic that
control plane before applying any explicit filters or rate limits. reaches the router control plane before applying any explicit filters
See the Section 3.3 section below for more discussion of this topic. or rate limits. See the Section 3.3 section below for more
discussion of this 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 control plane protocols themselves that are allowed to reach the router control
(e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH, TLS, plane (e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH,
ESP, etc.) may have cryptographic security methods applied to them, TLS, ESP, etc.) may have cryptographic security methods applied to
and the method of router control plane protection herein provided is them, and the method of router control plane protection provided
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 turn up 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 and multicast listener Example functions include Neighbor Discovery (ND) and Multicast
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 of policy and statistics gathering detail, and tighter protection at
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. For network deployments where IP and IP optioned packets:
fragmentation is necessary, a blanket policy of dropping all
fragments may not be possible. However, many deployments allow For network deployments where IP fragmentation is necessary, a
network configurations such that the router control plane should blanket policy of dropping all fragments may not be feasible.
never see a fragmented datagram. Since many attacks rely on IP However, many deployments allow network configurations such that
fragmentation, the example policy referenced here drops all the router control plane should never see a fragmented datagram.
fragments. Similarly, some deployments may chose to drop all IP Since many attacks rely on IP fragmentation, the example policy
Optioned Packets. Others may need to loosen the constraint to allow included herein drops all fragments.
for protocols that require IP Optioned packets such as RSVP.
Similarly, some deployments may chose to drop all IP optioned
packets. Others may need to loosen the constraint to allow for
protocols that require IP optioned packets such as Resource
Reservation Protocol (RSVP). The design trade-off is that
dropping all IP optioned packets protects the router from attacks
that leverage malformed options, as well as attacks that rely on
the slow-path processing (i.e., software processing path) of IP
optioned packets. For network deployments where the protocols
used rely on IP options, the filter is simpler to design in that
it can drop all packets with any IP option set. However for
networks utilizing protocols relying on IP options, then the
filter to identify the legitimate packets is more complex. If the
filter is not designed correctly, it could result in the
inadvertent blackholing of traffic for those protocols. This
document does not include IP options filter configurations;
additional IP options filtering explanations can be found at
[I-D.gont-opsec-ip-options-filtering].
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. The latter is inversely proportional to the granularity of
the filter design. The finer the granularity of the filter design the filter design. The finer the granularity of the filter design
(e.g., isolating a more targeted subset of traffic from the rest of (e.g., filtering a more targeted subset of traffic from the rest of
the policed traffic, or isolating valid source addresses into a the policed traffic, or isolating valid source addresses into a
different class or classes) the smaller the probability of different 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 matching explicit classes, care should be
taken on the policy decision that governs the handling of traffic 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 control plane and drop all other traffic that does not match a at the router control plane and drop all other traffic that does not
predefined class. As most vendor implementations permit all traffic match a predefined class. As most vendor implementations permit all
hitting the default class, an explicit drop action would need to be traffic hitting the default class, an explicit drop action would need
configured in the policy such that the traffic hitting that default to be configured in the policy such that the traffic hitting that
class would be dropped versus permitted and delivered to the control default class would be dropped versus permitted and delivered to the
plane. This approach requires rigorous traffic pattern router control plane. This approach requires rigorous traffic
identification such that a default drop policy does not break pattern identification such that a default drop policy does not break
existing functionality of the device. The approach defined in this existing device functionality. The approach defined in this document
document allows the default traffic and rate limits it rather than allows the default traffic and rate limits it as opposed to dropping
just dropping it. This approach was highlighted as a way to give it. This approach was chosen as a way to give time for the operator
time for the implementer to evaluate and characterize traffic in a to evaluate and characterize traffic in a production scenario prior
production scenario prior to dropping all traffic not explicitly to dropping all traffic not explicitly matched and permitted.
matched and permitted. However, it is highly recommended that after However, it is highly recommended that after monitoring the traffic
monitoring the traffic matching the default class that explicit matching the default class that explicit classes be defined to catch
classes be defined to catch the legitimate traffic. After all the legitimate traffic. After all legitimate traffic has been
legitimate traffic is being explicitly allowed the default class identified and explicitly allowed the default class should be
should be configured to drop any remaining traffic. 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 CLI functions
to identify what client/server functions a given router's control to identify what client/server functions a given router's control
plane handles would be very useful during initial policy development plane handles would be very useful during initial policy development
phases, and certainly for forensic analysis afterwards. phases, and certainly for ongoing forensic analysis.
3.4. Additional Protection Considerations
In addition to the design described in this document of defining
"allowed" traffic (i.e., identifying traffic that the control plane
must process) and limiting (e.g., rate-limiting or blocking) the
rest, the router control plane protection method can be applied to
thwart specific attacks. In particular, it can be used to protect
against TCP SYN flooding attacks and other denial-of-service attacks
that starve router control plane resources.
4. Security Considerations 4. Security Considerations
The filter above leaves the router susceptible to discovery from any The filter above leaves the router susceptible to discovery from any
host on the Internet. If network operators find this risk host in the Internet. If network operators find this risk
objectionable, they can reduce the exposure by restricting the sub- objectionable, they can reduce the exposure by restricting the sub-
networks from which ICMP Echo requests or traceroute packets are networks from which ICMP Echo requests or traceroute packets are
accepted. A similar concern exists for ICMPv6 traffic but on a accepted. A similar concern exists for ICMPv6 traffic but on a
broader level due to the additional functionalities implemented in broader level due to the additional functionalities implemented in
ICMPv6. Filtering recommendations for ICMPv6 can be found in ICMPv6. Filtering recommendations for ICMPv6 can be found in
[RFC4890]. Moreover, different rate-limiting policies may be defined [RFC4890]. Moreover, different rate-limiting policies may be defined
for internally (e.g., from the NOC) versus externally sourced for internally (e.g., from the NOC) versus externally sourced
traffic. Note that this document is not targeted at the specifics of traffic. Note that this document is not targeted at the specifics of
ICMP filtering or traffic filtering designed to prevent device ICMP filtering or traffic filtering designed to prevent device
discovery. discovery.
skipping to change at page 10, line 8 skipping to change at page 10, line 38
The ICMP rate limiter specified in this filter protects the router The ICMP rate limiter specified in this filter protects the router
from floods of ICMP traffic. However, during an ICMP flood, some from floods of ICMP traffic. However, during an ICMP flood, some
legitimate ICMP traffic may be dropped. Because of this, when 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 at
[I-D.ietf-intarea-router-alert-considerations], and additional IP [I-D.ietf-intarea-router-alert-considerations], and additional IP
Options filtering explanations can be found at options filtering explanations can be found at
[I-D.gont-opsec-ip-options-filtering]. [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 requires 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. Continuous benchmarking of router explicitly through configuration. When possible, different ICMP
generated ICMP traffic should be done before applying rate limits Destination Unreachable codes (e.g., "fragmentation needed and DF
such that sufficient headroom is included to prevent inadvertent set") or "Packet Too Big" messages can receive a different rate-
PMTUD blackhole scenarios during normal operation. It is also limiting treatment. Continuous benchmarking of router generated ICMP
recommended to deploy explicit rate limiters where possible to traffic should be done before applying rate limits such that
improve troubleshooting and monitoring capability. The explicit rate sufficient headroom is included to prevent inadvertent Path Maximum
limiters in a class allow for monitoring tools to detect and report Transmission Unit Discovery (PMTUD) blackhole scenarios during normal
when the rate limiters become active which serve as an indicator that operation. It is also recommended to deploy explicit rate limiters
either the normal traffic has increased or out of policy traffic where possible to improve troubleshooting and monitoring capability.
rates have been detected. For additional information regarding The explicit rate limiters in a class allow for monitoring tools to
specific ICMP rate limiting see Section 4.3.2.8 of [RFC1812]. detect and report when these rate limiters become active (i.e., when
traffic is policed). This in turn serves as an indicator that either
the normal traffic rates have increased or out of policy traffic
rates have been detected. More thorough analysis of the traffic
flows and rate-limited traffic is needed to identify which of these
two cases triggered the rate limiters. For additional information
regarding specific ICMP rate limiting see Section 4.3.2.8 of
[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.
skipping to change at page 11, line 7 skipping to change at page 11, line 42
6. Acknowledgements 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 Joel
Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie
Parra, Seo Boon Ng, Manav Bhatia, and German Martinez for providing Parra, Seo Boon Ng, Manav Bhatia, German Martinez, Wen Zhang, Roni
thorough review, useful suggestions, and valuable input. Many thanks Even, and Acee Lindem for providing thorough review, useful
to Jim Bailey and Raphan Han for providing technical direction and suggestions, and valuable input. Many thanks to Jim Bailey and
sample configuration guidance on the IPv6 sections. Many thanks also Raphan Han for providing technical direction and sample configuration
go to Andrew Yourtchenko for his review, comments, and willingness to guidance on the IPv6 sections. Many thanks also go to Andrew
present on behalf of the authors. Yourtchenko for his review, comments, and willingness to present on
behalf of the authors.
7. Informative References 7. Informative References
[I-D.gont-opsec-ip-options-filtering] [I-D.gont-opsec-ip-options-filtering]
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", draft-gont-opsec-ip-options-filtering-00
(work in progress), March 2010. (work in progress), March 2010.
[I-D.ietf-intarea-router-alert-considerations] [I-D.ietf-intarea-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage", Faucheur, F., "IP Router Alert Considerations and Usage",
skipping to change at page 12, line 7 skipping to change at page 12, line 42
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
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 non-
normative. normative.
A.1. Cisco Configuration A.1. Cisco Configuration
Refer to the Control Plane Policing (CoPP) document in the Cisco IOS
Software Feature Guides for more information on the syntax and
options available when configuring Control Plane Policing, available
at <http://www.cisco.com/>.
!Start: Protecting The Router Control Plane !Start: Protecting The Router Control Plane
! !
!Policy-map Configuration !Control Plane Policing (CoPP) Configuration
!
!Access Control List Definitions
! !
!Access-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
permit icmp any any permit icmp any any
ip access-list extended OSPF ip access-list extended OSPF
permit ospf 192.0.2.0 0.0.0.255 any permit ospf 192.0.2.0 0.0.0.255 any
ipv6 access-list OSPFv3 ipv6 access-list OSPFv3
permit 89 2001:DB8:1::/48 any permit 89 FE80::/10 any
ip access-list extended IBGP 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 eq bgp any
permit tcp 192.0.2.0 0.0.0.255 any eq bgp permit tcp 192.0.2.0 0.0.0.255 any eq bgp
ipv6 access-list IBGPv6 ipv6 access-list IBGPv6
permit tcp 2001:DB8:1::/48 eq bgp any permit tcp 2001:DB8:1::/48 eq bgp any
permit tcp 2001:DB8:1::/48 any eq bgp permit tcp 2001:DB8:1::/48 any eq bgp
ip access-list extended EBGP ip access-list extended EBGP
permit tcp host 198.51.100.25 eq bgp any 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.25 any eq bgp
permit tcp host 198.51.100.27 eq bgp any permit tcp host 198.51.100.27 eq bgp any
skipping to change at page 15, line 22 skipping to change at page 16, line 15
! !
!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
Software Policy Framework Configuration Guide for more information on
the syntax and options available when configuring Junos firewall
filters, available at <http://www.juniper.net/>.
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 19, line 39 skipping to change at page 20, line 36
next-header icmpv6; next-header icmpv6;
} }
then { then {
policer 500kbps; policer 500kbps;
accept; accept;
} }
} }
term ospfv3 { term ospfv3 {
from { from {
source-address { source-address {
2001:DB8:1::/48; FE80::/10;
} }
next-header ospf; next-header ospf;
} }
then accept; then accept;
} }
term ibgpv6-connect { term ibgpv6-connect {
from { from {
source-prefix-list { source-prefix-list {
IBGPv6-NEIGHBORS; IBGPv6-NEIGHBORS;
} }
 End of changes. 39 change blocks. 
112 lines changed or deleted 162 lines changed or added

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