idnits 2.17.1 draft-ietf-opsec-protect-control-plane-02.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 (August 6, 2010) is 5010 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-01 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: February 7, 2011 R. Dunn 6 Cisco Systems 7 August 6, 2010 9 Protecting The Router Control Plane 10 draft-ietf-opsec-protect-control-plane-02 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 limited 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 February 7, 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 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 66 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11 67 A.1. Cisco Configuration . . . . . . . . . . . . . . . . . . . 11 68 A.2. Juniper Configuration . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 71 1. Introduction 73 Modern router architecture design maintains a strict separation of 74 forwarding and routing control plane hardware and software. The 75 router control plane supports routing and management functions. It 76 is generally described as router architecture hardware and software 77 components for handling packets destined to the device itself as well 78 as building and sending packets originated locally on the device. 79 Forwarding plane is typically described as router architecture 80 hardware and software components responsible for taking a packet 81 coming in one interface, performing a lookup to identify the packet's 82 IP next hop and determine the outgoing interface towards the 83 destination, and forwarding the packet through the correct outgoing 84 interface. 86 Visually it can be represented as the router's control plane hardware 87 sitting on top of and interfacing with the forwarding plane hardware, 88 with interfaces connecting to other network devices. See Figure 1. 90 +----------------+ 91 | Router Control | 92 | Plane | 93 +------+ +-------+ 94 | | 95 Router Control 96 Plane Protection 97 | | 98 +------+ +-------+ 99 | Forwarding | 100 Interface X ==[ Plane ]== Interface Y 101 +----------------+ 103 Figure 1: Router Control Plane Protection 105 Typically, forwarding plane functionality is realized in high- 106 performance Application Specific Integrated Circuits (ASICs) that are 107 capable of handling very high packet rates. By contrast, the router 108 control plane is generally realized in software on general purpose 109 processors. While software instructions run on both planes, the 110 router control plane software is usually not optimized for high speed 111 packet handling. Given their differences in packet handling 112 capabilities, the router's control plane hardware is more susceptible 113 to be overwhelmed by a DoS attack than forwarding plane ASICs. It is 114 imperative that the router control plane remain stable regardless of 115 traffic load to and from the device because the router control plane 116 is what drives the programming of the forwarding plane. 118 The router control plane processes traffic destined to the router, 119 and because of the wider range of functionality is more susceptible 120 to security vulnerabilities and a more likely target for a DoS attack 121 than the forwarding plane. 123 It is advisable to protect the router control plane by implementing 124 mechanisms to filter completely or rate limit traffic not required at 125 the control plane level (i.e., unwanted traffic). Router Control 126 Plane Protection is the concept of filtering or rate limiting 127 unwanted traffic which would be diverted out of the forwarding plane 128 up to the router control plane. The closer to the forwarding plane 129 and line-rate hardware the filters and rate-limiters are, the more 130 effective the protection is and the more resistant the system is to 131 DoS attacks. This memo demonstrates how to deploy an example policy 132 filter that satisfies a set of example traffic matching, filtering 133 and rate limiting criteria. 135 2. Applicability Statement 137 The method described in Section 3 and depicted in Figure 1 138 illustrates how to protect the router control plane from unwanted 139 traffic. Recognizing that deployment scenarios will vary, the exact 140 implementation is not generally applicable in all situations. The 141 categorization of legitimate router control plane traffic is 142 critically important in a successful implementation. 144 The examples given in this memo are simplified and minimalistic, 145 designed to illustrate the concept of protecting the router's control 146 plane. From them, operators can extrapolate specifics based on their 147 unique configuration and environment. This document is about 148 semantics and Appendix A exemplifies syntax. For additional router 149 vendor implementations, or other converged devices, the syntax should 150 be translated to the respective language in a manner that preserves 151 the semantics. 153 Additionally, there may be other vendor or implementation specific 154 protection mechanisms that are on by default or always on. Those 155 approaches may apply in conjunction with or in addition to the method 156 described in Section 3 and illustrated in Appendices A.1 and A.2. 157 Those implementations should be considered as part of an overall 158 traffic management plan but are outside the scope of this document. 160 This method is applicable for IPv4 as well as IPv6 address families, 161 and the sample legitimate traffic in Section 3.1 provides examples 162 for both. 164 3. Method 166 In this memo, the authors demonstrate how a filter protecting the 167 router control plane can be deployed. In Section 3.1, a sample 168 router is introduced and all traffic that its control plane must 169 process is identified. In Section 3.2, filter design concepts are 170 discussed. Cisco (Cisco IOS software) and Juniper (JUNOS) 171 implementations are provided in Appendices A.1 and A.2, respectively. 173 3.1. Legitimate Traffic 175 In this example, the router control plane must process traffic per 176 the following criteria: 178 o Drop all IP packets that are fragments 180 o Permit ICMP and ICMPv6 traffic from any source, rate-limited to 181 500 kbps for each category 183 o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and 184 OSPFv3 traffic from subnet 2001:DB8:1::/48 186 o Permit iBGP traffic from routers within subnets 192.0.2.0/24 and 187 2001:DB8:1::/48 189 o Permit eBGP traffic from eBGP peers 198.51.100.25, 198.51.100.27, 190 198.51.100.29, and 198.51.100.31 and IPv6 peers 2001:DB8:100::25, 191 2001:DB8:100::27, 2001:DB8:100::29, 2001:DB8:100::31 193 o Permit DNS traffic from DNS resolvers within subnet 194 198.51.100.0/30 and 2001:DB8:100:1::/64 196 o Permit NTP traffic from NTP servers within subnet 198.51.100.4/30 197 and 2001:DB8:100:2::/64 199 o Permit SSH traffic from network management stations within subnet 200 198.51.100.128/25 and 2001:DB8:100:3::/64 202 o Permit SNMP traffic from network management stations within subnet 203 198.51.100.128/25 and 2001:DB8:100:3::/64 205 o Permit RADIUS authentication and accounting replies from RADIUS 206 servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: 207 DB8:100::10 that are listening on UDP ports 1645 and 1646. Note 208 that this doesn't account for a server using Internet Assigned 209 Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. 211 o Permit all other IPv4 and IPv6 traffic that was not explicitly 212 matched in a class above, rate-limited to 500 kbps, and drop above 213 that rate for each category 215 o Permit non-IP traffic, rate-limited to rate of 250 kbps, and drop 216 all remaining traffic above that rate 218 The characteristics of legitimate traffic will vary from network to 219 network. The list provided above is for example only. 221 3.2. Filter Design 223 A filter is installed on the forwarding plane. This filter counts 224 and applies the actions to the categories of traffic described in 225 Section 3.1. Because the filter is enforced in the forwarding plane, 226 it prevents traffic from consuming bandwidth on the interface that 227 connects the forwarding plane to the router control plane. The 228 counters serve as an important forensic tool for the analysis of 229 potential attacks, and as an invaluable debugging and troubleshooting 230 aid. By adjusting the granularity and order of the filters more 231 granular forensics can be performed (i.e., create a filter that 232 matches only on traffic allowed from a group of IP addresses for a 233 given protocol followed by a filter that denies all traffic for that 234 protocol). This would allow for counters to be monitored for the 235 allowed protocol filter as well as any traffic matching traffic for 236 the specific protocol that didn't originate from the explicitly 237 allowed hosts. 239 In addition to the filters, rate-limiters for certain classes of 240 traffic are also installed in the forwarding plane as defined in 241 Section 3.1. These rate limiters help futher control the traffic 242 that will reach the control plane for each filtered class as well as 243 all traffic not matching an explicit class. The actual rates 244 selected for various classes is network deployment specific and 245 analysis of required rates for stability should be done periodically. 246 It is important to note that the most significant factor to consider 247 regarding the traffic profile going to the router control plane is 248 the packets per second (pps) rate. Therefore, consideration should 249 be taken when defining the rate limiters for various packet size 250 distributions the potential packet rates that would be allowed. 252 Syntactically, these filters explicitly define "allowed" traffic 253 (including IP addresses, protocols, and ports), define acceptable 254 actions for these acceptable traffic profiles (e.g., rate-limit or 255 simply permit the traffic), and then drop to the bit bucket all 256 traffic destined to the router control plane that is not within the 257 specifications of the policy definition. 259 In an actual production environment, predicting a complete and 260 exhaustive list of traffic necessary to reach the router's control 261 plane for day-to-day operation may not be this obvious. One 262 recommended method to gauge this set of traffic is to allow all 263 traffic initially, and audit what hits the router control plane 264 before applying any explicit filters or rate limits. See the 265 Section 3.3 section below for more discussion of this topic. 267 The filter design provided in this document is intentionally limited 268 to attachment at the local router in question (e.g., a 'service- 269 policy' attached to the 'control-plane' in Cisco IOS, or a firewall 270 filter attached to the 'lo0' interface in JUNOS). While virtually 271 all production environments utilize and rely heavily upon edge 272 protection or interface filtering, these methods of router protection 273 are beyond the intended scope of this document. Additionally, the 274 protocols themselves that are allowed to reach the control plane 275 (e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH, TLS, 276 ESP, etc.) may have cryptographic security methods applied to them, 277 and the method of router control plane protection herein provided is 278 not a replacement for these cryptographic methods. 280 3.3. Design Trade-offs 282 In designing the protection method, there are two independent parts 283 to consider: the classification of traffic (i.e., which traffic is 284 matched by the filters), and the policy actions taken on the 285 classified traffic. 287 There are different levels of granularity utilized for traffic 288 classification. For example, allowing all traffic from specific 289 source IP addresses versus allowing only a specific set of protocols 290 from those specific source IP addresses will each affect a different 291 set of traffic. 293 Similarly, the policy actions taken on the classified traffic have 294 degrees of impact that may not become immediately obvious. For 295 example, discarding all ICMP traffic will have a negative impact on 296 the operational use of ICMP tools such as ping or traceroute to debug 297 network issues or to test turn up of a new circuit. Expanding on 298 this, in a real production network, an astute operator could define 299 varying rate limits for ICMP such that internal traffic is granted 300 uninhibited access to the router control plane, while traffic from 301 external addresses is rate limited. Operators should pay special 302 attention to the new functionality and roles that ICMPv6 has in the 303 overall operation of IPv6 when designing the rate limit policies. 304 Example functions include neighbor discovery and multicast listener 305 discovery version 2 (MLDv2). 307 It is important to note that both classification and policy action 308 decisions are accompanied by respective trade-offs. Two examples of 309 these trade-off decisions are, operational complexity at the expense 310 of policy (and statistics gathering) detail, and tighter protection 311 at the expense of network supportability and troubleshooting ability. 313 Two types of traffic that need special consideration are IP fragments 314 and IP optioned packets. For network deployments where IP 315 fragmentation is necessary, a blanket policy of dropping all 316 fragments may not be possible. However, many deployments allow 317 network configurations such that the router control plane should 318 never see a fragmented datagram. Since many attacks rely on ip 319 fragmentation the example policy referenced here drops all fragments. 320 Similarly, some deployments may chose to drop all IP Optioned 321 Packets. Others may need to losen the constraint to allow for 322 protocols that require IP Optioned packets such as RSVP. 324 The goal of the method for protecting the router control plane is to 325 minimize the possibility for disruptions by reducing the vulnerable 326 surface. The latter is inversely proportional to the granularity of 327 the filter design. The finer the granularity of the filter design 328 (e.g., isolating a more targeted subset of traffic from the rest of 329 the policed traffic, or isolating valid source addresses into a 330 different class or classes) the smaller the probability of 331 disruption. 333 Additionally, the baselining and monitoring of traffic flows to the 334 router's control plane are critical in determining both the rates and 335 granularity of the policies being applied. This is important to 336 validate the existing policies and rules or update them as the 337 network evolves and its traffic dynamics change. Some possible ways 338 to achieve this include individual policy counters that can be 339 exported or retrieved for example via SNMP, and logging of filtering 340 actions. 342 Finally, the use of flow-based behavioral analysis or CLI functions 343 to identify what client/server functions a given router's control 344 plane handles would be very useful during initial policy development 345 phases, and certainly for forensic analysis afterwards. 347 4. Security Considerations 349 The filter above leaves the router susceptible to discovery from any 350 host on the Internet. If network operators find this risk 351 objectionable, they can reduce the exposure by restricting the sub- 352 networks from which ICMP Echo requests or traceroute packets are 353 accepted. A similar concern exists for ICMPv6 traffic but on a 354 broader level due to the additional functionalities implemented in 355 ICMPv6. Filtering recommendations for ICMPv6 can be found in 356 [RFC4890]. Moreover, different rate-limiting policies may be defined 357 for internally (e.g., from the NOC) versus externally sourced 358 traffic. Note that this document is not targeted at the specifics of 359 ICMP filtering or traffic filtering designed to prevent device 360 discovery. 362 The filter above does not block unwanted traffic having spoofed 363 source addresses that match a defined traffic profile in Section 3.1. 364 Network operators can mitigate this risk by preventing source address 365 spoofing with filters applied at the network edge. Refer to Section 366 5.3.8 of [RFC1812] for more information regarding source address 367 validation. Other methods also exist for limiting exposure to packet 368 spoofing such as the Generalized TTL Security Mechanism (GTSM) 369 [RFC5082] and Ingress Filtering [RFC2827] [RFC3704]. 371 The ICMP rate limiter specified in this filter protects the router 372 from floods of ICMP traffic. However, during an ICMP flood, some 373 legitimate ICMP traffic may be dropped. Because of this, when 374 operators discover a flood of ICMP traffic, they are highly motivated 375 to cut it off at the source. 377 Additional considerations pertaining to the usage and handling of 378 traffic that utilizes the IP Router Alert Options can be found at 379 [I-D.ietf-intarea-router-alert-considerations], and additional IP 380 Options filtering explanations can be found at 381 [I-D.gont-opsec-ip-options-filtering]. 383 The treatment of exception traffic in the forwarding plane, and the 384 generation of specific messages by the router control plane also 385 requires protection from a DoS attack. Specifically, the generation 386 of ICMP Unreachable messages by the router control plane needs to be 387 rate-limited, either implicitly within the router's architecture or 388 explicitly through configuration. Continuous benchmarking of router 389 generated ICMP traffic should be done before applying rate limits 390 such that sufficient headroom is included to prevent inadvertent 391 PMTUD blackhole scenarios during normal operation. It is also 392 recommended to deploy explicit rate limiters where possible to 393 improve troubleshooting and monitoring capability. The explicit rate 394 limiters in a class allow for monitoring tools to detect and report 395 when the rate limiters become active which serve as an indicator that 396 either the normal traffic has increased or out of policy traffic 397 rates have been detected. For additional information regarding 398 specific ICMP rate limiting see Section 4.3.2.8 of [RFC1812]. 400 Additionally, the handling of TTL / Hop Limit expired traffic needs 401 protection. This traffic is not necessarily addressed to the device, 402 but it can get sent to the control plane to process the TTL / Hop 403 Limit expiration. For example, rate limiting the TTL / Hop Limit 404 expired traffic before sending the packets to the router control 405 plane component that will generate the ICMP error, and distributing 406 the sending of ICMP errors to Line Card CPUs are protection 407 mechanisms that mitigate attacks before they can negatively affect a 408 rate-limited router control plane component. 410 5. IANA Considerations 412 [RFC Editor: please remove this section prior to publication.] 414 This document has no IANA actions. 416 6. Acknowledgements 418 The authors would like to thank Ron Bonica for providing initial and 419 ongoing review, suggestions, and valuable input. Pekka Savola, 420 Warren Kumari, and Xu Chen provided very thorough and useful feedback 421 that improved the document. Many thanks to John Kristoff, 422 Christopher Morrow, and Donald Smith for a fruitful discussion around 423 the operational and manageability aspects of router control plane 424 protection techniques. The authors would also like to thank Joel 425 Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie 426 Parra, Seo Boon Ng, Manav Bhatia, and German Martinez for providing 427 thorough review, useful suggestions, and valuable input. Many thanks 428 to Jim Bailey and Raphan Han for providing technical direction and 429 sample configuration guidance on the IPv6 sections. Many thanks also 430 go to Andrew Yourtchenko for his review, comments, and willingness to 431 present on behalf of the authors. 433 7. Informative References 435 [I-D.gont-opsec-ip-options-filtering] 436 Gont, F. and S. Fouant, "IP Options Filtering 437 Recommendations", draft-gont-opsec-ip-options-filtering-00 438 (work in progress), March 2010. 440 [I-D.ietf-intarea-router-alert-considerations] 441 Faucheur, F., "IP Router Alert Considerations and Usage", 442 draft-ietf-intarea-router-alert-considerations-01 (work in 443 progress), July 2010. 445 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 446 RFC 1812, June 1995. 448 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 449 Defeating Denial of Service Attacks which employ IP Source 450 Address Spoofing", BCP 38, RFC 2827, May 2000. 452 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 453 Networks", BCP 84, RFC 3704, March 2004. 455 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 456 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 458 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 459 Pignataro, "The Generalized TTL Security Mechanism 460 (GTSM)", RFC 5082, October 2007. 462 Appendix A. Configuration Examples 464 The configurations provided below are syntactical represenations of 465 the semantics described in the document and should be treated as non- 466 normative. 468 A.1. Cisco Configuration 470 !Start: Protecting The Router Control Plane 471 ! 472 !Policy-map Configuration 473 ! 474 !Access-list Definitions 475 ip access-list extended ICMP 476 permit icmp any any 477 ipv6 access-list ICMPv6 478 permit icmp any any 479 ip access-list extended OSPF 480 permit ospf 192.0.2.0 0.0.0.255 any 481 ipv6 access-list OSPFv3 482 permit 89 2001:DB8:1::/48 any 483 ip access-list extended IBGP 484 permit tcp 192.0.2.0 0.0.0.255 eq bgp any 485 permit tcp 192.0.2.0 0.0.0.255 any eq bgp 486 ipv6 access-list IBGPv6 487 permit tcp 2001:DB8:1::/48 eq bgp any 488 permit tcp 2001:DB8:1::/48 any eq bgp 489 ip access-list extended EBGP 490 permit tcp host 198.51.100.25 eq bgp any 491 permit tcp host 198.51.100.25 any eq bgp 492 permit tcp host 198.51.100.27 eq bgp any 493 permit tcp host 198.51.100.27 any eq bgp 494 permit tcp host 198.51.100.29 eq bgp any 495 permit tcp host 198.51.100.29 any eq bgp 496 permit tcp host 198.51.100.31 eq bgp any 497 permit tcp host 198.51.100.31 any eq bgp 498 ipv6 access-list EBGPv6 499 permit tcp host 2001:DB8:100::25 eq bgp any 500 permit tcp host 2001:DB8:100::25 any eq bgp 501 permit tcp host 2001:DB8:100::27 eq bgp any 502 permit tcp host 2001:DB8:100::27 any eq bgp 503 permit tcp host 2001:DB8:100::29 eq bgp any 504 permit tcp host 2001:DB8:100::29 any eq bgp 505 permit tcp host 2001:DB8:100::31 eq bgp any 506 permit tcp host 2001:DB8:100::31 any eq bgp 507 ip access-list extended DNS 508 permit udp 198.51.100.0 0.0.0.252 eq domain any 509 ipv6 access-list DNSv6 510 permit udp 2001:DB8:100:1::/64 eq domain any 511 permit tcp 2001:DB8:100:1::/64 eq domain any 512 ip access-list extended NTP 513 permit udp 198.51.100.4 255.255.255.252 any eq ntp 514 ipv6 access-list NTPv6 515 permit udp 2001:DB8:100:2::/64 any eq ntp 516 ip access-list extended SSH 517 permit tcp 198.51.100.128 0.0.0.128 any eq 22 518 ipv6 access-list SSHv6 519 permit tcp 2001:DB8:100:3::/64 any eq 22 520 ip access-list extended SNMP 521 permit udp 198.51.100.128 0.0.0.128 any eq snmp 522 ipv6 access-list SNMPv6 523 permit udp 2001:DB8:100:3::/64 any eq snmp 524 ip access-list extended RADIUS 525 permit udp host 198.51.100.9 eq 1645 any 526 permit udp host 198.51.100.9 eq 1646 any 527 permit udp host 198.51.100.10 eq 1645 any 528 permit udp host 198.51.100.10 eq 1646 any 529 ipv6 access-list RADIUSv6 530 permit udp host 2001:DB8:100::9 eq 1645 any 531 permit udp host 2001:DB8:100::9 eq 1646 any 532 permit udp host 2001:DB8:100::10 eq 1645 any 533 permit udp host 2001:DB8:100::10 eq 1646 any 534 ip access-list extended FRAGMENTS 535 permit ip any any fragments 536 ipv6 access-list FRAGMENTSv6 537 permit ipv6 any any fragments 538 ip access-list extended ALLOTHERIP 539 permit ip any any 540 ipv6 access-list ALLOTHERIPv6 541 permit ipv6 any any 543 ! 544 !Class Definitions 545 ! 546 class-map match-any ICMP 547 match access-group name ICMP 548 class-map match-any ICMPv6 549 match access-group name ICMPv6 550 class-map match-any OSPF 551 match access-group name OSPF 552 match access-group name OSPFv3 553 class-map match-any IBGP 554 match access-group name IBGP 555 match access-group name IBGPv6 556 class-map match-any EBGP 557 match access-group name EBGP 558 match access-group name EBGPv6 559 class-map match-any DNS 560 match access-group name DNS 561 match access-group name DNSv6 562 class-map match-any NTP 563 match access-group name NTP 564 match access-group name NTPv6 565 class-map match-any SSH 566 match access-group name SSH 567 match access-group name SSHv6 568 class-map match-any SNMP 569 match access-group name SNMP 570 match access-group name SNMPv6 571 class-map match-any RADIUS 572 match access-group name RADIUS 573 match access-group name RADIUSv6 574 class-map match-any FRAGMENTS 575 match access-group name FRAGMENTS 576 match access-group name FRAGMENTSv6 577 class-map match-any ALLOTHERIP 578 match access-group name ALLOTHERIP 579 class-map match-any ALLOTHERIPv6 580 match access-group name ALLOTHERIPv6 581 ! 582 !Policy Definition 583 ! 584 policy-map COPP 585 class FRAGMENTS 586 drop 587 class ICMP 588 police 500000 589 conform-action transmit 590 exceed-action drop 591 violate-action drop 592 class ICMPv6 593 police 500000 594 conform-action transmit 595 exceed-action drop 596 violate-action drop 597 class OSPF 598 class IBGP 599 class EBGP 600 class DNS 601 class NTP 602 class SSH 603 class SNMP 604 class RADIUS 605 class ALLOTHERIP 606 police cir 500000 607 conform-action transmit 608 exceed-action drop 609 violate-action drop 610 class ALLOTHERIPv6 611 police cir 500000 612 conform-action transmit 613 exceed-action drop 614 violate-action drop 615 class class-default 616 police cir 250000 617 conform-action transmit 618 exceed-action drop 619 violate-action drop 620 ! 621 !Control Plane Configuration 622 ! 623 control-plane 624 service-policy input COPP 625 ! 626 !End: Protecting The Router Control Plane 628 A.2. Juniper Configuration 630 policy-options { 631 prefix-list IBGP-NEIGHBORS { 632 192.0.2.0/24; 633 } 634 prefix-list EBGP-NEIGHBORS { 635 198.51.100.25/32; 636 198.51.100.27/32; 637 198.51.100.29/32; 638 198.51.100.31/32; 639 } 640 prefix-list RADIUS-SERVERS { 641 198.51.100.9/32; 642 198.51.100.10/32; 643 } 644 prefix-list IBGPv6-NEIGHBORS { 645 2001:DB8:1::/48; 646 } 647 prefix-list EBGPv6-NEIGHBORS { 648 2001:DB8:100::25/128; 649 2001:DB8:100::27/128; 650 2001:DB8:100::29/128; 651 2001:DB8:100::31/128; 652 } 653 prefix-list RADIUSv6-SERVERS { 654 2001:DB8:100::9/128; 655 2001:DB8:100::10/128; 656 } 657 } 658 firewall { 659 policer 500kbps { 660 if-exceeding { 661 bandwidth-limit 500k; 662 burst-size-limit 1500; 663 } 664 then discard; 665 } 666 policer 250kbps { 667 if-exceeding { 668 bandwidth-limit 250k; 669 burst-size-limit 1500; 670 } 671 then discard; 672 } 673 family inet { 674 filter protect-router-control-plane { 675 term first-frag { 676 from { 677 first-fragment; 678 } 679 then { 680 count frag-discards; 681 log; 682 discard; 683 } 684 } 685 term next-frag { 686 from { 687 is-fragment; 688 } 689 then { 690 count frag-discards; 691 log; 692 discard; 693 } 694 } 695 term icmp { 696 from { 697 protocol icmp; 698 } 699 then { 700 policer 500kbps; 701 accept; 702 } 703 } 704 term ospf { 705 from { 706 source-address { 707 192.0.2.0/24; 708 } 709 protocol ospf; 710 } 711 then accept; 712 } 713 term ibgp-connect { 714 from { 715 source-prefix-list { 716 IBGP-NEIGHBORS; 717 } 718 protocol tcp; 719 destination-port bgp; 720 } 721 then accept; 722 } 723 term ibgp-reply { 724 from { 725 source-prefix-list { 726 IBGP-NEIGHBORS; 727 } 728 protocol tcp; 729 port bgp; 730 } 731 then accept; 732 } 733 term ebgp-connect { 734 from { 735 source-prefix-list { 736 EBGP-NEIGHBORS; 737 } 738 protocol tcp; 739 destination-port bgp; 740 } 741 then accept; 742 } 743 term ebgp-reply { 744 from { 745 source-prefix-list { 746 EBGP-NEIGHBORS; 747 } 748 protocol tcp; 749 port bgp; 750 } 751 then accept; 752 } 753 term dns { 754 from { 755 source-address { 756 198.51.100.0/30; 757 } 758 protocol udp; 759 port domain; 760 } 761 then accept; 762 } 763 term ntp { 764 from { 765 source-address { 766 198.51.100.4/30; 767 } 768 protocol udp; 769 destination-port ntp; 770 } 771 then accept; 772 } 773 term ssh { 774 from { 775 source-address { 776 198.51.100.128/25; 777 } 778 protocol tcp; 779 destination-port ssh; 780 } 781 then accept; 783 } 784 term snmp { 785 from { 786 source-address { 787 198.51.100.128/25; 788 } 789 protocol udp; 790 destination-port snmp; 791 } 792 then accept; 793 } 794 term radius { 795 from { 796 source-prefix-list { 797 RADIUS-SERVERS; 798 } 799 protocol udp; 800 port [ 1645 1646 ]; 801 } 802 then accept; 803 } 804 term default-term { 805 then { 806 count copp-exceptions; 807 log; 808 policer 500kbps; 809 accept; 810 } 811 } 812 } 813 } 815 family inet6 { 816 filter protect-router-control-plane-v6 { 817 term fragv6 { 818 from { 819 next-header fragment; 820 } 821 then { 822 count frag-v6-discards; 823 log; 824 discard; 825 } 826 } 827 term icmpv6 { 828 from { 829 next-header icmpv6; 830 } 831 then { 832 policer 500kbps; 833 accept; 834 } 835 } 836 term ospfv3 { 837 from { 838 source-address { 839 2001:DB8:1::/48; 840 } 841 next-header ospf; 842 } 843 then accept; 844 } 845 term ibgpv6-connect { 846 from { 847 source-prefix-list { 848 IBGPv6-NEIGHBORS; 849 } 850 next-header tcp; 851 destination-port bgp; 852 } 853 then accept; 854 } 855 term ibgpv6-reply { 856 from { 857 source-prefix-list { 858 IBGPv6-NEIGHBORS; 859 } 860 next-header tcp; 861 port bgp; 862 } 863 then accept; 864 } 865 term ebgpv6-connect { 866 from { 867 source-prefix-list { 868 EBGPv6-NEIGHBORS; 869 } 870 next-header tcp; 871 destination-port bgp; 872 } 873 then accept; 874 } 875 term ebgpv6-reply { 876 from { 877 source-prefix-list { 878 EBGPv6-NEIGHBORS; 880 } 881 next-header tcp; 882 port bgp; 883 } 884 then accept; 885 } 886 term dnsv6 { 887 from { 888 source-address { 889 2001:DB8:100:1::/64; 890 } 891 next-header [ udp tcp ]; 892 port domain; 893 } 894 then accept; 895 } 896 term ntpv6 { 897 from { 898 source-address { 899 2001:DB8:100:2::/64; 900 } 901 next-header udp; 902 destination-port ntp; 903 } 904 then accept; 905 } 906 term sshv6 { 907 from { 908 source-address { 909 2001:DB8:100:3::/64; 910 } 911 next-header tcp; 912 destination-port ssh; 913 } 914 then accept; 915 } 916 term snmpv6 { 917 from { 918 source-address { 919 2001:DB8:100:3::/64; 920 } 921 next-header udp; 922 destination-port snmp; 923 } 924 then accept; 925 } 926 term radiusv6 { 927 from { 928 source-prefix-list { 929 RADIUSv6-SERVERS; 930 } 931 next-header udp; 932 port [ 1645 1646 ]; 933 } 934 then accept; 935 } 936 term default-term-v6 { 937 then { 938 policer 500kbps; 939 count copp-exceptions-v6; 940 log; 941 accept; 942 } 943 } 944 } 945 } 947 family any { 948 filter protect-router-control-plane-non-ip { 949 term rate-limit-non-ip { 950 then { 951 policer 250kbps; 952 accept; 953 } 954 } 955 } 956 } 957 } 958 interfaces { 959 lo0 { 960 unit 0 { 961 family inet { 962 filter input protect-router-control-plane; 963 } 964 family inet6 { 965 filter input protect-router-control-plane-v6; 966 } 967 family any { 968 filter input protect-router-control-plane-non-ip; 969 } 970 } 971 } 972 } 974 Authors' Addresses 976 David Dugal 977 Juniper Networks 978 10 Technology Park Drive 979 Westford, MA 01886 980 US 982 Email: ddugal@juniper.net 984 Carlos Pignataro 985 Cisco Systems 986 7200-12 Kit Creek Road 987 Research Triangle Park, NC 27709 988 US 990 Email: cpignata@cisco.com 992 Rodney Dunn 993 Cisco Systems 994 7200-12 Kit Creek Road 995 Research Triangle Park, NC 27709 996 US 998 Email: rodunn@cisco.com