Re: Problems with implementation - DoS attacks possible

Tomasz Grabowski wrote:
> 
> What do You mean "days later"? I don't quite understand this. If the
> zombie will shut up, I will virtually *never* receive any further ICMP
> Traceback messages from router close to that zombie.
> Unless ofcourse I will DDoS that router by myself and wait for a ICMP
> Traceback message ;)

Heh. Interesting method of eliciting key disclosure :P


> Let's go back to the videotape:
> 
> HH:MM
> -----
> 00:00 "Router A" has been rebooted.
> 00:00 "Router A" generated a KEY_A with lifetime 10 minutes.
> 00:03 Attack started to my network from zombie close to the "Router A".
> 00:06 "Router A" generated iTrace_1 message hashed with KEY_A.
>         Key Disclosure is empty, because there were no keys before KEY_A -
>         it violates the draft(!).
> 00:06 I received iTrace_1 message. Now I need to wait for another iTrace
>         message with a KEY_A in Key Disclosure (sub)element.
> 00:08 Attack stops.
> 00:10 "Router A" generated a KEY_B with lifetime 10 minutes.
> 00:20 "Router A" generated a KEY_C with lifetime 10 minutes.
> 00:23 Attack started again.

Here's the misunderstanding.  I want to wreak maximum havoc to
the Internet at large. I have a "low" (as in traceable; everything
comes to pieces of we have tens of thousands anyhow) number of 
fairly powerful DDoS zombies.

"Attack started again" doesn't mean I attack the same target.
I attack another target. And then a while later, yet another
different target. 

Like this:
00:00 Zombie 1 attacks A
00:05 Zombie 1 switches to B
      Zombie 2 attacks A
00:10 Zombie 1 switches to C
      Zombie 2 switches to B
      Zombie 3 attacks A

Now I've kept victim1 under attack for 15 minutes, and he's 
probably only learned of ONE of my zombies (assuming 10-minute
key disclosure intervals). I only have three zombies though,
so we move on to other targets...

00:15 Zombie 1 switches to D
      Zombie 2 switches to C
      Zombie 3 switches to B

etc..

This way, I can probably keep this up for hours and hours,
and trust admin confusion (not to mention dumb software that
refuses to report traces that it cannot authenticate) to
delay discovery of all zombies much longer than it'd take
if I'd just target the same victim all the time.

Mitigating factor: there's not just _one_ router in the path.
There's several. Hopefully >1 with itrace capabilities.
This increases the chances of discovery.  Even if the closest 
hop doesn't send a new key in time, maybe the next-closest hop 
does, which usually still helps.


I'm not saying that this is a fatal flaw in the idea, but I
do believe that it means that a key disclosure of interval
of "minutes" should mean "a _few_ minutes" or maybe even
"one minute", not "30 or so".


-- 
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