>>> 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