idnits 2.17.1 draft-ietf-opsec-protect-control-plane-05.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 12, 2010) is 4874 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 15, 2011 R. Dunn 6 Cisco Systems 7 December 12, 2010 9 Protecting The Router Control Plane 10 draft-ietf-opsec-protect-control-plane-05 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 15, 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, there may be other vendor or implementation specific 157 protection mechanisms that are active by default or always active. 158 Those approaches may apply in conjunction with or in addition to the 159 method described in Section 3 and illustrated in Appendices A.1 and 160 A.2. Those implementations should be considered as part of an 161 overall traffic management plan but are outside the scope of this 162 document. 164 This method is applicable for IPv4 as well as IPv6 address families, 165 and the legitimate traffic example in Section 3.1 provides examples 166 for both. 168 3. Method 170 In this memo, the authors demonstrate how a filter protecting the 171 router control plane can be deployed. In Section 3.1, a sample 172 router is introduced and all traffic that its control plane must 173 process is identified. In Section 3.2, filter design concepts are 174 discussed. Cisco (Cisco IOS software) and Juniper (JUNOS) 175 implementations are provided in Appendices A.1 and A.2, respectively. 177 3.1. Legitimate Traffic 179 In this example, the router control plane must process traffic per 180 the following criteria: 182 o Drop all IP packets that are fragments 184 o Permit ICMP and ICMPv6 traffic from any source, rate-limited to 185 500 kbps for each category 187 o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and 188 OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10) 190 o Permit iBGP traffic from routers within subnets 192.0.2.0/24 and 191 2001:DB8:1::/48 193 o Permit eBGP traffic from eBGP peers 198.51.100.25, 198.51.100.27, 194 198.51.100.29, and 198.51.100.31 and IPv6 peers 2001:DB8:100::25, 195 2001:DB8:100::27, 2001:DB8:100::29, 2001:DB8:100::31 197 o Permit DNS traffic from DNS servers within subnet 198.51.100.0/30 198 and 2001:DB8:100:1::/64 200 o Permit NTP traffic from NTP servers within subnet 198.51.100.4/30 201 and 2001:DB8:100:2::/64 203 o Permit SSH traffic from network management stations within subnet 204 198.51.100.128/25 and 2001:DB8:100:3::/64 206 o Permit SNMP traffic from network management stations within subnet 207 198.51.100.128/25 and 2001:DB8:100:3::/64 209 o Permit RADIUS authentication and accounting replies from RADIUS 210 servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: 211 DB8:100::10 that are listening on UDP ports 1645 and 1646. Note 212 that this doesn't account for a server using Internet Assigned 213 Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. 215 o Permit all other IPv4 and IPv6 traffic that was not explicitly 216 matched in a class above, rate-limited to 500 kbps, and drop above 217 that rate for each category 219 o Permit non-IP traffic (e.g., CLNS, IPX, PPP LCP, etc.), rate- 220 limited to rate of 250 kbps, and drop all remaining traffic above 221 that rate 223 The characteristics of legitimate traffic will vary from network to 224 network. The list of criteria above is provided for example only. 226 3.2. Filter Design 228 A filter is installed on the forwarding plane. This filter counts 229 and applies the actions to the categories of traffic described in 230 Section 3.1. Because the filter is enforced in the forwarding plane, 231 it prevents traffic from consuming bandwidth on the interface that 232 connects the forwarding plane to the router control plane. The 233 counters serve as an important forensic tool for the analysis of 234 potential attacks, and as an invaluable debugging and troubleshooting 235 aid. By adjusting the granularity and order of the filters, more 236 granular forensics can be performed (i.e., create a filter that 237 matches only traffic allowed from a group of IP addresses for a given 238 protocol followed by a filter that denies all traffic for that 239 protocol). This would allow for counters to be monitored for the 240 allowed protocol filter as well as any traffic matching the specific 241 protocol that didn't originate from the explicitly allowed hosts. 243 In addition to the filters, rate-limiters for certain classes of 244 traffic are also installed in the forwarding plane as defined in 245 Section 3.1. These rate limiters help further control the traffic 246 that will reach the router control plane for each filtered class as 247 well as all traffic not matching an explicit class. The actual rates 248 selected for various classes is network deployment specific; analysis 249 of the rates required for stability should be done periodically. It 250 is important to note that the most significant factor to consider 251 regarding the traffic profile going to the router control plane is 252 the packets per second (pps) rate. Therefore, careful consideration 253 must be given to determine the maximum packets per second rate that 254 could be generated from a given set of packet size and bandwidth 255 usage scenarios. 257 Syntactically, these filters explicitly define "allowed" traffic 258 (including IP addresses, protocols, and ports), define acceptable 259 actions for these acceptable traffic profiles (e.g., rate-limit or 260 simply permit the traffic), and then discard all traffic destined to 261 the router control plane that is not within the specifications of the 262 policy definition. 264 In an actual production environment, predicting a complete and 265 exhaustive list of traffic necessary to reach the router's control 266 plane for day-to-day operation may not be as obvious as the example 267 described herein. One recommended method to gauge this set of 268 traffic is to allow all traffic initially, and audit the traffic that 269 reaches the router control plane before applying any explicit filters 270 or rate limits. See the Section 3.3 section below for more 271 discussion of this topic. 273 The filter design provided in this document is intentionally limited 274 to attachment at the local router in question (e.g., a 'service- 275 policy' attached to the 'control-plane' in Cisco IOS, or a firewall 276 filter attached to the 'lo0' interface in JUNOS). While virtually 277 all production environments utilize and rely heavily upon edge 278 protection or interface filtering, these methods of router protection 279 are beyond the intended scope of this document. Additionally, the 280 protocols themselves that are allowed to reach the router control 281 plane (e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH, 282 TLS, ESP, etc.) may have cryptographic security methods applied to 283 them, and the method of router control plane protection provided 284 herein is not a replacement for those cryptographic methods. 286 3.3. Design Trade-offs 288 In designing the protection method, there are two independent parts 289 to consider: the classification of traffic (i.e., which traffic is 290 matched by the filters), and the policy actions taken on the 291 classified traffic (i.e., drop, permit, rate limit, etc.). 293 There are different levels of granularity utilized for traffic 294 classification. For example, allowing all traffic from specific 295 source IP addresses versus allowing only a specific set of protocols 296 from those specific source IP addresses will each affect a different 297 subset of traffic. 299 Similarly, the policy actions taken on the classified traffic have 300 degrees of impact that may not become immediately obvious. For 301 example, discarding all ICMP traffic will have a negative impact on 302 the operational use of ICMP tools such as ping or traceroute to debug 303 network issues or to test deployment of a new circuit. Expanding on 304 this, in a real production network, an astute operator could define 305 varying rate limits for ICMP such that internal traffic is granted 306 uninhibited access to the router control plane, while traffic from 307 external addresses is rate limited. Operators should pay special 308 attention to the new functionality and roles that ICMPv6 has in the 309 overall operation of IPv6 when designing the rate limit policies. 310 Example functions include Neighbor Discovery (ND) and Multicast 311 Listener Discovery version 2 (MLDv2). 313 It is important to note that both classification and policy action 314 decisions are accompanied by respective trade-offs. Two examples of 315 these trade-off decisions are, operational complexity at the expense 316 of policy and statistics gathering detail, and tighter protection at 317 the expense of network supportability and troubleshooting ability. 319 Two types of traffic that need special consideration are IP fragments 320 and IP optioned packets: 322 For network deployments where IP fragmentation is necessary, a 323 blanket policy of dropping all fragments may not be feasible. 324 However, many deployments allow network configurations such that 325 the router control plane should never see a fragmented datagram. 326 Since many attacks rely on IP fragmentation, the example policy 327 included herein drops all fragments. 329 Similarly, some deployments may chose to drop all IP optioned 330 packets. Others may need to loosen the constraint to allow for 331 protocols that require IP optioned packets such as Resource 332 Reservation Protocol (RSVP). The design trade-off is that 333 dropping all IP optioned packets protects the router from attacks 334 that leverage malformed options, as well as attacks that rely on 335 the slow-path processing (i.e., software processing path) of IP 336 optioned packets. For network deployments where the protocols 337 used rely on IP options, the filter is simpler to design in that 338 it can drop all packets with any IP option set. However for 339 networks utilizing protocols relying on IP options, then the 340 filter to identify the legitimate packets is more complex. If the 341 filter is not designed correctly, it could result in the 342 inadvertent blackholing of traffic for those protocols. This 343 document does not include IP options filter configurations; 344 additional IP options filtering explanations can be found at 345 [I-D.gont-opsec-ip-options-filtering]. 347 The goal of the method for protecting the router control plane is to 348 minimize the possibility for disruptions by reducing the vulnerable 349 surface. The latter is inversely proportional to the granularity of 350 the filter design. The finer the granularity of the filter design 351 (e.g., filtering a more targeted subset of traffic from the rest of 352 the policed traffic, or isolating valid source addresses into a 353 different class or classes) the smaller the probability of 354 disruption. 356 In addition to the traffic matching explicit classes, care should be 357 taken on the policy decision that governs the handling of traffic 358 that would fall through the classification. Typically that traffic 359 is referred to as traffic that gets matched in a default class. It 360 may also be traffic that matches a blanket protocol specific class 361 where previous classes that have more granular classification did not 362 match all packets for that specific protocol. The ideal policy would 363 have explicit classes to match only the traffic specifically required 364 at the router control plane and drop all other traffic that does not 365 match a predefined class. As most vendor implementations permit all 366 traffic hitting the default class, an explicit drop action would need 367 to be configured in the policy such that the traffic hitting that 368 default class would be dropped versus permitted and delivered to the 369 router control plane. This approach requires rigorous traffic 370 pattern identification such that a default drop policy does not break 371 existing device functionality. The approach defined in this document 372 allows the default traffic and rate limits it as opposed to dropping 373 it. This approach was chosen as a way to give time for the operator 374 to evaluate and characterize traffic in a production scenario prior 375 to dropping all traffic not explicitly matched and permitted. 376 However, it is highly recommended that after monitoring the traffic 377 matching the default class that explicit classes be defined to catch 378 the legitimate traffic. After all legitimate traffic has been 379 identified and explicitly allowed the default class should be 380 configured to drop any remaining traffic. 382 Additionally, the baselining and monitoring of traffic flows to the 383 router's control plane are critical in determining both the rates and 384 granularity of the policies being applied. It is also important to 385 validate the existing policies and rules or update them as the 386 network evolves and its traffic dynamics change. Some possible ways 387 to achieve this include individual policy counters that can be 388 exported or retrieved for example via SNMP, and logging of filtering 389 actions. 391 Finally, the use of flow-based behavioral analysis or CLI functions 392 to identify what client/server functions a given router's control 393 plane handles would be very useful during initial policy development 394 phases, and certainly for ongoing forensic analysis. 396 3.4. Additional Protection Considerations 398 In addition to the design described in this document of defining 399 "allowed" traffic (i.e., identifying traffic that the control plane 400 must process) and limiting (e.g., rate-limiting or blocking) the 401 rest, the router control plane protection method can be applied to 402 thwart specific attacks. In particular, it can be used to protect 403 against TCP SYN flooding attacks and other denial-of-service attacks 404 that starve router control plane resources. 406 4. Security Considerations 408 The filter above leaves the router susceptible to discovery from any 409 host in the Internet. If network operators find this risk 410 objectionable, they can reduce the exposure by restricting the sub- 411 networks from which ICMP Echo requests or traceroute packets are 412 accepted. A similar concern exists for ICMPv6 traffic but on a 413 broader level due to the additional functionalities implemented in 414 ICMPv6. Filtering recommendations for ICMPv6 can be found in 415 [RFC4890]. Moreover, different rate-limiting policies may be defined 416 for internally (e.g., from the NOC) versus externally sourced 417 traffic. Note that this document is not targeted at the specifics of 418 ICMP filtering or traffic filtering designed to prevent device 419 discovery. 421 The filter above does not block unwanted traffic having spoofed 422 source addresses that match a defined traffic profile in Section 3.1. 423 Network operators can mitigate this risk by preventing source address 424 spoofing with filters applied at the network edge. Refer to Section 425 5.3.8 of [RFC1812] for more information regarding source address 426 validation. Other methods also exist for limiting exposure to packet 427 spoofing such as the Generalized TTL Security Mechanism (GTSM) 428 [RFC5082] and Ingress Filtering [RFC2827] [RFC3704]. 430 The ICMP rate limiter specified in this filter protects the router 431 from floods of ICMP traffic. However, during an ICMP flood, some 432 legitimate ICMP traffic may be dropped. Because of this, when 433 operators discover a flood of ICMP traffic, they are highly motivated 434 to stop it at the source where the traffic is being originated. 436 Additional considerations pertaining to the usage and handling of 437 traffic that utilizes the IP Router Alert Options can be found at 438 [I-D.ietf-intarea-router-alert-considerations], and additional IP 439 options filtering explanations can be found at 440 [I-D.gont-opsec-ip-options-filtering]. 442 The treatment of exception traffic in the forwarding plane and the 443 generation of specific messages by the router control plane also 444 requires protection from a DoS attack. Specifically, the generation 445 of ICMP Unreachable messages by the router control plane needs to be 446 rate-limited, either implicitly within the router's architecture or 447 explicitly through configuration. When possible, different ICMP 448 Destination Unreachable codes (e.g., "fragmentation needed and DF 449 set") or "Packet Too Big" messages can receive a different rate- 450 limiting treatment. Continuous benchmarking of router generated ICMP 451 traffic should be done before applying rate limits such that 452 sufficient headroom is included to prevent inadvertent Path Maximum 453 Transmission Unit Discovery (PMTUD) blackhole scenarios during normal 454 operation. It is also recommended to deploy explicit rate limiters 455 where possible to improve troubleshooting and monitoring capability. 456 The explicit rate limiters in a class allow for monitoring tools to 457 detect and report when these rate limiters become active (i.e., when 458 traffic is policed). This in turn serves as an indicator that either 459 the normal traffic rates have increased or out of policy traffic 460 rates have been detected. More thorough analysis of the traffic 461 flows and rate-limited traffic is needed to identify which of these 462 two cases triggered the rate limiters. For additional information 463 regarding specific ICMP rate limiting see Section 4.3.2.8 of 464 [RFC1812]. 466 Additionally, the handling of TTL / Hop Limit expired traffic needs 467 protection. This traffic is not necessarily addressed to the device, 468 but it can get sent to the router control plane to process the TTL / 469 Hop Limit expiration. For example, rate limiting the TTL / Hop Limit 470 expired traffic before sending the packets to the router control 471 plane component that will generate the ICMP error, and distributing 472 the sending of ICMP errors to Line Card CPUs are protection 473 mechanisms that mitigate attacks before they can negatively affect a 474 rate-limited router control plane component. 476 5. IANA Considerations 478 [RFC Editor: please remove this section prior to publication.] 480 This document has no IANA actions. 482 6. Acknowledgements 484 The authors would like to thank Ron Bonica for providing initial and 485 ongoing review, suggestions, and valuable input. Pekka Savola, 486 Warren Kumari, and Xu Chen provided very thorough and useful feedback 487 that improved the document. Many thanks to John Kristoff, 488 Christopher Morrow, and Donald Smith for a fruitful discussion around 489 the operational and manageability aspects of router control plane 490 protection techniques. The authors would also like to thank Joel 491 Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie 492 Parra, Seo Boon Ng, Manav Bhatia, German Martinez, Wen Zhang, Roni 493 Even, and Acee Lindem for providing thorough review, useful 494 suggestions, and valuable input. Many thanks to Jim Bailey and 495 Raphan Han for providing technical direction and sample configuration 496 guidance on the IPv6 sections. Many thanks also go to Andrew 497 Yourtchenko for his review, comments, and willingness to present on 498 behalf of the authors. 500 7. Informative References 502 [I-D.gont-opsec-ip-options-filtering] 503 Gont, F. and S. Fouant, "IP Options Filtering 504 Recommendations", draft-gont-opsec-ip-options-filtering-00 505 (work in progress), March 2010. 507 [I-D.ietf-intarea-router-alert-considerations] 508 Faucheur, F., "IP Router Alert Considerations and Usage", 509 draft-ietf-intarea-router-alert-considerations-02 (work in 510 progress), October 2010. 512 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 513 RFC 1812, June 1995. 515 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 516 Defeating Denial of Service Attacks which employ IP Source 517 Address Spoofing", BCP 38, RFC 2827, May 2000. 519 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 520 Networks", BCP 84, RFC 3704, March 2004. 522 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 523 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 525 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 526 Pignataro, "The Generalized TTL Security Mechanism 527 (GTSM)", RFC 5082, October 2007. 529 Appendix A. Configuration Examples 531 The configurations provided below are syntactical representations of 532 the semantics described in the document and should be treated as non- 533 normative. 535 A.1. Cisco Configuration 537 Refer to the Control Plane Policing (CoPP) document in the Cisco IOS 538 Software Feature Guides for more information on the syntax and 539 options available when configuring Control Plane Policing, available 540 at . 542 !Start: Protecting The Router Control Plane 543 ! 544 !Control Plane Policing (CoPP) Configuration 545 ! 546 !Access Control List Definitions 547 ! 548 ip access-list extended ICMP 549 permit icmp any any 550 ipv6 access-list ICMPv6 551 permit icmp any any 552 ip access-list extended OSPF 553 permit ospf 192.0.2.0 0.0.0.255 any 554 ipv6 access-list OSPFv3 555 permit 89 FE80::/10 any 556 ip access-list extended IBGP 557 permit tcp 192.0.2.0 0.0.0.255 eq bgp any 558 permit tcp 192.0.2.0 0.0.0.255 any eq bgp 559 ipv6 access-list IBGPv6 560 permit tcp 2001:DB8:1::/48 eq bgp any 561 permit tcp 2001:DB8:1::/48 any eq bgp 562 ip access-list extended EBGP 563 permit tcp host 198.51.100.25 eq bgp any 564 permit tcp host 198.51.100.25 any eq bgp 565 permit tcp host 198.51.100.27 eq bgp any 566 permit tcp host 198.51.100.27 any eq bgp 567 permit tcp host 198.51.100.29 eq bgp any 568 permit tcp host 198.51.100.29 any eq bgp 569 permit tcp host 198.51.100.31 eq bgp any 570 permit tcp host 198.51.100.31 any eq bgp 571 ipv6 access-list EBGPv6 572 permit tcp host 2001:DB8:100::25 eq bgp any 573 permit tcp host 2001:DB8:100::25 any eq bgp 574 permit tcp host 2001:DB8:100::27 eq bgp any 575 permit tcp host 2001:DB8:100::27 any eq bgp 576 permit tcp host 2001:DB8:100::29 eq bgp any 577 permit tcp host 2001:DB8:100::29 any eq bgp 578 permit tcp host 2001:DB8:100::31 eq bgp any 579 permit tcp host 2001:DB8:100::31 any eq bgp 580 ip access-list extended DNS 581 permit udp 198.51.100.0 0.0.0.252 eq domain any 582 ipv6 access-list DNSv6 583 permit udp 2001:DB8:100:1::/64 eq domain any 584 permit tcp 2001:DB8:100:1::/64 eq domain any 585 ip access-list extended NTP 586 permit udp 198.51.100.4 255.255.255.252 any eq ntp 587 ipv6 access-list NTPv6 588 permit udp 2001:DB8:100:2::/64 any eq ntp 589 ip access-list extended SSH 590 permit tcp 198.51.100.128 0.0.0.128 any eq 22 591 ipv6 access-list SSHv6 592 permit tcp 2001:DB8:100:3::/64 any eq 22 593 ip access-list extended SNMP 594 permit udp 198.51.100.128 0.0.0.128 any eq snmp 596 ipv6 access-list SNMPv6 597 permit udp 2001:DB8:100:3::/64 any eq snmp 598 ip access-list extended RADIUS 599 permit udp host 198.51.100.9 eq 1645 any 600 permit udp host 198.51.100.9 eq 1646 any 601 permit udp host 198.51.100.10 eq 1645 any 602 permit udp host 198.51.100.10 eq 1646 any 603 ipv6 access-list RADIUSv6 604 permit udp host 2001:DB8:100::9 eq 1645 any 605 permit udp host 2001:DB8:100::9 eq 1646 any 606 permit udp host 2001:DB8:100::10 eq 1645 any 607 permit udp host 2001:DB8:100::10 eq 1646 any 608 ip access-list extended FRAGMENTS 609 permit ip any any fragments 610 ipv6 access-list FRAGMENTSv6 611 permit ipv6 any any fragments 612 ip access-list extended ALLOTHERIP 613 permit ip any any 614 ipv6 access-list ALLOTHERIPv6 615 permit ipv6 any any 616 ! 617 !Class Definitions 618 ! 619 class-map match-any ICMP 620 match access-group name ICMP 621 class-map match-any ICMPv6 622 match access-group name ICMPv6 623 class-map match-any OSPF 624 match access-group name OSPF 625 match access-group name OSPFv3 626 class-map match-any IBGP 627 match access-group name IBGP 628 match access-group name IBGPv6 629 class-map match-any EBGP 630 match access-group name EBGP 631 match access-group name EBGPv6 632 class-map match-any DNS 633 match access-group name DNS 634 match access-group name DNSv6 635 class-map match-any NTP 636 match access-group name NTP 637 match access-group name NTPv6 638 class-map match-any SSH 639 match access-group name SSH 640 match access-group name SSHv6 641 class-map match-any SNMP 642 match access-group name SNMP 643 match access-group name SNMPv6 645 class-map match-any RADIUS 646 match access-group name RADIUS 647 match access-group name RADIUSv6 648 class-map match-any FRAGMENTS 649 match access-group name FRAGMENTS 650 match access-group name FRAGMENTSv6 651 class-map match-any ALLOTHERIP 652 match access-group name ALLOTHERIP 653 class-map match-any ALLOTHERIPv6 654 match access-group name ALLOTHERIPv6 655 ! 656 !Policy Definition 657 ! 658 policy-map COPP 659 class FRAGMENTS 660 drop 661 class ICMP 662 police 500000 663 conform-action transmit 664 exceed-action drop 665 violate-action drop 666 class ICMPv6 667 police 500000 668 conform-action transmit 669 exceed-action drop 670 violate-action drop 671 class OSPF 672 class IBGP 673 class EBGP 674 class DNS 675 class NTP 676 class SSH 677 class SNMP 678 class RADIUS 679 class ALLOTHERIP 680 police cir 500000 681 conform-action transmit 682 exceed-action drop 683 violate-action drop 684 class ALLOTHERIPv6 685 police cir 500000 686 conform-action transmit 687 exceed-action drop 688 violate-action drop 689 class class-default 690 police cir 250000 691 conform-action transmit 692 exceed-action drop 693 violate-action drop 694 ! 695 !Control Plane Configuration 696 ! 697 control-plane 698 service-policy input COPP 699 ! 700 !End: Protecting The Router Control Plane 702 A.2. Juniper Configuration 704 Refer to the Firewall Filter Configuration section of the Junos 705 Software Policy Framework Configuration Guide for more information on 706 the syntax and options available when configuring Junos firewall 707 filters, available at . 709 policy-options { 710 prefix-list IBGP-NEIGHBORS { 711 192.0.2.0/24; 712 } 713 prefix-list EBGP-NEIGHBORS { 714 198.51.100.25/32; 715 198.51.100.27/32; 716 198.51.100.29/32; 717 198.51.100.31/32; 718 } 719 prefix-list RADIUS-SERVERS { 720 198.51.100.9/32; 721 198.51.100.10/32; 722 } 723 prefix-list IBGPv6-NEIGHBORS { 724 2001:DB8:1::/48; 725 } 726 prefix-list EBGPv6-NEIGHBORS { 727 2001:DB8:100::25/128; 728 2001:DB8:100::27/128; 729 2001:DB8:100::29/128; 730 2001:DB8:100::31/128; 731 } 732 prefix-list RADIUSv6-SERVERS { 733 2001:DB8:100::9/128; 734 2001:DB8:100::10/128; 735 } 736 } 737 firewall { 738 policer 500kbps { 739 if-exceeding { 740 bandwidth-limit 500k; 741 burst-size-limit 1500; 742 } 743 then discard; 744 } 745 policer 250kbps { 746 if-exceeding { 747 bandwidth-limit 250k; 748 burst-size-limit 1500; 749 } 750 then discard; 751 } 752 family inet { 753 filter protect-router-control-plane { 754 term first-frag { 755 from { 756 first-fragment; 757 } 758 then { 759 count frag-discards; 760 log; 761 discard; 762 } 763 } 764 term next-frag { 765 from { 766 is-fragment; 767 } 768 then { 769 count frag-discards; 770 log; 771 discard; 772 } 773 } 774 term icmp { 775 from { 776 protocol icmp; 777 } 778 then { 779 policer 500kbps; 780 accept; 781 } 782 } 783 term ospf { 784 from { 785 source-address { 786 192.0.2.0/24; 787 } 788 protocol ospf; 790 } 791 then accept; 792 } 793 term ibgp-connect { 794 from { 795 source-prefix-list { 796 IBGP-NEIGHBORS; 797 } 798 protocol tcp; 799 destination-port bgp; 800 } 801 then accept; 802 } 803 term ibgp-reply { 804 from { 805 source-prefix-list { 806 IBGP-NEIGHBORS; 807 } 808 protocol tcp; 809 port bgp; 810 } 811 then accept; 812 } 813 term ebgp-connect { 814 from { 815 source-prefix-list { 816 EBGP-NEIGHBORS; 817 } 818 protocol tcp; 819 destination-port bgp; 820 } 821 then accept; 822 } 823 term ebgp-reply { 824 from { 825 source-prefix-list { 826 EBGP-NEIGHBORS; 827 } 828 protocol tcp; 829 port bgp; 830 } 831 then accept; 832 } 833 term dns { 834 from { 835 source-address { 836 198.51.100.0/30; 837 } 838 protocol udp; 839 port domain; 840 } 841 then accept; 842 } 843 term ntp { 844 from { 845 source-address { 846 198.51.100.4/30; 847 } 848 protocol udp; 849 destination-port ntp; 850 } 851 then accept; 852 } 853 term ssh { 854 from { 855 source-address { 856 198.51.100.128/25; 857 } 858 protocol tcp; 859 destination-port ssh; 860 } 861 then accept; 862 } 863 term snmp { 864 from { 865 source-address { 866 198.51.100.128/25; 867 } 868 protocol udp; 869 destination-port snmp; 870 } 871 then accept; 872 } 873 term radius { 874 from { 875 source-prefix-list { 876 RADIUS-SERVERS; 877 } 878 protocol udp; 879 port [ 1645 1646 ]; 880 } 881 then accept; 882 } 883 term default-term { 884 then { 885 count copp-exceptions; 886 log; 887 policer 500kbps; 888 accept; 889 } 890 } 891 } 892 } 894 family inet6 { 895 filter protect-router-control-plane-v6 { 896 term fragv6 { 897 from { 898 next-header fragment; 899 } 900 then { 901 count frag-v6-discards; 902 log; 903 discard; 904 } 905 } 906 term icmpv6 { 907 from { 908 next-header icmpv6; 909 } 910 then { 911 policer 500kbps; 912 accept; 913 } 914 } 915 term ospfv3 { 916 from { 917 source-address { 918 FE80::/10; 919 } 920 next-header ospf; 921 } 922 then accept; 923 } 924 term ibgpv6-connect { 925 from { 926 source-prefix-list { 927 IBGPv6-NEIGHBORS; 928 } 929 next-header tcp; 930 destination-port bgp; 931 } 932 then accept; 933 } 934 term ibgpv6-reply { 935 from { 936 source-prefix-list { 937 IBGPv6-NEIGHBORS; 938 } 939 next-header tcp; 940 port bgp; 941 } 942 then accept; 943 } 944 term ebgpv6-connect { 945 from { 946 source-prefix-list { 947 EBGPv6-NEIGHBORS; 948 } 949 next-header tcp; 950 destination-port bgp; 951 } 952 then accept; 953 } 954 term ebgpv6-reply { 955 from { 956 source-prefix-list { 957 EBGPv6-NEIGHBORS; 958 } 959 next-header tcp; 960 port bgp; 961 } 962 then accept; 963 } 964 term dnsv6 { 965 from { 966 source-address { 967 2001:DB8:100:1::/64; 968 } 969 next-header [ udp tcp ]; 970 port domain; 971 } 972 then accept; 973 } 974 term ntpv6 { 975 from { 976 source-address { 977 2001:DB8:100:2::/64; 978 } 979 next-header udp; 980 destination-port ntp; 981 } 982 then accept; 983 } 984 term sshv6 { 985 from { 986 source-address { 987 2001:DB8:100:3::/64; 988 } 989 next-header tcp; 990 destination-port ssh; 991 } 992 then accept; 993 } 994 term snmpv6 { 995 from { 996 source-address { 997 2001:DB8:100:3::/64; 998 } 999 next-header udp; 1000 destination-port snmp; 1001 } 1002 then accept; 1003 } 1004 term radiusv6 { 1005 from { 1006 source-prefix-list { 1007 RADIUSv6-SERVERS; 1008 } 1009 next-header udp; 1010 port [ 1645 1646 ]; 1011 } 1012 then accept; 1013 } 1014 term default-term-v6 { 1015 then { 1016 policer 500kbps; 1017 count copp-exceptions-v6; 1018 log; 1019 accept; 1020 } 1021 } 1022 } 1023 } 1025 family any { 1026 filter protect-router-control-plane-non-ip { 1027 term rate-limit-non-ip { 1028 then { 1029 policer 250kbps; 1030 accept; 1031 } 1032 } 1033 } 1034 } 1035 } 1036 interfaces { 1037 lo0 { 1038 unit 0 { 1039 family inet { 1040 filter input protect-router-control-plane; 1041 } 1042 family inet6 { 1043 filter input protect-router-control-plane-v6; 1044 } 1045 family any { 1046 filter input protect-router-control-plane-non-ip; 1047 } 1048 } 1049 } 1050 } 1052 Authors' Addresses 1054 Dave Dugal 1055 Juniper Networks 1056 10 Technology Park Drive 1057 Westford, MA 01886 1058 US 1060 Email: dave@juniper.net 1062 Carlos Pignataro 1063 Cisco Systems 1064 7200-12 Kit Creek Road 1065 Research Triangle Park, NC 27709 1066 US 1068 Email: cpignata@cisco.com 1069 Rodney Dunn 1070 Cisco Systems 1071 7200-12 Kit Creek Road 1072 Research Triangle Park, NC 27709 1073 US 1075 Email: rodunn@cisco.com