[3393] in North American Network Operators' Group
Re: Ping flooding (fwd)
daemon@ATHENA.MIT.EDU (Curtis Villamizar)
Tue Jul 9 19:25:20 1996
To: Michael Dillon <michael@memra.com>
cc: nanog@merit.edu
Reply-To: curtis@ans.net
In-reply-to: Your message of "Mon, 08 Jul 1996 19:07:13 PDT."
<Pine.BSI.3.93.960708190406.27458F-100000@sidhe.memra.com>
Date: Tue, 09 Jul 1996 14:21:32 -0400
From: Curtis Villamizar <curtis@ans.net>
In message <Pine.BSI.3.93.960708190406.27458F-100000@sidhe.memra.com>, 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
