Re: Problems with implementation - DoS attacks possible

Tomasz Grabowski <[email protected]> Tue, 21 Jan 2003 21:22:10 +0100 (CET)
Newsgroups gmane.ietf.itrace
Message-ID <[email protected]>
Hello.

On Tue, 21 Jan 2003, Mikael Olsson wrote:

> Hey, there's an interesting thought. Moving DDoS. If key
> disclosure takes a "long" time, e.g. one hour, one could
> switch zombies once in a while to hope that their locations
> are never fully disclosed/authenticated.  Sure, we'll get
> plenty of tracebacks, but we won't be able to authenticate
> them until we get another traceback from a router close to
> the DDoS zombie. And if the zombie decides to shut up, that
> might be "never". Or at least days later, during which time
> said zombie has had time to wreak havoc in other places.

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


This is quote from the draft:

      A packet SHOULD contain a list of recently-used keys for hash
      algorithms.  This is provided in the Key Disclosure List element.
      This element MUST contain at least one Key Disclosure subelement,


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.
00:26 "Router A" generated iTrace_2 message hashed with KEY_C.
        Key Disclosure has only information about KEY_B, bacause draft
        states that "This element MUST contain at least one Key Disclosure
        subelement".
00:26 I received iTrace_2 message. I still can't authenticate iTrace_1
	because I don't know the KEY_A. I'm flushing iTrace_1 because I'm
	unable to authenticate it.

I hope I misunderstood the draft. Please point me out what's wrong with
this videotape :)


The main question is: what exactly means that "at least one Key Disclosure
Element"?


---
Tomasz Grabowski  (0-91)4494234
Akademickie Centrum Informatyki
mailto:[email protected]