idnits 2.17.1 draft-ietf-opsec-blackhole-urpf-04.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 == Line 204 has weird spacing: '...Shorter prefi...' == Line 206 has weird spacing: '... single prefi...' == Line 210 has weird spacing: '...ll have multi...' -- The document date (June 4, 2009) is 5434 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 (~~), 6 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: December 4, 2009 7 June 4, 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 December 4, 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 .....................................................4 57 3. Destination address RTBH filtering ..............................4 58 3.1. Overview ...................................................4 59 3.2. Detail .....................................................5 60 4. Source address RTBH filtering ...................................8 61 4.1. Steps to deploy RTBH filtering with uRPF ...................9 62 5. Security Considerations .........................................9 63 6. IANA Considerations ............................................10 64 7. Acknowledgments ................................................10 65 8. References .....................................................10 66 8.1. Normative References ......................................10 67 8.2. Informative References ....................................10 68 A. Cisco Router Configuration Sample...............................11 69 B. Juniper Configuration Sample....................................13 70 C. A Brief History of RTBH.........................................15 72 1. Introduction 74 This document expands upon the technique outlined in "Configuring BGP 75 to Block Denial-of-Service Attacks" [RFC3882] to demonstrate a method 76 that allows for filtering by source address(es). 78 Network operators have developed a variety of techniques for 79 mitigating denial of service attacks. While different techniques have 80 varying strengths and weaknesses, from an implementation perspective 81 the selection of which method to use for each type of attack involves 82 evaluating the tradeoffs associated with each method. 84 A common DoS attack directed against a customer of a service provider 85 involves generating a greater volume of attack traffic destined for 86 the target than will fit down the links from the service provider(s) 87 to the victim (customer). This traffic "starves out" legitimate 88 traffic and often results in collateral damage or negative effects to 89 other customers or the network infrastructure as well. Rather than 90 having all destinations on their network be affected by the attack, 91 the customer may ask their service provider to filter traffic 92 destined to the target destination IP address(es), or the service 93 provider may determine that this is necessary themselves, in order to 94 preserve network availability. 96 One method that the service provider can use to implement this 97 filtering is to deploy access control lists on the edge of their 98 network. While this technique provides a large amount of flexibility 99 in the filtering, it runs into scalability issues, both in terms of 100 the number of entries in the filter and the packet rate. 102 Most routers are able to forward traffic at a much higher rate than 103 they are able to filter, and are able to hold many more forwarding 104 table entries and routes than filter entries. RTBH filtering 105 leverages the forwarding performance of modern routers to filter both 106 more entries and at a higher rate than access control lists would 107 otherwise allow. 109 However, with destination-based RTBH filtering, the impact of the 110 attack on the target is complete. That is, destination-based RTBH 111 filtering injects a discard route into the forwarding table for the 112 target prefix. All packets towards that destination, attack traffic 113 AND legitimate traffic, are then dropped by the participating 114 routers,thereby taking the target completely offline. The benefit is 115 that collateral damage to other systems or network availability at 116 the customer location or in the ISP network is limited, but the 117 negative impact to the target itself is arguably increased. 119 By coupling unicast reverse path forwarding (RPF) [RFC3704] 120 techniques with RTBH filtering, BGP can be used to distribute discard 121 routes that are based not on destination or target addresses, but 122 based on source addresses of unwanted traffic. Note that this will 123 drop all traffic to / from the address, and not just the traffic to 124 the victim. 126 This document is broken up into three logical parts, the first 127 outlines how to configure destination based RTBH, the second covers 128 source based RTBH and the third part has examples and a history of 129 the technique. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119. [RFC2119]. 137 3. Destination address RTBH filtering 139 3.1. Overview 141 A "discard" route is installed on each edge router in the network 142 with the destination set to the discard (or null) interface. In order 143 to use RTBH filtering for a single IP address (or prefix), a BGP 144 route for the address to be filtered is announced, with the next-hop 145 set as the "discard" route. This causes traffic to the announced 146 network prefix to be forwarded to the discard interface so that it 147 does not transit the network wasting resources or triggering 148 collateral damage to other resources along the path towards the 149 target. 151 While this does "complete" the attack in that the target address(es) 152 are made unreachable, collateral damage is minimized. It may also be 153 possible to move the host or service on the target IP address(es) to 154 another address and keep the service up, for example by updating 155 associated DNS resource records. 157 3.2. Detail 159 Before deploying RTBH filtering, there is some preparation and 160 planning that needs to occur and decisions that need to be made. 161 These include: 163 - what are the discard addresses? 164 - what are the discard BGP communities? 165 - what is the largest prefix that can be black-holed? 166 - what is the smallest advertisement that your provider will 167 accept? 169 Steps to configure destination based RTBH filtering: 171 Step 1. Select your Discard Address schema. An address is chosen to 172 become the "discard address". This is often chosen from 192.0.2.0/24 173 (TEST-NET [RFC3330]), or from RFC 1918 [RFC1918] space. Multiple 174 addresses allow an operator to configure multiple static routes, one 175 for each incident: 177 192.0.2.1 = Incident #1 178 192.0.2.2 = Incident #2 179 192.0.2.3 = Incident #3 180 192.0.2.4 = Incident #4 181 192.0.2.5 = Incident #5 183 Customer #1 who has a DDoS attack can be pointed to discard route 184 192.0.2.1. Customer #2 can be pointed to discard route 192.0.2.2. If 185 capable, the router can then count the drops for each, providing some 186 level of telemetry on the volume of drops as well as status of an 187 ongoing attack. A consistent address schema facilitates operations. 189 Step 2. Configure the Discard Route(s) on each router, A route for 190 the "discard address" is installed on the routers that form the 191 edge/perimeter of the network, in all routers in the network, or some 192 subset (e.g., peering, but not customer, etc.). The destination of 193 the route is set to the "discard" or "null" interface. This route is 194 called the "discard route". Implementation experience demonstrates 195 the value of configuring each ingress router with a capability for 196 dropping traffic via RTBH filtering. 198 Step 3. Configure the RTBH BGP Policy on each router. A BGP policy 199 is configured on all routers that have the discard route so that 200 routes announced with a chosen community will have their next hop set 201 to the discard address. The BGP policy should be made restrictive so 202 that only BGP routes covering a defined number of hosts addresses 203 will be accepted. That is, typically, only specific /32s are 204 necessary. Shorter prefix blocks may also be required or desirable, 205 for example if larger numbers of attack targets are located within a 206 single prefix, or the employment of this mechanism is to drop 207 traffic bound for specific networks. When filtering based on shorter 208 prefixes, extreme caution should be used as to avoid collateral 209 damage to other hosts that reside within those address blocks. Full 210 implementations will have multiple communities, with each community 211 used for different parts of a provider's network and for different 212 security incidents. 214 Step 4. Configure the Safety Egress Prefix Filters. There is always 215 a chance that the triggering BGP Update could leak from the network 216 and so egress prefix filters are strongly recommended. These egress 217 prefix filter details may vary, but experience has demonstrated that 218 the following works: 220 - Deny all prefixes longer than the longest prefix that you expect 221 to 222 announce. For example, if the longest prefix that you expect to 223 announce is /24, deny all prefixes of length /25 though /32. If 224 your triggering BGP update is only /32s, then this egress prefix 225 filter will add a safe measure in case the NO_EXPORT community 226 does not work. 228 - Deny all communities used for triggering RTBH filtering. This is 229 also a "safety" measure in case the NO_EXPORT community does 230 not work. 232 Step 5: Configure the Trigger Router. Configure the trigger router, 233 workstation, or other device so that adding and removing the triggers 234 can be done easily and quickly. The BGP Update should have the 235 NO_EXPORT community as a mandatory attribute. An egress prefix filter 236 or policy which prevents RTBH filtering prefixes in the /8 to /24 237 range is also recommended as a safety tool. The trigger router can be 238 set up as a iBGP route reflector client which does not receive any 239 prefixes from its BGP peer. This allows a low cost router / 240 workstation to be used as the trigger router. 242 Using the RTBH filtering: 244 1. When RTBH filtering is desired for a specific address, that 245 address is announced from a trigger router (or route server), tagged 246 with the chosen "RTBH" community and with the NO_EXPORT community, 247 and passed via iBGP. The receiving routers check the BGP policy, set 248 the next-hop to be the discard route, resulting in a FIB entry 249 pointing to a discard address. 251 2. Traffic entering the network will now be forwarded to the discard 252 interface on all edge routers and will therefore be dropped at the 253 edge of the network, saving resources. 255 2.1 Multiple Discard Addresses for Incident Granularity. This 256 technique can be expanded by having multiple discard addresses, 257 routes and communities to allow for monitoring of the discarded 258 traffic volume on devices that support multiple discard interfaces. 259 As mentioned earlier, each router can have a discard address schema 260 to allow the operator to distinguish multiple incidents from each 261 other - making it easier to monitor the life-cycle of the incidents. 263 2.2 Multiple "Trigger Communities" for Network Wide Granularity. The 264 network can be sectioned into multiple communities, providing the 265 operator with an ability to drop in discrete parts of their network. 266 For example, the network can be divided into the following 267 communities: 269 XXX:600 RTBH filtering on all router 270 XXX:601 RTBH filtering on only peering router 271 XXX:602 RTBH filtering on only customers who peer BGP 272 XXX:603 RTBH filtering on Datacenters (to see if the data center 273 is the 274 source of attack) 275 XXX:604 RTBH filtering on all customers (to see how many 276 customers are 277 being used by the attacker) 279 Some diligent thinking is required to develop a community schema 280 which provides flexibility while reflecting topological 281 considerations. 283 2.3 "Customer Triggered" RTBH filtering. The technique can also be 284 expanded by relaxing the AS path rule to allow customers of a service 285 provider to enable RTBH filtering without interacting with the 286 service provider's trigger routers. If this is configured, an 287 operator MUST only accept announcements for prefixes from the 288 customer that the customer is authorized to advertise, in order to 289 prevent the customer from accidentally (or intentionally) black- 290 holing space that they are not allowed to advertise. 292 A common policy for this type of setup would first permit any more 293 specific of an authorized prefix only if the blackhole communities is 294 attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and 295 then also accept from the customer the original aggregate prefix that 296 will be advertised as standard policy permits. 298 Extreme caution should be used in order to avoid leaking any more 299 specifics beyond the local routing domain, unless policy explicitly 300 aims at doing just that. 302 4. Source address RTBH filtering. 304 In many instances denial-of-service attacks sourced from botnets are 305 being configured to "follow DNS" (the attacking machines are 306 instructed to attack www.example.com, and re-resolve this 307 periodically. Historically the attacks were aimed simply at an IP 308 address and so renumbering www.example.com to a new address was an 309 effective mitigation). This makes employing technique that allows 310 black-holing to be based on source address desirable. 312 By combining traditional RTBH filtering with unicast Reverse Path 313 Forwarding (uRPF) a network operator can filter based upon the source 314 address. uRPF performs a route lookup of the source address of the 315 packet and checks to see if the ingress interface of the packet is a 316 valid egress interface for the packet source address (strict mode) or 317 if any route to the source address of the packet exists (loose mode). 318 If the check fails, the packet is typically dropped. In loose mode 319 some vendors also verify that the destination route does not point to 320 an invalid next-hop - this allows source based RTBH filtering to be 321 deployed in networks that cannot implement strict (or feasible path) 322 mode uRPF. Before enabling uRPF (in any mode), it is vital that you 323 fully understand the implications of doing so: 325 - Strict mode will cause the router to drop all ingress traffic 326 if the best path back to the source address of the traffic is 327 not the interface from which the traffic was received. 328 Asymetric routing will cause strict mode uRPF to drop 329 legitimate traffic. 331 - Loose mode causes the router to check if a route for the source 332 address of the traffic exists. This may also cause legitimate 333 traffic to be discarded. 335 It is hoped that in the future, vendors will implement a "DoS- 336 mitigation" mode in addition to the Loose and Strict modes -- in this 337 mode, the uRPF check will only fail if the next-hop for the source of 338 the packet is a discard interface. 340 By enabling the uRPF feature on interfaces at pre-determined points 341 in their network and announcing the source address(es) of attack 342 traffic, a network operator can effectively drop the identified 343 attack traffic at specified devices (ideally ingress edge) of their 344 network based on source address. 346 While administrators may choose to drop traffic from any prefix they 347 wish, it is recommended when employing source-based RTBH filtering 348 inter-domain that explicit policy be defined that enables peers to 349 only announce source-based RTBH routes for prefixes which they 350 originate. 352 4.1 Steps to deploy RTBH filtering with uRPF for source filtering. 354 The same steps that are required to implement destination address 355 RTBH filtering are taken with the additional step of enabling unicast 356 reverse path forwarding on predetermined interfaces. When a source 357 address (or network) needs to be blocked, that address (or network) 358 is announced using BGP tagged with a community. This will cause the 359 route to be installed with a next hop of the discard interface, 360 causing the uRPF check to fail and the packets to be discarded. The 361 destination based RTBH filtering community should not be used for 362 source based RTBH filtering, and the routes tagged with the selected 363 community should be carefully filtered. 365 The BGP policy will need to be relaxed to accept announcements tagged 366 with this community to be accepted even though they contain addresses 367 not controlled by the network announcing them. These announcements 368 must NOT be propagated outside the local AS and should carry the 369 NO_EXPORT community. 371 As a matter of policy, operators SHOULD NOT accept source-based RTBH 372 announcements from their peers or customers, they should only be 373 installed by local or attack management systems within their 374 administrative domain. 376 5. Security Considerations 378 The techniques presented here provide enough power to cause 379 significant traffic forwarding loss if incorrectly deployed. It is 380 imperative that the announcements that trigger the black-holing are 381 carefully checked and that the BGP policy that accepts these 382 announcements is implemented in such a manner that the announcements: 384 - Are not propagated outside the AS (NO_EXPORT). 385 - Are not accepted from outside the AS (except from customers). 386 - Except where source based filtering is deployed, that the network 387 contained in the announcement falls within the address ranges 388 controlled by the announcing AS (i.e.: for customers that the 389 address falls within their space). 391 6. IANA Considerations 393 No action required. 395 7. Acknowledgments 397 I would like to thank Joe Abley, Ron Bonica, Rodney Dunn, Alfred 398 Hoenes, Donald Smith, Joel Jaeggli, and Steve Williams for their 399 assistance, feedback and not laughing *too* much at the quality of the 400 initial drafts. 402 I would also like to thank all of the regular contributors to the 403 OpSec Working Group and Google for 20% time :-) 405 The authors would also like to thank Steven L Johnson and Barry Greene 406 for getting this implemented and Chris Morrow for publicizing the 407 technique in multiple talks. 409 8. References 411 8.1. Normative References 413 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 414 and E. Lear, "Address Allocation for Private Internets", 415 BCP 5, RFC 1918, February 1996. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 421 2002. 423 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 424 Networks", BCP 84, RFC 3704, March 2004. 426 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 427 Attacks", RFC 3882, September 2004. 429 9.2. Informative References 431 [Greene2001] Greene Barry Raveendran and Jarvis Neil "Unicast Reverse 432 Path Forwarding (uRPF) Enhancements for the ISP-ISP Edge", 433 [ftp://ftp- 434 eng.cisco.com/cons/isp/documents/uRPF_Enhancement.pdf], 435 2001. 437 Appendix A: Cisco Router Configuration Sample 439 This section provides a partial configuration for configuring RTBH 440 filtering on a Cisco router. This is not a complete configuration and 441 should be customized before being used. 443 Announcing router: 444 ! The discard route 445 ip route 192.0.2.1 255.255.255.255 Null0 446 ! 447 ! Matches and empty AS-PATH only. 448 ip as-path access-list 10 permit ^$ 449 ! 450 ! This route-map matches routes with tag 666 and sets the next-hop 451 ! to be the discard route. 452 route-map remote-trigger-black-hole permit 10 453 match tag 666 454 set ip next-hop 192.0.2.1 455 set local-preference 200 456 set community no-export 457 ! The community used internally to tag RTBH announcements. 458 set community 65505:666 459 set origin igp 460 ! 461 route-map remote-trigger-black-hole permit 20 462 ! 463 router bgp 65505 464 no synchronization 465 bgp log-neighbor-changes 466 redistribute static route-map remote-trigger-black-hole 467 no auto-summary 468 ! 469 ! An example IP that we are applying RTBH filtering to. 470 ! All traffic destined to 10.0.0.1 will now be dropped! 471 ip route 10.0.0.1 255.255.255.255 null0 tag 666 472 ! 474 Filtering router: 475 ! 476 ! The discard route 477 ip route 192.0.2.1 255.255.255.255 Null0 478 ! 479 ! Matches and empty AS-PATH only. 480 ip as-path access-list 10 permit ^$ 481 ! 482 route-map black-hole-filter permit 10 483 match ip address prefix-list only-host-routes 484 match as-path 10 485 match community 65505:666 no-export 486 ! 487 ! Don't accept any other announcements with the RTBH community. 488 route-map black-hole-filter deny 20 489 match community 65505:666 490 ! 491 route-map black-hole-filter permit 30 492 ! 493 ! An interface for source-based RTBH filtering with uRPF loose mode. 494 interface FastEthernet 0/0 495 ip verify unicast source reachable-via any 497 Appendix B: Juniper Configuration Sample 499 This section provides a partial configuration for configuring RTBH 500 filtering on a Juniper router. This is not a complete configuration 501 and should be customized before being used. 503 Announcing router: 505 routing-options { 506 static { 507 /* EXAMPLE ATTACK SOURCE */ 508 route 10.11.12.66/32 { 509 next-hop 192.0.2.1; 510 resolve; 511 tag 666; 512 } 513 /* EXAMPLE ATTACK DESTINATION */ 514 route 10.128.0.2/32 { 515 next-hop 192.0.2.1; 516 resolve; 517 tag 666; 518 } 519 } 520 autonomous-system 100; 521 } 523 protocols { 524 bgp { 525 group ibgp { 526 type internal; 527 export rtbh; 528 neighbor 172.16.0.2; 529 } 530 } 531 } 533 policy-options { 534 policy-statement rtbh { 535 term black-hole-filter { 536 from { 537 tag 666; 538 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 539 } 540 then { 541 local-preference 200; 542 origin igp; 543 community set black-hole; 544 community add no-export; 545 next-hop 192.0.2.1; 546 accept; 547 } 548 } 549 } 550 community black-hole members 100:666; 551 community no-export members no-export; 552 } 554 Filtering router: 556 policy-statement black-hole-filter { 557 from { 558 protocol bgp; 559 as-path LocalOnly; 560 community black-hole; 561 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 562 } 563 then { 564 community set no-export; 565 next-hop 192.0.2.1; 566 } 567 } 568 community black-hole members 100:666; 569 community no-export members no-export; 571 routing-options { 572 forwarding-table { 573 unicast-reverse-path feasible-paths; 574 } 575 static { 576 route 192.0.2.1/32 discard; 577 } 578 } 580 interfaces { 581 xe-1/0/0 { 582 vlan-tagging; 583 mtu 9192; 584 unit 201 { 585 vlan-id 201; 586 family inet { 587 rpf-check; 588 address 10.11.12.1/24; 589 } 590 } 592 } 593 } 595 Appendix C: A Brief History of RTBH filtering 597 Understanding the history and motivation behind the development of a 598 technique often helps with understanding how to best utilize the 599 technique. In this spirit we present a history of Unicast RPF and 600 RTBH filtering. 602 This section provided by Barry Raveendran Greene: 604 Unicast RPF Loose Check (uRPF Loose Check) was created by Neil Jarvis 605 and Barry Greene to be used with dRTBH as a rapid reaction tool to 606 DDoS Attacks. The requirements for this rapid reaction tool was based 607 on post mortem conversation after the Feb 2000 attacks on several big 608 content hosting companies. The summary of the requirement became the 609 "Exodus Requirement" which stated: 611 "We need a tool to drop packets based on source IP address that can 612 be pushed out to over 60 routers within 60 seconds, be longer than a 613 thousand lines, be modified on the fly, and work in all your 614 platforms filtering at line rate." 616 A variety of options were looked at to meet this requirement, from 617 reviving COPS, to pushing out ACLs with BGP, creating a new protocol. 618 In 2000, the quickest way to meet the "Exodus requirement" was to 619 marry two functions. First, modify Unicast RPF so that the interface 620 check was no longer required and to make sure that a "null" or 621 discard route would drop the packet (i.e. loose check). Second, the 622 technique where BGP is used to trigger a distributed drop is dusted 623 off and documented. Combining these two techniques was deemed a fast 624 way to put a distributed capability to drop packets out into the 625 industry. 627 To clarify and restate, uRPF Loose Check was created as one part of a 628 rapid reaction tool to DDoS attacks that "drop packets based on 629 source IP address that can be pushed out to over 60 routers with in 630 60 seconds, be longer than a thousand lines, be modified on the fly, 631 and work in all your platforms filtering at line rate." The secondary 632 benefits of using uRPF Loose Check for other functions is a secondary 633 benefit - not the primary goal for its creation. 635 To facilitate the adoption to the industry, uRPF Loose Check was not 636 patented. It was publicly published and disclosed in "Unicast Reverse 637 PathForwarding (uRPF) Enhancements for the ISP-ISP Edge" 638 [Greene2001]. 640 Authors' Addresses 642 Warren Kumari 643 Google 644 1600 Amphitheatre Parkway 645 Mountain View, CA 94043 646 Email: warren@kumari.net 648 Danny McPherson 649 Arbor Networks, Inc. 650 Email: danny@arbor.net