nanog mailing list archives

RE: Cisco's Statement about IPR Claimed in draft-ietf-tcpm-tcpsecure


From: "Terry Baranski" <tbaranski () mail com>
Date: Wed, 19 May 2004 22:04:55 -0400


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


Current thread: