next up previous
Next: IP packets Up: An Analysis of Using Previous: Defenses against reflectors

Filtering out reflector replies

We now turn to an assessment of the practicality of a victim site being able to attain relief from a DDOS reflector flood by filtering out specific types of traffic. To do so, we need to attempt to catalog the different types of reflectors that an attacker might employ.

We assume that the victim (or an upstream provider assisting the victim) can only afford to deploy stateless filtering, given the potentially immense volume of (bogus) state that a flooding attack generates. In principle this could be relaxed to allow some stateful filtering when either the state is highly aggregatable, such as pertaining to particular pairs of interfaces and address prefixes, or the state is instantiated only by traffic from the victim, and hence will not scale disproportionately (unless the attacker can manipulate the victim into violating this assumption). We also assume that the victim, with the cooperation of their service provider, can have such filters installed sufficiently far away from the victim's links that a DDOS attack that targets the access link bandwidth rather than the victim's servers directly can still be throttled, if enough of it matches a particular small set of filters.

Finally, we assume that success in terms of defending the victim is that the filtering allows a significant proportion of the victim's service to continue; we do not require that the filtering leave the service completely unimpaired.

Table I: Summary of different reflector threats and the efficacy of combatting them using filtering.
Protocol/element Filtering notes
IP version Insignificant.
IP options Insignificant.
IP TOS / DSCP Could aid victim if attack traffic non-premium.
IP length Insignificant.
IP ID Insignificant.
IP fragments No cost to filter out unless victim uses fragment-inducing protocols (NFS, AFS, GRE).
IP TTL None.
IP protocol None.
IP checksum None.
IP source Only filterable if victim can identify as uninteresting.
IP destination Only filterable if victim can identify as uninteresting.
ICMP request/reply Likely not difficult to filter out. Includes smurf attacks.
ICMP problem Likely not difficult to filter out.
TCP source port If filtered, no general access to remote server of given type.
TCP SYN ACK If filtered, no general access to remote servers.
TCP RST If filtered, state will accumulate over time.
TCP guessable seq. no. Major threat.
T/TCP Would be significant threat but easily filtered due to limited deployment.
UDP No threat due to no inherent reply mechanism.
UDP length Insignificant.
UDP checksum Insignificant.
DNS query/response Can be filtered by opening up holes to specific remote servers.
Recursive DNS queries Major threat to name servers.
SNMP request/response Generally can be filtered out with little impact on victim.
HTTP proxy caches A significant threat, but likely easily traced back to slave.
Gnutella ``push'' Major threat.
Other TCP applications Will in general be traceable to slave if application server keeps logs.
Other UDP applications Unknown.
Other overlay networks Unknown.

Table I summarizes the analysis developed in the remainder of this section.

next up previous
Next: IP packets Up: An Analysis of Using Previous: Defenses against reflectors
Vern Paxson