idnits 2.17.1
draft-ietf-opsec-protect-control-plane-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (December 15, 2010) is 4878 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-04) exists of
draft-gont-opsec-ip-options-filtering-00
== Outdated reference: A later version (-10) exists of
draft-ietf-intarea-router-alert-considerations-02
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 OPSEC D. Dugal
3 Internet-Draft Juniper Networks
4 Intended status: Informational C. Pignataro
5 Expires: June 18, 2011 R. Dunn
6 Cisco Systems
7 December 15, 2010
9 Protecting The Router Control Plane
10 draft-ietf-opsec-protect-control-plane-06
12 Abstract
14 This memo provides a method for protecting a router's control plane
15 from undesired or malicious traffic. In this approach, all
16 legitimate router control plane traffic is identified. Once
17 legitimate traffic has been identified, a filter is deployed in the
18 router's forwarding plane. That filter prevents traffic not
19 specifically identified as legitimate from reaching the router's
20 control plane, or rate limits such traffic to an acceptable level.
22 Status of this Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on June 18, 2011.
39 Copyright Notice
41 Copyright (c) 2010 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
57 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
58 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
59 3.1. Legitimate Traffic . . . . . . . . . . . . . . . . . . . . 5
60 3.2. Filter Design . . . . . . . . . . . . . . . . . . . . . . 6
61 3.3. Design Trade-offs . . . . . . . . . . . . . . . . . . . . 7
62 3.4. Additional Protection Considerations . . . . . . . . . . . 9
63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
66 7. Informative References . . . . . . . . . . . . . . . . . . . . 12
67 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 12
68 A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 12
69 A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 16
70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
72 1. Introduction
74 Modern router architecture design maintains a strict separation of
75 forwarding and router control plane hardware and software. The
76 router control plane supports routing and management functions. It
77 is generally described as the router architecture hardware and
78 software components for handling packets destined to the device
79 itself as well as building and sending packets originated locally on
80 the device. The forwarding plane is typically described as the
81 router architecture hardware and software components responsible for
82 receiving a packet on an incoming interface, performing a lookup to
83 identify the packet's IP next hop and determine the best outgoing
84 interface towards the destination, and forwarding the packet out
85 through the appropriate outgoing interface.
87 Visually this architecture can be represented as the router's control
88 plane hardware sitting on top of, and interfacing with, the
89 forwarding plane hardware with interfaces connecting to other network
90 devices. See Figure 1.
92 +----------------+
93 | Router Control |
94 | Plane |
95 +------+ +-------+
96 | |
97 Router Control
98 Plane Protection
99 | |
100 +------+ +-------+
101 | Forwarding |
102 Interface X ==[ Plane ]== Interface Y
103 +----------------+
105 Figure 1: Router Control Plane Protection
107 Typically, forwarding plane functionality is realized in high-
108 performance Application Specific Integrated Circuits (ASICs) that are
109 capable of handling very high packet rates. By contrast, the router
110 control plane is generally realized in software on general purpose
111 processors. While software instructions run on both planes, the
112 router control plane software is usually not optimized for high speed
113 packet handling. Given their differences in packet handling
114 capabilities, the router's control plane hardware is more susceptible
115 to being overwhelmed by a Denial of Service (DoS) attack than the
116 forwarding plane's ASICs. It is imperative that the router control
117 plane remains stable regardless of traffic load to and from the
118 device because the router control plane is what drives the
119 programming of the forwarding plane.
121 The router control plane also processes traffic destined to the
122 router, and because of the wider range of functionality is more
123 susceptible to security vulnerabilities and a more likely target for
124 a DoS attack than the forwarding plane.
126 It is advisable to protect the router control plane by implementing
127 mechanisms to filter completely or rate limit traffic not required at
128 the control plane level (i.e., unwanted traffic). Router Control
129 Plane Protection is the concept of filtering or rate limiting
130 unwanted traffic which would be diverted from the forwarding plane up
131 to the router control plane. The closer to the forwarding plane and
132 line-rate hardware the filters and rate-limiters are, the more
133 effective the protection is and the more resistant the system is to
134 DoS attacks. This memo demonstrates one example of how to deploy a
135 policy filter that satisfies a set of sample traffic matching,
136 filtering and rate limiting criteria.
138 2. Applicability Statement
140 The method described in Section 3 and depicted in Figure 1
141 illustrates how to protect the router control plane from unwanted
142 traffic. Recognizing that deployment scenarios will vary, the exact
143 implementation is not generally applicable in all situations. The
144 categorization of legitimate router control plane traffic is
145 critically important in a successful implementation.
147 The examples given in this memo are simplified and minimalistic,
148 designed to illustrate the concept of protecting the router's control
149 plane. From them, operators can extrapolate specifics based on their
150 unique configuration and environment. This document is about
151 semantics and Appendix A exemplifies syntax. For additional router
152 vendor implementations, or other converged devices, the syntax should
153 be translated to the respective language in a manner that preserves
154 the semantics.
156 Additionally, the need to provide the router control plane with
157 isolation, stability and protection against rogue packets has been
158 incorporated into router designs for some time. Consequently, there
159 may be other vendor or implementation specific router control plane
160 protection mechanisms that are active by default or always active.
161 Those approaches may apply in conjunction with or in addition to the
162 method described in Section 3 and illustrated in Appendices A.1 and
163 A.2. Those implementations should be considered as part of an
164 overall traffic management plan but are outside the scope of this
165 document.
167 This method is applicable for IPv4 as well as IPv6 address families,
168 and the legitimate traffic example in Section 3.1 provides examples
169 for both.
171 3. Method
173 In this memo, the authors demonstrate how a filter protecting the
174 router control plane can be deployed. In Section 3.1, a sample
175 router is introduced and all traffic that its control plane must
176 process is identified. In Section 3.2, filter design concepts are
177 discussed. Cisco (Cisco IOS software) and Juniper (JUNOS)
178 implementations are provided in Appendices A.1 and A.2, respectively.
180 3.1. Legitimate Traffic
182 In this example, the router control plane must process traffic per
183 the following criteria:
185 o Drop all IP packets that are fragments (see Section 3.3)
187 o Permit ICMP and ICMPv6 traffic from any source, rate-limited to
188 500 kbps for each category
190 o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and
191 OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10)
193 o Permit iBGP traffic from routers within subnets 192.0.2.0/24 and
194 2001:DB8:1::/48
196 o Permit eBGP traffic from eBGP peers 198.51.100.25, 198.51.100.27,
197 198.51.100.29, and 198.51.100.31 and IPv6 peers 2001:DB8:100::25,
198 2001:DB8:100::27, 2001:DB8:100::29, 2001:DB8:100::31
200 o Permit DNS traffic from DNS servers within subnet 198.51.100.0/30
201 and 2001:DB8:100:1::/64
203 o Permit NTP traffic from NTP servers within subnet 198.51.100.4/30
204 and 2001:DB8:100:2::/64
206 o Permit SSH traffic from network management stations within subnet
207 198.51.100.128/25 and 2001:DB8:100:3::/64
209 o Permit SNMP traffic from network management stations within subnet
210 198.51.100.128/25 and 2001:DB8:100:3::/64
212 o Permit RADIUS authentication and accounting replies from RADIUS
213 servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001:
214 DB8:100::10 that are listening on UDP ports 1812 and 1813
215 (Internet Assigned Numbers Authority (IANA) RADIUS ports). Note
216 that this does not accomodate a server using the original UDP
217 ports of 1645 and 1646.
219 o Permit all other IPv4 and IPv6 traffic that was not explicitly
220 matched in a class above, rate-limited to 500 kbps, and drop above
221 that rate for each category
223 o Permit non-IP traffic (e.g., CLNS, IPX, PPP LCP, etc.), rate-
224 limited to rate of 250 kbps, and drop all remaining traffic above
225 that rate
227 The characteristics of legitimate traffic will vary from network to
228 network. To illustrate this, a router implementing the DHCP relay
229 function can rate limit inbound DHCP traffic from clients and
230 restrict traffic from servers to a list of known DHCP servers. The
231 list of criteria above is provided for example only.
233 3.2. Filter Design
235 A filter is installed on the forwarding plane. This filter counts
236 and applies the actions to the categories of traffic described in
237 Section 3.1. Because the filter is enforced in the forwarding plane,
238 it prevents traffic from consuming bandwidth on the interface that
239 connects the forwarding plane to the router control plane. The
240 counters serve as an important forensic tool for the analysis of
241 potential attacks, and as an invaluable debugging and troubleshooting
242 aid. By adjusting the granularity and order of the filters, more
243 granular forensics can be performed (i.e., create a filter that
244 matches only traffic allowed from a group of IP addresses for a given
245 protocol followed by a filter that denies all traffic for that
246 protocol). This would allow for counters to be monitored for the
247 allowed protocol filter as well as any traffic matching the specific
248 protocol that didn't originate from the explicitly allowed hosts.
250 In addition to the filters, rate-limiters for certain classes of
251 traffic are also installed in the forwarding plane as defined in
252 Section 3.1. These rate limiters help further control the traffic
253 that will reach the router control plane for each filtered class as
254 well as all traffic not matching an explicit class. The actual rates
255 selected for various classes is network deployment specific; analysis
256 of the rates required for stability should be done periodically. It
257 is important to note that the most significant factor to consider
258 regarding the traffic profile going to the router control plane is
259 the packets per second (pps) rate. Therefore, careful consideration
260 must be given to determine the maximum packets per second rate that
261 could be generated from a given set of packet size and bandwidth
262 usage scenarios.
264 Syntactically, these filters explicitly define "allowed" traffic
265 (including IP addresses, protocols, and ports), define acceptable
266 actions for these acceptable traffic profiles (e.g., rate-limit or
267 simply permit the traffic), and then discard all traffic destined to
268 the router control plane that is not within the specifications of the
269 policy definition.
271 In an actual production environment, predicting a complete and
272 exhaustive list of traffic necessary to reach the router's control
273 plane for day-to-day operation may not be as obvious as the example
274 described herein. One recommended method to gauge this set of
275 traffic is to allow all traffic initially, and audit the traffic that
276 reaches the router control plane before applying any explicit filters
277 or rate limits. See the Section 3.3 section below for more
278 discussion of this topic.
280 The filter design provided in this document is intentionally limited
281 to attachment at the local router in question (e.g., a 'service-
282 policy' attached to the 'control-plane' in Cisco IOS, or a firewall
283 filter attached to the 'lo0' interface in JUNOS). While virtually
284 all production environments utilize and rely heavily upon edge
285 protection or interface filtering, these methods of router protection
286 are beyond the intended scope of this document. Additionally, the
287 protocols themselves that are allowed to reach the router control
288 plane (e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH,
289 TLS, ESP, etc.) may have cryptographic security methods applied to
290 them, and the method of router control plane protection provided
291 herein is not a replacement for those cryptographic methods.
293 3.3. Design Trade-offs
295 In designing the protection method, there are two independent parts
296 to consider: the classification of traffic (i.e., which traffic is
297 matched by the filters), and the policy actions taken on the
298 classified traffic (i.e., drop, permit, rate limit, etc.).
300 There are different levels of granularity utilized for traffic
301 classification. For example, allowing all traffic from specific
302 source IP addresses versus allowing only a specific set of protocols
303 from those specific source IP addresses will each affect a different
304 subset of traffic.
306 Similarly, the policy actions taken on the classified traffic have
307 degrees of impact that may not become immediately obvious. For
308 example, discarding all ICMP traffic will have a negative impact on
309 the operational use of ICMP tools such as ping or traceroute to debug
310 network issues or to test deployment of a new circuit. Expanding on
311 this, in a real production network, an astute operator could define
312 varying rate limits for ICMP such that internal traffic is granted
313 uninhibited access to the router control plane, while traffic from
314 external addresses is rate limited. Operators should pay special
315 attention to the new functionality and roles that ICMPv6 has in the
316 overall operation of IPv6 when designing the rate limit policies.
317 Example functions include Neighbor Discovery (ND) and Multicast
318 Listener Discovery version 2 (MLDv2).
320 It is important to note that both classification and policy action
321 decisions are accompanied by respective trade-offs. Two examples of
322 these trade-off decisions are, operational complexity at the expense
323 of policy and statistics gathering detail, and tighter protection at
324 the expense of network supportability and troubleshooting ability.
326 Two types of traffic that need special consideration are IP fragments
327 and IP optioned packets:
329 For network deployments where IP fragmentation is necessary, a
330 blanket policy of dropping all fragments may not be feasible.
331 However, many deployments allow network configurations such that
332 the router control plane should never see a fragmented datagram.
333 Since many attacks rely on IP fragmentation, the example policy
334 included herein drops all fragments.
336 Similarly, some deployments may chose to drop all IP optioned
337 packets. Others may need to loosen the constraint to allow for
338 protocols that require IP optioned packets such as Resource
339 Reservation Protocol (RSVP). The design trade-off is that
340 dropping all IP optioned packets protects the router from attacks
341 that leverage malformed options, as well as attacks that rely on
342 the slow-path processing (i.e., software processing path) of IP
343 optioned packets. For network deployments where the protocols
344 used do not rely on IP options, the filter is simpler to design in
345 that it can drop all packets with any IP option set. However for
346 networks utilizing protocols relying on IP options, then the
347 filter to identify the legitimate packets is more complex. If the
348 filter is not designed correctly, it could result in the
349 inadvertent blackholing of traffic for those protocols. This
350 document does not include IP options filter configurations;
351 additional IP options filtering explanations can be found at
352 [I-D.gont-opsec-ip-options-filtering].
354 The goal of the method for protecting the router control plane is to
355 minimize the possibility for disruptions by reducing the vulnerable
356 surface. The latter is inversely proportional to the granularity of
357 the filter design. The finer the granularity of the filter design
358 (e.g., filtering a more targeted subset of traffic from the rest of
359 the policed traffic, or isolating valid source addresses into a
360 different class or classes) the smaller the probability of
361 disruption.
363 In addition to the traffic matching explicit classes, care should be
364 taken on the policy decision that governs the handling of traffic
365 that would fall through the classification. Typically that traffic
366 is referred to as traffic that gets matched in a default class. It
367 may also be traffic that matches a blanket protocol specific class
368 where previous classes that have more granular classification did not
369 match all packets for that specific protocol. The ideal policy would
370 have explicit classes to match only the traffic specifically required
371 at the router control plane and drop all other traffic that does not
372 match a predefined class. As most vendor implementations permit all
373 traffic hitting the default class, an explicit drop action would need
374 to be configured in the policy such that the traffic hitting that
375 default class would be dropped versus permitted and delivered to the
376 router control plane. This approach requires rigorous traffic
377 pattern identification such that a default drop policy does not break
378 existing device functionality. The approach defined in this document
379 allows the default traffic and rate limits it as opposed to dropping
380 it. This approach was chosen as a way to give time for the operator
381 to evaluate and characterize traffic in a production scenario prior
382 to dropping all traffic not explicitly matched and permitted.
383 However, it is highly recommended that after monitoring the traffic
384 matching the default class that explicit classes be defined to catch
385 the legitimate traffic. After all legitimate traffic has been
386 identified and explicitly allowed the default class should be
387 configured to drop any remaining traffic.
389 Additionally, the baselining and monitoring of traffic flows to the
390 router's control plane are critical in determining both the rates and
391 granularity of the policies being applied. It is also important to
392 validate the existing policies and rules or update them as the
393 network evolves and its traffic dynamics change. Some possible ways
394 to achieve this include individual policy counters that can be
395 exported or retrieved for example via SNMP, and logging of filtering
396 actions.
398 Finally, the use of flow-based behavioral analysis or CLI functions
399 to identify what client/server functions a given router's control
400 plane handles would be very useful during initial policy development
401 phases, and certainly for ongoing forensic analysis.
403 3.4. Additional Protection Considerations
405 In addition to the design described in this document of defining
406 "allowed" traffic (i.e., identifying traffic that the control plane
407 must process) and limiting (e.g., rate-limiting or blocking) the
408 rest, the router control plane protection method can be applied to
409 thwart specific attacks. In particular, it can be used to protect
410 against TCP SYN flooding attacks and other denial-of-service attacks
411 that starve router control plane resources.
413 4. Security Considerations
415 The filter above leaves the router susceptible to discovery from any
416 host in the Internet. If network operators find this risk
417 objectionable, they can reduce the exposure by restricting the sub-
418 networks from which ICMP Echo requests or traceroute packets are
419 accepted. A similar concern exists for ICMPv6 traffic but on a
420 broader level due to the additional functionalities implemented in
421 ICMPv6. Filtering recommendations for ICMPv6 can be found in
422 [RFC4890]. Moreover, different rate-limiting policies may be defined
423 for internally (e.g., from the NOC) versus externally sourced
424 traffic. Note that this document is not targeted at the specifics of
425 ICMP filtering or traffic filtering designed to prevent device
426 discovery.
428 The filter above does not block unwanted traffic having spoofed
429 source addresses that match a defined traffic profile in Section 3.1.
430 Network operators can mitigate this risk by preventing source address
431 spoofing with filters applied at the network edge. Refer to Section
432 5.3.8 of [RFC1812] for more information regarding source address
433 validation. Other methods also exist for limiting exposure to packet
434 spoofing such as the Generalized TTL Security Mechanism (GTSM)
435 [RFC5082] and Ingress Filtering [RFC2827] [RFC3704].
437 The ICMP rate limiter specified in this filter protects the router
438 from floods of ICMP traffic. However, during an ICMP flood, some
439 legitimate ICMP traffic may be dropped. Because of this, when
440 operators discover a flood of ICMP traffic, they are highly motivated
441 to stop it at the source where the traffic is being originated.
443 Additional considerations pertaining to the usage and handling of
444 traffic that utilizes the IP Router Alert Options can be found at
445 [I-D.ietf-intarea-router-alert-considerations], and additional IP
446 options filtering explanations can be found at
447 [I-D.gont-opsec-ip-options-filtering].
449 The treatment of exception traffic in the forwarding plane and the
450 generation of specific messages by the router control plane also
451 requires protection from a DoS attack. Specifically, the generation
452 of ICMP Unreachable messages by the router control plane needs to be
453 rate-limited, either implicitly within the router's architecture or
454 explicitly through configuration. When possible, different ICMP
455 Destination Unreachable codes (e.g., "fragmentation needed and DF
456 set") or "Packet Too Big" messages can receive a different rate-
457 limiting treatment. Continuous benchmarking of router generated ICMP
458 traffic should be done before applying rate limits such that
459 sufficient headroom is included to prevent inadvertent Path Maximum
460 Transmission Unit Discovery (PMTUD) blackhole scenarios during normal
461 operation. It is also recommended to deploy explicit rate limiters
462 where possible to improve troubleshooting and monitoring capability.
463 The explicit rate limiters in a class allow for monitoring tools to
464 detect and report when these rate limiters become active (i.e., when
465 traffic is policed). This in turn serves as an indicator that either
466 the normal traffic rates have increased or out of policy traffic
467 rates have been detected. More thorough analysis of the traffic
468 flows and rate-limited traffic is needed to identify which of these
469 two cases triggered the rate limiters. For additional information
470 regarding specific ICMP rate limiting see Section 4.3.2.8 of
471 [RFC1812].
473 Additionally, the handling of TTL / Hop Limit expired traffic needs
474 protection. This traffic is not necessarily addressed to the device,
475 but it can get sent to the router control plane to process the TTL /
476 Hop Limit expiration. For example, rate limiting the TTL / Hop Limit
477 expired traffic before sending the packets to the router control
478 plane component that will generate the ICMP error, and distributing
479 the sending of ICMP errors to Line Card CPUs are protection
480 mechanisms that mitigate attacks before they can negatively affect a
481 rate-limited router control plane component.
483 5. IANA Considerations
485 [RFC Editor: please remove this section prior to publication.]
487 This document has no IANA actions.
489 6. Acknowledgements
491 The authors would like to thank Ron Bonica for providing initial and
492 ongoing review, suggestions, and valuable input. Pekka Savola,
493 Warren Kumari, and Xu Chen provided very thorough and useful feedback
494 that improved the document. Many thanks to John Kristoff,
495 Christopher Morrow, and Donald Smith for a fruitful discussion around
496 the operational and manageability aspects of router control plane
497 protection techniques. The authors would also like to thank Joel
498 Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie
499 Parra, Seo Boon Ng, Manav Bhatia, German Martinez, Wen Zhang, Roni
500 Even, Acee Lindem, Glen Zorn, Joe Abley, Ralph Droms, and Stewart
501 Bryant for providing thorough review, useful suggestions, and
502 valuable input. Many thanks to Jim Bailey and Raphan Han for
503 providing technical direction and sample configuration guidance on
504 the IPv6 sections. Many thanks also go to Andrew Yourtchenko for his
505 review, comments, and willingness to present on behalf of the
506 authors.
508 7. Informative References
510 [I-D.gont-opsec-ip-options-filtering]
511 Gont, F. and S. Fouant, "IP Options Filtering
512 Recommendations", draft-gont-opsec-ip-options-filtering-00
513 (work in progress), March 2010.
515 [I-D.ietf-intarea-router-alert-considerations]
516 Faucheur, F., "IP Router Alert Considerations and Usage",
517 draft-ietf-intarea-router-alert-considerations-02 (work in
518 progress), October 2010.
520 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
521 RFC 1812, June 1995.
523 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
524 Defeating Denial of Service Attacks which employ IP Source
525 Address Spoofing", BCP 38, RFC 2827, May 2000.
527 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
528 Networks", BCP 84, RFC 3704, March 2004.
530 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
531 ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
533 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
534 Pignataro, "The Generalized TTL Security Mechanism
535 (GTSM)", RFC 5082, October 2007.
537 Appendix A. Configuration Examples
539 The configurations provided below are syntactical representations of
540 the semantics described in the document and should be treated as non-
541 normative.
543 A.1. Cisco Configuration
545 Refer to the Control Plane Policing (CoPP) document in the Cisco IOS
546 Software Feature Guides for more information on the syntax and
547 options available when configuring Control Plane Policing, available
548 at .
550 !Start: Protecting The Router Control Plane
551 !
552 !Control Plane Policing (CoPP) Configuration
553 !
554 !Access Control List Definitions
555 !
556 ip access-list extended ICMP
557 permit icmp any any
558 ipv6 access-list ICMPv6
559 permit icmp any any
560 ip access-list extended OSPF
561 permit ospf 192.0.2.0 0.0.0.255 any
562 ipv6 access-list OSPFv3
563 permit 89 FE80::/10 any
564 ip access-list extended IBGP
565 permit tcp 192.0.2.0 0.0.0.255 eq bgp any
566 permit tcp 192.0.2.0 0.0.0.255 any eq bgp
567 ipv6 access-list IBGPv6
568 permit tcp 2001:DB8:1::/48 eq bgp any
569 permit tcp 2001:DB8:1::/48 any eq bgp
570 ip access-list extended EBGP
571 permit tcp host 198.51.100.25 eq bgp any
572 permit tcp host 198.51.100.25 any eq bgp
573 permit tcp host 198.51.100.27 eq bgp any
574 permit tcp host 198.51.100.27 any eq bgp
575 permit tcp host 198.51.100.29 eq bgp any
576 permit tcp host 198.51.100.29 any eq bgp
577 permit tcp host 198.51.100.31 eq bgp any
578 permit tcp host 198.51.100.31 any eq bgp
579 ipv6 access-list EBGPv6
580 permit tcp host 2001:DB8:100::25 eq bgp any
581 permit tcp host 2001:DB8:100::25 any eq bgp
582 permit tcp host 2001:DB8:100::27 eq bgp any
583 permit tcp host 2001:DB8:100::27 any eq bgp
584 permit tcp host 2001:DB8:100::29 eq bgp any
585 permit tcp host 2001:DB8:100::29 any eq bgp
586 permit tcp host 2001:DB8:100::31 eq bgp any
587 permit tcp host 2001:DB8:100::31 any eq bgp
588 ip access-list extended DNS
589 permit udp 198.51.100.0 0.0.0.252 eq domain any
590 ipv6 access-list DNSv6
591 permit udp 2001:DB8:100:1::/64 eq domain any
592 permit tcp 2001:DB8:100:1::/64 eq domain any
593 ip access-list extended NTP
594 permit udp 198.51.100.4 255.255.255.252 any eq ntp
596 ipv6 access-list NTPv6
597 permit udp 2001:DB8:100:2::/64 any eq ntp
598 ip access-list extended SSH
599 permit tcp 198.51.100.128 0.0.0.128 any eq 22
600 ipv6 access-list SSHv6
601 permit tcp 2001:DB8:100:3::/64 any eq 22
602 ip access-list extended SNMP
603 permit udp 198.51.100.128 0.0.0.128 any eq snmp
604 ipv6 access-list SNMPv6
605 permit udp 2001:DB8:100:3::/64 any eq snmp
606 ip access-list extended RADIUS
607 permit udp host 198.51.100.9 eq 1812 any
608 permit udp host 198.51.100.9 eq 1813 any
609 permit udp host 198.51.100.10 eq 1812 any
610 permit udp host 198.51.100.10 eq 1813 any
611 ipv6 access-list RADIUSv6
612 permit udp host 2001:DB8:100::9 eq 1812 any
613 permit udp host 2001:DB8:100::9 eq 1813 any
614 permit udp host 2001:DB8:100::10 eq 1812 any
615 permit udp host 2001:DB8:100::10 eq 1813 any
616 ip access-list extended FRAGMENTS
617 permit ip any any fragments
618 ipv6 access-list FRAGMENTSv6
619 permit ipv6 any any fragments
620 ip access-list extended ALLOTHERIP
621 permit ip any any
622 ipv6 access-list ALLOTHERIPv6
623 permit ipv6 any any
624 !
625 !Class Definitions
626 !
627 class-map match-any ICMP
628 match access-group name ICMP
629 class-map match-any ICMPv6
630 match access-group name ICMPv6
631 class-map match-any OSPF
632 match access-group name OSPF
633 match access-group name OSPFv3
634 class-map match-any IBGP
635 match access-group name IBGP
636 match access-group name IBGPv6
637 class-map match-any EBGP
638 match access-group name EBGP
639 match access-group name EBGPv6
640 class-map match-any DNS
641 match access-group name DNS
642 match access-group name DNSv6
643 class-map match-any NTP
644 match access-group name NTP
645 match access-group name NTPv6
646 class-map match-any SSH
647 match access-group name SSH
648 match access-group name SSHv6
649 class-map match-any SNMP
650 match access-group name SNMP
651 match access-group name SNMPv6
652 class-map match-any RADIUS
653 match access-group name RADIUS
654 match access-group name RADIUSv6
655 class-map match-any FRAGMENTS
656 match access-group name FRAGMENTS
657 match access-group name FRAGMENTSv6
658 class-map match-any ALLOTHERIP
659 match access-group name ALLOTHERIP
660 class-map match-any ALLOTHERIPv6
661 match access-group name ALLOTHERIPv6
662 !
663 !Policy Definition
664 !
665 policy-map COPP
666 class FRAGMENTS
667 drop
668 class ICMP
669 police 500000
670 conform-action transmit
671 exceed-action drop
672 violate-action drop
673 class ICMPv6
674 police 500000
675 conform-action transmit
676 exceed-action drop
677 violate-action drop
678 class OSPF
679 class IBGP
680 class EBGP
681 class DNS
682 class NTP
683 class SSH
684 class SNMP
685 class RADIUS
686 class ALLOTHERIP
687 police cir 500000
688 conform-action transmit
689 exceed-action drop
690 violate-action drop
691 class ALLOTHERIPv6
692 police cir 500000
693 conform-action transmit
694 exceed-action drop
695 violate-action drop
696 class class-default
697 police cir 250000
698 conform-action transmit
699 exceed-action drop
700 violate-action drop
701 !
702 !Control Plane Configuration
703 !
704 control-plane
705 service-policy input COPP
706 !
707 !End: Protecting The Router Control Plane
709 A.2. Juniper Configuration
711 Refer to the Firewall Filter Configuration section of the Junos
712 Software Policy Framework Configuration Guide for more information on
713 the syntax and options available when configuring Junos firewall
714 filters, available at .
716 policy-options {
717 prefix-list IBGP-NEIGHBORS {
718 192.0.2.0/24;
719 }
720 prefix-list EBGP-NEIGHBORS {
721 198.51.100.25/32;
722 198.51.100.27/32;
723 198.51.100.29/32;
724 198.51.100.31/32;
725 }
726 prefix-list RADIUS-SERVERS {
727 198.51.100.9/32;
728 198.51.100.10/32;
729 }
730 prefix-list IBGPv6-NEIGHBORS {
731 2001:DB8:1::/48;
732 }
733 prefix-list EBGPv6-NEIGHBORS {
734 2001:DB8:100::25/128;
735 2001:DB8:100::27/128;
736 2001:DB8:100::29/128;
737 2001:DB8:100::31/128;
738 }
739 prefix-list RADIUSv6-SERVERS {
740 2001:DB8:100::9/128;
741 2001:DB8:100::10/128;
742 }
743 }
744 firewall {
745 policer 500kbps {
746 if-exceeding {
747 bandwidth-limit 500k;
748 burst-size-limit 1500;
749 }
750 then discard;
751 }
752 policer 250kbps {
753 if-exceeding {
754 bandwidth-limit 250k;
755 burst-size-limit 1500;
756 }
757 then discard;
758 }
759 family inet {
760 filter protect-router-control-plane {
761 term first-frag {
762 from {
763 first-fragment;
764 }
765 then {
766 count frag-discards;
767 log;
768 discard;
769 }
770 }
771 term next-frag {
772 from {
773 is-fragment;
774 }
775 then {
776 count frag-discards;
777 log;
778 discard;
779 }
780 }
781 term icmp {
782 from {
783 protocol icmp;
784 }
785 then {
786 policer 500kbps;
787 accept;
789 }
790 }
791 term ospf {
792 from {
793 source-address {
794 192.0.2.0/24;
795 }
796 protocol ospf;
797 }
798 then accept;
799 }
800 term ibgp-connect {
801 from {
802 source-prefix-list {
803 IBGP-NEIGHBORS;
804 }
805 protocol tcp;
806 destination-port bgp;
807 }
808 then accept;
809 }
810 term ibgp-reply {
811 from {
812 source-prefix-list {
813 IBGP-NEIGHBORS;
814 }
815 protocol tcp;
816 port bgp;
817 }
818 then accept;
819 }
820 term ebgp-connect {
821 from {
822 source-prefix-list {
823 EBGP-NEIGHBORS;
824 }
825 protocol tcp;
826 destination-port bgp;
827 }
828 then accept;
829 }
830 term ebgp-reply {
831 from {
832 source-prefix-list {
833 EBGP-NEIGHBORS;
834 }
835 protocol tcp;
836 port bgp;
838 }
839 then accept;
840 }
841 term dns {
842 from {
843 source-address {
844 198.51.100.0/30;
845 }
846 protocol udp;
847 port domain;
848 }
849 then accept;
850 }
851 term ntp {
852 from {
853 source-address {
854 198.51.100.4/30;
855 }
856 protocol udp;
857 destination-port ntp;
858 }
859 then accept;
860 }
861 term ssh {
862 from {
863 source-address {
864 198.51.100.128/25;
865 }
866 protocol tcp;
867 destination-port ssh;
868 }
869 then accept;
870 }
871 term snmp {
872 from {
873 source-address {
874 198.51.100.128/25;
875 }
876 protocol udp;
877 destination-port snmp;
878 }
879 then accept;
880 }
881 term radius {
882 from {
883 source-prefix-list {
884 RADIUS-SERVERS;
885 }
886 protocol udp;
887 port [ 1812 1813 ];
888 }
889 then accept;
890 }
891 term default-term {
892 then {
893 count copp-exceptions;
894 log;
895 policer 500kbps;
896 accept;
897 }
898 }
899 }
900 }
902 family inet6 {
903 filter protect-router-control-plane-v6 {
904 term fragv6 {
905 from {
906 next-header fragment;
907 }
908 then {
909 count frag-v6-discards;
910 log;
911 discard;
912 }
913 }
914 term icmpv6 {
915 from {
916 next-header icmpv6;
917 }
918 then {
919 policer 500kbps;
920 accept;
921 }
922 }
923 term ospfv3 {
924 from {
925 source-address {
926 FE80::/10;
927 }
928 next-header ospf;
929 }
930 then accept;
931 }
932 term ibgpv6-connect {
933 from {
934 source-prefix-list {
935 IBGPv6-NEIGHBORS;
936 }
937 next-header tcp;
938 destination-port bgp;
939 }
940 then accept;
941 }
942 term ibgpv6-reply {
943 from {
944 source-prefix-list {
945 IBGPv6-NEIGHBORS;
946 }
947 next-header tcp;
948 port bgp;
949 }
950 then accept;
951 }
952 term ebgpv6-connect {
953 from {
954 source-prefix-list {
955 EBGPv6-NEIGHBORS;
956 }
957 next-header tcp;
958 destination-port bgp;
959 }
960 then accept;
961 }
962 term ebgpv6-reply {
963 from {
964 source-prefix-list {
965 EBGPv6-NEIGHBORS;
966 }
967 next-header tcp;
968 port bgp;
969 }
970 then accept;
971 }
972 term dnsv6 {
973 from {
974 source-address {
975 2001:DB8:100:1::/64;
976 }
977 next-header [ udp tcp ];
978 port domain;
979 }
980 then accept;
981 }
982 term ntpv6 {
983 from {
984 source-address {
985 2001:DB8:100:2::/64;
986 }
987 next-header udp;
988 destination-port ntp;
989 }
990 then accept;
991 }
992 term sshv6 {
993 from {
994 source-address {
995 2001:DB8:100:3::/64;
996 }
997 next-header tcp;
998 destination-port ssh;
999 }
1000 then accept;
1001 }
1002 term snmpv6 {
1003 from {
1004 source-address {
1005 2001:DB8:100:3::/64;
1006 }
1007 next-header udp;
1008 destination-port snmp;
1009 }
1010 then accept;
1011 }
1012 term radiusv6 {
1013 from {
1014 source-prefix-list {
1015 RADIUSv6-SERVERS;
1016 }
1017 next-header udp;
1018 port [ 1812 1813 ];
1019 }
1020 then accept;
1021 }
1022 term default-term-v6 {
1023 then {
1024 policer 500kbps;
1025 count copp-exceptions-v6;
1026 log;
1027 accept;
1028 }
1029 }
1031 }
1032 }
1034 family any {
1035 filter protect-router-control-plane-non-ip {
1036 term rate-limit-non-ip {
1037 then {
1038 policer 250kbps;
1039 accept;
1040 }
1041 }
1042 }
1043 }
1044 }
1045 interfaces {
1046 lo0 {
1047 unit 0 {
1048 family inet {
1049 filter input protect-router-control-plane;
1050 }
1051 family inet6 {
1052 filter input protect-router-control-plane-v6;
1053 }
1054 family any {
1055 filter input protect-router-control-plane-non-ip;
1056 }
1057 }
1058 }
1059 }
1061 Authors' Addresses
1063 Dave Dugal
1064 Juniper Networks
1065 10 Technology Park Drive
1066 Westford, MA 01886
1067 US
1069 Email: dave@juniper.net
1070 Carlos Pignataro
1071 Cisco Systems
1072 7200-12 Kit Creek Road
1073 Research Triangle Park, NC 27709
1074 US
1076 Email: cpignata@cisco.com
1078 Rodney Dunn
1079 Cisco Systems
1080 7200-12 Kit Creek Road
1081 Research Triangle Park, NC 27709
1082 US
1084 Email: rodunn@cisco.com