draft-ietf-opsec-protect-control-plane-03.txt   draft-ietf-opsec-protect-control-plane-04.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 24, 2011 R. Dunn Expires: April 28, 2011 R. Dunn
Cisco Systems Cisco Systems
August 23, 2010 October 25, 2010
Protecting The Router Control Plane Protecting The Router Control Plane
draft-ietf-opsec-protect-control-plane-03 draft-ietf-opsec-protect-control-plane-04
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 24, 2011. This Internet-Draft will expire on April 28, 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 3, line 10 skipping to change at page 3, line 10
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11
A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 12 A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 12
A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 15 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 the router architecture hardware and
components for handling packets destined to the device itself as well software components for handling packets destined to the device
as building and sending packets originated locally on the device. itself as well as building and sending packets originated locally on
Forwarding plane is typically described as router architecture the device. The forwarding plane is typically described as the
hardware and software components responsible for taking a packet router architecture hardware and software components responsible for
coming in one interface, performing a lookup to identify the packet's receiving a packet on an incoming interface, performing a lookup to
IP next hop and determine the outgoing interface towards the identify the packet's IP next hop and determine the best outgoing
destination, and forwarding the packet through the correct outgoing interface towards the destination, and forwarding the packet out
interface. through the appropriate outgoing interface.
Visually it can be represented as the router's control plane hardware Visually it can be represented as the router's control plane hardware
sitting on top of and interfacing with the forwarding plane hardware, sitting on top of, and interfacing with, the forwarding plane
with interfaces connecting to other network devices. See Figure 1. hardware with interfaces connecting to other network 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 47 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 be overwhelmed by a DoS attack than forwarding plane ASICs. It is to being overwhelmed by a DoS attack than the forwarding plane's
imperative that the router control plane remain stable regardless of ASICs. It is imperative that the router control plane remain stable
traffic load to and from the device because the router control plane regardless of traffic load to and from the device because the router
is what drives the programming of the forwarding plane. control plane is what drives the programming of the forwarding plane.
The router control plane processes traffic destined to the router, The router control plane also processes traffic destined to the
and because of the wider range of functionality is more susceptible router, and because of the wider range of functionality is more
to security vulnerabilities and a more likely target for a DoS attack susceptible to security vulnerabilities and a more likely target for
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 out of the forwarding plane
up to the router control plane. The closer to the forwarding plane up to the router control plane. The closer to the forwarding plane
and line-rate hardware the filters and rate-limiters are, the more and 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 how to deploy an example policy DoS attacks. This memo demonstrates one example of how to deploy a
filter that satisfies a set of example traffic matching, filtering policy filter that satisfies a set of sample traffic matching,
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
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.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
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, rate-limited to rate of 250 kbps, and drop
all remaining traffic above that rate 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 provided above is 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
skipping to change at page 6, line 50 skipping to change at page 6, line 50
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, 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 drop to the bit bucket all simply permit the traffic), and then discard all traffic destined to
traffic destined to the router control plane that is not within the the router control plane that is not within the specifications of 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 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 the traffic that reaches the router traffic initially, and audit the traffic that reaches the router
control plane before applying any explicit filters or rate limits. control plane before applying any explicit filters or rate limits.
See the 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
skipping to change at page 8, line 16 skipping to change at page 8, line 16
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 the expense of network supportability and troubleshooting ability. at 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. For network deployments where IP
fragmentation is necessary, a blanket policy of dropping all fragmentation is necessary, a blanket policy of dropping all
fragments may not be possible. However, many deployments allow fragments may not be possible. However, many deployments allow
network configurations such that the router control plane should network configurations such that the router control plane should
never see a fragmented datagram. Since many attacks rely on ip never see a fragmented datagram. Since many attacks rely on IP
fragmentation the example policy referenced here drops all fragments. fragmentation, the example policy referenced here drops all
Similarly, some deployments may chose to drop all IP Optioned fragments. Similarly, some deployments may chose to drop all IP
Packets. Others may need to losen the constraint to allow for Optioned Packets. Others may need to loosen the constraint to allow
protocols that require IP Optioned packets such as RSVP. for protocols that require IP Optioned packets such as RSVP.
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 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 mach a at the control plane and drop all other traffic that does not match a
predefined class. As most vendor implementations permit all traffic predefined class. As most vendor implementations permit all traffic
hitting the default class, an explicit drop action would need to be hitting the default class, an explicit drop action would need to be
configured in the policy such that the traffic hitting that default configured in the policy such that the traffic hitting that default
class would be dropped versus permitted and delivered to the control class would be dropped versus permitted and delivered to the control
plane. This approach requires rigorous traffic pattern plane. This approach requires rigorous traffic pattern
identification such that a default drop policy does not break identification such that a default drop policy does not break
existing functionality of the device. The approach defined in this existing functionality of the device. The approach defined in this
document allows the default traffic and rate limits it rather than document allows the default traffic and rate limits it rather than
just dropping it. This approach was highlighted as a way to give just dropping it. This approach was highlighted as a way to give
time for the implementer to evaluate and characterize traffic in a time for the implementer to evaluate and characterize traffic in a
skipping to change at page 11, line 23 skipping to change at page 11, line 23
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",
draft-ietf-intarea-router-alert-considerations-01 (work in draft-ietf-intarea-router-alert-considerations-02 (work in
progress), July 2010. progress), October 2010.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "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., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
Appendix A. Configuration Examples Appendix A. Configuration Examples
The configurations provided below are syntactical represenations 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
!Start: Protecting The Router Control Plane !Start: Protecting The Router Control Plane
! !
!Policy-map Configuration !Policy-map Configuration
! !
!Access-list Definitions !Access-list Definitions
skipping to change at page 22, line 31 skipping to change at page 22, line 31
} }
family any { family any {
filter input protect-router-control-plane-non-ip; filter input protect-router-control-plane-non-ip;
} }
} }
} }
} }
Authors' Addresses Authors' Addresses
David Dugal Dave Dugal
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
US US
Email: ddugal@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
 End of changes. 17 change blocks. 
41 lines changed or deleted 42 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/