idnits 2.17.1 draft-turk-bgp-dos-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (December 2002) is 7796 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-2119' on line 35 == Unused Reference: '1' is defined on line 321, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft D. Turk 4 Document: draft-turk-bgp-dos-03.txt Bell Canada 5 Expires: June 2003 December 2002 7 Configuring BGP to Block Denial-of-Service Attacks 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 except that the right to 13 produce derivative works is not granted. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Conventions used in this document 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 33 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 34 this document are to be interpreted as described in [RFC-2119]. 36 Abstract 38 This document describes an operational technique that uses BGP 39 communities to remotely trigger black-holing of a particular 40 destination network to block denial-of-service attacks. Black- 41 holing can be applied on a selection of routers rather than all BGP- 42 speaking routers in the network. The document also describes a 43 sinkhole tunnel technique using BGP communities and tunnels to pull 44 traffic into a sinkhole router for analysis. 46 Configuring BGP to Block DoS Attacks December 2002 48 Table of Contents 50 1. Existing BGP-Triggered Black holing Techniques 2 51 2. Enhanced BGP-Triggered Black holing Technique 3 52 3. Sinkhole tunnels 4 53 Security Considerations 7 54 Disclaimer 7 55 References 7 56 Acknowledgments 7 57 Author's Addresses 7 59 1. Existing BGP-Triggered Black-holing Techniques 61 Current BGP-triggered black-holing techniques rely on altering the 62 BGP next hop address of a network targeted by an attack throughout 63 the iBGP network. A customized iBGP advertisement is generated from 64 a router participating in the destination/attacked AS where the next 65 hop address for the targeted network or host is modified to point to 66 an RFC 1918 (private internet) address. Most routers on the 67 Internet, especially edge routers, have static routes pointing RFC 68 1918 addresses to the null interface. Those static routes drive all 69 traffic destined to the network under attack to the null interface. 71 When an iBGP-speaking router inside the destination AS receives the 72 iBGP update, the advertised prefix will be added to the routing table 73 with a next hop of one of the networks listed in RFC 1918. The 74 router will then attempt to resolve the RFC 1918 next-hop in order to 75 qualify the route and derive a forwarding interface. This process 76 will return a valid next hop as the null interface. Assuming the 77 router is properly configured to direct RFC 1918 destined traffic to 78 a null interface, traffic destined to the attacked network gets 79 dropped making the attacked network unreachable to the attacker and 80 everyone else. 82 While this technique shields the internal infrastructure from the 83 attack, thereby protecting a large number of devices, it has the 84 undesirable side effect of rendering the targeted/attacked network 85 unreachable throughout the entire destination AS. Even if a static 86 route pointing an RFC 1918 address to a null interface is not 87 configured on all routers within the destination AS, the modified 88 next hop makes the traffic un-routable to its legitimate destination. 90 Network operators usually use the BGP-triggered black holes for a 91 short period of time. The technique causes traffic drops on all 92 ingress points of the AS for traffic destined to the attacked 93 network. By default, routers dropping traffic into a null interface 94 should send "ICMP unreachable" message to the source address 95 belonging to the origin/attacking AS. 97 Configuring BGP to Block DoS Attacks December 2002 99 Once the procedure reaches this point, one of the source addresses of 100 the attack traffic is hijacked by introducing a device with the same 101 source IP address into the BGP domain of the destination/attacked AS. 102 The device hijacking the source address collects the ICMP unreachable 103 packets. The source addresses of these ICMP unreachable packets 104 reveal which edge routers within the destination/attacked AS the 105 attack is coming from. The network operator may then opt to manually 106 stop the traffic on the routers from which attack traffic is 107 entering. 109 2. Enhanced BGP-Triggered Black-holing Technique 111 This paper describes a technique developed to instruct a selected set 112 of routers to alter the next hop address of a particular prefix by 113 use of BGP protocol. The next hop can either be a null interface or, 114 as discussed later on in this paper, a sinkhole tunnel interface. 115 This technique does not invoke an access list or rate limiting 116 statement to treat attack traffic, nor does it involve a network wide 117 change of the attacked prefix next hop address. The next hop will 118 only be changed on a selection of routers with the aid of BGP 119 communities within the destination/attacked AS. 121 To prepare the network for this technique, the network operator needs 122 to define a unique community value for each destination AS border 123 router that could potentially drive attack traffic to the victim. 124 For example, a network with a BGP autonomous system number 65001 has 125 two border routers (R1 and R2). Community value 65001:1 is assigned 126 to identify R1, community value 65001:2 is assigned to identify R2 127 and community value 65001:666 is assigned to identify both R1 and R2. 129 After the BGP community assignment, R1 and R2 must be configured with 130 the following: 132 1. Static route pointing an RFC 1918 network to a null interface. 133 2. AS-Path access list that matches local BGP prefix advertisement. 134 3. BGP community access list to match the community value assigned by 135 the network operator for the particular router (i.e. 65001:1 136 for R1). 137 4. BGP community access list to match the community value assigned by 138 the network operator for all router (i.e. 65001:666 for R1 and R2) 139 5. Under the BGP process, an iBGP import route policy should be 140 applied on received iBGP advertisements to do the following logic. 141 (Statements are in a logical AND order) 142 a. A policy statement to permit routes that match the following 143 criteria and apply the following changes. 145 Configuring BGP to Block DoS Attacks December 2002 147 i. Match for community specific to that router (i.e. 148 65001:1, for R1). 149 ii. Match AS-Path to locally generated BGP advertisements. 150 iii. Set BGP next hop to an RFC 1918 network. 151 iv. Overwrite BGP community with the well-known community 152 (no-advertise). 154 b. A policy statement to permit routes that match the following 155 criteria and apply the following changes. 156 i. Match for community that covers all routers (i.e. 157 65001:666). 158 ii. Match AS-Path to locally generated BGP advertisements. 159 iii. Set BGP next hop to an RFC 1918 network. 160 iv. Overwrite BGP community with the well-known community 161 (no-advertise). 163 After the policies have been configured on R1 and R2, the network 164 operator can, in the case of an attack, advertise the targeted 165 network that could be one or more /32 "host" routes into iBGP of the 166 destination/attacked AS. The advertisement must contain the community 167 value associated with the router(s) where the attack is arriving in 168 addition to the well-known community (no-export). Using BGP 169 communities preserves the original next hop address of the targeted 170 network on all routers where the special route policy configuration 171 is not present. iBGP will then carry the prefix advertisement to all 172 routers in the destination/attacked AS. All routers within the 173 destination AS, except the ones that match the community stamped on 174 the prefix, will be oblivious to the community value and will install 175 the network route with the legitimate next hop address. Routers that 176 match the community will also install the network route into their 177 routing table but will alter the next hop address to an RFC 1918 178 network and then to a null interface as per the route policies 179 configuration and recursive route lookup. The reason for matching 180 locally announced networks is to make sure that no eBGP peer can 181 misuse this community to drive any network to a null interface. It is 182 recommended to blackhole the targeted/attached hosts and not the 183 entire address block they belong to so that the blackhole effect has 184 the minimum impact on the attacked network. 186 This technique stops traffic from getting forwarded to the legitimate 187 destination on routers identified as transit routers for attack 188 traffic and that have route map matches for the community value 189 associated with the network advertisement. All other traffic on the 190 network will still get forwarded to the legitimate destination thus 191 minimizing the impact on the targeted network. 193 Configuring BGP to Block DoS Attacks December 2002 195 3. Sinkhole tunnels 197 Following the "Enhanced BGP-Triggered Black-holing Technique", it may 198 become a requirement to take a look at the attack traffic for further 199 analysis. This requirement adds to the complexity of the exercise. 200 Usually with broadcast interfaces, network operators install network 201 sniffers on a spanned port of a switch for analysis of traffic. 202 Another method would be to announce a network prefix that covers the 203 attack host address into iBGP, altering the next hop to a sinkhole 204 device that can log traffic for analysis. The latter technique 205 results in taking down the services offered on the targeted/attacked 206 IP addresses. Inter-AS traffic will be sucked into the sinkhole 207 along with Intra-AS traffic. Packet level analysis involves 208 redirecting traffic away from the destination host to a sniffer or a 209 router. As a result, if the traffic being examined includes 210 legitimate traffic, that legitimate traffic will never make it to the 211 destination host. This will result in denial of service for the 212 legitimate traffic. A better alternative would be to use a sinkhole 213 tunnel. A sinkhole tunnel is implemented only at the entry point to 214 the destination/attacked AS. All traffic destined to the attack 215 targeted host will be re-routed to a special path (tunnel) where a 216 sniffer will be able to analyze the traffic. After being analyzed, 217 traffic will exit the tunnel and gets routed normally to the 218 destination host. In other words, the traffic will pass through the 219 network to a sniffer without altering the next hop information of the 220 destination network. All routers within the destination/attacked AS 221 iBGP domain with have the proper next hop address. Only the entry 222 point router will have the altered next hop information. 224 To detail the procedure, a sinkhole router with an optional sniffer 225 attached to its interface is installed and configured to participate 226 in IGP and iBGP of the attacked AS. Next, a tunnel is created using 227 for instance, MPLS Traffic Engineering, from all border routers 228 attacks can potentially enter from (Inter-AS traffic) to the sinkhole 229 router. When a host or network is under attack, a customized iBGP 230 advertisement is sent to announce the attacked host(s) network 231 address with the proper next hop that insures traffic will reach 232 those hosts or networks. The customized advertisement will also have 233 a community string value that matches the set of border routers the 234 attack is entering from, as described in section 2. The new next hop 235 address configured within the route policy section of all border 236 routers should be the sinkhole IP address. This IP address belongs 237 to the /30 subnet assigned to the tunnel connecting the border router 238 to the sinkhole router. Routers other than the border router(s) 239 where the attack is entering from will install the customized 240 advertisement with the proper next hop pointing to the host(s) under 241 attack. 243 Configuring BGP to Block DoS Attacks December 2002 245 Lack of community string match on other routers in the iBGP network 246 will insure that the special route policy does not change next hop 247 address. Traffic entering from border routers that do not have 248 matches for the special community will be passed through regular 249 router interfaces to the legitimate destination. The next hop will 250 not be altered. Attack traffic is then treated at the sinkhole 251 device. It might be required to analysis the traffic and send it 252 back towards the host(s) it was originally destined to. In this 253 case, a default network route is configured to point to any interface 254 attached and configured on the iBGP network. That includes the same 255 physical interface the tunnel is built on. Traffic entering the 256 sinkhole device from the tunnel will be sent back to the network due 257 to the presence of the default route. Routing protocols will then 258 take care of properly routing the traffic to its original destination 259 (attacked network). 261 It becomes apparent that this technique can also be used for purposes 262 other than analyzing attack traffic. Legitimate traffic could also 263 be pulled out of normal routing into a tunnel and then reinserted 264 onto the backbone without altering the next hop addressing scheme 265 throughout the iBGP network. 267 MPLS Traffic Engineering with its many feature, is a good method of 268 sliding traffic to the sinkhole device. Features like QoS policies 269 can be applied on the attack traffic, thus preventing it from 270 competing with legitimate traffic. 272 To be able to alter the next hop on the border router, a subnet of an 273 RFC 1918 network is statically routed to the tunnel interface. An 274 example of the static route is: 276 ip route 192.168.0.12 255.255.255.255 Tunnel0 278 Setting the next hop of the target IP address to 192.168.0.12/32 will 279 force the traffic to go through the tunnel. 281 Traffic is received at the sinkhole interface via the TE tunnel. 282 Subsequently, three methods could be installed, namely rate-limiting 283 policies, QoS policies and access lists. These policies could rate 284 limit or drop traffic classified as attack traffic. This process 285 would be done on the interface of the sinkhole device. Another 286 useful application for a sinkhole router is to pull in traffic via 287 tunnels to an inbound interface and have a default route statement 288 forwarding the traffic out to an Ethernet interface. The Ethernet 289 interface is connected to the iBGP network and guarantees proper 290 delivery of traffic but allows the use of a packet sniffer to further 291 analyze the attack traffic. 293 Configuring BGP to Block DoS Attacks December 2002 295 This becomes very useful when it is not feasible to apply an Access 296 list or a rate limiting statement on the BGP border router or last 297 hop router before the attacked host or network because of hardware or 298 software limitations. Hence, instead of upgrading interfaces at the 299 point of entry of attack traffic, the latter could be pulled into the 300 sinkhole and treated on that device. Operational costs can be 301 rendered minimal if the sinkhole router is a powerful device. 303 Security Considerations 305 It is very important to practice tight control over eBGP peering 306 points before implementing the techniques described in this paper. 307 eBGP customers might be able to blackhole a particular subnet using 308 the Blackhole communities. To eliminate the risk, the match for 309 locally generated BGP advertisements in the special route policy 310 should not be neglected. 312 Disclaimer 314 The views and specification here are those of the authors and are not 315 necessarily those of their employers. The authors and their employers 316 specifically disclaim responsibility for any problems arising from 317 correct or incorrect implementation or use of this specification. 319 References 321 [1] B. Greene "ISP Security Essentials - Best Practice Cisco IOS and 322 other Techniques to Help an ISP Survive in today's Internet, 323 version 2.0", May, 2001 325 Acknowledgments 327 The author of this document would like to acknowledge the developers 328 of the remotely triggered black-holing technique and the developers 329 of the backscatter technique for collecting backscatter traffic. The 330 author would also like to thank all members of the IP Engineering 331 department for their help in verifying the functionality of this 332 technique. 334 Author's Addresses 336 Doughan Turk 337 Bell Canada 338 100 Wynford Drive 339 Email: doughan.turk@bell.ca