Subject: FW: AAAWG: Diameter vulnerability to connection depletion DoS attacks

From: <[email-masked]>
Date: Tue, 10 Jun 2003 16:41:00 +0300

Hi,

FYI: Here is a comment from AAA WG mailing list about client puzzles.

- Dan

-----Original Message-----
From: ext Floroiu John [mailto:[email-masked]]
Sent: 04 June, 2003 13:57
To: Avi Lior
Cc: 'David Mitton'; [email-masked]'
Subject: Re: [AAA-WG]: Diameter vulnerability to connection depletion
DoS attacks

Thanks everybody for your answers, I will merge my comments into this
reply.

> The second issue is about how much information is kept in the server during
> each transaction.  You can certainly design a protocol that minimize or even
> elliminates the need to keep any information in memory.  However, that comes
> at a price.  You either have to give up functionality, or have message
> bloat.

I perfectly agree with that. Myself, however I regarded Diameter primarly as an
authentication protocol and there are examples of protocols that require
participants neither to perform expensive computations nor to create state
unless the peer is known to be legitimate.

> For example, in AAA we belive that an intermediary AAA server should be able
> to detect a timeout and act on that timeout for each transaction.  Therefore
> it must as a minimum store each message, as well as an associated timer, and
> where it sent that message.  You can do away with this memory burden but
> then how would you meet this requirement?  You certainly can't store
> information in the message to solve this problem.

I agree with that, too: one cannot perform retransimissions based on the
information contained in a lost packet (and if the packet is not lost
then one doesn't need that information anyway). But on the other hand if
an AAA server retransimits forged requests, then this aggravates the
impact of any potential DoS attack.

As another message in this thread has suggested, the matter could be
delegated to the AAA front-end protocols (such as PANA).  However, in
the case of inter-domain roaming scenarios, for instance, when the
mobile users and the NASs do not share any pre-existent trust
relationship, such protocols cannot prevent forged authentication
requests from entering the AAA infrastructure. Cookies can only protect
against blind attacks.

Relevant to http://danforsberg.info:8080/pana-issues/issue15, client
puzzles are also ineffective because malicious nodes may pose as NASs
and perform computational DoS against legitimate nodes by proposing
"difficult" puzzles. Since there is no pre-existent trust relationship
between "pac" and "paa" puzzle proposals may only be authenticated using
asymmetric cryptography ([1]), which is however also a source of
computational DoS attacks.

Maybe the safest approach would be to provide a real stateless AAA
client operation and support more features (retransimissions, security
contexts, just to refer to those already mentioned in this context)
after the client has been successfully authenticated. Just an opinion...

John.

[1] T. Aura, P. Nikander, J. Leiwo - DoS-resistant Authentication with
Client Puzzles