Introduction

In a distributed denial-of-service (DDOS) attack, the attacker compromises a number of slaves and installs flooding servers on them, later contacting the set of servers to combine their transmission power in an orchestrated flooding attack. The use of a large number of slaves both augments the power of the attack and complicates defending against it: the dilution of locality in the flooding stream makes it more difficult for the victim to isolate the attack traffic in order to block it, and also undermines the potential effectiveness of traceback techniques for locating the source of streams of packets with spoofed source addresses.

  

Figure 1: Structure of a distributed denial-of-service (DDOS) attack.

  

Figure 2: Using reflectors to render a DDOS attack much more diffuse.

Figure 1 illustrates the nature of the attack: one host, the master, sends control messages to the previously compromised slaves, instructing them to target a given victim. The slaves then generate high volume streams of traffic toward the victim, but with fake or randomized source addresses, so that the victim cannot locate the slaves.

The problem of tracing back such streams of spoofed packets has recently received considerable attention. In Bellovin's proposed ITRACE scheme, routers (or outboard processors), with a very low probability, send ICMP messages to the destinations of packets they have just forwarded [Be00a]. For a high-volume flow, the victim will eventually receive ICMPs from all of the ITRACE routers along the path back to the slave, revealing its location.

Savage and colleagues proposed a different scheme, in which routers with considerably higher probability mark the packets they process with highly compressed information that the victim can decode in order to detect the edges (pairs of packet-marking routers) traversed by the packets, again enabling recovery of the path back to the slave [SWKA00]. This scheme can trace back potentially lower-volume flows than required for traceback using ITRACE; however, the scheme runs into computational difficulties as the number of slaves increases, a problem addressed by Song and Perrig by supplementing the scheme with the use of network topology maps [SP01].

In more recent work, Snoeren and colleagues discuss a Source Path Isolation Engine (SPIE) that records sets of hashes of packets traversing a given router [S+01]. A victim can then locate the path of a given packet by querying routers within a domain for the set of hashes corresponding to the packet, providing they issue the query soon enough after the packet was transmitted that the record of its presence is still available. SPIE has a major advantage over ITRACE and probabilistic packet marking in that it can facilitate traceback of even low volume (including single packet) flows.

The use of hundreds or thousands of slaves can both greatly complicate traceback (due to the difficulty of disentangling partial traceback information relating to different sources, and/or having to contact thousands of routers) and greatly hinder taking action once traceback succeeds (because it requires installing hundreds of filters and/or contacting hundreds of administrators).

Attackers can do considerably better still by structuring their attack traffic to use reflectors. A reflector is any IP host that will return a packet if sent a packet. So, for example, all Web servers, DNS servers, and routers are reflectors, since they will return SYN ACKs or RSTs in response to SYN or other TCP packets; as are query replies in response to query requests, and ICMP Time Exceeded or Host Unreachable messages in response to particular IP packets.

The attacker first locates a very large number of reflectors, say on the order of 1 million. (This is probably not too difficult, as there are at least that many Web servers on the Internet; plus, see below on relaxing this requirement.) They then orchestrate their slaves to send to the reflectors spoofed traffic purportedly coming from the victim, V. The reflectors will in turn generate traffic from themselves to V. The net result is that the flood at V arrives not from a few hundred or thousand sources, but from a million sources, an exceedingly diffuse flood likely clogging every single path to V from the rest of the Internet.

Figure 2 illustrates this modification to a conventional DDOS attack. Note that the victim does not require any traceback in order to locate the reflectors; they are readily identified as the source addresses in the flooding packets received by the victim. The operator of a reflector, on the other hand, cannot easily locate the slave that is pumping the reflector, because the traffic sent to the reflector does not have the slave's source address, but rather the source address of the victim.

In principle the operator can use traceback techniques such as those discussed above in order to locate the slaves. However, note that the individual reflectors send at a much lower rate than the slaves would if they were flooding V directly. Each slave can scatter its reflector triggers across all or a large subset of the reflectors, with the result being that if there are N_r reflectors, N_s slaves, and a flooding rate F coming out of each slave, then each reflector generates a flooding rate of $F' = { N_s \over N_r } F$. So a local mechanism that attempts to automatically detect that a site has a flooding source within it could fail if the mechanism is based on traffic volume.

In addition, traceback techniques based on observing large volumes of traffic (ITRACE, probabilistic packet marking; but not SPIE) will fail to locate any particular slave sending to a given reflector. If there are N_r reflectors, then it will take N_r times longer to observe the same amount of traffic at the reflector from a particular slave as it would if the slave sent to the victim directly. Thus, using reflectors provides significant protection against these forms of traceback even if there aren't more reflectors than slaves (or even fewer). Against a low-volume traceback mechanism like SPIE, however, reflectors do not yield such an advantage, and indeed the attacker should instead confine each slave to a small set of reflectors, so that the use of traceback by the operator of a single reflector does not reveal the location of multiple slaves.

Note that unlike some forms of denial-of-service attacks, the reflectors do not need to serve as amplifiers (sending out a larger volume of traffic than the attacker sends to them). They can even somewhat attenuate the volume of traffic sent to them and still serve their purpose effectively. This latitude on not requiring amplification consequently allows a large number of different network mechanisms to serve as reflectors, facilitating the attacker's task of finding a sufficient number of reflectors to launch the attack.

Finally, note that we do not consider here two quite different forms of reflectors: social attacks (in which many people are duped into attempting to connect to the victim) and viral attacks (in which the attacker acquires a vast number of slaves using a virulent virus, and then instructs the slaves to directly attack the victim, perhaps with perfectly legitimate requests [Me00]--the use of reflectors is basically irrelevant, because the attacker already has such an immense number of slaves).