idnits 2.17.1 draft-turk-bgp-dos-02.txt: -(90): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(178): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(298): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == 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 11 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 283: '...ome other security considerations MUST...' 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 (November 2002) is 7826 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 34 == Unused Reference: '1' is defined on line 298, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft D. Turk 3 Document: draft-turk-bgp-dos-02.txt Bell Canada 4 Expires: May 2003 November 2002 6 Configuring BGP to Block Denial-of-Service Attacks 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 except that the right to 12 produce derivative works is not granted. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Conventions used in this document 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 32 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 33 this document are to be interpreted as described in [RFC-2119]. 35 Abstract 37 This document describes an operational technique that uses BGP 38 communities to remotely trigger black-holing of a particular 39 destination network to block denial-of-service attacks. Black- 40 holing can be applied on a selection of routers rather than all BGP- 41 speaking routers in the network. The document also describes a 42 sinkhole tunnel technique using BGP communities and tunnels to pull 43 traffic into a sinkhole router for analysis. 45 Configuring BGP to Block DoS Attacks November 2002 47 Table of Contents 49 1. Existing BGP-Triggered Black holing Techniques 2 50 2. Enhanced BGP-Triggered Black holing Technique 3 51 3. Sinkhole tunnels 4 52 Security Considerations 6 53 Disclaimer 6 54 References 7 55 Acknowledgments 7 56 Author's Addresses 7 58 1. Existing BGP-Triggered Black-holing Techniques 60 Current BGP-triggered black-holing techniques rely on altering the 61 next hop address of a particular network experiencing an attack by 62 the use of BGP. The BGP announcement propagates from a router 63 participating in the BGP domain where the next hop address is 64 modified to point to an RFC 1918 (private internet) address. Most 65 routers on the Internet, especially edge routers, have static routes 66 pointing RFC 1918 addresses to the null interface. 68 When a BGP-speaking router receives the update, it will install the 69 announced prefix into the routing table with a next hop of one of the 70 networks listed in RFC 1918. The router will then attempt to resolve 71 the RFC 1918 based BGP next-hop in order to qualify the route and 72 derive a forwarding next-hop. This process will return a valid next 73 hop of the null interface, assuming the router is properly configured 74 to direct RFC 1918 destined traffic to a null interface. Thus, 75 traffic destined to the announced network gets dropped, making the 76 announced network unreachable to the attacker and everyone else. 78 While this technique shields the internal infrastructure from the 79 attack, thereby protecting a large number of devices, it has the 80 undesirable side effect of rendering the targeted network unreachable 81 throughout the entire AS. Even if a static route pointing an RFC 82 1918 address to a null interface does not exist on a particular 83 router participating in the BGP domain, the modified next hop makes 84 the traffic un-routable to its legitimate destination. 86 Network operators usually use the BGP-triggered black holes for a 87 short period of time. The technique causes traffic drops on all 88 ingress points of the network for traffic destined toward the target 89 network. By default, routers dropping traffic into a null interface 90 should send �ICMP unreachable� to the source address of packet being 91 dropped. Once the procedure reaches this point, one of the source 92 addresses is hijacked by introducing a device with the same source IP 93 address into the network. 95 Configuring BGP to Block DoS Attacks November 2002 97 The device with the hijacked address collects the ICMP unreachable 98 packets and source addresses reveal which edge routers the attack is 99 coming from. A network operator may then opt to manually stop the 100 traffic on the routers from which attack traffic is entering. 102 2. Enhanced BGP-Triggered Black-holing Technique 104 This paper describes a technique developed to remotely trigger a 105 selective set of routers to alter the next hop address of a 106 particular prefix. The next hop can either be a null interface or as 107 discussed later on in this draft it could be a sinkhole tunnel 108 interface. This technique does not invoke an access list or rate 109 limiting statement to treat attack traffic nor does it involve a BGP 110 domain wide change of the victims next hop address to an RFC 1918 111 address. The next hop will only be changed on selection of routers 112 with the aid of BGP communities. 114 To prepare the network for this technique, the network operator needs 115 to define a unique community value for each edge router that could 116 potentially drive attack traffic to the victim. For examples, a 117 network with a BGP autonomous system number 65001 has two edge 118 routers (R1 and R2). Community value 65001:1 is assigned to identify 119 R1, community value 65001:2 is assigned to identify R2 and community 120 value 65001:666 is assigned to identify both R1 and R2. 122 After the BGP community assignment, R1 and R2 must be configured with 123 the following: 125 1. Static route pointing an RFC 1918 network to a null interface. 126 2. AS-Path access list that matches local BGP prefix announcements. 127 3. BGP community access list to match the community value assigned by 128 the network operator for the particular router (i.e. 65001:1 for R1). 129 4. BGP community access list to match the community value assigned by 130 the network operator for all router (i.e. 65001:666 for R1 and R2) 131 5. Under the BGP process, an iBGP import route policy should be 132 applied on received BGP announcements to do the following logic. 133 (Statements are in a logical AND order) 134 a. A policy statement to permit routes that match the following 135 criteria and apply the following changes. 136 i. Match for community specific to that router (i.e. 65001:1, 137 for R1). 138 ii. Match AS-Path to locally generated BGP announcements. 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 Configuring BGP to Block DoS Attacks November 2002 145 b. A policy statement to permit routes that match the following 146 criteria and apply the following changes. 147 i. Match for community that covers all routers (i.e. 65001:666). 148 ii. Match AS-Path to locally generated BGP announcements. 149 iii. Set BGP next hop to an RFC 1918 network. 150 iv. Overwrite BGP community with the well-known community (no- 151 advertise). 153 After the policies have been configured on R1 and R2, the network 154 operator can, in the case of an attack, announce the targeted network 155 in its BGP domain with a community value associated with the 156 router(s) where the attack is arriving. Using BGP communities 157 preserves the original next hop address of the targeted network on 158 all routers where the special route policy configuration is not 159 configured. iBGP will then carry the prefix announcement to all 160 router in the AS. All routers except the ones that match the 161 community stamped on the prefix will be oblivious to the community 162 value and will install the network route with the legitimate next hop 163 address. Routers that match the community will also install the 164 network route into their routing table but will alter the next hop to 165 an RFC 1918 network and then a null interface as per the route 166 policies configuration. The reason for matching locally announced 167 networks is to make sure that no eBGP customer can misuse this 168 community to drive any network to a null interface. 170 This technique stops traffic from getting forwarded to the legitimate 171 destination on routers identified as transit routers for attack 172 traffic. All other traffic on the network will still get forwarded 173 to the legitimate destination thus minimizing the impact on the 174 targeted network. 176 3. Sinkhole tunnels 178 Further to the �Enhanced BGP-Triggered Black-holing Technique�, it 179 may become a requirement to take a look at the attack traffic for 180 further analysis. This requirement adds to the complexity of the 181 exercise. Usually with broadcast interfaces, network operators 182 install network sniffers on a spanned port for analysis of traffic. 183 Another method would be to announce a network prefix that covers the 184 attack host address(s) into BGP, altering the next hop to a sinkhole 185 device that can log traffic for analysis. Those techniques result in 186 taking down the services offered on the targeted IP addresses. Inter- 187 AS traffic will be sucked into the sinkhole along with Intra-AS 188 traffic. 190 Configuring BGP to Block DoS Attacks November 2002 192 Packet level analysis involves redirecting traffic away from the 193 destination host to a sniffer or a router. As a result, if the 194 traffic being examined includes legitimate traffic, that legitimate 195 traffic will never make it to the destination host. This will result 196 in denial of service for the legitimate traffic. A better 197 alternative would be to use a sinkhole tunnel. A sinkhole tunnel is 198 implemented only at the entry point to the network, where the all 199 traffic destined to the target host will be re-routed to a special 200 path (tunnel) where the sniffer will be able to analyze the traffic. 201 After being analyzed, the traffic will exit the tunnel and get routed 202 normally to the destination host. In other words, the traffic will 203 be passed through the network to a sniffer without altering the next 204 hop information of the destination network in all routers in the BGP 205 domain. Only the entry point router will have the altered next hop 206 information. 208 First, a sinkhole router with an optional sniffer attached to it is 209 installed. A tunnel is then set up using for instance, MPLS Traffic 210 Engineering tunnel, from all border routers a packet can potentially 211 enter from (Inter-AS traffic) to the sinkhole router. This allows 212 the use of the community technique of altering the next hop of the 213 targeted prefix to a series of /30 subnets assigned to the tunnels 214 with the tail end terminating at the sinkhole router. In other 215 words, the border router alters the next hop of the targeted IP 216 address to the address of the sinkhole router within the subnet of 217 the tunnel that starts at the border router. All other routers 218 within the AS are oblivious to the change made by announcing a prefix 219 with the preset community described in section 2. If legitimate 220 traffic is coming from a different part of the network, the next hop 221 would not be altered because of the community since next hop altering 222 route maps do not exist anywhere else. 224 Attack traffic is then treated at the sinkhole device. If the 225 requirement was not to kill the traffic but rather to analyze it and 226 then send it back towards the router it was originally destined to. 227 Then on the sinkhole device, a default network statement is 228 configured pointing to any interface attached to the network 229 including the same physical interface the traffic came from. Traffic 230 entering the sinkhole device from the tunnel will be pushed out of an 231 interface back to the network because of the default route. Routing 232 protocols will then take care of properly routing the traffic to its 233 original destination as if nothing had happened. This is possible 234 because no router other than the border router that has a match for 235 the community will take action based on that community. It becomes 236 apparent that this technique can be used for purposes other than 237 Configuring BGP to Block DoS Attacks November 2002 239 analyzing attack traffic. Legitimate traffic could be pulled out of 240 normal routing into a tunnel and then reinserted onto the backbone 241 without altering the next hop addressing scheme. 243 MPLS Traffic Engineering is a good way of sliding traffic to the 244 sinkhole simply because of the many features it is associated with. 245 Features like QoS policies on the attack traffic can be applied so 246 that it will not compete with legitimate traffic. Hiding the extra 247 hops caused by diverting the traffic by altering its TTL, and so on. 249 To be able to alter the next hop on the border router, a subnet of an 250 RFC 1918 network is statically routed to the tunnel interface. Take 251 for example 192.0.2.33/32 253 ip route 192.0.2.1 255.255.255.255 Tunnel0 255 Setting next hop of the target IP address to 192.0.2.1/32 will force 256 the traffic to go through the tunnel. 258 After the traffic is received on the sinkhole interface via TE 259 tunnel, rate-limiting policies, QoS policies or access lists could be 260 installed to rate limit or drop traffic classified as attack traffic. 261 This could be done on the interface of the sinkhole. 263 Another useful application for a sinkhole router is to pull in 264 traffic via tunnels to an inbound interface and have a default route 265 statement forwarding the traffic out to an Ethernet interface. The 266 Ethernet interface is connected to the network and guarantees proper 267 delivery of traffic but allows the use of a packet sniffer to further 268 analyze the attack traffic. This becomes very useful when it is not 269 feasible to apply an Access list or a rate limiting statement on the 270 border router or last hop router because of hardware or software 271 limitations. Instead of upgrading interfaces where attack traffic 272 will potentially enter from, traffic could be pulled into the 273 sinkhole and treated on that box. Reduction in cost can be exercised 274 if the sinkhole router is a powerful device. 276 Security Considerations 278 It is very important to practice tight control over BGP peering 279 points before implementing this technique. BGP customers might be 280 able to compromise a particular piece of the network using the Black 281 holing communities. Making sure that a match for locally generated 282 BGP announcement exist helps in limiting the ability to drive a 283 network to a null interface. Some other security considerations MUST 284 be looked at based on the status of the AS those techniques are being 285 implemented at. 287 Configuring BGP to Block DoS Attacks November 2002 289 Disclaimer 291 The views and specification here are those of the authors and are not 292 necessarily those of their employers. The authors and their employers 293 specifically disclaim responsibility for any problems arising from 294 correct or incorrect implementation or use of this specification. 296 References 298 [1] B. Greene �ISP Security Essentials � Best Practice Cisco IOS and 299 other Techniques to Help an ISP Survive in today�s Internet, 300 version 2.0�, May, 2001 302 Acknowledgments 304 The author of this document would like to acknowledge the developers 305 of the remotely triggered black-holing technique and the developers 306 of the backscatter technique for collecting backscatter traffic. The 307 author would also like to thank all members of the IP Engineering 308 department for their help in verifying the functionality of this 309 technique. 311 Author's Addresses 313 Doughan Turk 314 Bell Canada 315 100 Wynford Drive 316 Email: doughan.turk@bell.ca