idnits 2.17.00 (12 Aug 2021) /tmp/idnits17595/draft-kumari-blackhole-urpf-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 488. 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 5 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 232 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 (July 31, 2008) is 5042 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 263, but not defined == Unused Reference: '2223BIS' is defined on line 296, 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: January 31, 2008 Arbor Networks 7 July 31, 2008 8 Triggered black-hole routing with uRPF 9 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Remote triggered black hole (RTBH) routing is a popular and effective 38 technique for the mitigation of denial of service attacks. This document 39 expands upon destination-based remote triggered black hole routing by 40 outlining a method to enable filtering by source address as well. It 41 also defines a standard BGP community for black hole prefixes to 42 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) routing 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 routing, the impact is that you 97 effectively complete the attack. That is, with destination-based 98 blackhole routing you inject a discard route into the forwarding 99 table for the prefix in question. All packets towards that 100 destination, attack traffic AND legitimate traffic, are then dropped 101 by the participating routers, thereby taking the target completely 102 offline. The benefit is that collateral damage to other systems or 103 network availability at the customer location or in the ISP network 104 is 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. 213 By enabling the uRPF feature on interfaces on pre-determined points 214 of their network and announcing the source address(es) of attack 215 traffic, a network operator can effectively drop the attack traffic 216 at the edge of their network based on source addresses. 218 Note: This will block all traffic sourced from the attacking 219 addresses and may cause collateral damage that exceeds the benefit of 220 this technique. Announcing space (even within your own network) that 221 you don't control is bad form -- the decision to use this technique 222 should not be taken lightly. 224 4.1 Steps to deploy RTBH w/ uRPF for source filtering. 226 The same steps that are required to implement destination address 227 RTBH filtering are taken with the additional step of enabling unicast 228 reverse path forwarding on predetermined interfaces. When a source 229 address (or network) needs to be blocked, that address (or network) 230 is announced using BGP tagged with the community [IANA - INSERT 231 REGISTERED COMMUNITY HERE]. This will cause the route to be 232 installed with a next hop of the discard interface, causing the uRPF 233 check to fail. 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 7. Acknowledgments 268 I would like to thank Joel Jaeggli, Joe Abley and Danny McPherson for 269 their assistance, feedback and not laughing *too* much at the quality 270 of the initial drafts. I would also like to thank all regular 271 contributors to the OpSec Working Group and Google for 20% time :-) 273 The authors are not aware of who initially developed this technique, 274 but would like to thank Chris Morrow for publicizing it. 276 8. References 278 8.1. Normative References 280 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 281 Attacks", RFC 3882, September 2004. Requirement Levels", 282 BCP 14, RFC 2119, March 1997. 284 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 285 2002. 287 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de 288 Groot, "Address Allocation for Private Internets", RFC 289 1597, March 1994. 291 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 292 Networks", BCP 84, RFC 3704, March 2004. 294 8.2. Informative References 296 [2223BIS] Reynolds, J. and R. Braden, "Instructions to Request for 297 Comments (RFC) Authors", draft-rfc-editor- 298 rfc2223bis-08.txt, August 2004. 300 Appendix A: Cisco Router Configuration Sample 302 This section provides a partial configuration for configuring RTBH on 303 a Cisco router. This is not a complete configuration and should be 304 customized for before being used. 305 Announcing router: 306 ! The discard route 307 ip route 192.0.2.1 255.255.255.255 Null0 308 ! 309 ! Matches and empty AS-PATH only. 310 ip as-path access-list 10 permit ^$ 311 ! 312 ! This route-map matches routes with the tag 666 and sets the next-hop 313 ! to be the discard route. 314 route-map remote-trigger-black-hole permit 10 315 match tag 666 316 set ip next-hop 192.0.2.1 317 set local-preference 200 318 set community no-export 319 ! The community used internally to tag RTBH announcements. 320 set community 65505:666 321 set origin igp 322 ! 323 route-map remote-trigger-black-hole permit 20 324 ! 325 router bgp 65505 326 no synchronization 327 bgp log-neighbor-changes 328 redistribute static route-map remote-trigger-black-hole 329 no auto-summary 330 ! 331 ! An example IP that we are applying RTBH routing to. 332 ! All traffic destined to 10.0.0.1 will now be dropped! 333 ip route 10.0.0.1 255.255.255.255 null0 tag 666 334 ! 336 Filtering router: 337 ! 338 ! The discard route 339 ip route 192.0.2.1 255.255.255.255 Null0 340 ! 341 ! Matches and empty AS-PATH only. 342 ip as-path access-list 10 permit ^$ 343 ! 344 route-map black-hole-filter permit 10 345 match ip address prefix-list only-host-routes 346 match as-path 10 347 match community 65505:666 no-export 349 ! 350 ! Don't accept any other announcements with the RTBH community. 351 route-map black-hole-filter deny 20 352 match community 65505:666 353 ! 354 route-map black-hole-filter permit 30 355 ! 357 Appendix B: Juniper Configuration Sample 359 This section provides a partial configuration for configuring RTBH on 360 a Juniper router. This is not a complete configuration and should be 361 customized for before being used. 363 Announcing router: 365 routing-options { 366 static { 367 # The discard route. 368 route 192.0.2.1/32 discard; 369 # An example route to be RTBH filtered. 370 route 10.0.0.1/32 { 371 next-hop 192.0.2.1; 372 resolve; 373 tag 666; 374 } 375 } 376 autonomous-system 65505; 377 } 378 protocols { 379 bgp { 380 import remote-trigger-black-hole; 381 local-as 65505; 382 } 383 } 384 policy-options { 385 policy-statement remote-trigger-black-hole { 386 term black-hole-filter { 387 from { 388 tag 666; 389 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 390 } 391 then { 392 local-preference 200; 393 origin igp; 394 community set black-hole; 395 community add no-export; 396 next-hop 192.0.2.1; 397 } 398 } 399 } 400 community black-hole members 65505:666; 401 community no-export members no-export; 402 } 404 Filtering router: 405 routing-options { 406 static { 407 # The discard route. 408 route 192.0.2.1/32 discard; 409 } 410 autonomous-system 65505; 411 } 412 protocols { 413 bgp { 414 group iBGP { 415 import black-hole-filter; 416 } 417 } 418 } 419 policy-options { 420 policy-statement black-hole-filter { 421 from { 422 protocol bgp; 423 as-path LocalOnly; 424 community black-hole; 425 route-filter 0.0.0.0/0 prefix-length-range /32-/32; 426 } 427 then { 428 community set no-export; 429 next-hop 192.0.2.1; 430 } 431 } 432 community black-hole members 65505:666; 433 community no-export members no-export; 434 as-path LocalOnly "^$"; 435 } 437 Authors' Addresses 439 Warren Kumari 440 Google 441 1600 Amphitheatre Parkway 442 Mountain View, CA 94043 443 Email: warren@kumari.net 445 Danny McPherson 446 Arbor Networks, Inc. 447 Email: danny@arbor.net 449 Full Copyright Statement 451 Copyright (C) The IETF Trust (2006). 453 This document is subject to the rights, licenses and restrictions 454 contained in BCP 78, and except as set forth therein, the authors 455 retain all their rights. 457 This document and the information contained herein are provided on an 458 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 459 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 460 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 461 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 462 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 463 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 464 FOR A PARTICULAR PURPOSE. 466 Intellectual Property 468 The IETF takes no position regarding the validity or scope of any 469 Intellectual Property Rights or other rights that might be claimed 470 to pertain to the implementation or use of the technology 471 described in this document or the extent to which any license 472 under such rights might or might not be available; nor does it 473 represent that it has made any independent effort to identify any 474 such rights. Information on the procedures with respect to 475 rights in RFC documents can be found in BCP 78 and BCP 79. 477 Copies of IPR disclosures made to the IETF Secretariat and any 478 assurances of licenses to be made available, or the result of an 479 attempt made to obtain a general license or permission for the use 480 of such proprietary rights by implementers or users of this 481 specification can be obtained from the IETF on-line IPR repository 482 at http://www.ietf.org/ipr. 484 The IETF invites any interested party to bring to its attention 485 any copyrights, patents or patent applications, or other 486 proprietary rights that may cover technology that may be required 487 to implement this standard. Please address the information to the 488 IETF at ietf-ipr@ietf.org.