Re: Problems with implementation - DoS attacks possible

On Tue, 21 Jan 2003, Mikael Olsson wrote:

> > Unless ofcourse I will DDoS that router by myself and wait for a ICMP
> > Traceback message ;)
>
> Heh. Interesting method of eliciting key disclosure :P

Anyway, maybe there should be a method to get ICMP Traceback message from
router without DDoSing it? It can be a good solution to your "moving DDoS"
attack.

> > 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(!).

And what with that? What should I put to Key Disclosure subelement if
there where no others keys yet?


[cut]

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

Maybe not so dumb if someone is DDoS-ing you with spoofed ICMP Traceback
messages.

> to
> delay discovery of all zombies much longer than it'd take
> if I'd just target the same victim all the time.

The bottom line is: you can attack victim1 from zombie1 only for the
period of key lifetime. After that you need to attack another victim.

In my proposition you can attack victim1 from zombie1 again after the
KEY_C has been generated. In ICMP Traceback messages hashed with KEY_C
Key Disclosure List element may have only KEY_B because, according to
the draft, it "MUST contain at least one Key Disclosure subelement".
"At least" means that it can contain only one key subelement (KEY_B) and
not KEY_A.
What I'm saying here is that this sentence is very bad and can lead to
security bug in protocol specification. It must be exectly specified how
many subelements should be in the Key Disclosure List.
Can anyone tell me how long TAG=0x0E can be (in octets)? The problematic
are KEY MATERIAL and SIGNATURE fields ofcourse.


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

Agreed. But if there will be a method to authenticate an ICMP Traceback
message after the DDoS attack has stopped, your "moving DDoS" attack will
not work. The question is how can we do this?
1. Add some kind of method to get ICMP Traceback message from router (hard
to do because only those to which we sended ICMP Traceback messages should
be able to request another such message from us).
2. After key change we should send ICMP Traceback messages to hosts to
which we sended previous ICMP Traceback messages (hashed with previous
key).

I can tune one of this solutions (propably no.2) if we want to prevent
"moving DDoS" attacks. I'm waiting for opinions.


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