Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Terry Baranski
  • Date: Wed May 19 22:07:07 2004

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





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.