idnits 2.17.1 draft-ietf-opsec-blackhole-urpf-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 (March 30, 2009) is 5506 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Opsec Working Group W. Kumari 3 Internet Draft Google 4 D. McPherson 5 Category: Informational Arbor Networks 6 Expires: September 30, 2009 7 March 30, 2009 9 Remote Triggered Black Hole filtering with uRPF 10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 5, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Remote Triggered Black Hole (RTBH) filtering is a popular and 49 effective technique for the mitigation of denial-of-service attacks. 50 This document expands upon destination-based RTBH filtering by 51 outlining a method to enable filtering by source address as well. 53 Table of Contents 55 1. Introduction ....................................................3 56 2. Terminology .....................................................3 57 3. Background ......................................................3 58 4. Destination address RTBH filtering ..............................4 59 4.1. Overview ...................................................4 60 4.2. Detail .....................................................5 61 5. Source address RTBH filtering ...................................7 62 5.1. Steps to deploy RTBH filtering with uRPF ...................8 63 6. Security Considerations .........................................9 64 7. IANA Considerations .............................................9 65 8. Acknowledgments .................................................9 66 9. References ......................................................9 67 9.1. Normative References .......................................9 68 9.2. Informative References ....................................10 69 A. Cisco Router Configuration Sample...............................11 70 B. Juniper Configuration Sample....................................13 71 C. A Brief History of RTBH.........................................15 73 1. Introduction 75 This document expands upon the technique outlined in "Configuring BGP 76 to Block Denial-of-Service Attacks" [RFC3882] to demonstrate a method 77 that allows for filtering by source address(es). 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119. [RFC2119]. 85 3. Background 87 Network operators have developed a variety of techniques for 88 mitigating denial of service attacks. While different techniques have 89 varying strengths and weaknesses, from an implementation perspective 90 the selection of which method to use for each type of attack involves 91 evaluating the tradeoffs associated with each method. 93 A common DoS attack directed against a customer of a service provider 94 involves generating a greater volume of attack traffic destined for 95 the target than will fit down the links from the service provider(s) 96 to the victim (customer). This traffic "starves out" legitimate 97 traffic and often results in collateral damage or negative effects to 98 other customers or the network infrastructure as well. Rather than 99 having all destinations on their network be affected by the attack, 100 the customer may ask their service provider to filter traffic 101 destined to the target destination IP address(es), or the service 102 provider may determine that this is necessary themselves, in order to 103 preserve network availability. 105 One method that the service provider can use to implement this 106 filtering is to deploy access control lists on the edge of their 107 network. While this technique provides a large amount of flexibility 108 in the filtering, it runs into scalability issues, both in terms of 109 the number of entries in the filter and the packet rate. 111 Most routers are able to forward traffic at a much higher rate than 112 they are able to filter, and are able to hold many more forwarding 113 table entries and routes than filter entries. RTBH filtering 114 leverages the forwarding performance of modern routers to filter both 115 more entries and at a higher rate than access control lists would 116 otherwise allow. 118 However, with destination-based RTBH filtering, the impact of the 119 attack on the target is complete. That is, destination-based RTBH 120 filtering injects a discard route into the forwarding table for the 121 target prefix. All packets towards that destination, attack traffic 122 AND legitimate traffic, are then dropped by the participating 123 routers,thereby taking the target completely offline. The benefit is 124 that collateral damage to other systems or network availability at 125 the customer location or in the ISP network is limited, but the 126 negative impact to the target itself is arguably increased. 128 By coupling unicast reverse path forwarding (RPF) [RFC3704] 129 techniques with RTBH filtering, BGP can be used to distribute discard 130 routes that are based not on destination or target addresses, but 131 based on source addresses of unwanted traffic. 133 4. Destination address RTBH filtering 135 4.1. Overview 137 A "discard" route is installed on each edge router in the network 138 with the destination set to the discard (or null) interface. In order 139 to use RTBH filtering for a single IP address (or prefix), a BGP 140 route for the address to be filtered is announced, with the next-hop 141 set as the "discard" route. This causes traffic to the announced 142 network prefix to be forwarded to the discard interface so that it 143 does not transit the network wasting resources or triggering 144 collateral damage to other resources along the path towards the 145 target. 147 While this does "complete" the attack in that the target address(es) 148 are made unreachable, collateral damage is minimized. It may also be 149 possible to move the host or service on the target IP address(es) to 150 another address and keep the service up, for example by updating 151 associated DNS resource records. 153 4.2. Detail 155 Steps to configure destination based RTBH filtering: 157 1. Select your Discard Address schema. An address is chosen to become 158 the "discard address". This is often chosen from 192.0.2.0/24 (TEST- 159 NET [RFC3330]), or from RFC 1918 [RFC1918] space. Multiple addresses 160 allow an operator to configure multiple static routes, one for each 161 incident: 163 192.0.2.1 = Incident #1 164 192.0.2.2 = Incident #2 165 192.0.2.3 = Incident #3 166 192.0.2.4 = Incident #4 167 192.0.2.5 = Incident #5 169 Customer #1 who has a DDoS attack can be pointed to discard route 170 192.0.2.1. Customer #2 can be pointed to discard route 192.0.2.2. If 171 capable, the router can then count the drops for each, providing some 172 level of telemetry on the volume of drops as well as status of an 173 ongoing attack. A consistent address schema facilitates operations. 175 2. Set the Discard Route(s) on each router. A route for the "discard 176 address" is installed on the routers that form the edge/perimeter of 177 the network, in all routers in the network, or some subset (e.g., 178 peering, but not customer, etc.). The destination of the route is set 179 to the "discard" or "null" interface. This route is called the 180 "discard route". Implementation experience demonstrates the value of 181 configuring each ingress router with a capability for dropping 182 traffic via RTBH filtering. 184 3. Configure the RTBH BGP Policy on each router. A BGP policy is 185 configured on all routers that have the discard route so that routes 186 announced with a chosen community will have their next hop set to the 187 discard address. The BGP policy should be made restrictive so that 188 only BGP routes covering a defined number of hosts addresses will be 189 accepted. That is, typically, only specific /32s are necessary. 190 Shorter prefix blocks may also be required or desirable, for example 191 if larger numbers of attack targets are located within a single 192 prefix, or the employment of this mechanism is to drop traffic bound 193 for specific networks. When filtering based on shorter prefixes, 194 extreme caution should be used as to avoid collateral damage to other 195 hosts that reside within those address blocks. Full implementations 196 will have multiple communities, with each community used for 197 different parts of a provider's network and for different security 198 incidents. 200 4. Configure the Safety Egress Prefix Filters (Murphy Prefix 201 Filters). There is always a chance that the triggering BGP Update 202 could leak from the network. This has happened [ Youtube/Pakistan 203 incident ]. Egress prefix filters are recommended. These egress 204 prefix filter details may varying, but experience has demonstrated 205 that the following works: 207 4.1 Deny all prefixes /30 through /32 from leaving your network. If 208 your triggering BGP update is only /32s, then this egress prefix 209 filter will add a safe measure in case the NO_EXPORT community does 210 not work. 212 4.2 Deny all communities used for triggering RTBH filtering. This is 213 also a "safety" measure in case the NO_EXPORT community does not 214 work. 216 5: Configure the Trigger Router. Set the trigger router, workstation, 217 or other device so that adding and removing the triggers can be done 218 easily and quickly. The BGP Update should have the NO_EXPORT 219 community as a mandatory attribute. An egress prefix filter or policy 220 which prevents RTBHing prefixes in the /8 to /24 range is also 221 recommended as a safety tool. The trigger router can be set up as a 222 iBGP route reflector client which does not receive any prefixes from 223 its BGP peer. This allows a low cost router/workstation to be used 224 as the trigger router. 226 6. When RTBH filtering is desired for a specific address, that 227 address is announced from a trigger router (or route server), tagged 228 with the chosen "RTBH" community and with the NO_EXPORT community, 229 and passed via iBGP. The receiving routers check the BGP policy, set 230 the next-hop to be the discard route, resulting in a FIB entry 231 pointing to a discard address. 233 7. Traffic entering the network will now be forwarded to the discard 234 interface on all edge routers and will therefore be dropped at the 235 edge of the network, saving resources. 237 7.1 Multiple Discard Addresses for Incident Granularity. This 238 technique can be expanded by having multiple discard addresses, 239 routes and communities to allow for monitoring of the discarded 240 traffic volume on devices that support multiple discard interfaces. 241 As mentioned earlier, each router can have a discard address schema 242 to allow the operator to distinguish multiple incidents from each 243 other - making it easier to monitor the life-cycle of the incidents. 245 7.2 Multiple "Trigger Communities" for Network Wide Granularity. The 246 network can be sectioned into multiple communities, providing the 247 operator with an ability to drop in discreete parts of their network. 248 For example, the network can be divided into the following 249 communities: 251 XXX:600 RTBH filtering on all router 252 XXX:601 RTBH filtering on only peering router 253 XXX:602 RTBH filtering on only customers who peer BGP 254 XXX:603 RTBH filtering on Datacenters (to see if the data center 255 is the 256 source of attack) 257 XXX:604 RTBH filtering on all customers (to see how many 258 customers are 259 being used by the attacker) 261 Some diligent thinking is required to develop a community schema 262 which provides flexibility while reflecting topological 263 considerations. 265 7.3 "Customer Triggered" RTBH filtering. The technique can also be 266 expanded by relaxing the AS path rule to allow customers of a service 267 provider to enable RTBH filtering without interacting with the 268 service provider's trigger routers. If this is configured, an 269 operator MUST only accept announcements for prefixes from the 270 customer that the customer is authorized to advertise, in order to 271 prevent the customer from accidentally (or intentionally) black- 272 holing space that they are not allowed to advertise. 274 A common policy for this type of setup would first permit any more 275 specific of an authorized prefix only if the blackhole communities is 276 attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and 277 then also accept from the customer the original aggregate prefix that 278 will be advertised as standard policy permits. 280 Extreme caution should be used in order to avoid leaking any more 281 specifics beyond the local routing domain, unless policy explicitly 282 aims at doing just that. 284 5. Source address RTBH filtering. 286 In many instances denial-of-service attacks sourced from botnets are 287 being configured to "follow DNS" (the attacking machines are 288 instructed to attack www.example.com, and re-resolve this 289 periodically. Historically the attacks were aimed simply at an IP 290 address and so renumbering www.example.com to a new address was an 291 effective mitigation). This makes employing technique that allows 292 black-holing to be based on source address desirable. 294 By combining traditional RTBH filtering with unicast Reverse Path 295 Forwarding (uRPF) a network operator can filter based upon the source 296 address. uRPF performs a route lookup of the source address of the 297 packet and checks to see if the ingress interface of the packet is a 298 valid egress interface for the packet source address (strict mode) or 299 if any route to the source address of the packet exists (loose mode). 300 If the check fails, the packet is typically dropped. In loose mode 301 some vendors also verify that the destination route does not point to 302 a discard interface - this allows source based RTBH filtering to be 303 deployed in networks that cannot implement strict (or feasible path) 304 mode uRPF. 306 By enabling the uRPF feature on interfaces at pre-determined points 307 in their network and announcing the source address(es) of attack 308 traffic, a network operator can effectively drop the identified 309 attack traffic at specified devices (ideally ingress edge) of their 310 network based on source address. 312 While administrators may choose to drop traffic from any prefix they 313 wish, it is recommended when employing source-based RTBH filtering 314 inter-domain that explicit policy be defined that enables peers to 315 only announce source-based RTBH routes for prefixes which they 316 originate. 318 5.1 Steps to deploy RTBH filtering with uRPF for source filtering. 320 The same steps that are required to implement destination address 321 RTBH filtering are taken with the additional step of enabling unicast 322 reverse path forwarding on predetermined interfaces. When a source 323 address (or network) needs to be blocked, that address (or network) 324 is announced using BGP tagged with a community. This will cause the 325 route to be installed with a next hop of the discard interface, 326 causing the uRPF check to fail. The destination based RTBH filtering 327 community should not be used for source based RTBH filtering, and the 328 routes tagged with the selected community should be carefully 329 filtered. 331 The BGP policy will need to be relaxed to accept announcements tagged 332 with this community to be accepted even though they contain addresses 333 not controlled by the network announcing them. These announcements 334 must NOT be propagated outside the local AS and should carry the 335 NO_EXPORT community. 337 As a matter of policy, operators SHOULD NOT accept source-based RTBH 338 announcements from their peers or customers, they should only be 339 installed by local or attack management systems within their 340 administrative domain. 342 6. Security Considerations 344 The techniques presented here provide enough power to cause 345 significant traffic forwarding loss if incorrectly deployed. It is 346 imperative that the announcements that trigger the black-holing are 347 carefully checked and that the BGP policy that accepts these 348 announcements is implemented in such a manner that the announcements: 350 - Are not propagated outside the AS (NO_EXPORT). 351 - Are not accepted from outside the AS (except from customers). 352 - Except where source based filtering is deployed, that the network 353 contained in the announcement falls within the address ranges 354 controlled by the announcing AS (i.e.: for customers that the 355 address falls within their space). 357 7. IANA Considerations 359 No action required. 361 8. Acknowledgments 363 I would like to thank Joe Abley, Rodney Dunn, Alfred Hoenes, Donald 364 Smith, Joel Jaeggli and Steve Williams for their assistance, feedback 365 and not laughing *too* much at the quality of the initial drafts. 367 I would also like to thank all of the regular contributors to the 368 OpSec Working Group and Google for 20% time :-) 370 The authors would also like to thank Steven L Johnson and Barry Greene 371 for getting this implemented and Chris Morrow for publicizing the 372 technique in multiple talks. 374 9. References 376 9.1. Normative References 378 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 379 and E. Lear, "Address Allocation for Private Internets", 380 BCP 5, RFC 1918, February 1996. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 386 2002. 388 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 389 Networks", BCP 84, RFC 3704, March 2004. 391 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 392 Attacks", RFC 3882, September 2004. 394 9.2. Informative References 396 [Greene2001] Greene Barry Raveendran and Jarvis Neil "Unicast Reverse 397 Path Forwarding (uRPF) Enhancements for the ISP-ISP Edge", 398 [ftp://ftp- 399 eng.cisco.com/cons/isp/documents/uRPF_Enhancement.pdf], 400 2001. 402 Appendix A: Cisco Router Configuration Sample 404 This section provides a partial configuration for configuring RTBH 405 filtering on a Cisco router. This is not a complete configuration and 406 should be customized before being used. 408 Announcing router: 409 ! The discard route 410 ip route 192.0.2.1 255.255.255.255 Null0 411 ! 412 ! Matches and empty AS-PATH only. 413 ip as-path access-list 10 permit ^$ 414 ! 415 ! This route-map matches routes with tag 666 and sets the next-hop 416 ! to be the discard route. 417 route-map remote-trigger-black-hole permit 10 418 match tag 666 419 set ip next-hop 192.0.2.1 420 set local-preference 200 421 set community no-export 422 ! The community used internally to tag RTBH announcements. 423 set community 65505:666 424 set origin igp 425 ! 426 route-map remote-trigger-black-hole permit 20 427 ! 428 router bgp 65505 429 no synchronization 430 bgp log-neighbor-changes 431 redistribute static route-map remote-trigger-black-hole 432 no auto-summary 433 ! 434 ! An example IP that we are applying RTBH filtering to. 435 ! All traffic destined to 10.0.0.1 will now be dropped! 436 ip route 10.0.0.1 255.255.255.255 null0 tag 666 437 ! 439 Filtering router: 440 ! 441 ! The discard route 442 ip route 192.0.2.1 255.255.255.255 Null0 443 ! 444 ! Matches and empty AS-PATH only. 445 ip as-path access-list 10 permit ^$ 446 ! 447 route-map black-hole-filter permit 10 448 match ip address prefix-list only-host-routes 449 match as-path 10 450 match community 65505:666 no-export 451 ! 452 ! Don't accept any other announcements with the RTBH community. 453 route-map black-hole-filter deny 20 454 match community 65505:666 455 ! 456 route-map black-hole-filter permit 30 457 ! 458 ! An interface for source-based RTBH filtering with uRPF loose mode. 459 interface FastEthernet 0/0 460 ip verify unicast source reachable-via any 462 Appendix B: Juniper Configuration Sample 464 This section provides a partial configuration for configuring RTBH 465 filtering on a Juniper router. This is not a complete configuration 466 and should be customized before being used. 468 Announcing router: 470 routing-options { 471 static { 472 /* EXAMPLE ATTACK SOURCE */ 473 route 10.11.12.66/32 { 474 next-hop 192.0.2.1; 475 resolve; 476 tag 666; 477 } 478 /* EXAMPLE ATTACK DESTINATION */ 479 route 10.128.0.2/32 { 480 next-hop 192.0.2.1; 481 resolve; 482 tag 666; 483 } 484 } 485 autonomous-system 100; 486 } 488 protocols { 489 bgp { 490 group ibgp { 491 type internal; 492 export rtbh; 493 neighbor 172.16.0.2; 494 } 495 } 496 } 498 policy-options { 499 policy-statement rtbh { 500 term black-hole-filter { 501 from { 502 tag 666; 503 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 504 } 505 then { 506 local-preference 200; 507 origin igp; 508 community set black-hole; 509 community add no-export; 510 next-hop 192.0.2.1; 511 accept; 512 } 513 } 514 } 515 community black-hole members 100:666; 516 community no-export members no-export; 517 } 519 Filtering router: 521 policy-statement black-hole-filter { 522 from { 523 protocol bgp; 524 as-path LocalOnly; 525 community black-hole; 526 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 527 } 528 then { 529 community set no-export; 530 next-hop 192.0.2.1; 531 } 532 } 533 community black-hole members 100:666; 534 community no-export members no-export; 536 routing-options { 537 forwarding-table { 538 unicast-reverse-path feasible-paths; 539 } 540 static { 541 route 192.0.2.1/32 discard; 542 } 543 } 545 interfaces { 546 xe-1/0/0 { 547 vlan-tagging; 548 mtu 9192; 549 unit 201 { 550 vlan-id 201; 551 family inet { 552 rpf-check; 553 address 10.11.12.1/24; 554 } 555 } 557 } 558 } 560 Appendix C: A Brief History of RTBH filtering 562 Understanding the history and motivation behind the development of a 563 technique often helps with understanding how to best utilize the 564 technique. In this spirit we present a history of Unicast RPF and 565 RTBH filtering. 567 This section provided by Barry Raveendran Greene: 569 Unicast RPF Loose Check (uRPF Loose Check) was created by Neil Jarvis 570 and Barry Greene to be used with dRTBH as a rapid reaction tool to 571 DDoS Attacks. The requirements for this rapid reaction tool was based 572 on post mortem conversation after the Feb 2000 attacks on several big 573 content hosting companies. The summary of the requirement became the 574 "Exodus Requirement" which stated: 576 "We need a tool to drop packets based on source IP address that can 577 be pushed out to over 60 routers within 60 seconds, be longer than a 578 thousand lines, be modified on the fly, and work in all your 579 platforms filtering at line rate." 581 A variety of options were looked at to meet this requirement, from 582 reviving COPS, to pushing out ACLs with BGP, creating a new protocol. 583 In 2000, the quickest way to meet the "Exodus requirement" was to 584 marry two functions. First, modify Unicast RPF so that the interface 585 check was no longer required and to make sure that a "null" or 586 discard route would drop the packet (i.e. loose check). Second, the 587 technique where BGP is used to trigger a distributed drop is dusted 588 off and documented. Combining these two techniques was deemed a fast 589 way to put a distributed capability to drop packets out into the 590 industry. 592 To clarify and restate, uRPF Loose Check was created as one part of a 593 rapid reaction tool to DDoS attacks that "drop packets based on 594 source IP address that can be pushed out to over 60 routers with in 595 60 seconds, be longer than a thousand lines, be modified on the fly, 596 and work in all your platforms filtering at line rate." The secondary 597 benefits of using uRPF Loose Check for other functions is a secondary 598 benefit - not the primary goal for its creation. 600 To facilitate the adoption to the industry, uRPF Loose Check was not 601 patented. It was publicly published and disclosed in "Unicast Reverse 602 PathForwarding (uRPF) Enhancements for the ISP-ISP Edge" 603 [Greene2001]. 605 Authors' Addresses 607 Warren Kumari 608 Google 609 1600 Amphitheatre Parkway 610 Mountain View, CA 94043 611 Email: warren@kumari.net 613 Danny McPherson 614 Arbor Networks, Inc. 615 Email: danny@arbor.net