Subject: RE: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks

From: Avi Lior <[email-masked]>
Date: Fri, 6 Jun 2003 10:16:31 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, June 04, 2003 6:57 AM
> 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.

Hmmmm Diameter is an authentication protocol but that doesn't mean that it
can't be sophisticated to address real world problems.  Diameter's
complexity, comes from years of experience in the real world.  You want
something simpler, stick with RADIUS.

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

Those laws of physics get in the way again.

>But on the other hand if an AAA server retransimits 
> forged requests, then this aggravates the impact of any 
> potential DoS attack.

So you are stuck between a rock and a hard place. If you have any ideas
about how to fix this we would love to hear them.

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

This is exactly what is done.  Session state is only established after we
validate the client. 

What we were talking about was short lived communication state that is
required in order to provide capabilities such as retransmission at the
intermediary nodes, and security context for establishing the authenticity
of a client, which may require more then one Authentication transcation.

You can reduce your short live communication state by giving up on these
"features".  But do you want to?
 
> John.
> 
> 
> [1] T. Aura, P. Nikander, J. Leiwo - DoS-resistant 
> Authentication with Client Puzzles
>

---

From: Harold Hunt <[email-masked]>
Date: Thu, 12 Jun 2003 04:07:56 -0700 (PDT)

Hello,

I have a query regarding mobile ip registation and diameter server.How does the mobile node register itself in the home network? Though the registration request(AMR) in the foreign network reaches the Home Server via Foreign Server and Foreign Agent, nothing is mentioned about the start of a session in the home network. Through the home agent perhaps ??

regards,

Harold

---------------------------------
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).