draft-ietf-opsec-protect-control-plane-02.txt   draft-ietf-opsec-protect-control-plane-03.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: February 7, 2011 R. Dunn Expires: February 24, 2011 R. Dunn
Cisco Systems Cisco Systems
August 6, 2010 August 23, 2010
Protecting The Router Control Plane Protecting The Router Control Plane
draft-ietf-opsec-protect-control-plane-02 draft-ietf-opsec-protect-control-plane-03
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 limited to an acceptable level.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 February 7, 2011. This Internet-Draft will expire on February 24, 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 . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . . 10 7. Informative References . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11
A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 11 A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 12
A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 14 A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 routing 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 router architecture hardware and software is generally described as router architecture hardware and software
components for handling packets destined to the device itself as well components for handling packets destined to the device itself as well
as building and sending packets originated locally on the device. as building and sending packets originated locally on the device.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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 on traffic allowed from a group of IP addresses for a
given protocol followed by a filter that denies all traffic for that given 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 traffic for
the specific protocol that didn't originate from the explicitly the specific 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 futher 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 control plane for each filtered class as well as
all traffic not matching an explicit class. The actual rates 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 and
analysis of required rates for stability should be done periodically. analysis of required rates for stability should be done periodically.
It is important to note that the most significant factor to consider It 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, consideration should the packets per second (pps) rate. Therefore, careful consideration
be taken when defining the rate limiters for various packet size must be given to determine the maximum packets per second rate that
distributions the potential packet rates that would be allowed. could be generated from a given set of packet size and bandwidth
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 drop to the bit bucket all simply permit the traffic), and then drop to the bit bucket all
traffic destined to the router control plane that is not within the traffic destined to the router control plane that is not within the
specifications of the policy definition. specifications of the 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 this obvious. One
recommended method to gauge this set of traffic is to allow all recommended method to gauge this set of traffic is to allow all
traffic initially, and audit what hits the router control plane traffic initially, and audit the traffic that reaches the router
before applying any explicit filters or rate limits. See the control plane before applying any explicit filters or rate limits.
Section 3.3 section below for more discussion of this topic. 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 control plane
(e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH, TLS, (e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH, TLS,
ESP, etc.) may have cryptographic security methods applied to them, ESP, etc.) may have cryptographic security methods applied to them,
and the method of router control plane protection herein provided is and the method of router control plane protection herein provided is
not a replacement for these cryptographic methods. 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. 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
set 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 turn up 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
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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., isolating 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
taken on the policy decision that governs the handling of traffic
that would fall through the classification. Typically that traffic
is referred to as traffic that gets matched in a default class. It
may also be traffic that matches a blanket protocol specific class
where previous classes that have more granular classification did not
match all packets for that specific protocol. The ideal policy would
have explicit classes to match only the traffic specifically required
at the control plane and drop all other traffic that does not mach a
predefined class. As most vendor implementations permit all traffic
hitting the default class, an explicit drop action would need to be
configured in the policy such that the traffic hitting that default
class would be dropped versus permitted and delivered to the control
plane. This approach requires rigorous traffic pattern
identification such that a default drop policy does not break
existing functionality of the device. The approach defined in this
document allows the default traffic and rate limits it rather than
just dropping it. This approach was highlighted as a way to give
time for the implementer to evaluate and characterize traffic in a
production scenario prior to dropping all traffic not explicitly
matched and permitted. However, it is highly recommended that after
monitoring the traffic matching the default class that explicit
classes be defined to catch the legitimate traffic. After all
legitimate traffic is being explicitly allowed the default class
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. This is 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 forensic analysis afterwards.
skipping to change at page 9, line 25 skipping to change at page 9, line 50
spoofing with filters applied at the network edge. Refer to Section spoofing with filters applied at the network edge. Refer to Section
5.3.8 of [RFC1812] for more information regarding source address 5.3.8 of [RFC1812] for more information regarding source address
validation. Other methods also exist for limiting exposure to packet validation. Other methods also exist for limiting exposure to packet
spoofing such as the Generalized TTL Security Mechanism (GTSM) spoofing such as the Generalized TTL Security Mechanism (GTSM)
[RFC5082] and Ingress Filtering [RFC2827] [RFC3704]. [RFC5082] and Ingress Filtering [RFC2827] [RFC3704].
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 cut it off at the source. 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. Continuous benchmarking of router
generated ICMP traffic should be done before applying rate limits generated ICMP traffic should be done before applying rate limits
such that sufficient headroom is included to prevent inadvertent such that sufficient headroom is included to prevent inadvertent
PMTUD blackhole scenarios during normal operation. It is also PMTUD blackhole scenarios during normal operation. It is also
recommended to deploy explicit rate limiters where possible to recommended to deploy explicit rate limiters where possible to
improve troubleshooting and monitoring capability. The explicit rate improve troubleshooting and monitoring capability. The explicit rate
limiters in a class allow for monitoring tools to detect and report limiters in a class allow for monitoring tools to detect and report
when the rate limiters become active which serve as an indicator that when the rate limiters become active which serve as an indicator that
either the normal traffic has increased or out of policy traffic either the normal traffic has increased or out of policy traffic
rates have been detected. For additional information regarding rates have been detected. For additional information regarding
specific ICMP rate limiting see Section 4.3.2.8 of [RFC1812]. 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 control plane to process the TTL / Hop but it can get sent to the router control plane to process the TTL /
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. IANA Considerations
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
 End of changes. 18 change blocks. 
23 lines changed or deleted 50 lines changed or added

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