draft-ietf-opsec-protect-control-plane-01.txt   draft-ietf-opsec-protect-control-plane-02.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: January 8, 2011 R. Dunn Expires: February 7, 2011 R. Dunn
Cisco Systems Cisco Systems
July 7, 2010 August 6, 2010
Protecting The Router Control Plane Protecting The Router Control Plane
draft-ietf-opsec-protect-control-plane-01 draft-ietf-opsec-protect-control-plane-02
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 January 8, 2011. This Internet-Draft will expire on February 7, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . . 9 7. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Cisco Configuration . . . . . . . . . . . . . . . . . 10 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11
Appendix B. Juniper Configuration . . . . . . . . . . . . . . . . 12 A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 14
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, and 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.
Forwarding plane is typically described as router architecture Forwarding plane is typically described as router architecture
hardware and software components responsible for taking a packet hardware and software components responsible for taking a packet
coming in one interface, performing a lookup to identify the packet's coming in one interface, performing a lookup to identify the packet's
IP next hop and determine the outgoing interface towards the IP next hop and determine the outgoing interface towards the
destination, and forwarding the packet through the correct outgoing destination, and forwarding the packet through the correct outgoing
interface. interface.
skipping to change at page 4, line 32 skipping to change at page 4, line 32
The method described in Section 3 and depicted in Figure 1 The method described in Section 3 and depicted in Figure 1
illustrates how to protect the router control plane from unwanted illustrates how to protect the router control plane from unwanted
traffic. Recognizing that deployment scenarios will vary, the exact traffic. Recognizing that deployment scenarios will vary, the exact
implementation is not generally applicable in all situations. The implementation is not generally applicable in all situations. The
categorization of legitimate router control plane traffic is categorization of legitimate router control plane traffic is
critically important in a successful implementation. critically important in a successful implementation.
The examples given in this memo are simplified and minimalistic, The examples given in this memo are simplified and minimalistic,
designed to illustrate the concept of protecting the router's control designed to illustrate the concept of protecting the router's control
plane. From them, operators can extrapolate specifics based on their plane. From them, operators can extrapolate specifics based on their
unique configuration and environment. unique configuration and environment. This document is about
semantics and Appendix A exemplifies syntax. For additional router
vendor implementations, or other converged devices, the syntax should
be translated to the respective language in a manner that preserves
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 on by default or always on. Those
approaches may apply in conjunction with or in addition to the method approaches may apply in conjunction with or in addition to the method
described in Section 3 and illustrated in Appendices A and B. Those described in Section 3 and illustrated in Appendices A.1 and A.2.
implementations should be considered as part of an overall traffic Those implementations should be considered as part of an overall
management plan but are outside the scope of this document. 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
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 and B, respectively. implementations are provided in Appendices A.1 and A.2, respectively.
3.1. Legitimate Traffic 3.1. Legitimate Traffic
In this example, the router control plane must process traffic per In this example, the router control plane must process traffic 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 traffic from any source, rate-limited to 500 kbps o Permit ICMP and ICMPv6 traffic from any source, rate-limited to
500 kbps for each category
o Permit OSPF traffic from routers within the local network o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and
(192.0.2.0/24) OSPFv3 traffic from subnet 2001:DB8:1::/48
o Permit iBGP traffic from routers within the local network o Permit iBGP traffic from routers within subnets 192.0.2.0/24 and
(192.0.2.0/24) 2001:DB8:1::/48
o Permit eBGP traffic from known eBGP peers (198.51.100.25, o Permit eBGP traffic from eBGP peers 198.51.100.25, 198.51.100.27,
198.51.100.27, 198.51.100.29, and 198.51.100.31) 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
o Permit DNS traffic from local DNS resolvers (198.51.100.0/30) o Permit DNS traffic from DNS resolvers within subnet
198.51.100.0/30 and 2001:DB8:100:1::/64
o Permit NTP traffic from local NTP servers (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
o Permit SSH traffic from network management stations o Permit SSH traffic from network management stations within subnet
(198.51.100.128/25) 198.51.100.128/25 and 2001:DB8:100:3::/64
o Permit SNMP traffic from network management stations o Permit SNMP traffic from network management stations within subnet
(198.51.100.128/25) 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 and 198.51.100.10) that are listening on UDP servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001:
ports 1645 and 1646. Note that this doesn't account for a server DB8:100::10 that are listening on UDP ports 1645 and 1646. Note
using Internet Assigned Numbers Authority (IANA) ports 1812 and that this doesn't account for a server using Internet Assigned
1813 for RADIUS. Numbers Authority (IANA) ports 1812 and 1813 for RADIUS.
o Permit all other IP traffic that was not explicitly matched in a o Permit all other IPv4 and IPv6 traffic that was not explicitly
class above, rate-limited to 500 kbps, and drop above that rate matched in a class above, rate-limited to 500 kbps, and drop above
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 provided above is 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
skipping to change at page 6, line 30 skipping to change at page 6, line 40
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 futher 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
regarding the traffic profile going to the router control plane is
the packets per second (pps) rate. Therefore, consideration should
be taken when defining the rate limiters for various packet size
distributions the potential packet rates that would be allowed.
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
skipping to change at page 7, line 25 skipping to change at page 7, line 41
classified traffic. classified traffic.
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. set 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 may 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. external addresses is rate limited. Operators should pay special
attention to the new functionality and roles that ICMPv6 has in the
overall operation of IPv6 when designing the rate limit policies.
Example functions include neighbor discovery and multicast 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 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 fragments.
Similarly, some deployments may chose to drop all IP Optioned Similarly, some deployments may chose to drop all IP Optioned
Packets. Others may need to losen the constraint to allow for Packets. Others may need to losen the constraint to allow for
protocols that require IP Optioned packets such as RSVP. 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 potential disruptions. The granularity of the filter design minimize the possibility for disruptions by reducing the vulnerable
inversely correlates to the scope of the potential disruption. The surface. The latter is inversely proportional to the granularity of
finer the granularity of the filter design (e.g., isolating a more the filter design. The finer the granularity of the filter design
targeted subset of traffic from the rest of the policed traffic, or (e.g., isolating a more targeted subset of traffic from the rest of
isolating valid source addresses into a different class or classes) the policed traffic, or isolating valid source addresses into a
the smaller the scope of disruption. different class or classes) the smaller the probability of
disruption.
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. This is 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.
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 on the Internet. If network operators find this risk
objectionable, they can mitigate it by restricting the sub-networks objectionable, they can reduce the exposure by restricting the sub-
from which ICMP Echo requests or traceroute packets are accepted. networks from which ICMP Echo requests or traceroute packets are
Moreover, different rate-limiting policies may be defined for accepted. A similar concern exists for ICMPv6 traffic but on a
internally (e.g., from the NOC) versus externally sourced traffic. broader level due to the additional functionalities implemented in
ICMPv6. Filtering recommendations for ICMPv6 can be found in
[RFC4890]. Moreover, different rate-limiting policies may be defined
for internally (e.g., from the NOC) versus externally sourced
traffic. Note that this document is not targeted at the specifics of
ICMP filtering or traffic filtering designed to prevent device
discovery.
The filter above also leaves the router exposed to port scans from The filter above does not block unwanted traffic having spoofed
hosts spoofing the source addresses found in Section 3.1. Network source addresses that match a defined traffic profile in Section 3.1.
operators can mitigate this risk by preventing source address Network operators can mitigate this risk by preventing source address
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 its source. to cut it off at the source.
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. See Section 4.3.2.8 of [RFC1812]. explicitly through configuration. Continuous benchmarking of router
generated ICMP traffic should be done before applying rate limits
such that sufficient headroom is included to prevent inadvertent
PMTUD blackhole scenarios during normal operation. It is also
recommended to deploy explicit rate limiters where possible to
improve troubleshooting and monitoring capability. The explicit rate
limiters in a class allow for monitoring tools to detect and report
when the rate limiters become active which serve as an indicator that
either the normal traffic has increased or out of policy traffic
rates have been detected. 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 control plane to process the TTL / Hop but it can get sent to the control plane to process the TTL / Hop
Limit expiration. For example, rate limiting the TTL / Hop Limit 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 9, line 40 skipping to change at page 10, line 28
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, and Manav Bhatia for providing thorough review, useful Parra, Seo Boon Ng, Manav Bhatia, and German Martinez for providing
suggestions, and valuable input. thorough review, useful suggestions, and valuable input. Many thanks
to Jim Bailey and Raphan Han for providing technical direction and
sample configuration guidance on the IPv6 sections. Many thanks also
go to Andrew 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",
draft-ietf-intarea-router-alert-considerations-00 (work in draft-ietf-intarea-router-alert-considerations-01 (work in
progress), March 2010. progress), July 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
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. Cisco Configuration Appendix A. Configuration Examples
The configurations provided below are syntactical represenations of
the semantics described in the document and should be treated as non-
normative.
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
ip access-list extended ICMP ip access-list extended ICMP
permit icmp any any permit icmp any any
ipv6 access-list ICMPv6
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
permit 89 2001:DB8:1::/48 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
permit tcp 2001:DB8:1::/48 eq bgp any
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
permit tcp host 198.51.100.27 any eq bgp permit tcp host 198.51.100.27 any eq bgp
permit tcp host 198.51.100.29 eq bgp any permit tcp host 198.51.100.29 eq bgp any
permit tcp host 198.51.100.29 any eq bgp permit tcp host 198.51.100.29 any eq bgp
permit tcp host 198.51.100.31 eq bgp any permit tcp host 198.51.100.31 eq bgp any
permit tcp host 198.51.100.31 any eq bgp permit tcp host 198.51.100.31 any eq bgp
ipv6 access-list EBGPv6
permit tcp host 2001:DB8:100::25 eq bgp any
permit tcp host 2001:DB8:100::25 any eq bgp
permit tcp host 2001:DB8:100::27 eq bgp any
permit tcp host 2001:DB8:100::27 any eq bgp
permit tcp host 2001:DB8:100::29 eq bgp any
permit tcp host 2001:DB8:100::29 any eq bgp
permit tcp host 2001:DB8:100::31 eq bgp any
permit tcp host 2001:DB8:100::31 any eq bgp
ip access-list extended DNS ip access-list extended DNS
permit udp 198.51.100.0 0.0.0.252 eq domain any permit udp 198.51.100.0 0.0.0.252 eq domain any
ipv6 access-list DNSv6
permit udp 2001:DB8:100:1::/64 eq domain any
permit tcp 2001:DB8:100:1::/64 eq domain any
ip access-list extended NTP ip access-list extended NTP
permit udp 198.51.100.4 255.255.255.252 any eq ntp permit udp 198.51.100.4 255.255.255.252 any eq ntp
ipv6 access-list NTPv6
permit udp 2001:DB8:100:2::/64 any eq ntp
ip access-list extended SSH ip access-list extended SSH
permit tcp 198.51.100.0 0.0.0.128 any eq 22 permit tcp 198.51.100.128 0.0.0.128 any eq 22
ipv6 access-list SSHv6
permit tcp 2001:DB8:100:3::/64 any eq 22
ip access-list extended SNMP ip access-list extended SNMP
permit udp 198.51.100.128 0.0.0.125 any eq snmp permit udp 198.51.100.128 0.0.0.128 any eq snmp
ipv6 access-list SNMPv6
permit udp 2001:DB8:100:3::/64 any eq snmp
ip access-list extended RADIUS ip access-list extended RADIUS
permit udp host 198.51.100.9 eq 1645 any permit udp host 198.51.100.9 eq 1645 any
permit udp host 198.51.100.9 eq 1646 any permit udp host 198.51.100.9 eq 1646 any
permit udp host 198.51.100.10 eq 1645 any permit udp host 198.51.100.10 eq 1645 any
permit udp host 198.51.100.10 eq 1646 any permit udp host 198.51.100.10 eq 1646 any
ipv6 access-list RADIUSv6
permit udp host 2001:DB8:100::9 eq 1645 any
permit udp host 2001:DB8:100::9 eq 1646 any
permit udp host 2001:DB8:100::10 eq 1645 any
permit udp host 2001:DB8:100::10 eq 1646 any
ip access-list extended FRAGMENTS ip access-list extended FRAGMENTS
permit ip any any fragments permit ip any any fragments
ipv6 access-list FRAGMENTSv6
permit ipv6 any any fragments
ip access-list extended ALLOTHERIP ip access-list extended ALLOTHERIP
permit ip any any permit ip any any
ipv6 access-list ALLOTHERIPv6
permit ipv6 any any
! !
!Class Definitions !Class Definitions
! !
class-map match-all ICMP class-map match-any ICMP
match access-group name ICMP match access-group name ICMP
class-map match-all OSPF class-map match-any ICMPv6
match access-group name ICMPv6
class-map match-any OSPF
match access-group name OSPF match access-group name OSPF
class-map match-all IBGP match access-group name OSPFv3
class-map match-any IBGP
match access-group name IBGP match access-group name IBGP
class-map match-all EBGP match access-group name IBGPv6
class-map match-any EBGP
match access-group name EBGP match access-group name EBGP
class-map match-all DNS match access-group name EBGPv6
class-map match-any DNS
match access-group name DNS match access-group name DNS
class-map match-all NTP match access-group name DNSv6
class-map match-any NTP
match access-group name NTP match access-group name NTP
class-map match-all SSH match access-group name NTPv6
class-map match-any SSH
match access-group name SSH match access-group name SSH
class-map match-all SNMP match access-group name SSHv6
class-map match-any SNMP
match access-group name SNMP match access-group name SNMP
class-map match-all RADIUS match access-group name SNMPv6
class-map match-any RADIUS
match access-group name RADIUS match access-group name RADIUS
class-map match-all FRAGMENTS match access-group name RADIUSv6
class-map match-any FRAGMENTS
match access-group name FRAGMENTS match access-group name FRAGMENTS
class match-all ALLOTHERIP match access-group name FRAGMENTSv6
class-map match-any ALLOTHERIP
match access-group name ALLOTHERIP match access-group name ALLOTHERIP
class-map match-any ALLOTHERIPv6
match access-group name ALLOTHERIPv6
! !
!Policy Definition !Policy Definition
! !
policy-map COPP policy-map COPP
class FRAGMENTS class FRAGMENTS
drop drop
class ICMP class ICMP
police 500000 police 500000
conform-action transmit
exceed-action drop
violate-action drop
class ICMPv6
police 500000
conform-action transmit
exceed-action drop
violate-action drop
class OSPF class OSPF
class IBGP class IBGP
class EBGP class EBGP
class DNS class DNS
class NTP class NTP
class SSH class SSH
class SNMP class SNMP
class RADIUS class RADIUS
class ALLOTHERIP class ALLOTHERIP
police cir 500000 police cir 500000
conform-action transmit conform-action transmit
exceed-action drop exceed-action drop
violate-action drop violate-action drop
class ALLOTHERIPv6
police cir 500000
conform-action transmit
exceed-action drop
violate-action drop
class class-default class class-default
police cir 250000 police cir 250000
conform-action transmit conform-action transmit
exceed-action drop exceed-action drop
violate-action drop violate-action drop
! !
!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
Appendix B. Juniper Configuration A.2. Juniper Configuration
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;
} }
prefix-list RADIUS-SERVERS { prefix-list RADIUS-SERVERS {
198.51.100.9/32; 198.51.100.9/32;
198.51.100.10/32; 198.51.100.10/32;
} }
prefix-list IBGPv6-NEIGHBORS {
2001:DB8:1::/48;
}
prefix-list EBGPv6-NEIGHBORS {
2001:DB8:100::25/128;
2001:DB8:100::27/128;
2001:DB8:100::29/128;
2001:DB8:100::31/128;
}
prefix-list RADIUSv6-SERVERS {
2001:DB8:100::9/128;
2001:DB8:100::10/128;
}
} }
firewall { firewall {
policer 500kbps { policer 500kbps {
if-exceeding { if-exceeding {
bandwidth-limit 500k; bandwidth-limit 500k;
burst-size-limit 1500; burst-size-limit 1500;
} }
then discard; then discard;
} }
policer 250kbps { policer 250kbps {
if-exceeding { if-exceeding {
bandwidth-limit 250k; bandwidth-limit 250k;
burst-size-limit 1500; burst-size-limit 1500;
} }
then discard; then discard;
} }
skipping to change at page 15, line 44 skipping to change at page 18, line 22
destination-port snmp; destination-port snmp;
} }
then accept; then accept;
} }
term radius { term radius {
from { from {
source-prefix-list { source-prefix-list {
RADIUS-SERVERS; RADIUS-SERVERS;
} }
protocol udp; protocol udp;
port [1645 1646]; port [ 1645 1646 ];
} }
then accept; then accept;
} }
term default-term { term default-term {
then { then {
count copp-exceptions; count copp-exceptions;
log; log;
policer 500kbps; policer 500kbps;
accept; accept;
} }
} }
} }
} }
family inet6 {
filter protect-router-control-plane-v6 {
term fragv6 {
from {
next-header fragment;
}
then {
count frag-v6-discards;
log;
discard;
}
}
term icmpv6 {
from {
next-header icmpv6;
}
then {
policer 500kbps;
accept;
}
}
term ospfv3 {
from {
source-address {
2001:DB8:1::/48;
}
next-header ospf;
}
then accept;
}
term ibgpv6-connect {
from {
source-prefix-list {
IBGPv6-NEIGHBORS;
}
next-header tcp;
destination-port bgp;
}
then accept;
}
term ibgpv6-reply {
from {
source-prefix-list {
IBGPv6-NEIGHBORS;
}
next-header tcp;
port bgp;
}
then accept;
}
term ebgpv6-connect {
from {
source-prefix-list {
EBGPv6-NEIGHBORS;
}
next-header tcp;
destination-port bgp;
}
then accept;
}
term ebgpv6-reply {
from {
source-prefix-list {
EBGPv6-NEIGHBORS;
}
next-header tcp;
port bgp;
}
then accept;
}
term dnsv6 {
from {
source-address {
2001:DB8:100:1::/64;
}
next-header [ udp tcp ];
port domain;
}
then accept;
}
term ntpv6 {
from {
source-address {
2001:DB8:100:2::/64;
}
next-header udp;
destination-port ntp;
}
then accept;
}
term sshv6 {
from {
source-address {
2001:DB8:100:3::/64;
}
next-header tcp;
destination-port ssh;
}
then accept;
}
term snmpv6 {
from {
source-address {
2001:DB8:100:3::/64;
}
next-header udp;
destination-port snmp;
}
then accept;
}
term radiusv6 {
from {
source-prefix-list {
RADIUSv6-SERVERS;
}
next-header udp;
port [ 1645 1646 ];
}
then accept;
}
term default-term-v6 {
then {
policer 500kbps;
count copp-exceptions-v6;
log;
accept;
}
}
}
}
family any { family any {
filter protect-router-control-plane-non-ip { filter protect-router-control-plane-non-ip {
term rate-limit-non-ip { term rate-limit-non-ip {
then { then {
policer 250kbps; policer 250kbps;
accept; accept;
} }
} }
} }
} }
} }
interfaces { interfaces {
lo0 { lo0 {
unit 0 { unit 0 {
family inet { family inet {
filter input protect-router-control-plane; filter input protect-router-control-plane;
} }
family inet6 {
filter input protect-router-control-plane-v6;
}
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 David Dugal
 End of changes. 65 change blocks. 
77 lines changed or deleted 336 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/