idnits 2.17.1 draft-kumari-blackhole-urpf-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 510. 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 9 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == 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 Copyright Line does not match the current year == Line 115 has weird spacing: '... in the netwo...' == Line 203 has weird spacing: '...ket and check...' == Line 229 has weird spacing: '... of the disca...' == Line 275 has weird spacing: '...quality of th...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5660 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 ---------------------------------------------------------------------------- == Missing Reference: 'RFC4360' is mentioned on line 263, but not defined == Unused Reference: '2223BIS' is defined on line 302, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1597 (ref. 'RFC1918') (Obsoleted by RFC 1918) ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft W. Kumari 3 Google 4 Category: Informational D. McPherson 5 Expires: April 27, 2009 Arbor Networks 7 October 27, 2008 9 Remote Triggered Black Hole filtering with uRPF 10 12 Status of this Memo 14 Distribution of this memo is unlimited. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Remote Triggered Black Hole (RTBH) filtering is a popular and effective 39 technique for the mitigation of denial of service attacks. This document 40 expands upon destination-based RTBH filtering by outlining a method to 41 enable filtering by source address as well. It also defines a standard 42 BGP community for black hole prefixes to simplify associated semantics. 44 Table of Contents 46 1. Introduction ....................................................2 47 2. Background ......................................................2 48 3. Destination address RTBH filtering ..............................3 49 3.1. Overview ...................................................3 50 3.2. Detail .....................................................3 51 4. Source address RTBH filtering ...................................4 52 5. Security Considerations .........................................6 53 6. IANA Considerations .............................................6 54 7. Acknowledgments .................................................7 55 8. References ......................................................7 56 A. Cisco Router Configuration Sample................................8 57 B. Juniper Configuration Sample....................................10 59 1. Introduction 61 This document expands upon the technique outlined in "Configuring BGP 62 to Block Denial-of-Service Attacks" [RFC3882] and presents a method 63 to allow filtering by source address. It also defines a standard BGP 64 community to signal that Remote Triggered Black Hole (RTBH) filtering 65 should occur for a network. 67 2. Background 69 Denial of Service (DoS) attacks that starve out legitimate traffic by 70 saturating circuits are becoming an increasingly common occurrence. 71 Network operators have developed a selection of techniques for 72 mitigating these attacks. Different techniques have different 73 strengths and weaknesses -- the selection of which technique to use 74 for each type of attack involves tradeoffs. 76 A common attack directed against a customer of a service provider 77 involves generating more traffic at the customer than will fit down 78 the links from the service provider to the customer. This traffic 79 "starves out" legitimate traffic. Rather than having all of their 80 network affected the customer may ask their service provider to 81 filter traffic destined to the attacked IP address(es). 83 One method that the service provider can use to implement this 84 filtering is to deploy access control lists on the edge of their 85 network. While this technique provides a large amount of flexibility 86 in the filtering, it runs into scalability issues, both in terms of 87 the number of entries in the filter and the packet rate. 89 Most routers are able to forward traffic at a much higher rate than 90 they are able to filter, and are able to hold many more forwarding 91 table entries and routes than filter entries. RTBH leverages the 92 forwarding performance of modern routers to filter both more entries 93 and at a higher rate than access control lists would allow. 95 However, with destination-based RTBH filtering, the impact is that 96 you effectively complete the attack. That is, with destination-based 97 RTBH filtering you inject a discard route into the forwarding table 98 for the prefix in question. All packets towards that destination, 99 attack traffic AND legitimate traffic, are then dropped by the 100 participating routers, thereby taking the target completely offline. 101 The benefit is that collateral damage to other systems or network 102 availability at the customer location or in the ISP network is 103 limited, but the negative impact to the target itself is arguably 104 increased. 106 By coupling unicast reverse path forwarding (RPF) [RFC3704] 107 techniques with RTBH, BGP can be used to distribute discard routes 108 that are based not on destination or target addresses, but based on 109 source addresses. 111 3. Destination address RTBH filtering 113 3.1. Overview 115 A "discard" route is installed on each edge router in the network 116 with the destination set to be the discard (or null) interface. In 117 order to use RTBH filtering for an IP address (or network) a BGP 118 route for the address to be filtered is announced, with the next-hop 119 set as the "discard" route. This causes traffic to the announced 120 network to be forwarded to the discard interface and so it does not 121 transit the network and waste resources or trigger collateral damage 122 or negative impact to other resources along the path towards the 123 target. 125 While this does "complete" the attack in that the attacked 126 address(es) are made unreachable, it cuts down on collateral damage. 127 It may also be possible to move the host / service on the attacked IP 128 address(es) to another address and keep the service up. 130 3.2. Detail 132 Steps to configure destination based RTBH filtering: 134 1: An address is chosen to become the "discard address". This is 135 often chosen from 192.0.2.0/24 (TEST-NET [RFC3330]), or from 136 RFC 1918 [RFC1918] space. 138 2: A route for the "discard address" is installed on the routers 139 that form the edge/perimeter of the network, in all routers 140 in the network, or some subset (e.g., peering, but not customer, 141 etc.), with the destination of the route being the "discard" or 142 "null" interface. This route is called the "discard route". 144 3: A BGP policy is configured on all routers that have the discard 145 route so that routes announced with the community 146 [ TBD1 ] will have their next hop set to the discard address. 147 The BGP policy should be made restrictive so that only BGP 148 routes covering a defined number of hosts addresses will 149 be accepted. 150 That is, typically, only specific /32s are necessary, unless 151 shorter prefix blocks are required. This might occur where 152 larger numbers of attacking sources are located within a 153 single prefix, or the employment of this mechanism is to drop 154 traffic to specific networks. When filtering based on shorter 155 prefixes, extreme caution should be used as to avoid collateral 156 damage to other hosts that reside within those address blocks. 158 4: When RTBH filtering is desired for a specific address, that 159 address is announced from a central router (or route server), 160 tagged with the community [ TBD1 ]. The receiving routers check 161 the BGP policy, setting the next-hop to be the discard route, 162 which resolves to the discard interface. 164 5: Traffic entering the network will now be forwarded to the 165 discard interface on all edge routers and so will be dropped at 166 the edge of the network, saving resources. 168 This technique can be expanded by having multiple discard addresses, 169 routes and communities to allow for monitoring of the discarded 170 traffic volume on devices that support multiple discard interfaces. 172 The technique can also be expanded by relaxing the AS path rule to 173 allow customers of a service provider to enable RTBH filtering 174 without interacting with the service provider. If this is configured, 175 an operator MUST only accept announcements for prefixes from the 176 customer that the customer is authorized to advertise, to prevent the 177 customer accidentally (or intentionally) black-holing space that is 178 not theirs. 180 A common policy for this type of setup would first permit any more 181 specific of an authorized prefix only if the blackhole communities is 182 attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and 183 then also accept from the customer the original aggregate prefix that 184 will be advertised to as standard policy permits. 186 Extreme caution should be used in order to avoid leaking any more 187 specifics beyond the local routing domain, unless policy explicitly 188 aims at doing just that. 190 4. Source address RTBH filtering. 192 In many instances the denial of service attacks are being sourced 193 from botnets and are being configured to "follow DNS" (the attacking 194 machines are instructed to attack www.example.com, and re-resolve 195 this periodically. Historically the attacks were aimed simply at an 196 IP address and so renumbering www.example.com to a new address was an 197 effective mitigation). This makes a technique that allows black- 198 holing based upon source address desirable. 200 By combining traditional RTBH filtering with unicast Reverse Path 201 Forwarding (uRPF) a network operator can filter based upon the source 202 address. uRPF performs a route lookup of the source address of the 203 packet and checks to see if the ingress interface of the packet is a 204 valid egress interface for the packet source address (strict mode) or 205 if any route or the source address of the packet exists (loose mode). 206 If the check fails, the packet is (generally) dropped. In loose mode 207 some vendors also verify that the destination route does not point to 208 a discard interface - this allows source based RTBH filtering to be 209 deployed in networks that cannot implement strict (or feasible path) 210 mode uRPF. 212 By enabling the uRPF feature on interfaces on pre-determined points 213 of their network and announcing the source address(es) of attack 214 traffic, a network operator can effectively drop the attack traffic 215 at the edge of their network based on source addresses. 217 While administrators may choose to drop any prefixes they wish, it is 218 recommended when employing source-based RTBH inter-domain that 219 explicit policy be defined that enables peers to only announce 220 source-based RTBH routes for prefixes which they originate. 222 4.1 Steps to deploy RTBH w/ uRPF for source filtering. 224 The same steps that are required to implement destination address 225 RTBH filtering are taken with the additional step of enabling unicast 226 reverse path forwarding on predetermined interfaces. When a source 227 address (or network) needs to be blocked, that address (or network) 228 is announced using BGP tagged with a community. This will cause the 229 route to be installed with a next hop of the discard interface, 230 causing the uRPF check to fail. The destination based RTBH filtering 231 community ([ TBD1 ]) should not be used for source based RTBH 232 filtering, and the routes tagged with the selected community should 233 be carefully filtered. 235 The BGP policy will need to be relaxed to accept announcements tagged 236 with this community to be accepted even though they contain addresses 237 not controlled by the network announcing them. These announcements 238 must NOT be propagated outside the current AS and should carry the 239 no-export community. 241 As a matter of policy, operators SHOULD NOT accept source-based RTBH 242 announcements from their peers or customers, they should only be 243 installed by local or attack management systems within their 244 administrative domain. 246 5. Security Considerations 248 The techniques presented here provide enough power to cause severe 249 unhappiness. It is imperative that the announcements that trigger the 250 black-holing are carefully checked and that the BGP policy that 251 accepts these announcements is implemented in such a manner that the 252 announcements: 253 - Are not propagated outside the AS (no-export). 254 - Are not accepted from outside the AS (except from customers). 255 - Except where source based filtering is deployed, that the network 256 contained within the announcement falls with the address ranges 257 controlled by the announcing AS (i.e.: for customer that the address 258 falls within their space). 260 6. IANA Considerations 262 This document requests registration of a regular Type, non-transitive 263 BGP Extended Communities Attribute [RFC4360] from the First Come, 264 First Served range to be named "Remote Triggered Black Hole Filter". 266 This community will provide a standard method to signal a provider 267 that RTBH filtering should occur for a destination and will eliminate 268 the need for customers to track different communities for each 269 provider. 271 7. Acknowledgments 273 I would like to thank Alfred Hoenes, Danny McPherson, Donald Smith, 274 Joe Abley and Joel Jaeggli for their assistance, feedback and not 275 laughing *too* much at the quality of the initial drafts. I would 276 also like to thank all of the regular contributors to the OpSec 277 Working Group and Google for 20% time :-) 279 The authors are not aware of who initially developed this technique, 280 but would like to thank Chris Morrow for publicizing it. 282 8. References 284 8.1. Normative References 286 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de 287 Groot, "Address Allocation for Private Internets", RFC 288 1597, March 1994. 290 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 291 2002. 293 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 294 Networks", BCP 84, RFC 3704, March 2004. 296 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 297 Attacks", RFC 3882, September 2004. Requirement Levels", 298 BCP 14, RFC 2119, March 1997. 300 8.2. Informative References 302 [2223BIS] Reynolds, J. and R. Braden, "Instructions to Request for 303 Comments (RFC) Authors", draft-rfc-editor- 304 rfc2223bis-08.txt, August 2004. 306 Appendix A: Cisco Router Configuration Sample 308 This section provides a partial configuration for configuring RTBH on 309 a Cisco router. This is not a complete configuration and should be 310 customized before being used. 311 Announcing router: 312 ! The discard route 313 ip route 192.0.2.1 255.255.255.255 Null0 314 ! 315 ! Matches and empty AS-PATH only. 316 ip as-path access-list 10 permit ^$ 317 ! 318 ! This route-map matches routes with the tag 666 and sets the next-hop 319 ! to be the discard route. 320 route-map remote-trigger-black-hole permit 10 321 match tag 666 322 set ip next-hop 192.0.2.1 323 set local-preference 200 324 set community no-export 325 ! The community used internally to tag RTBH announcements. 326 set community 65505:666 327 set origin igp 328 ! 329 route-map remote-trigger-black-hole permit 20 330 ! 331 router bgp 65505 332 no synchronization 333 bgp log-neighbor-changes 334 redistribute static route-map remote-trigger-black-hole 335 no auto-summary 336 ! 337 ! An example IP that we are applying RTBH filtering to. 338 ! All traffic destined to 10.0.0.1 will now be dropped! 339 ip route 10.0.0.1 255.255.255.255 null0 tag 666 340 ! 342 Filtering router: 343 ! 344 ! The discard route 345 ip route 192.0.2.1 255.255.255.255 Null0 346 ! 347 ! Matches and empty AS-PATH only. 348 ip as-path access-list 10 permit ^$ 349 ! 350 route-map black-hole-filter permit 10 351 match ip address prefix-list only-host-routes 352 match as-path 10 353 match community 65505:666 no-export 354 ! 355 ! Don't accept any other announcements with the RTBH community. 356 route-map black-hole-filter deny 20 357 match community 65505:666 358 ! 359 route-map black-hole-filter permit 30 360 ! 361 ! An interface for source-based RTBH with uRPF loose mode. 362 interface FastEthernet 0/0 363 ip verify unicast source reachable-via any 365 Appendix B: Juniper Configuration Sample 367 This section provides a partial configuration for configuring RTBH on 368 a Juniper router. This is not a complete configuration and should be 369 customized for before being used. 371 Announcing router: 373 routing-options { 374 static { 375 # The discard route. 376 route 192.0.2.1/32 discard; 377 # An example route to be RTBH filtered. 378 route 10.0.0.1/32 { 379 next-hop 192.0.2.1; 380 resolve; 381 tag 666; 382 } 383 } 384 autonomous-system 65505; 385 } 386 protocols { 387 bgp { 388 import remote-trigger-black-hole; 389 local-as 65505; 390 } 391 } 392 policy-options { 393 policy-statement remote-trigger-black-hole { 394 term black-hole-filter { 395 from { 396 tag 666; 397 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 398 } 399 then { 400 local-preference 200; 401 origin igp; 402 community set black-hole; 403 community add no-export; 404 next-hop 192.0.2.1; 405 } 406 } 407 } 408 community black-hole members 65505:666; 409 community no-export members no-export; 410 } 412 Filtering router: 413 routing-options { 414 static { 415 # The discard route. 416 route 192.0.2.1/32 discard; 417 } 418 autonomous-system 65505; 419 # Enable feasible-paths mode uRPF. 420 forwarding-table { 421 unicast-reverse-path feasible-paths; 422 } 423 } 424 protocols { 425 bgp { 426 group iBGP { 427 import black-hole-filter; 428 } 429 } 430 } 431 policy-options { 432 policy-statement black-hole-filter { 433 from { 434 protocol bgp; 435 as-path LocalOnly; 436 community black-hole; 437 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 438 } 439 then { 440 community set no-export; 441 next-hop 192.0.2.1; 442 } 443 } 444 community black-hole members 65505:666; 445 community no-export members no-export; 446 as-path LocalOnly "^$"; 447 } 448 # Enable uRPF on an interface for source based uRPF. 449 interfaces { 450 so-0/0/0 { 451 unit 0 { 452 family inet { 453 rpf-check; 454 } 455 } 456 } 457 } 459 Authors' Addresses 461 Warren Kumari 462 Google 463 1600 Amphitheatre Parkway 464 Mountain View, CA 94043 465 Email: warren@kumari.net 467 Danny McPherson 468 Arbor Networks, Inc. 469 Email: danny@arbor.net 471 Full Copyright Statement 473 Copyright (C) The IETF Trust (2006). 475 This document is subject to the rights, licenses and restrictions 476 contained in BCP 78, and except as set forth therein, the authors 477 retain all their rights. 479 This document and the information contained herein are provided on an 480 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 481 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 482 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 483 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 484 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 485 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 486 FOR A PARTICULAR PURPOSE. 488 Intellectual Property 490 The IETF takes no position regarding the validity or scope of any 491 Intellectual Property Rights or other rights that might be claimed 492 to pertain to the implementation or use of the technology 493 described in this document or the extent to which any license 494 under such rights might or might not be available; nor does it 495 represent that it has made any independent effort to identify any 496 such rights. Information on the procedures with respect to 497 rights in RFC documents can be found in BCP 78 and BCP 79. 499 Copies of IPR disclosures made to the IETF Secretariat and any 500 assurances of licenses to be made available, or the result of an 501 attempt made to obtain a general license or permission for the use 502 of such proprietary rights by implementers or users of this 503 specification can be obtained from the IETF on-line IPR repository 504 at http://www.ietf.org/ipr. 506 The IETF invites any interested party to bring to its attention 507 any copyrights, patents or patent applications, or other 508 proprietary rights that may cover technology that may be required 509 to implement this standard. Please address the information to the 510 IETF at ietf-ipr@ietf.org.