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