Re: Problems with implementation - DoS attacks possible

At 20:14 03/01/21 +0100, you wrote:
>On Tue, 21 Jan 2003, Naohiro Fukuda wrote:
>
>[...]
>
> > (2) The collector handles that if the ICMP traceback message in the buffer-1
> >      is not valid as a result of the authentication, flushing the message
> >      or move it to another buffer-2, second.
> >
> > (3) Finally, the buffer-1 keeps only valid ICMP traceback message.
>
>But the problem remains. The collector can't authenticate the message
>right after the message is retrived. It must *wait* for the proper key to
>be disclosured by the remote router/host/whatever. It will take minutes,
>hours or maybe days(?).
>
>So I think your proposition isn't quite suitable for this.

Oh, I understood.

The draft-ietf-itrace-03.txt says;

2.8 Authentication data:
[...] "The current key MUST NOT be included in this disclosure.

2.8.3 Key Disclosure (TAG=0x0E)
[...] The primary content of the Key Disclosure element consists of a key
used to authenticate previous TRACEBACK messages and the starting
and ending times between which that key was used. [...]

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.

But, if the disclosure key comes first or same-time don't you think it 
becomes better?



> >
> > I think the problem is how to keep the speed of authentication.
>
>Yes, but collector *can't* speed up the authentication process. Look
>above.
>
>
> >    i)   Increase the size of buffer-1
>
>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.

Thinking about CRL check, 30 seconds? will be required?


> >    ii)  Accelarate the process of authentication
>
>But in proposed authentication scheme the process can't be accelerated by
>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.



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