|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Technical solutions to tracing
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: [email protected] http://www.memra.com - *check out the new name & new website*
|