Re: Problems with implementation - DoS attacks possible

Hello,

At 10:07 03/01/22 +0100, you wrote:

>Hello.
>
>[cut]
>
> > These means the disclosure key of previous TRACEBACK messages
> >   will be included in next TRACEBACK message.
> >
> > So, if the comming DoS traffic is as forged ICMP traceback,  under the
> > jammy noisy traffic, the collector need to "*WAIT" the disclosure key.
>
>Exactly.
>
>
> > But, if the disclosure key comes first or same-time don't you think it
> > becomes better?
>
>Hash algorithm is a one-way function. If the key is disclosured, everyone
>can spoof a ICMP Traceback message.
>Very simple explanation:
>P(_message_ + _key_material_) = _hash_
>
>In itrace we know only P() function, _message_ and _hash_. So, we can't
>check if the _hash_ is correct as far as we don't have _key_material_. If
>the router will disclosure his _key_material_, we will be able to make the
>same P() function as router did before and check if the hash is correct.
>Moreover, we can now produce our own hash for our spoofed message:
>P(_spoofed_message_ + _key_material_) = _spoofed_hash_
>So, you can see now, that after key disclosure we musn't use that key
>anymore.
>
>We are not talking about digital signatures here! We are hashing only and
>nothing more. The digital signature will be used only in Key Disclosure
>List element.
>
>The main reason for such solution is speed. Hash algorithms are very
>fast - we can use it on every ICMP Traceback packet. Digital signatures
>are much slower - we will use it only to sign Key Disclosure List which
>means we need to do this only when keys are changing.

I understood, thank you. i.e., the reason for the performance this draft-03.txt
  does not allow to use "ICMP + HASH + SIG" combination, correct?

But, thinking about the collector's performance, don't you think to admit it?

If it required, I think, there is another solusion to implement RSA accelerators
in ther routers for signing.

This "binding" will be very tight for collector's implementators.



> > >Assuming I have 622 Mbps speed and I'm flooded with ICMP Traceback
> > >messages. The time beetwen key change is one hour. Imagine how big
> > >buffer-1 must be...
> > >
> >
> > If the full network speed were available, it is about 80MB/s. Assuming
> > the average size of packets were 500 bytes, it is about 160,000 packet/s.
> >
> > If we use a PC of 1GB Memory as collector, the memory will be filled up
> >   about 10 seconds, though we need to backup the data to HDD until then.
>
>You need a big HDD to collect all messages :)
>What I'm saying here it is *not possible* to collect all messages (and
>yes, I'm connected 622 Mbps to the Internet and I recently experienced an
>attack at >500 Mbps speed).

Oh... How much do you think the cost to achive the complete traceback
collector?


> > > >    iii) Configure the lifetime of the key much longer
> > >
> > >I rather hoped it will be much shorter :)
> >
> > I think this issue comes from or depends on the weakness of Hash or PKI tech,
> > and traceback is not necessary success, so I think the lifetime, 
> actually days
> >   or week level, can be acceptable. I hope so but not nesessary.
>
>Untrue.
>
>
>---
>Tomasz Grabowski  (0-91)4494234
>Akademickie Centrum Informatyki
>mailto:[email protected]

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