Network Working Group Internet Draft D. Turk Document: draft-turk-bgp-dos-01.txt Bell Canada Expires: February 2003 August 2002 Configuring BGP to Block Denial-of-Service Attacks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Abstract This document describes a technique that uses BGP communities to remotely trigger black holing of a particular destination network. Black holing can be applied on a selection of routers rather than all BGP speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. Turk Expires - February 2002 [Page 1]
Configuring BGP to Block DoS Attacks August 2002 Table of Contents 1. Existing BGP-Triggered Black holing Techniques 2 2. Enhanced BGP-Triggered Black holing Technique 3 3. Sinkhole tunnels 4 Security Considerations 6 Disclaimer 6 References 7 Acknowledgments 7 Author's Addresses 7 1. Existing BGP-Triggered Black holing Techniques Current BGP-triggered black holing techniques rely on altering the next hop address of a particular network experiencing an attack by the use of BGP. The BGP announcement propagates from a router participating in the BGP domain where the next hop address is modified to point to an RFC1918 address. Most routers on the Internet, especially edge routers, have static routes pointing RFC1918 addresses to the null interface. When a BGP speaking router receives the update, it will install the announced prefix into the routing table with a next hop of one of the networks listed in RFC1918. The router will then attempt to resolve the RFC1918 based BGP next-hop in order to qualify the route and derive a forwarding next-hop. This process will return a valid next hop of the null interface assuming the router is properly configured to direct RFC1918 destined traffic to a null interface. Thus, traffic destined to the announced network gets dropped making the announced network unreachable to the attacker. While this technique shields the internal infrastructure from the attack thereby protecting a large number of devices, it has the undesirable side effect or rendering the targeted network unreachable throughout the entire AS. Even if a static route pointing RFC1918 to a null interface does not exist on a particular router participating in the BGP domain, the modified next hop makes the traffic un- routable to its legitimate destination. Network operators usually use the BGP-triggered black holes for a short period of time. The technique causes traffic drops on all ingress points of the network for traffic destined toward the target network. By default, routers dropping traffic into a null interface should send "ICMP unreachable" to the source address of packet being dropped. Once the procedure reaches this point, one of the source addresses is hijacked by introducing a device with the same source IP address into the network. Turk Expires - February 2002 [Page 2]
Configuring BGP to Block DoS Attacks August 2002 The device with the hijacked address collects the ICMP unreachable packets and source addresses reveal which edge routers the attack is coming from. A network operator may then opt to manually stop the traffic on the routers from which attack traffic is entering. 2. Enhanced BGP-Triggered Black holing Technique This paper describes a technique developed to remotely trigger a selective set of routers to alter the next hop address of a particular prefix. The next hop can either be a null interface or as discussed later to in this draft it could be a sinkhole tunnel. This technique does not invoke an access list or rate limiting statement to treat attack traffic nor does it involve a BGP domain wide change of the victims next hop address to an RFC1918 address. The next hop will only be changed on selection of routers with the aid of BGP communities. To prepare the network for this technique, the network operator needs to define a unique community value for each edge router that could potentially drive attack traffic to the victim. For examples, a network with a BGP autonomous system number 65001 has two edge routers (R1 and R2). Community value 65001:1 is assigned to identify R1, community value 65001:2 is assigned to identify R2 and community value 65001:666 is assigned to identify both R1 and R2. After the BGP community assignment, R1 and R2 must be configured with the following: 1. Static route pointing an RFC1918 network to a null interface. 2. AS-Path access list that matches local BGP prefix announcements. 3. BGP community access list to match the community value assigned by the network operator for the particular router (i.e. 65001:1 for R1). 4. BGP community access list to match the community value assigned by the network operator for all router (i.e. 65001:666 for R1 and R2) 5. Under the BGP process, an iBGP import route policy should be applied on received BGP announcements to do the following logic. (Statements are in a logical AND order) a. A policy statement to permit routes that match the following criteria and apply the following changes. i. Match for community specific to that router (i.e. 65001:1, for R1). ii. Match AS-Path to locally generated BGP announcements. iii. Set BGP next hop to an RFC1918 network. iv. Overwrite BGP community with the well-known community (no- advertise). Turk Expires - February 2002 [Page 3]
Configuring BGP to Block DoS Attacks August 2002 b. A policy statement to permit routes that match the following criteria and apply the following changes. i. Match for community that covers all routers (i.e. 65001:666). ii. Match AS-Path to locally generated BGP announcements. iii. Set BGP next hop to an RFC1918 network. iv. Overwrite BGP community with the well-known community (no- advertise). After the policies have been configured on R1 and R2, the network operator can, in the case of an attack, announce the targeted network in its BGP domain with a community value associated with the router(s) where the attack is arriving. Using BGP communities preserves the original next hop address of the targeted network on all routers where the special route policy configuration is not configured. iBGP will then carry the prefix announcement to all router in the AS. All routers except the ones that match the community stamped on the prefix will be oblivious to the community value and will install the network route with the legitimate next hop address. Routers that match the community will also install the network route into their routing table but will alter the next hop to an RFC1918 network and then a null interface as per the route policies configuration. The reason for matching locally announced networks is to make sure that no eBGP customer can misuse this community to drive any network to a null interface. This technique stops traffic from getting forwarded to the legitimate destination on routers identified as transit routers for attack traffic. All other traffic on the network will still get forwarded to the legitimate destination thus minimizing the impact on the targeted network. 3. Sinkhole tunnels Further to the "Enhanced BGP-Triggered Black holing Technique", it may become a requirement to take a look at the attack traffic for further analysis. This requirement adds to the complexity of the exercise. Usually with broadcast interfaces, network operators install network sniffers on a spanned port for analysis of traffic. Another method would be to announce a network prefix that covers the attack host address(s) into BGP, altering the next hop to a sinkhole device that can log traffic for analysis. Those techniques result in taking down the services offered on the targeted IP addresses. Inter- AS traffic will be sucked into the sinkhole along with Intra-AS traffic. Turk Expires - February 2002 [Page 4]
Configuring BGP to Block DoS Attacks August 2002 The concept of sinkhole tunnels becomes viable when the solutions usually involve taking the targeted IP address down when the need for packet level analysis arises. The idea of a sinkhole tunnel is like a garden hose or a short cut path. When traffic is pushed to enter one end of the tunnel, it will end up exiting from the other end. This concept is useful to forward traffic on a network where there was no tampering with the targeted address next hop address. First, a sinkhole router with an optional sniffer attached to is installed. A tunnel is then set up using for instance, MPLS Traffic Engineering tunnel, from all border routers a packet can potentially enter from (Inter-AS traffic) to the sinkhole router. This allows the use of the community technique of altering the next hop of the targeted prefix to a series of /30 subnets assigned to the tunnels with the tail end terminating at the sinkhole router. In other words, the border router alters the next hop of the targeted IP address to the address of the sinkhole router within the subnet of the tunnel that starts at the border router. All other routers within the AS are oblivious to the change made by announcing a prefix with the preset community described in section 2. If legitimate traffic is coming from a different part of the network, the next hop would not be altered because of the community since next hop altering route maps do not exist anywhere else. Attack traffic is then treated at the sinkhole device. If the requirement was not to kill the traffic but rather to analyze it and then send it back towards the router it was originally destined to. Then on the sinkhole device, a default network statement is configured pointing to any interface attached to the network including the same physical interface the traffic came from. Traffic entering the sinkhole device from the tunnel will be pushed out of an interface back to the network because of the default route. Routing protocols will then take care of properly routing the traffic to its original destination as if nothing had happened. This is possible because no router other than the border router that has a match for the community will take action based on that community. It becomes apparent that this technique can be used for purposes other than analyzing attack traffic. Legitimate traffic could be pulled out of normal routing into a tunnel and then reinserted onto the backbone without altering the next hop addressing scheme. MPLS Traffic Engineering is a good way of sliding traffic to the sinkhole simply because of the many features it is associated with. Features like QoS policies on the attack traffic can be applied so that it will not compete with legitimate traffic. Hiding the extra hops caused by diverting the traffic by altering its TTL, and so on. Turk Expires - February 2002 [Page 5]
Configuring BGP to Block DoS Attacks August 2002 To be able to alter the next hop on the border router, a subnet of an RFC1918 network is statically routed to the tunnel interface. Take for example 192.0.2.33/32 ip route 192.0.2.1 255.255.255.255 Tunnel0 Setting next hop of the target IP address to 192.0.2.1/32 will force the traffic to go through the tunnel. After the traffic is received on the sinkhole interface via TE tunnel, rate-limiting policies, QoS policies or access lists could be installed to rate limit or drop traffic classified as attack traffic. This could be done on the interface of the sinkhole. Another useful application for a sinkhole router is to pull in traffic via tunnels to an inbound interface and have a default route statement forwarding the traffic out to an Ethernet interface. The Ethernet interface is connected to the network and guarantees proper delivery of traffic but allows the use of a packet sniffer to further analyze the attack traffic. This becomes very useful when it is not feasible to apply an Access list or a rate limiting statement on the border router or last hop router because of hardware or software limitations. Instead of upgrading interfaces where attack traffic will potentially enter from, traffic could be pulled into the sinkhole and treated on that box. Reduction in cost can be exercised if the sinkhole router is a powerful device. Security Considerations It is very important to practice tight control over BGP peering points before implementing this technique. BGP customers might be able to compromise a particular piece of the network using the Black holing communities. Making sure that a match for locally generated BGP announcement exist helps in limiting the ability to drive a network to a null interface to the local AS. Some other security considerations MUST be looked at based on the status of the AS those techniques are being implemented at. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Turk Expires - February 2002 [Page 6]
Configuring BGP to Block DoS Attacks August 2002 References [1] B. Greene "ISP Security Essentials - Best Practice Cisco IOS and other Techniques to Help an ISP Survive in today's Internet, version 2.0", May, 2001 Acknowledgments The author of this document would like to acknowledge the developers of the remotely triggered black holing technique and the developers of the backscatter technique for collecting backscatter traffic. The author would also like to thank all members of the IP Engineering department for their help in verifying the functionality of this technique. Author's Addresses Doughan Turk Bell Canada 100 Wynford Drive Email: doughan.turk@bell.ca Turk Expires - February 2002 [Page 7]