* DoS/DDoS protection: There are times when packet-blasting at high rates is exactly what's needed, and that's true for denial-of-service testing. Test tools need to have enough horsepower to saturate one or more backbone links with known forms of DoS and DDoS attacks, and they need to do so in a way that offers fine-grained control of key traffic parameters such as attack source addresses.
* Fuzzing. There's a bit of an arms race going on among vendors of signature-based security devices such as intrusion prevention devices (IPSs). One vendor will claim its IPS supports X number of signatures, while another will say its products are better because it has 2X signatures.
Unfortunately, neither vendor can claim totally effective protection because of a basic limitation with the signature-based approach: Signatures match only an exact sequence of bytes or packets. As a result, altering even one bit in a sequence is likely to "blind" a signature. Attackers know this, and make small changes to known vulnerabilities to escape detection. In effect, the attackers are fuzzing exploit traffic by changing parts of a known signature.
An effective security test tool also uses fuzzing. For example, a tool that uses fuzzing can take a SQL injection exploit and iterate over each field in the SQL query, changing random bits in each field. Because the IPS signature matches only on exact field contents, it's likely to miss this varied form of attack.
Fuzzing isn't limited to attack traffic; it also can expose weaknesses in benign traffic, covering many common network protocols. A good illustration of this is Open Shortest Path First (OSPF), the widely used enterprise routing protocol. Many routers running OSPF will behave in unexpected ways -- or even crash -- when receiving unexpected values in some OSPF headers. Fuzzing is equally effective in exposing security issues with attack and non-attack traffic.