Re: Problems with implementation - DoS attacks possible

Mikael Olsson <[email protected]> Thu, 23 Jan 2003 08:47:43 +0100
Newsgroups gmane.ietf.itrace
Organization Clavister AB
Message-ID <[email protected]>

Tomasz Grabowski wrote:
> ... "MUST contain at least one Key Disclosure subelement". ...
> 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.

Good point. Perhaps not a complete solution, but read on...

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


Looking at your suggestions:

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

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


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