Re: Problems with implementation - DoS attacks possible

On Thu, 23 Jan 2003, Mikael Olsson wrote:

> Hey, how's this for a flat-out disgusting attack:
> - Keep changing victims.
> - Go back to a previous victim when the key used to authenticate
>   the last batch of itrace responses has disappeared from the list.
> - You know that the previous key has disappered by keeping a trickle
>   stream going from a zombie to somewhere else. After all, you get
>   backtraces too, so you see the disclosure lists.
>
> How to guard against this?
>
> I see two ways:
> - Use really short key disclosure periods. Maybe even randomize
>   the period?

I thought about the same idea two days ago and I'm sure randomizing the
period would be a good idea. (Can we use LCPRNG here?)
I think min. and max. periods should be as follows:
min. period: "moving DDoS" attacks will be not possible/effective
		(10 seconds?)
max. period: collector will be able to collect all ICMP Traceback messages
		for this period. It heavily depends on bandwitch
		(10 minutes?)

Moving DDoS attacks can be extended. Instruct zombies to change victims
every one second. In this scenario it will not do much harm to particular
victim. It is rather problem for the network from which zombie is
attacking. In this situation that network administrator should notice that
something is wrong (his Internet connection is very slow) and locate the
zombie. In my opinion it has nothing to do with iTrace. ITrace should be
effective agains long-term attacks directed to one/few victim(s).
As an network administrator I will not be interested in tracing attacks on
my network which last for few seconds.

Ofcourse you can instruct zombies to send one packet per second to
different victims :) It will be untraceble both by victim and zombie
networks, but can we really call it an "attack" anymore...



> - Or: Add a method to request a specific key. Cesar Eduardo Barros
>   proposed something along these lines in September 2000, in his
>   posting "Anonymous Authentication for IPSEC proposal".
>   Maybe the right way is to just send a "gimme heaps of keys"
>   message, to which the router responds with a pubkey URL and
>   then a bunch of signed HMAC keys? (More than would fit in a
>   regular itrace packet?)

How many keys can be in this bunch of signed HMAC keys?
Maybe we should have a method to request one specific key from disclosured
keys list?
Maybe the router will respond with a URL with Disclosure Key List (there
can be milions of keys on such page)?

We really need to add such method to the specification. We should only
think about *how* to do this and not *if* we should 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).
>
> Naw. There's no need for such constraints. Let anyone ask.

Remember that the attacker can request this too, so he can easily notice
that the key has been changed and immediatelly stop the attack (or move to
another victim). Randomizing of key disclosure will be questionable.


> > 2. After key change we should send ICMP Traceback messages to hosts to
> > which we sended previous ICMP Traceback messages (hashed with previous
> > key).
>
> This requires keeping state, which a router won't do for us.
> (And is also unnecessary load as long as an attack isn't happening)

I did some mathematics on it yesterday and now I think that the better
solution is to provide mechanism to request a key (or key list) from router.


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