North American Network Operators Group

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

Re: Ping flooding (fwd)

  • From: Michael Dillon
  • Date: Tue Jul 09 00:19:25 1996

On Mon, 8 Jul 1996, Daniel W. McRobb wrote:

> The problem is not really a technical one.  It's administrative.  It's
> much more of a headache to backtrack through 30 routers that aren't in
> your own network than to backtrack to the ingress to your own network
> domain and filter it out there (which is the typical response to this
> kind of thing).  Getting everyone in the path to cooperate with
> backtracking is difficult in many instances, impossible in others. 

I recall that people have cooperated in the past on some sort of
performance analysis tool that transported packets through a tunnel to
some remote point and initiated an analysis of some sort from that point
I believe this was done by NLANR and had something to do with vBNS.

I don't think this is all that different. If some means existed for an NSP
to initiate a trace on a specific source address to backtrack it to the
real source then an easy to use tool could be built. Of course, first of
all router vendors need to make a quick and relatively painless way to 
track down the interface that a packet comes in from, maybe

set icmp-source-trace 148.32.45.67 on

and later....

show icmp-source-trace

IP address          Interface
----------          ---------
148.32.45.67        NO TRACE

Note that the source trace was active for a period of time and then
expired automatically with no new ICMP packets bearing the specified
source address in that period of time. If this facility is available an
easy to use tool could be built.

> that doesn't even take into account the cases where an attacker has
> multiple paths into your network and is using multiple forged source
> addresses, much less the fact that the attacker can turn off the attack
> when he/she chooses, thwarting your effort to track them. 

No doubt about it. Being a detective is hard boring plodding work and
sometimes you just never find the crook. But it's still worth trying.

Michael Dillon                                   ISP & Internet Consulting
Memra Software Inc.                                 Fax: +1-604-546-3049
http://www.memra.com                             E-mail: [email protected]

- - - - - - - - - - - - - - - - -