North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Technical solutions to tracing
- From: Michael Dillon
- Date: Tue Jun 16 17:17:57 1998
On Tue, 16 Jun 1998, Mo wrote:
> > We need some sort of protocol that will recursively track spoofed source
> > address packets back to their source one hop at a time. Given a
> > destination address the protocol would track it to the previous hop router
> > and recurively initiate the same tracking procedure on that router. Once
> > the attack is tracked to the source, the probe would unroll and report the
> > results to all routers along the probe path for logging or reporting.
> I have few questions about this. Do we run it on the router?
At least part of this needs to be run on the router but part of it could
be run on a workstation.
> If yes what type CPU and Memory load can we expect?
Limited load. This tracing needs to be limited similar to the way that
UNIX shells limit resource consumption with the ulimit command. And there
needs to be some sort of rudimentary trust relationship set up, perhaps to
only allow traces to be initiated by a router that has a BGP peering
session in place.
> We must realise that the router
> are usually doing full BGP with upstreams and processing many different
> things on locally. Anything we do cannot take way from the proformance of
> a router.
I agree. If a peer initiates too many traces in a given timeframe then
extra ones should be silently ignored. A trace should start with human
intervention, i.e. a NOC employee runs some trace utility on a workstation
that initiates a trace probe on their own routers and the probe propogates
through the network until it succeeds or fades due to too many probes at
one spot at the same time. In most cases a single victim will contact a
single upstream and ask for a single probe. The only time probe activity
would hit its limits would be if a single attacker was simultaneously
attacking a large number of sites. If even one of the probes succeeds in
flushing out the attack source then it will be useful even if many probes
must fail to limit the load on the routers.
Michael Dillon - Internet & ISP Consulting
Memra Communications Inc. - E-mail: firstname.lastname@example.org
http://www.memra.com - *check out the new name & new website*