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]