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.