Re: Problems with implementation - DoS attacks possible

Daniel Senie wrote:
> 
> Or to put it a better way: [pubkey signed itraces on backbone routers]
> could certainly be made to work, but would require an "itrace 
> coprocessor" 

I still don't think it's economically feasible :)

> Mikael Olsson wrote:
> >The situation is just as bad on small edge routers. They don't come
> >equipped with pentium class CPUs. They do packet processing in ASICs.
> 
> Actually in most cases this isn't true even today. Many of the edge routers
> don't contain ASICs and do all their processing in software on a general
> purpose CPU. Depends what you consider a "small edge router" I like the
> 26xx series as a typical edge/CPE box, which contains a PowerPC core in
> which ALL of the forwarding and management work occurs.

Oho, interesting.  This doesn't agree very well with what cisco people
told us here on the list ~2 years ago, but ..... well, if this is the
future, it's good news :)

However, we still need a scheme that can be rolled out on existing
routers via normal software updates.  This definately include things 
with M680x0 processors and custom ASICs.

 
> >And, even if through some Great Miracle, all routers suddenly started
> >emitting pubkey signed itraces, what kind of hardware do we want to
> >require at the collectors?  We want people with "normal" internet
> >connections to be able to do this on the equivalent of a standard PC.
> >We do NOT want to require boxes equipped with crypto accelerators.
> 
> Here I'll disagree with you a bit too. The typical P4-powered PC on a
> desktop sits idle nearly all the time. It's quite capable of crunching the
> keys.

Nope. A P4-powered PC is capable of checking HMACs on a <100 Mbps
internet connection, and doing analysis logic.  It is NOT capable of
verifying pubkey signatures on the same traffic.  

I forget the exact numbers, but let's assume that a PC can check 200 
pubkey signatures per second.  Let's assume a mean itrace packet size
of ~300 bytes.  If the 200 ops/s figure is correct, this means that 
this box could handle a 600 kbps stream (flood) of itrace packets.


> We should explore whether it is possible to deploy an itrace mechanism with
> SOME level of security and with low compute overhead in the near term and
> continue to work on ways to strengthen the cryptography further.

Actually, the itrace mechanism can provide "some" level of security
without cryptography.  It'll handle non-itrace floods just fine.
It'll handle "dumb" itrace floods just fine just by looking at TTLs.

It will however not protect against some of the specialized attacks
outlined during earlier "let's try to break it" sessions here on this
list. (Back in 2000, I guess.) Such attacks would let the closest 
DDoS zombie cloak the location of other zombies for extended times.  
When this zombie is located, the next-closest is now the cloak for 
the others.

IMHO, the delayed key disclosure algorithm is currently our best bet.
It obviously needs some more thinking (and maybe tweaking), but it
does overcome the pubkey problems nicely.


-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com