idnits 2.17.1 draft-turk-bgp-dos-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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.) ** There are 5 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 2004) is 7339 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Turk 2 Internet Draft Bell Canada 3 Document: draft-turk-bgp-dos-05.txt March 2004 4 Expires: September 2004 6 Configuring BGP to Block Denial-of-Service Attacks 8 Status of this Memo 10 Internet-Drafts are working documents of the Internet Engineering 11 Task Force (IETF), its areas, and its working groups. Note that 12 other groups may also distribute working documents as Internet- 13 Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Abstract 27 This document describes an operational technique that uses BGP 28 communities to remotely trigger black-holing of a particular 29 destination network to block denial-of-service attacks. Black- 30 holing can be applied on a selection of routers rather than all BGP- 31 speaking routers in the network. The document also describes a 32 sinkhole tunnel technique using BGP communities and tunnels to pull 33 traffic into a sinkhole router for analysis. 35 Table of Contents 37 1. Existing BGP-Triggered Black holing Techniques 2 38 2. Enhanced BGP-Triggered Black holing Technique 3 39 3. Sinkhole tunnels 4 40 Security Considerations 7 41 Disclaimer 7 42 References 7 43 Acknowledgments 7 44 Author's Addresses 7 46 1. Existing BGP-Triggered Black-holing Techniques 48 Current BGP-triggered black-holing techniques rely on altering the 49 BGP next hop address of a network targeted by an attack throughout 50 the iBGP network. A customized iBGP advertisement is generated from 51 a router participating in the destination/attacked AS where the next 52 hop address for the targeted network or host is modified to point to 53 an RFC 1918 (private internet) address. Most routers on the 54 Internet, especially edge routers, have static routes pointing RFC 55 1918 addresses to the null interface. Those static routes drive all 56 traffic destined to the network under attack to the null interface. 58 When an iBGP-speaking router inside the destination AS receives the 59 iBGP update, the advertised prefix will be added to the routing table 60 with a next hop of one of the networks listed in RFC 1918. The 61 router will then attempt to resolve the RFC 1918 next-hop in order to 62 qualify the route and derive a forwarding interface. This process 63 will return a valid next hop as the null interface. Assuming the 64 router is properly configured to direct RFC 1918 destined traffic to 65 a null interface, traffic destined to the attacked network gets 66 dropped making the attacked network unreachable to the attacker and 67 everyone else. 69 While this technique shields the internal infrastructure from the 70 attack, thereby protecting a large number of devices, it has the 71 undesirable side effect of rendering the targeted/attacked network 72 unreachable throughout the entire destination AS. Even if a static 73 route pointing an RFC 1918 address to a null interface is not 74 configured on all routers within the destination AS, the modified 75 next hop makes the traffic un-routable to its legitimate destination. 77 Network operators usually use the BGP-triggered black holes for a 78 short period of time. The technique causes traffic drops on all 79 ingress points of the AS for traffic destined to the attacked 80 network. By default, routers dropping traffic into a null interface 81 should send "ICMP unreachable" message to the source address 82 belonging to the origin/attacking AS. 84 Once the procedure reaches this point, one of the source addresses of 85 the attack traffic is hijacked by introducing a device with the same 86 source IP address into the BGP domain of the destination/attacked AS. 87 The device hijacking the source address collects the ICMP unreachable 88 packets. The source addresses of these ICMP unreachable packets 89 reveal which edge routers within the destination/attacked AS the 90 attack is coming from. The network operator may then opt to manually 91 stop the traffic on the routers from which attack traffic is 92 entering. 94 2. Enhanced BGP-Triggered Black-holing Technique 96 This paper describes a technique developed to instruct a selected set 97 of routers to alter the next hop address of a particular prefix by 98 use of BGP protocol. The next hop can either be a null interface or, 99 as discussed later on in this paper, a sinkhole tunnel interface. 100 This technique does not invoke an access list or rate limiting 101 statement to treat attack traffic, nor does it involve a network wide 102 change of the attacked prefix next hop address. The next hop will 103 only be changed on a selection of routers with the aid of BGP 104 communities within the destination/attacked AS. 106 To prepare the network for this technique, the network operator needs 107 to define a unique community value for each destination AS border 108 router that could potentially drive attack traffic to the victim. 109 For example, a network with a BGP autonomous system number 65001 has 110 two border routers (R1 and R2). Community value 65001:1 is assigned 111 to identify R1, community value 65001:2 is assigned to identify R2 112 and community value 65001:666 is assigned to identify both R1 and R2. 114 After the BGP community assignment, R1 and R2 must be configured with 115 the following: 117 1. Static route pointing an RFC 1918 network to a null interface. 118 2. AS-Path access list that matches local BGP prefix advertisement. 119 3. BGP community access list to match the community value assigned by 120 the network operator for the particular router (i.e. 65001:1 for R1). 121 4. BGP community access list to match the community value assigned by 122 the network operator for all router (i.e. 65001:666 for R1 and R2) 123 5. Under the BGP process, an iBGP import route policy should be 124 applied on received iBGP advertisements to do the following logic. 125 (Statements are in a logical AND order) 126 a. A policy statement to permit routes that match the following 127 criteria and apply the following changes. 129 i. Match for community specific to that router (i.e. 65001:1, for R1). 130 ii. Match AS-Path to locally generated BGP advertisements. 131 iii. Set BGP next hop to an RFC 1918 network. 132 iv. Overwrite BGP community with the well-known community (no- 133 advertise). 135 b. A policy statement to permit routes that match the following 136 criteria and apply the following changes. 137 i. Match for community that covers all routers (i.e. 65001:666). 138 ii. Match AS-Path to locally generated BGP advertisements. 139 iii. Set BGP next hop to an RFC 1918 network. 140 iv. Overwrite BGP community with the well-known community (no- 141 advertise). 143 After the policies have been configured on R1 and R2, the network 144 operator can, in the case of an attack, advertise the targeted 145 network that could be one or more /32 "host" routes into iBGP of the 146 destination/attacked AS. The advertisement must contain the community 147 value associated with the router(s) where the attack is arriving in 148 addition to the well-known community (no-export). Using BGP 149 communities preserves the original next hop address of the targeted 150 network on all routers where the special route policy configuration 151 is not present. iBGP will then carry the prefix advertisement to all 152 routers in the destination/attacked AS. All routers within the 153 destination AS, except the ones that match the community stamped on 154 the prefix, will be oblivious to the community value and will install 155 the network route with the legitimate next hop address. Routers that 156 match the community will also install the network route into their 157 routing table but will alter the next hop address to an RFC 1918 158 network and then to a null interface as per the route policies 159 configuration and recursive route lookup. The reason for matching 160 locally announced networks is to make sure that no eBGP peer can 161 misuse this community to drive any network to a null interface. It is 162 recommended to blackhole the targeted/attached hosts and not the 163 entire address block they belong to so that the blackhole effect has 164 the minimum impact on the attacked network. 166 This technique stops traffic from getting forwarded to the legitimate 167 destination on routers identified as transit routers for attack 168 traffic and that have route map matches for the community value 169 associated with the network advertisement. All other traffic on the 170 network will still get forwarded to the legitimate destination thus 171 minimizing the impact on the targeted network. 173 3. Sinkhole tunnels 175 Following the "Enhanced BGP-Triggered Black-holing Technique", it may 176 become a requirement to take a look at the attack traffic for further 177 analysis. This requirement adds to the complexity of the exercise. 178 Usually with broadcast interfaces, network operators install network 179 sniffers on a spanned port of a switch for analysis of traffic. 180 Another method would be to announce a network prefix that covers the 181 attack host address into iBGP, altering the next hop to a sinkhole 182 device that can log traffic for analysis. The latter technique 183 results in taking down the services offered on the targeted/attacked 184 IP addresses. Inter-AS traffic will be sucked into the sinkhole 185 along with Intra-AS traffic. Packet level analysis involves 186 redirecting traffic away from the destination host to a sniffer or a 187 router. As a result, if the traffic being examined includes 188 legitimate traffic, that legitimate traffic will never make it to the 189 destination host. This will result in denial of service for the 190 legitimate traffic. 192 A better alternative would be to use a sinkhole tunnel. A sinkhole 193 tunnel is implemented at all possible entry points from which attacks 194 can pass into the destination/attacked AS. Using the BGP community 195 technique, traffic destined to the attacked/targeted host could be re- 196 routed to a special path (tunnel) where a sniffer could capture the 197 traffic for analysis. After being analyzed, traffic will exit the 198 tunnel and be routed normally to the destination host. In other 199 words, the traffic will pass through the network to a sniffer without 200 altering the next hop information of the destination network. All 201 routers within the destination/attacked AS iBGP domain wi have the 202 proper next hop address. Only the entry point router will have the 203 altered next hop information. 205 To detail the procedure, a sinkhole router with an optional sniffer 206 attached to its interface is installed and configured to participate 207 in IGP and iBGP of the attacked AS. Next, a tunnel is created using 208 for instance, MPLS Traffic Engineering, from all border routers 209 attacks can potentially enter from (Inter-AS traffic) to the sinkhole 210 router. When a host or network is under attack, a customized iBGP 211 advertisement is sent to announce the network address of the attacked 212 host(s) with the proper next hop that insures traffic will reach 213 those hosts or networks. The customized advertisement will also have 214 a community string value that matches the set of border routers the 215 attack is entering from, as described in section 2. The new next hop 216 address configured within the route policy section of all border 217 routers should be the sinkhole IP address. This IP address belongs 218 to the /30 subnet assigned to the tunnel connecting the border router 219 to the sinkhole router. 221 Routers that do not have a match for the community string will do 222 regular routing. Lack of community string match on these routers will 223 insure that the special route policy does not change next hop 224 address. Traffic entering from border routers that do not have 225 matches for the special community will pass through regular router 226 interfaces to the legitimate destination. It might also be required 227 to allow the traffic to reach its destination after being captured. 228 In this case, a default network route is configured to point to any 229 interface attached and configured on the iBGP network. This would 230 also include the same physical interface the tunnel is built on. 231 Since the next hop address is not changed on the sinkhole device, 232 traffic entering this device from the tunnel will be sent back to the 233 network due to the presence of the default route. Routing protocols 234 will then take care of properly routing the traffic to its original 235 destination (attacked network). 237 It becomes apparent that this technique can also be used for purposes 238 other than analyzing attack traffic. Legitimate traffic could also 239 be pulled out of normal routing into a tunnel and then reinserted 240 onto the backbone without altering the next hop addressing scheme 241 throughout the iBGP network. 243 MPLS Traffic Engineering with its many feature, is a good method of 244 sliding traffic to the sinkhole device. Features like QoS policies 245 can be applied on the attack traffic, thus preventing it from 246 competing with legitimate traffic. 248 To be able to alter the next hop on the border router, a subnet of an 249 RFC 1918 network is statically routed to the tunnel interface. An 250 example of the static route is: 252 ip route 192.168.0.12 255.255.255.255 Tunnel0 254 Setting the next hop of the target IP address to 192.168.0.12/32 will 255 force the traffic to go through the tunnel. 257 Traffic is received at the sinkhole interface via the TE tunnel. 258 Subsequently, three methods could be installed, namely rate-limiting 259 policies, QoS policies and access lists. These policies could rate 260 limit or drop traffic classified as attack traffic. This process 261 would be done on the interface of the sinkhole device. Another 262 useful application for a sinkhole router is to pull in traffic via 263 tunnels to an inbound interface and have a default route statement 264 forwarding the traffic out to an Ethernet interface. The Ethernet 265 interface is connected to the iBGP network and guarantees proper 266 delivery of traffic but allows the use of a packet sniffer to further 267 analyze the attack traffic. 269 This becomes very useful when it is not feasible to apply an Access 270 list or a rate limiting statement on the BGP border router or last 271 hop router before the attacked host or network because of hardware or 272 software limitations. Hence, instead of upgrading interfaces at the 273 point of entry of attack traffic, the latter could be pulled into the 274 sinkhole and treated on that device. Operational costs can be 275 rendered minimal if the sinkhole router is a powerful device. 277 Security Considerations 279 It is very important to practice tight control over eBGP peering 280 points before implementing the techniques described in this paper. 281 eBGP customers might be able to blackhole a particular subnet using 282 the Blackhole communities. To eliminate the risk, the match for 283 locally generated BGP advertisements in the special route policy 284 should not be neglected. 286 Disclaimer 288 The views and specification here are those of the authors and are not 289 necessarily those of their employers. The authors and their employers 290 specifically disclaim responsibility for any problems arising from 291 correct or incorrect implementation or use of this specification. 293 Acknowledgments 295 The author of this document would like to acknowledge the developers 296 of the remotely triggered black-holing technique and the developers 297 of the backscatter technique for collecting backscatter traffic. The 298 author would also like to thank all members of the IP Engineering 299 department for their help in verifying the functionality of this 300 technique. 302 Author's Addresses 304 Doughan Turk 305 Bell Canada 306 100 Wynford Drive 307 Email: doughan.turk@bell.ca