Defenses against reflectors

There are a number of possible defenses against reflector attacks:

1.

If it is impossible to spoof source addresses in packets, for example by ubiquitous deployment of ingress filtering [FS00], then the threat is significantly diminished. The threat does not entirely go away, though, due to the possible use of application-level reflectors such as recursive DNS queries (Section III-E) or HTTP proxy requests (Section III-G), as discussed below. However, while an attacker can still mount a reflector attack even if the slaves lack the ability to spoof source addresses, the victim will be able to more quickly locate the slaves, because if a reflector server maintains logs of the requests it receives, those logs will pinpoint the slave location(s).

For the remainder of the discussion, we assume that we care about preventing attacks in an Internet for which source integrity is not guaranteed.

2.

Traffic generated by reflectors may have sufficient regularity and semantics that it can be filtered out near the victim without the filtering itself constituting a denial-of-service to the victim (``collateral damage''). Here, ``filtering'' refers to the general notion of packet classification; the filtered traffic could then be rate-limited, delayed, or dropped. We will usually, however, presume that filtering means dropping the traffic, and assess the dangers of collateral damage in that context.

3.

Bogus reflector requests used to pump reflectors may have sufficient regularity and semantics to enable sites to deploy filtering to prevent their network elements from serving as reflectors.

4.

In principle it could be possible to deploy traceback mechanisms that incorporate the reflector end-host software itself in the traceback scheme, allowing traceback through the reflector back to the slave.

5.

Traffic patterns resulting from a slave pumping a disparate set of reflectors may be discernible to intrusion detection systems monitoring a site's Internet access link.

Of these, we argue that only (2) is potentially viable. We regard (1) as out of scope for the entire discussion of DDOS attacks that utilize spoofed source addresses. (3) requires widespread deployment of filtering, on a scale nearly comparable with that required for widespread deployment of anti-spoof filtering, and of a more complicated nature. (4) has enormous deployment difficulties, requiring incorporation into a large number of different applications developed and maintained by a large number of different software vendors, and requiring upgrading of a very large number of end systems, many of which lack any direct incentive to do so. In addition, (4) may not help with traceback in practice if the traceback scheme cannot cope with a million separate Internet paths to trace back to a smaller number of sources; neither ITRACE nor probabilistic packet marking appears amenable to doing so. (5) requires widespread deployment of security technology at sites which fail to provide such basic security precautions as anti-spoof mechanisms, not a likely combination.

In Section III we examine the viability of (2) in detail, finding that most, but not all, reflector-generated traffic can be filtered without grievously impairing the functionality of most sites. In Section IV we then look at the implications of reflector attacks for traceback, focussing on a modification to ITRACE proposed by Barros [Ba00] and the use of SPIE [S+01].