The same document that fully ignores that port number randomness will severely limit the risk of susceptibility to such an attack?
How many zombies would it take to search the port number space exhaustively?
Irrelevant.
The limiting factor here is how many packets can make it to the CPU. Using 10K pps as a nice round (and high) figure, a single machine can do that.
Also, many of the calculations I've seen assume much higher pps when calculating time to reset a session. Has anyone done a test to see what a Juniper M5/10/whatever and a GSR can actually take without dropping packets due to rate limiting and/or falling over from being packeted?
In some fairly informal tests that I did with an M20/RE3, I had to saturate the PFE <-> RE link (100Mbps) with packets destined to the RE before routing adjacencies started flapping. Packet size (64-1518 bytes) didn't make much of a difference (larger packets seemed to make things a bit more difficult for the routing protocols), and CPU usage on the RE rarely went above 30% during any test. Streams were sent from random source addresses. Packets that elicited a response from the RE (e.g., pings) didn't appear to have a greater effect on performance than ones that didn't, as there appears to be a good amount of rate-limiting going on internally to keep things reasonably calm. It's documented that pings to the RE are limited to 1000/sec, but it also appears that other packet types such as SYNs are rate-limited in some fashion, either the ingress packets themselves or maybe the responses from the RE. But in any case, whatever rate-limiting was going on didn't appear to be affecting routing adjacencies. Although I didn't try anything too fancy, it appears that it's pretty difficult to bog down the CPU (a PIII 600) on an RE3. Routing adjacencies were only affected with the PFE <-> RE link became saturated, which isn't surprising. There was no indication of transit traffic being affected, which also isn't surprising given that such packets are handled by ASICs. -Terry