idnits 2.17.1 draft-dugal-opsec-protect-control-plane-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 23, 2010) is 5176 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: August 27, 2010 R. Dunn 6 Cisco Systems 7 February 23, 2010 9 Protecting The Router Control Plane 10 draft-dugal-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 control plane traffic is identifed. Once legitimate 17 traffic has been identified, a filter is deployed on the router's 18 forwarding plane. That filter prevents traffic not specifically 19 identified as legitimate from reaching the router's control plane. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 27, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 63 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Legitimate Traffic . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Filter Design . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Design Trade-offs . . . . . . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 71 Appendix A. Cisco Configuration . . . . . . . . . . . . . . . . . 8 72 Appendix B. Juniper Configuration . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 Modern core router architecture design maintains a strict separation 78 of forwarding and control plane hardware and software. Forwarding 79 plane is typically described as router architecture hardware and 80 software components responsible for taking a packet coming in one 81 interface, performing a lookup to identify the packet's IP next hop 82 and determine the outgoing interface towards the destination, and 83 forwarding the packet through the correct outgoing interface. 84 Control plane supports routing and management functions, and is 85 generally described as as router architecture hardware and software 86 components for handling packets destined to the device itself as well 87 as building and sending packets originated locally on the device. 89 Visually it can be represented as the control plane hardware sitting 90 on top of and interfacing with the forwarding plane hardware, with 91 interfaces connecting to other network devices. See Figure 1. 93 +---------------+ 94 | Control 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 control 110 plane is generally realized in software on general purpose 111 processors. While software instructions run on both planes, the 112 control plane software is usually not optimized for high speed packet 113 handling. Given their differences in packet handling capabilities, 114 control plane hardware is more suceptible to be overwhelmed by a DoS 115 attack than forwarding plane ASICs. It is imperative that the 116 control plane remain stable regardless of traffic load to and from 117 the device because the control plane is what drives the programming 118 of the forwarding plane. 120 The control plane processes traffic destined to the router, and 121 because of the wider range of functionality is more suceptible to 122 security vulnerabilities and a more likely target for a DoS attack 123 than the forwarding plane. 125 It is advisable to protect the control plane by implementing 126 mechanisms to filter completely or rate limit traffic not required at 127 the control plane level (i.e., unwanted traffic). Control Plane 128 Protection is the concept of filtering traffic unwanted traffic which 129 would be diverted out of the forwarding plane up to the control 130 plane. The closer to the forwarding plane and line-rate hardware the 131 filters and rate-limiters are, the more effective the protection is 132 and the more resistent the system is to DoS attacks. This memo 133 demonstrates how to deploy such a filter. 135 2. Applicability Statement 137 The method described in Section 3 is a sample illustration to 138 demonstrate 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 cateorization of legitimate control plane traffic is critically 142 important in a successul 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. 149 This method is applicable for IPv4 as well as IPv6 traffic. The 150 sample legitimate traffic in Section 3.1 uses IPv4 addresses, but can 151 be expanded to IPv6 as well. 153 3. Method 155 In this memo, the authors demonstrate how a filter protecting the 156 control plane can be deployed. In Section 3.1, a sample router 157 introduced and all traffic that its control plane must process is 158 identified. In Section 3.2, filter design concepts are discussed. 159 Cisco (Cisco IOS software) and Juniper (JUNOS) implementations are 160 provided in Appendices A and B, respectively. 162 3.1. Legitimate Traffic 164 In this example, the router control plane must process traffic from 165 the following sources: 167 o ICMP traffic from any source, rate-limited to 2 Mbps 169 o OSPF traffic from routers within own network (network mask 170 192.0.2.0/24) 172 o iBGP traffic from routers within own network (network mask 173 192.0.2.0/24) 175 o eBGP traffic from known eBGP peers (network addresses 176 198.51.100.25, 198.51.100.27, 198.51.100.29, 198.51.100.31) 178 o DNS traffic from local DNS resolvers (198.51.100.0/30) 180 o NTP traffic from local NTP (198.51.100.4/30) 182 o SSH traffic from network management stations (198.51.100.128/25) 184 o SNMP traffic from network management stations (198.51.100.128/25) 186 The characteristics of legitimate traffic will vary from network to 187 network. The list provided above is for example only. 189 3.2. Filter Design 191 A filter is installed on the forwarding plane. This filter counts 192 and silently discards all traffic not matching the profile provided 193 in Section 3.1. Because the filter is enforced on the forwarding 194 plane, it prevents unwanted traffic from consuming bandwidth on the 195 interface that connects the forwarding plane to the control plane. 196 The counters serve as an important forensic tool for the analysis of 197 potential attacks, and as an invaluable debugging and troubleshooting 198 aid. 200 A rate limiter also is installed on the forwarding plane. The rate 201 limiter restricts ICMP traffic bound for the control plane to some 202 reasonable volume. In our example, we will rate limit to 2 Megabits 203 per second (Mbps). 205 Syntactically, these filters explicitly define "allowed" traffic 206 (including IP addresses, protocols, and ports), define acceptable 207 actions for these acceptable traffic profiles (e.g., rate-limit or 208 simply permit the traffic), and then drop to the bit bucket all 209 traffic destined to the control plane but not explicitly allowed. 211 3.3. Design Trade-offs 213 In designing the protection method, there are two independent parts 214 to consider: the classification of traffic (i.e., which traffic is 215 matched by the filters), and the policy actions taken on the 216 classified traffic. 218 There are different levels of granularity utilized for traffic 219 classification. For example, allowing all traffic from specific 220 source IP addresses versus allowing only a specific set of protocols 221 from those specific source IP addresses will each affect a different 222 set of traffic. 224 Similarly, the policy actions taken on the classified traffic have 225 degrees of impact that may not become immediately obvious. For 226 example, discarding all ICMP traffic may have a negative impact on 227 the operational use of ICMP tools such as ping or traceroute to debug 228 network issues or to test turn up of a new circuit. 230 It is important to note that both classification and policy action 231 decisions are accompanied by respective trade-offs. Two examples of 232 these trade-off decisions are, operational complexity at the expense 233 of policy (and statistics gathering) detail, and tighter protection 234 at the expense of network supportability and troubleshooting ability. 236 The goal of the method for protecting the router control plane is to 237 minimize potential disruptions. The granularity of the filter design 238 inversely correlates to the scope of the potential disruption. The 239 finer the granularity of the filter design (e.g., isolating kinds of 240 sub-traffic from the rest of the policed traffic, or isolating valid 241 source addresses into a different class or classes) the smaller the 242 scope of disruption. 244 Additionally, the baselining and monitoring of traffic flows to the 245 router's control plane are critical in determining both the rates and 246 granularity of the policies being applied. This is important to 247 validate the existing policies and rules or update them as the 248 network evolves and its traffic dynamics change. Some possible ways 249 to achieve this include individual policy counters that can be 250 exported or retrieved for example via SNMP, and logging of filtering 251 actions. 253 4. Security Considerations 255 The filter above leaves the router susceptible to discovery from any 256 host on the Internet. If network operators find this risk 257 objectionable, they can mitigate it by restricting the sub-networks 258 from which ICMP Echo requests are accepted. 260 The filter above also leaves the router exposed to port scans from 261 hosts spoofing the source addresses found in Section 3.1. Network 262 operators can mitigate this risk by preventing source address 263 spoofing with filters applied at the network edge. Refer to Section 264 5.3.8 of [RFC1812] for more information regarding source address 265 validation. Other methods also exist for limiting exposure to packet 266 spoofing such as the Generalized TTL Security Mechanism (GTSM) 267 [RFC5082] and Ingress Filtering [RFC3704]. 269 The ICMP rate limiter specified in this filter protects the router 270 from floods of ICMP traffic. However, during an ICMP flood, some 271 legitimate ICMP traffic may be dropped. Because of this, when 272 operators discover a flood of ICMP traffic, they are highly motivated 273 to cut it off at its source. 275 Additional considerations pertaining to the usage and handling of 276 traffic that utilizes the IP Router Alert Options can be found at 277 [I-D.rahman-rtg-router-alert-considerations]. 279 The treatment of exception traffic in the forwarding plane, and the 280 generation of specific messages by the control plane also requires 281 protection from a DoS attack. Specifically, the generation of ICMP 282 Unreachable messages by the control plane needs to be rate-limited, 283 either implicitly within the router's architecture or explicitly 284 through configuration. See Section 4.3.2.8 of [RFC1812]. 286 Additionally, the handling of TTL / Hop Limit expired traffic needs 287 protection. For example, rate limiting the TTL / Hop Limit expired 288 traffic before sending the packets to the control plane component 289 that will send the ICMP error, and distributing the sending of ICMP 290 errors in a Line Card CPU are protection mechanisms that deter 291 attacks before a rate limited in the main control plane component. 293 5. IANA Considerations 295 [RFC Editor: please remove this section prior to publication.] 297 This document has no IANA actions. 299 6. Acknowledgements 301 The authors would like to thank Ron Bonica for providing initial 302 review, suggestions, and valuable input. Pekka Savola, Warren Kumari 303 and Xu Chen provided very thorough and useful feedback that improved 304 the document. Many thanks to John Kristoff, Christopher Morrow, and 305 Donald Smith for a fruitful discussion around operational and 306 manegeability aspects of control plane protection techniques. 308 7. Informative References 310 [I-D.rahman-rtg-router-alert-considerations] 311 Faucheur, F., "IP Router Alert Considerations and Usage", 312 draft-rahman-rtg-router-alert-considerations-03 (work in 313 progress), October 2009. 315 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 316 RFC 1812, June 1995. 318 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 319 Networks", BCP 84, RFC 3704, March 2004. 321 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 322 Pignataro, "The Generalized TTL Security Mechanism 323 (GTSM)", RFC 5082, October 2007. 325 Appendix A. Cisco Configuration 327 !Start: Protecting The Router Control Plane 328 ! 329 !Policy-map Configuration 330 ! 331 !Access-list Definitions 332 ip access-list extended ICMP 333 permit icmp any any 334 ip access-list extended OSPF 335 permit ospf 192.0.2.0 0.0.0.255 any 336 ip access-list extended IBGP 337 permit tcp 192.0.2.0 0.0.0.255 eq bgp any 338 permit tcp 192.0.2.0 0.0.0.255 any eq bgp 339 ip access-list extended EBGP 340 permit tcp host 198.51.100.25 eq bgp any 341 permit tcp host 198.51.100.25 any eq bgp 342 permit tcp host 198.51.100.27 eq bgp any 343 permit tcp host 198.51.100.27 any eq bgp 344 permit tcp host 198.51.100.29 eq bgp any 345 permit tcp host 198.51.100.29 any eq bgp 346 permit tcp host 198.51.100.31 eq bgp any 347 permit tcp host 198.51.100.31 any eq bgp 348 ip access-list extended DNS 349 permit udp 198.51.100.0 0.0.0.252 eq domain any 350 ip access-list extended NTP 351 permit udp 198.51.100.4 255.255.255.252 any eq ntp 352 ip access-list extended SSH 353 permit tcp 198.51.100.0 0.0.0.128 any eq 22 355 ip access-list extended SNMP 356 permit udp 198.51.100.128 0.0.0.125 eq snmp any 357 permit udp 198.51.100.128 0.0.0.125 eq snmptrap any 358 ! 359 !Class Definitions 360 ! 361 class-map match-all ICMP 362 match access-group name ICMP 363 class-map match-all OSPF 364 match access-group name OSPF 365 class-map match-all IBGP 366 match access-group name IBGP 367 class-map match-all EBGP 368 match access-group name EBGP 369 class-map match-all DNS 370 match access-group name DNS 371 class-map match-all NTP 372 match access-group name NTP 373 class-map match-all SSH 374 match access-group name SSH 375 class-map match-all SNMP 376 match access-group name SNMP 377 ! 378 !Policy Definition 379 ! 380 policy-map COPP 381 class ICMP 382 police 2000000 383 class OSPF 384 class IBGP 385 class EBGP 386 class DNS 387 class NTP 388 class SSH 389 class SNMP 390 class class-default 391 police cir 8000 392 conform-action drop 393 exceed-action drop 394 violate-action drop 395 ! 396 !Control Plane Configuration 397 ! 398 control-plane 399 service-policy input COPP 400 ! 401 !End: Protecting The Router Control Plane 403 Appendix B. Juniper Configuration 405 policy-options { 406 prefix-list IBGP-NEIGHBORS { 407 192.0.2.0/24; 408 } 409 prefix-list EBGP-NEIGHBORS { 410 198.51.100.25/32; 411 198.51.100.27/32; 412 198.51.100.29/32; 413 198.51.100.31/32; 414 } 415 } 416 firewall { 417 policer 2Mbps { 418 if-exceeding { 419 bandwidth-limit 2m; 420 burst-size-limit 2k; 421 } 422 then discard; 423 } 424 family inet { 425 filter protect-control-plane { 426 term icmp { 427 from { 428 protocol icmp; 429 } 430 policer 2Mbps; 431 then accept; 432 } 433 term ospf { 434 from { 435 source-address { 436 192.0.2.0/24; 437 } 438 protocol ospf; 439 } 440 then accept; 441 } 442 term ibgp-connect { 443 from { 444 source-prefix-list { 445 IBGP-NEIGHBORS; 446 } 447 protocol tcp; 448 destination-port bgp; 449 } 450 then accept; 451 } 452 term ibgp-reply { 453 from { 454 source-prefix-list { 455 IBGP-NEIGHBORS; 456 } 457 protocol tcp; 458 port bgp; 459 } 460 then accept; 461 } 462 term ebgp-connect { 463 from { 464 source-prefix-list { 465 EBGP-NEIGHBORS; 466 } 467 protocol tcp; 468 destination-port bgp; 469 } 470 then accept; 471 } 472 term ebgp-reply { 473 from { 474 source-prefix-list { 475 EBGP-NEIGHBORS; 476 } 477 protocol tcp; 478 port bgp; 479 } 480 then accept; 481 } 482 term dns { 483 from { 484 source-address { 485 198.51.100.0/30; 486 } 487 protocol udp; 488 port domain; 489 } 490 then accept; 491 } 492 term ntp { 493 from { 494 source-address { 495 198.51.100.4/30; 496 } 497 protocol udp; 498 destination-port ntp; 499 } 500 then accept; 501 } 502 term ssh { 503 from { 504 source-address { 505 198.51.100.128/25; 506 } 507 protocol tcp; 508 destination-port ssh; 509 } 510 then accept; 511 } 512 term snmp { 513 from { 514 source-address { 515 198.51.100.128/25; 516 } 517 protocol udp; 518 port [snmp snmptrap]; 519 } 520 then accept; 521 } 522 term default-term { 523 then { 524 count copp-discards; 525 log; 526 discard; 527 } 528 } 529 } 530 } 531 } 532 interfaces { 533 lo0 { 534 unit 0 { 535 family inet { 536 filter input protect-control-plane; 537 } 538 } 539 } 540 } 542 Authors' Addresses 544 David Dugal 545 Juniper Networks 546 10 Technology Park Drive 547 Westford, MA 01886 548 US 550 Email: ddugal@juniper.net 552 Carlos Pignataro 553 Cisco Systems 554 7200-12 Kit Creek Road 555 Research Triangle Park, NC 27709 556 US 558 Email: cpignata@cisco.com 560 Rodney Dunn 561 Cisco Systems 562 7200-12 Kit Creek Road 563 Research Triangle Park, NC 27709 564 US 566 Email: rodunn@cisco.com