Re: Problems with implementation - DoS attacks possible

Naohiro Fukuda <[email protected]> Wed, 22 Jan 2003 18:35:12 +0900
Newsgroups gmane.ietf.itrace
Message-ID <[email protected]>
At 19:26 03/01/21 +0100, you wrote:


>Naohiro Fukuda wrote:
> >
> > If attacker will send ICMP tarceback messages with various fake 
> authentications,
> > CRLs request will also be issued for the validation. If many classed 
> CAs exsist,
> >   it will be delayed much more.
> >
> > I think if it is not realtime traceback, it can be meaningful for forensics.
>
>I've got to admit that this isn't making sense to me. Either you're
>two steps ahead in your line of thinking, or you haven't understood
>the dynamics of the key disclosure algorithm: when I receive a packet,
>I have to _wait_ to find out what the key was used in its HMAC.

Why traceback message have "authentication" and "disclosure key"
infomation separately?

>It's not just an issue of "it takes time to connect to the web
>server and retreive the certificate".  I have to wait until the
>router that originated the traceback message decides to change
>its key and send a new traceback my way, a process which I cannot
>force.
>



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

I understood.

>Again: what kind of time periods are we talking about for
>key disclosure?  A few minutes? Hours?
>

Thinking about contention of hash by brute force;

Hash:

  HMAC-MD5(128 bits) ->  96 bits
  HMAC-SHA1(160 bits) -> 80 bits

  Assuming 10Gbps network, 64bits/packet, then around 2^27 packets/s
  can be transmitted. One year is 2^25, so around 2^25*2^27 = 2^52
  packets can be transmitted by a year.

  if it were MD5-96bits truncated hash, 2^48/2^52 = 1/16 year, i.e.,
  almost less than 1 month is dead line.

  So,in worst case, if it selects HMAC-MD5-96bits, it needs to change
  in "several weeks".

Certificate:

  If they use RSR 512bits, the secure level is as same as HMAC-MD5,
  RSR 1024bits is as same as HMAC-SHA1.

  So, if it selects RSA-512bits, 2^96/2^52 = 2^40 years, i.e.,
it needs to change in "1099511627776 years".

So, I think if it does not use 96bits truncated hash like IPsec,
IMHO, we do not have to care about anything about the lifetime.


>(Of course, in an ideal future world, where itrace has been
>  implemented in "all" routers, authentication becomes less
>  important; one can construct complete route chains with high
>  degrees of trust without it.)
>
>--
>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


----------------------------------------------------------------------------------------
Naohiro Fukuda
Matsushita Electric Works, Ltd.
Network Security Team
New Business Promotion Division
Address: 5-13-2, Mita, Minato-ku, Tokyo 108-8351, Japan
Tel: +81-3-3452-3390 Fax: +81-3-5442-9156
(MIC)  :7-331-4856 (MIC-FAX)  :7-331-4869
E-mail: [email protected]
English Homepage: http://www.netcocoon.com
Japanese Homepage: http://www.nais-netcocoon.com
----------------------------------------------------------------------------------------