North American Network Operators Group

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

Re: Ping flooding (fwd)

  • From: Curtis Villamizar
  • Date: Tue Jul 09 14:28:32 1996

In message <[email protected]>, Michael 
Dillon writes:
> 
> Is anyone working on tools to help NSP's quickly backtrack this kind of
> thing?

The NSS routers allow us to do statistical sampling continuously and
the occurance of a source address at an entry point where it does not
usually enter can be detected and has in the past been used to
followup these sort of attacks after the fact.  Other routers are not
capable of doing this but if the offense is repeated, successive
monitoring can be set up until the source is isolated.

We have requested the same sort of statistical sampling from Cisco and
Bay (and BNR/NSC).  It is a long ways back on the development schedule
for all but Bay.  It requires a hook in the forwarding path and is a
bit memory intensive and requires some, but not a lot of CPU on the
processor given the task of summarization (usually the processor doing
routing, not neccesarily for Bay - not sure yet).  The RS6000s are
typically running in the range of 50% to 90% CPU idle if you check one
second intervals or 75% to 90% if you check 10 second intervals unless
very major sustained route flap in occurring (or cron kicks something
off).  Milage will vary with router design.

The main purpose of the statistical sampling is traffic engineering,
but it sometimes comes in handy for following up on attacks with
forged source addresses.  Requests for this type of data for security
followups have been very infrequent.

Curtis
- - - - - - - - - - - - - - - - -