A major advantage to attackers in using reflectors in DDOS attacks is the degree to which they complicate traceback. First, instead of the victim being able to trace back the attack traffic from themselves directly to the slave, they must induce the operator of one of the reflector sites to do so on their behalf, which can be administratively cumbersome or difficult. Furthermore, if that traceback is then done using a scheme that relies on observing a high volume of spoofed traffic, such as ITRACE or probabilistic packet marking, then the attacker can undermine the traceback by spreading each slave's trigger traffic across many reflectors, greatly increasing the amount of time required by the traceback scheme to gather sufficient traffic to analyze.
However, if traceback is done using a scheme that also works for low volume flows, such as SPIE, then this advantage disappears, and the attacker should not spread out each slave's trigger traffic, as doing so will increase the chances that the slave will be detected by one of the different cooperating operators.
Another facet of the analysis in the previous section to keep in mind is that some forms of reflector attacks require legitimate (non-spoofed) connections from the slave to the reflector, such as exploiting HTTP proxies. Such reflector attacks will expose the slave to potentially immediate traceback.
For reflectors running on TCP stacks with guessable sequence numbers, the attacker may well be able to establish the necessary slave-to-reflector connection without exposing the slave's IP address; however, guessing sequence numbers generally requires establishing a series of legitimate connections beforehand, in order to infer the pattern of sequence number generation. If the logs at the reflector include these initial probes, then the slave may still be exposed. That said, for application-level logs, the attacker may be able to escape having the probes logged by failing to complete the 3-way TCP connection establishment handshake, in which case the application running at user level will generally never see the connection.
Finally, we note that Barros independently discovered DDOS reflector attacks, and proposed an elegant modification to ITRACE to address them [Ba00]. Barros' refinement is for ITRACE routers to sometimes send the ICMP message to the source of the just-processed packet rather than its destination. The net effect is that if a slave is forging traffic from a victim in order to dupe a server into acting as a reflector, occasionally routers on the path between the slave and the reflector will send ITRACE messages to the victim, enabling the victim to trace back the attack to the slave(s).
Note that the efficacy of Barros' ``reverse ITRACE'' mechanism does not depend on Nr, the number of reflectors, but only on Ns, the number of slaves. From our analysis above, it is clear that this appealing scaling property makes the mechanism helpful for defending against many forms of reflector attacks.