idnits 2.17.1 draft-ietf-opsec-blackhole-urpf-00.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 19, 2009) is 5548 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 ---------------------------------------------------------------------------- == Unused Reference: '2223BIS' is defined on line 329, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: July 19, 2009 7 January 19, 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 July 13, 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 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 Remote Triggered Black Hole (RTBH) filtering is a popular and 50 effective technique for the mitigation of denial-of-service attacks. 51 This document expands upon destination-based RTBH filtering by 52 outlining a method to enable filtering by source address as well. It 53 also defines a standard BGP community for black hole prefixes to 54 simplify associated semantics. 56 Table of Contents 58 1. Introduction ....................................................2 59 2. Background ......................................................2 60 3. Destination address RTBH filtering ..............................3 61 3.1. Overview ...................................................3 62 3.2. Detail .....................................................3 63 4. Source address RTBH filtering ...................................4 64 5. Security Considerations .........................................6 65 6. IANA Considerations .............................................6 66 7. Acknowledgments .................................................7 67 8. References ......................................................7 68 A. Cisco Router Configuration Sample................................8 69 B. Juniper Configuration Sample....................................10 71 1. Introduction 73 This document expands upon the technique outlined in "Configuring BGP 74 to Block Denial-of-Service Attacks" [RFC3882] to present a method 75 that allows filtering by source address(es). It also defines a 76 standard BGP community to signal that Remote Triggered Black Hole 77 (RTBH) filtering should occur for a network. 79 1.2 Terminology 81 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 82 in this document are to be interpreted as described in BCP 14, RFC 83 2119 [RFC2119]. 85 2. Background 87 Network operators have developed a variety of techniques for 88 mitigating these types of attacks. While the different techniques 89 have varying strengths and weaknesses from an implementation 90 perspective, the selection of which method to use for each type of 91 attack involves evaluating tradeoffs. 93 A common DoS attack directed against a customer of a service provider 94 involves generating more attack traffic destined for the target than 95 will fit down the links from the service provider to the victim 96 (customer). This traffic "starves out" legitimate traffic and often 97 results in collateral damage or negative effects to other customers 98 or the network infrastructure as well. Rather than having all of 99 their network affected the attack, the customer may ask their service 100 provider to filter traffic destined to the target destination IP 101 address(es), or the service provider may determine that this is 102 necessary themselves, in order to preserve network availability. 104 One method that the service provider can use to implement this 105 filtering is to deploy access control lists on the edge of their 106 network. While this technique provides a large amount of flexibility 107 in the filtering, it runs into scalability issues, both in terms of 108 the number of entries in the filter and the packet rate. 110 Most routers are able to forward traffic at a much higher rate than 111 they are able to filter, and are able to hold many more forwarding 112 table entries and routes than filter entries. RTBH leverages the 113 forwarding performance of modern routers to filter both more entries 114 and at a higher rate than access control lists would allow. 116 However, with destination-based RTBH filtering, the impact is that 117 the attack is complete. That is, with destination-based RTBH 118 filtering you inject a discard route into the forwarding table for 119 the prefix in question. All packets towards that destination, attack 120 traffic AND legitimate traffic, are then dropped by the participating 121 routers, thereby taking the target completely offline. The benefit is 122 that collateral damage to other systems or network availability at 123 the customer location or in the ISP network is limited, but the 124 negative impact to the target itself is arguably increased. 126 By coupling unicast reverse path forwarding (RPF) [RFC3704] 127 techniques with RTBH, BGP can be used to distribute discard routes 128 that are based not on destination or target addresses, but based on 129 source addresses. 131 3. Destination address RTBH filtering 133 3.1. Overview 135 A "discard" route is installed on each edge router in the network 136 with the destination set to be the discard (or null) interface. In 137 order to use RTBH filtering for an IP address (or network) a BGP 138 route for the address to be filtered is announced, with the next-hop 139 set as the "discard" route. This causes traffic to the announced 140 network to be forwarded to the discard interface and so it does not 141 transit the network and waste resources or trigger collateral damage 142 or negative impact to other resources along the path towards the 143 target. 145 While this does "complete" the attack in that the attacked 146 address(es) are made unreachable, it minimizes collateral damage. It 147 may also be possible to move the host / service on the attacked IP 148 address(es) to another address and keep the service up, for example 149 by updating associated DNS resource records. 151 3.2. Detail 152 Steps to configure destination based RTBH filtering: 154 1: An address is chosen to become the "discard address". This is 155 often chosen from 192.0.2.0/24 (TEST-NET [RFC3330]), or from 156 RFC 1918 [RFC1918] space. 158 2: A route for the "discard address" is installed on the routers 159 that form the edge/perimeter of the network, in all routers 160 in the network, or some subset (e.g., peering, but not customer, 161 etc.), with the destination of the route being the "discard" or 162 "null" interface. This route is called the "discard route". 164 3: A BGP policy is configured on all routers that have the discard 165 route so that routes announced with the community 166 [ TBD1 ] will have their next hop set to the discard address. 167 The BGP policy should be made restrictive so that only BGP 168 routes covering a defined number of hosts addresses will 169 be accepted. That is, typically, only specific /32s are 170 necessary, 171 unless shorter prefix blocks are required. When filtering based 172 on 173 shorter prefixes, extreme caution should be used as to avoid 174 collateral damage to other hosts that reside within those 175 address blocks. 177 4: When RTBH filtering is desired for a specific address, that 178 address is announced from a central router (or route server), 179 tagged with the community [ TBD1 ]. The receiving routers check 180 the BGP policy, setting the next-hop to be the discard route, 181 which resolves to the discard interface. 183 5: Traffic entering the network will now be forwarded to the 184 discard interface on all edge routers and so will be dropped at 185 the edge of the network, saving resources. 187 This technique can be expanded by having multiple discard addresses, 188 routes and communities to allow for monitoring of the discarded 189 traffic volume on devices that support multiple discard interfaces. 191 The technique can also be expanded by relaxing the AS path rule to 192 allow customers of a service provider to enable RTBH filtering 193 without interacting with the service provider. If this is configured, 194 an operator MUST only accept announcements for prefixes from the 195 customer that the customer is authorized to advertise, to prevent the 196 customer accidentally (or intentionally) black-holing space that is 197 not theirs. 199 A common policy for this type of setup would be to accept from a 200 customer their authorized aggregate block and then permit any more 201 specific of the authorized prefix only if the blackhole communities 202 are equal or similar to attached, append NO_EXPORT, NO_ADVERTISE. 204 Extreme caution should be used in order to avoid leaking any more 205 specifics beyond the local routing domain, unless policy explicitly 206 aims at doing just that. 208 4. Source address RTBH filtering. 210 In many instances the denial-of-service attacks are being sourced 211 from botnets and are being configured to "follow DNS" (the attacking 212 machines are instructed to attack www.example.com, and re-resolve 213 this periodically. Historically the attacks were aimed simply at an 214 IP address and so renumbering www.example.com to a new address was an 215 effective mitigation). This makes a technique that allows black- 216 holing based upon source address desirable. 218 By combining traditional RTBH filtering with unicast Reverse Path 219 Forwarding (uRPF) a network operator can filter based upon the source 220 address. uRPF performs a route lookup of the source address of the 221 packet and checks to see if the ingress interface of the packet is a 222 valid egress interface for the packet source address (strict mode) or 223 if any route to the source address of the packet exists (loose mode). 224 If the check fails, the packet is typically dropped. In loose mode 225 some vendors also verify that the destination route does not point to 226 a discard interface - this allows source based RTBH filtering to be 227 deployed in networks that cannot implement strict (or feasible path) 228 mode uRPF. 230 By enabling the uRPF feature on interfaces at pre-determined points 231 of their network and announcing the source address(es) of attack 232 traffic, a network operator can effectively drop the attack traffic 233 at specified devices (ideally ingress edge) of their network based on 234 source addresses. 236 While administrators may choose to drop any prefixes they wish, it is 237 recommended when employing source-based RTBH inter-domain that 238 explicit policy be defined that enables peers to only announce 239 source-based RTBH routes for prefixes which they originate. 241 4.1 Steps to deploy RTBH with uRPF for source filtering. 243 The same steps that are required to implement destination address 244 RTBH filtering are taken with the additional step of enabling unicast 245 reverse path forwarding on predetermined interfaces. When a source 246 address (or network) needs to be blocked, that address (or network) 247 is announced using BGP tagged with a community. This will cause the 248 route to be installed with a next hop of the discard interface, 249 causing the uRPF check to fail. The destination based RTBH filtering 250 community ([ TBD1 ]) should not be used for source based RTBH 251 filtering, and the routes tagged with the selected community should 252 be carefully filtered. 254 The BGP policy will need to be relaxed to accept announcements tagged 255 with this community to be accepted even though they contain addresses 256 not controlled by the network announcing them. These announcements 257 must NOT be propagated outside the local AS and should carry the 258 NO_EXPORT community. 260 As a matter of policy, operators SHOULD NOT accept source-based RTBH 261 announcements from their peers or customers, they should only be 262 installed by local or attack management systems within their 263 administrative domain. 265 5. Security Considerations 267 The techniques presented here provide enough power to cause 268 significant traffic forwarding loss if incorrectly deployed. It is 269 imperative that the announcements that trigger the black-holing are 270 carefully checked and that the BGP policy that accepts these 271 announcements is implemented in such a manner that the announcements: 273 - Are not propagated outside the AS (NO_EXPORT). 274 - Are not accepted from outside the AS (except from customers). 275 - Except where source based filtering is deployed, that the network 276 contained in the announcement falls within the address ranges 277 controlled by the announcing AS (i.e.: for customers that the 278 address falls within their space). 280 6. IANA Considerations 282 This document requests registration of a regular Type, non-transitive 283 BGP Extended Communities Attribute [RFC4360] from the First Come, 284 First Served range to be named "Remote Triggered Black Hole Filter". 286 This community will provide a standard method to signal a provider 287 that RTBH filtering should occur for a destination and will eliminate 288 the need for customers to track different communities for each 289 provider. 291 7. Acknowledgments 293 I would like to thank Joe Abley, Rodnet Dunn, Alfred Hoenes, Donald 294 Smith, Joel Jaeggli and Steve Williams for their assistance, feedback 295 and not laughing *too* much at the quality of the initial drafts. 297 I would also like to thank all of the regular contributors to the 298 OpSec Working Group and Google for 20% time :-) 300 The authors would also like to thank Barry Greene for his efforts in 301 getting this implemented and Chris Morrow for publicizing the 302 technique in multiple talks. 304 8. References 306 8.1. Normative References 308 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 309 and E. Lear, "Address Allocation for Private Internets", 310 BCP 5, RFC 1918, February 1996. 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 316 2002. 318 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 319 Communities Attribute", RFC 4360, February 2006. 321 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 322 Networks", BCP 84, RFC 3704, March 2004. 324 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 325 Attacks", RFC 3882, September 2004. 327 8.2. Informative References 329 [2223BIS] Reynolds, J. and R. Braden, "Instructions to Request for 330 Comments (RFC) Authors", draft-rfc-editor- 331 rfc2223bis-08.txt, August 2004. 333 Appendix A: Cisco Router Configuration Sample 335 This section provides a partial configuration for configuring RTBH on 336 a Cisco router. This is not a complete configuration and should be 337 customized before being used. 339 Announcing router: 340 ! The discard route 341 ip route 192.0.2.1 255.255.255.255 Null0 342 ! 343 ! Matches and empty AS-PATH only. 344 ip as-path access-list 10 permit ^$ 345 ! 346 ! This route-map matches routes with tag 666 and sets the next-hop 347 ! to be the discard route. 348 route-map remote-trigger-black-hole permit 10 349 match tag 666 350 set ip next-hop 192.0.2.1 351 set local-preference 200 352 set community no-export 353 ! The community used internally to tag RTBH announcements. 354 set community 65505:666 355 set origin igp 356 ! 357 route-map remote-trigger-black-hole permit 20 358 ! 359 router bgp 65505 360 no synchronization 361 bgp log-neighbor-changes 362 redistribute static route-map remote-trigger-black-hole 363 no auto-summary 364 ! 365 ! An example IP that we are applying RTBH filtering to. 366 ! All traffic destined to 10.0.0.1 will now be dropped! 367 ip route 10.0.0.1 255.255.255.255 null0 tag 666 368 ! 370 Filtering router: 371 ! 372 ! The discard route 373 ip route 192.0.2.1 255.255.255.255 Null0 374 ! 375 ! Matches and empty AS-PATH only. 376 ip as-path access-list 10 permit ^$ 377 ! 378 route-map black-hole-filter permit 10 379 match ip address prefix-list only-host-routes 380 match as-path 10 381 match community 65505:666 no-export 382 ! 383 ! Don't accept any other announcements with the RTBH community. 384 route-map black-hole-filter deny 20 385 match community 65505:666 386 ! 387 route-map black-hole-filter permit 30 388 ! 389 ! An interface for source-based RTBH with uRPF loose mode. 390 interface FastEthernet 0/0 391 ip verify unicast source reachable-via any 393 Appendix B: Juniper Configuration Sample 395 This section provides a partial configuration for configuring RTBH on 396 a Juniper router. This is not a complete configuration and should be 397 customized for before being used. 399 Announcing router: 401 routing-options { 402 static { 403 /* EXAMPLE ATTACK SOURCE */ 404 route 10.11.12.66/32 { 405 next-hop 192.0.2.1; 406 resolve; 407 tag 666; 408 } 409 /* EXAMPLE ATTACK DESTINATION */ 410 route 10.128.0.2/32 { 411 next-hop 192.0.2.1; 412 resolve; 413 tag 666; 414 } 415 } 416 autonomous-system 100; 417 } 419 protocols { 420 bgp { 421 group ibgp { 422 type internal; 423 export rtbh; 424 neighbor 172.16.0.2; 425 } 426 } 427 } 429 policy-options { 430 policy-statement rtbh { 431 term black-hole-filter { 432 from { 433 tag 666; 434 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 435 } 436 then { 437 local-preference 200; 438 origin igp; 439 community set black-hole; 440 community add no-export; 441 next-hop 192.0.2.1; 442 accept; 443 } 444 } 445 } 446 community black-hole members 100:666; 447 community no-export members no-export; 448 } 450 Filtering router: 452 policy-statement black-hole-filter { 453 from { 454 protocol bgp; 455 as-path LocalOnly; 456 community black-hole; 457 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 458 } 459 then { 460 community set no-export; 461 next-hop 192.0.2.1; 462 } 463 } 464 community black-hole members 100:666; 465 community no-export members no-export; 467 routing-options { 468 forwarding-table { 469 unicast-reverse-path feasible-paths; 470 } 471 static { 472 route 192.0.2.1/32 discard; 473 } 474 } 476 interfaces { 477 xe-1/0/0 { 478 vlan-tagging; 479 mtu 9192; 480 unit 201 { 481 vlan-id 201; 482 family inet { 483 rpf-check; 484 address 10.11.12.1/24; 485 } 486 } 488 } 489 } 491 Authors' Addresses 493 Warren Kumari 494 Google 495 1600 Amphitheatre Parkway 496 Mountain View, CA 94043 497 Email: warren@kumari.net 499 Danny McPherson 500 Arbor Networks, Inc. 501 Email: danny@arbor.net