idnits 2.17.00 (12 Aug 2021) /tmp/idnits17328/draft-kumari-blackhole-urpf-01.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 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 513. 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 116 has weird spacing: '... in the netwo...' == Line 206 has weird spacing: '...ket and check...' == Line 233 has weird spacing: '... of the disca...' == 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 (September 27, 2008) is 4984 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: 'FLOWSPEC' is mentioned on line 85, but not defined == Missing Reference: 'REF' is mentioned on line 107, but not defined == Missing Reference: 'RFC4360' is mentioned on line 267, but not defined == Unused Reference: '2223BIS' is defined on line 305, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) ** Obsolete normative reference: RFC 1597 (ref. 'RFC1918') (Obsoleted by RFC 1918) Summary: 4 errors (**), 0 flaws (~~), 10 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: March 27, 2009 Arbor Networks 7 September 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, either manually or by using [FLOWSPEC]. While this technique 86 provides a large amount of flexibility in the filtering, it runs into 87 scalability issues, both in terms of the number of entries in the 88 filter and the packet rate. 90 Most routers are able to forward traffic at a much higher rate than 91 they are able to filter, and are able to hold many more forwarding 92 table entries and routes than filter entries. RTBH leverages the 93 forwarding performance of modern routers to filter both more entries 94 and at a higher rate than access control lists would allow. 96 However, with destination-based RTBH filtering, the impact is that 97 you effectively complete the attack. That is, with destination-based 98 RTBH filtering you inject a discard route into the forwarding table 99 for the prefix in question. All packets towards that destination, 100 attack traffic AND legitimate traffic, are then dropped by the 101 participating routers, thereby taking the target completely offline. 102 The benefit is that collateral damage to other systems or network 103 availability at the customer location or in the ISP network is 104 limited, but the negative impact to the target itself is arguably 105 increased. 107 By coupling unicast reverse path forwarding (RPF) [REF] techniques 108 with RTBH, BGP can be used to distribute discard routes that are 109 based not on destination or target addresses, but based on source 110 addresses. 112 3. Destination address RTBH filtering 114 3.1. Overview 116 A "discard" route is installed on each edge router in the network 117 with the destination set to be the discard (or null) interface. In 118 order to use RTBH filtering for an IP address (or network) a BGP 119 route for the address to be filtered is announced, with the next-hop 120 set as the "discard" route. This causes traffic to the announced 121 network to be forwarded to the discard interface and so it does not 122 transit the network and waste resources or trigger collateral damage 123 or negative impact to other resources along the path towards the 124 target 126 While this does "complete" the attack in that the attacked 127 address(es) are made unreachable, it cuts down on collateral damage. 128 It may also be possible to move the host / service on the attacked IP 129 address(es) to another address and keep the service up. 131 3.2. Detail 133 Steps to configure destination based RTBH filtering: 1: An address is 134 chosen to become the "discard address". This is often chosen from 135 192.0.2.0/24 (TEST-NET [RFC3330]), or from RFC 1918 [RFC1918] space. 137 2: A route for the "discard address" is installed on the routers that 138 form the edge/perimeter of the network, in all routers in the 139 network, or some subset (e.g., peering, but not customer, etc.), with 140 the destination of the route being the "discard" or "null" interface. 141 This route is called the "discard route". 143 3: A BGP policy is configured on all routers that have the discard 144 route so that routes announced with with the community [IANA - INSERT 145 REGISTERED COMMUNITY HERE] will have their next hop set to the 146 discard address. The BGP policy should be made restrictive so that: 147 - Only BGP routes covering a defined number of hosts addresses will 148 be accepted. That is, typically, only specific /32s are necessary, 149 unless shorter prefix blocks are required. This might occur where 150 larger numbers of attacking sources are located within a single 151 prefix, or the employment of this mechanism is to drop traffic to 152 specific networks. When filtering based on shorter prefixes, extreme 153 caution should be used as to avoid collateral damage to legitimate 154 hosts that reside within those address blocks. 156 While administrators may choose to drop any prefixes they wish, it is 157 recommended when employing source-based RTBH inter-domain that 158 explicit policy be defined that enables peers to only announce 159 source-based RTBH routes for prefixes which they originate. 161 4: When RTBH filtering is desired for a specific address, that 162 address is announced from a central router (or route server), tagged 163 with the community [IANA - INSERT REGISTERED COMMUNITY HERE]. The 164 receiving routers check the BGP policy, setting the next-hop to be 165 the discard route, which resolves to the discard interface. 167 5: Traffic entering the network will now be forwarded to the discard 168 interface on all edge routers and so will be dropped at the edge of 169 the network, saving resources. 171 This technique can be expanded by having multiple discard addresses, 172 routes and communities to allow for monitoring of the discarded 173 traffic volume on devices that support multiple discard interfaces. 175 The technique can also be expanded by relaxing the AS path rule to 176 allow customers of a service provider to enable RTBH filtering 177 without interacting with the service provider. If this is configured, 178 an operator MUST only accept announcements for prefixes from the 179 customer that the customer is authorized to advertise, to prevent the 180 customer accidentally (or intentionally) black-holing space that is 181 not theirs. 183 A common policy for this type of setup would first permit any more 184 specific of an authorized prefix only if the blackhole communities is 185 attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and 186 then also accept from the customer the original aggregate prefix that 187 will be advertised to as standard policy permits. 189 Extreme caution should be used in order to avoid leaking any more 190 specifics beyond the local routing domain, unless policy explicitly 191 aims at doing just that. 193 4. Source address RTBH filtering. 195 In many instances the denial of service attacks are being sourced 196 from botnets and are being configured to "follow DNS" (the attacking 197 machines are instructed to attack www.example.com, and re-resolve 198 this periodically. Historically the attacks were aimed simply at an 199 IP address and so renumbering www.example.com to a new address was an 200 effective mitigation). This makes a technique that allows black- 201 holing based upon source address desirable. 203 By combining traditional RTBH filtering with unicast Reverse Path 204 Forwarding (uRPF [RFC3704]) a network operator can filter based upon 205 source address. uRPF performs a route lookup of the source address of 206 the packet and checks to see if the ingress interface of the packet 207 is a valid egress interface for the packet source address (strict 208 mode) or if any route or the source address of the packet exists 209 (loose mode). If the check fails, the packet is (generally) dropped. 210 In loose mode some vendors also verify that the destination route 211 does not point to a discard interface - this allows source based RTBH 212 filtering to be deployed in networks that cannot implement strict (or 213 feasible path) mode uRPF. 215 By enabling the uRPF feature on interfaces on pre-determined points 216 of their network and announcing the source address(es) of attack 217 traffic, a network operator can effectively drop the attack traffic 218 at the edge of their network based on source addresses. 220 Note: This will block all traffic sourced from the attacking 221 addresses and may cause collateral damage that exceeds the benefit of 222 this technique. Announcing space (even within your own network) that 223 you don't control is bad form -- the decision to use this technique 224 should not be taken lightly. 226 4.1 Steps to deploy RTBH w/ uRPF for source filtering. 228 The same steps that are required to implement destination address 229 RTBH filtering are taken with the additional step of enabling unicast 230 reverse path forwarding on predetermined interfaces. When a source 231 address (or network) needs to be blocked, that address (or network) 232 is announced using BGP tagged with a community. This will cause the 233 route to be installed with a next hop of the discard interface, 234 causing the uRPF check to fail. The destination based RTBH filtering 235 community ([IANA - INSERT REGISTERED COMMUNITY HERE]) should not be 236 used for source based RTBH filtering, and the routes tagged with the 237 selected community should be carefully filtered. 239 The BGP policy will need to be relaxed to accept announcements tagged 240 with this community to be accepted even though they contain addresses 241 not controlled by the network announcing them. These announcements 242 must NOT be propagated outside the current AS and should carry the 243 no-export community. 245 As a matter of policy, operators SHOULD NOT accept source-based RTBH 246 announcements from their peers or customers, they should only be 247 installed by local or attack management systems within their 248 administrative domain. 250 5. Security Considerations 252 The techniques presented here provide enough power to cause severe 253 unhappiness. It is imperative that the announcements that trigger the 254 black-holing are carefully checked and that the BGP policy that 255 accepts these announcements is implemented in such a manner that the 256 announcements: 257 - Are not propagated outside the AS (no-export). 258 - Are not accepted from outside the AS (except from customers). 259 - Except where source based filtering is deployed, that the network 260 contained within the announcement falls with the address ranges 261 controlled by the announcing AS (i.e.: for customer that the address 262 falls within their space). 264 6. IANA Considerations 266 This document requests registration of a regular Type, non-transitive 267 BGP Extended Communities Attribute [RFC4360] from the First Come, 268 First Served range to be named "Remote Triggered Black Hole Filter". 270 This community will provide a standard method to signal a provider 271 that RTBH filtering should occur for a destination and will eliminate 272 the need for customers to track different communities for each 273 provider. 275 7. Acknowledgments 277 I would like to thank Joel Jaeggli, Joe Abley and Danny McPherson for 278 their assistance, feedback and not laughing *too* much at the quality 279 of the initial drafts. I would also like to thank all regular 280 contributors to the OpSec Working Group and Google for 20% time :-) 282 The authors are not aware of who initially developed this technique, 283 but would like to thank Chris Morrow for publicizing it. 285 8. References 287 8.1. Normative References 289 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 290 Attacks", RFC 3882, September 2004. Requirement Levels", 291 BCP 14, RFC 2119, March 1997. 293 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 294 2002. 296 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de 297 Groot, "Address Allocation for Private Internets", RFC 298 1597, March 1994. 300 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 301 Networks", BCP 84, RFC 3704, March 2004. 303 8.2. Informative References 305 [2223BIS] Reynolds, J. and R. Braden, "Instructions to Request for 306 Comments (RFC) Authors", draft-rfc-editor- 307 rfc2223bis-08.txt, August 2004. 309 Appendix A: Cisco Router Configuration Sample 311 This section provides a partial configuration for configuring RTBH on 312 a Cisco router. This is not a complete configuration and should be 313 customized before being used. 314 Announcing router: 315 ! The discard route 316 ip route 192.0.2.1 255.255.255.255 Null0 317 ! 318 ! Matches and empty AS-PATH only. 319 ip as-path access-list 10 permit ^$ 320 ! 321 ! This route-map matches routes with the tag 666 and sets the next-hop 322 ! to be the discard route. 323 route-map remote-trigger-black-hole permit 10 324 match tag 666 325 set ip next-hop 192.0.2.1 326 set local-preference 200 327 set community no-export 328 ! The community used internally to tag RTBH announcements. 329 set community 65505:666 330 set origin igp 331 ! 332 route-map remote-trigger-black-hole permit 20 333 ! 334 router bgp 65505 335 no synchronization 336 bgp log-neighbor-changes 337 redistribute static route-map remote-trigger-black-hole 338 no auto-summary 339 ! 340 ! An example IP that we are applying RTBH filtering to. 341 ! All traffic destined to 10.0.0.1 will now be dropped! 342 ip route 10.0.0.1 255.255.255.255 null0 tag 666 343 ! 345 Filtering router: 346 ! 347 ! The discard route 348 ip route 192.0.2.1 255.255.255.255 Null0 349 ! 350 ! Matches and empty AS-PATH only. 351 ip as-path access-list 10 permit ^$ 352 ! 353 route-map black-hole-filter permit 10 354 match ip address prefix-list only-host-routes 355 match as-path 10 356 match community 65505:666 no-export 357 ! 358 ! Don't accept any other announcements with the RTBH community. 359 route-map black-hole-filter deny 20 360 match community 65505:666 361 ! 362 route-map black-hole-filter permit 30 363 ! 364 ! An interface for source-based RTBH with uRPF loose mode. 365 interface FastEthernet 0/0 366 ip verify unicast source reachable-via any 368 Appendix B: Juniper Configuration Sample 370 This section provides a partial configuration for configuring RTBH on 371 a Juniper router. This is not a complete configuration and should be 372 customized for before being used. 374 Announcing router: 376 routing-options { 377 static { 378 # The discard route. 379 route 192.0.2.1/32 discard; 380 # An example route to be RTBH filtered. 381 route 10.0.0.1/32 { 382 next-hop 192.0.2.1; 383 resolve; 384 tag 666; 385 } 386 } 387 autonomous-system 65505; 388 } 389 protocols { 390 bgp { 391 import remote-trigger-black-hole; 392 local-as 65505; 393 } 394 } 395 policy-options { 396 policy-statement remote-trigger-black-hole { 397 term black-hole-filter { 398 from { 399 tag 666; 400 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 401 } 402 then { 403 local-preference 200; 404 origin igp; 405 community set black-hole; 406 community add no-export; 407 next-hop 192.0.2.1; 408 } 409 } 410 } 411 community black-hole members 65505:666; 412 community no-export members no-export; 413 } 415 Filtering router: 416 routing-options { 417 static { 418 # The discard route. 419 route 192.0.2.1/32 discard; 420 } 421 autonomous-system 65505; 422 # Enable feasible-paths mode uRPF. 423 forwarding-table { 424 unicast-reverse-path feasible-paths; 425 } 426 } 427 protocols { 428 bgp { 429 group iBGP { 430 import black-hole-filter; 431 } 432 } 433 } 434 policy-options { 435 policy-statement black-hole-filter { 436 from { 437 protocol bgp; 438 as-path LocalOnly; 439 community black-hole; 440 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 441 } 442 then { 443 community set no-export; 444 next-hop 192.0.2.1; 445 } 446 } 447 community black-hole members 65505:666; 448 community no-export members no-export; 449 as-path LocalOnly "^$"; 450 } 451 # Enable uRPF on an interface for source based uRPF. 452 interfaces { 453 so-0/0/0 { 454 unit 0 { 455 family inet { 456 rpf-check; 457 } 458 } 459 } 460 } 462 Authors' Addresses 464 Warren Kumari 465 Google 466 1600 Amphitheatre Parkway 467 Mountain View, CA 94043 468 Email: warren@kumari.net 470 Danny McPherson 471 Arbor Networks, Inc. 472 Email: danny@arbor.net 474 Full Copyright Statement 476 Copyright (C) The IETF Trust (2006). 478 This document is subject to the rights, licenses and restrictions 479 contained in BCP 78, and except as set forth therein, the authors 480 retain all their rights. 482 This document and the information contained herein are provided on an 483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 484 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 485 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 486 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 487 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 488 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 489 FOR A PARTICULAR PURPOSE. 491 Intellectual Property 493 The IETF takes no position regarding the validity or scope of any 494 Intellectual Property Rights or other rights that might be claimed 495 to pertain to the implementation or use of the technology 496 described in this document or the extent to which any license 497 under such rights might or might not be available; nor does it 498 represent that it has made any independent effort to identify any 499 such rights. Information on the procedures with respect to 500 rights in RFC documents can be found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any 503 assurances of licenses to be made available, or the result of an 504 attempt made to obtain a general license or permission for the use 505 of such proprietary rights by implementers or users of this 506 specification can be obtained from the IETF on-line IPR repository 507 at http://www.ietf.org/ipr. 509 The IETF invites any interested party to bring to its attention 510 any copyrights, patents or patent applications, or other 511 proprietary rights that may cover technology that may be required 512 to implement this standard. Please address the information to the 513 IETF at ietf-ipr@ietf.org.