------- Blind-Carbon-Copy X-Mailer: exmh version 2.0.2 2/24/98 From: Alex Bligh <amb@gxn.net> To: amb@Gxn.net Subject: Proposal for mitigating DoS attacks Reply-To: amb@gxn.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Jul 1999 17:50:06 +0200 Sender: amb@gxn.net Warning: This message contains operational content. I'd invite comments on an idea I had to mitigate the effect of Denial of Service attacks. I've outlined it below. Alex Bligh GX Networks (formerly Xara Networks) Using a Well Known Community to mitigate the effects of a Denial of Service Attack. ========================================================= Author: Alex Bligh (amb@gxn.net) Version: 0.01 Date: Sat 10 Jul 1999 Background - ---------- Most Denial of Service (DoS) attacks consist of a large number of packets directed at a single or small number of specific hosts. The constituent packets often have spoofed source IP addresses, and the attacks may come from multiple sources, or via third party reflectors. In order to trace the attacks, even where technically possible, multiple NOC's have to be called and, due to difficulties in human-to-human interaction, as well as technical difficulties, it is difficult, and in practice often impossible, to trace and stop the attack in a timely manner. Thus, whilst tracing the ultimate perpetrator is obviously preferable from a legal and moral standpoint, from an operational standpoint much benefit can be gained from mitigating the effects of the attack. Many attacks have effects on hosts other than the target host. As the traffic to the victim host is increased, not only will the performance of that host suffer, but also the victim's entire connection to the net. It is possible that parts of the downstream ISP's backbone have lower available capacity than the magnitude of the attack, and that the consequent congestion or extra switching load will cause degradation to other traffic, or even link failure. This effect is referred to below as 'collateral damage'. An entire customer, or even an ISP, can be severely affected or cut off from the net by a concerted attack on a single host unless preventative measures are taken. Various heuristic measures are possible - rate-limiting ICMP inbound at network borders is in general an effective way to limit the damage done by a SMURF attack, for instance. However, in general, the best way to reduce the collateral damage component is to block the attack as close to its sources as possible. This in general requires working through the same set of tracing procedures as finding the perpetrator, and is often impractical. Thus an oft-used response to an attack is to block traffic either to, or from, particular IP addresses. In the case of attacks involving forged source IP addresses, or reflected attacks such as SMURF, the only way to easilly block these attacks to prevent collateral damage, is to prevent all traffic from reaching the IP address concerned (filtering) until the attack has ceased (either as a consequence of a parallel act of tracing, or otherwise). However, it is often insufficient for the victim to block the attack at their ingress point, as the magnitude of the attack may be larger than their connection to their ISP. It is thus often useful for the ISP to block the attack instead. However, the ISP suffers the same problem, and to minimize the effect on their backbone, will want to block the attack at their network boundaries (i.e. at the points of interconnect with their upstreams and peers). A very large attack may require upstreams and peers to put in the same measures. Currently, the procedures for implementing these measures are, to say the least, manual, and rely on levels of interprovider communication which appear not to prevalent in the industry in general. This proposal describes a method to implement blocking of particular IP addresses across large portions of the internet using existing technlogy and protocols, and without the need for interprovider communication beyond the initial setup. Use of a Well Known BGP Community ================================= The core concept behind this proposal is the propagation of /32 routes (i.e. host routes) throughout large proportions of the BGP-speaking set of ISPs, through peering and transit relationships. Each of these routes will be tagged with a well-known community. For the purposes of this document, the community will be referred to as 65534:1. Each route so tagged will be referred to below as a "Victim Route". Throughout each provider's iBGP mesh, where a Victim Route is received, traffic to that destination is discarded (examples of configuration for a Cisco follow). These routes are propagated using the same rules as the propagation of the supernet to which they belong. By this technology, anyone receiving a supernet advertisement will also receive any relevant victim routes, and discard the traffic. A discussion on Route Filtering =============================== Responsible transit providers filter the routes from their customers. Most ISPs apply some form of filtering to their peers. Normally neither form of filtering allows for /32s (host routes) to be admitted. Indeed many ISPs specifically reject routes longer than a /24. This proposal does not invalidate the concept of route filtering. In fact it is vital that the same level of filtering is applied to Victim Routes as to the superblock in which they reside; elsewise they could themselves be used by irresponsible people as a Denial of Service attack. The same technology that currently ensures ISP's do not lose connectivity to their customers by accepting similar routes from their peers can be used to filter acceptance of Victim Routes. Filter lists should be deployed which admit /32s only if they are tagged with the relevant community, and only if they are subnets of a block which would otherwise be accepted by the BGP peer. Increase in size of the Routing Table ===================================== Whilst it is inevitable that this proposal would increase the size of the routing table, and the volume of advertisements, it has some gains in this respect too. The main reason to restrict routing table growth is to minimize CPU load on routers. The CPU load gains from not switching DoS traffic, and from the consequent saving of BGP advertisements from lines flapping under excess congestion, is almost certainly well worth a few extra transient advertisements. Example configurations for a Cisco Router ========================================= Whilst this proposal is no doubt applicable on other vendors, it has only thus-far been tested on Cisco IOS 11.1.26CC1 running CEF. The above configuration on a 7507 happilly sinks at least 10Mb/s of ICMP Denial of Service traffic without measurable CPU impact. Using an ASN of 5555, the configuration router bgp 5555 neighbor 5555-IBGP-PEER route-map IN-5555-IBGP-PEER in is added to the IBGP peer group. ip community-list 9 permit 65534:1 is used to detect the Well Known Community. route-map IN-5555-IBGP-PEER permit 10 match community 9 set ip next-hop 10.1.1.1 ! route-map IN-5555-IBGP-PEER permit 20 ! is used to set the next hop to an unused IP address when received from any other IBGP peer. A similar route-map can be used with external peers. ip route 10.1.1.1 255.255.255.255 loopback0 ensures packets with this next hop are discarded in a CPU efficient manner. Where connecting to a customer who wishes to control their own blackholing within your AS (we assume here they have a single network 200.100.0.0/16) a configuration like the following is used: ip prefix-list CUSTOMER seq 5 permit 200.100.0.0/16 ! ip prefix-list CUSTOMER-BLACKHOLE seq 5 permit 200.100.0.0/16 ge 32 ! route-map IN-5555-CUST-CUSTOMER permit 5 match ip address prefix-list CUSTOMER-BLACKHOLE match community 9 [only necessary if customer is sending communities] set ip next-hop 10.1.1.1 set community 65534:1 [only necessary if customer doesn't send communities] ! route-map IN-5555-CUST-CUSTOMER permit 10 match ip address prefix-list 191 CUSTOMER match as-path 123 set community <whatever> ! router bgp 5555 neighbor 1.2.3.4 remote-as 1234 neighbor 1.2.3.4 route-map IN-5555-CUST-CUSTOMER in This ensures that routes received from the customer are appropriately dealt with and tagged. Alex Bligh ------- End of Blind-Carbon-Copy