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

From: Avi Lior <[email-masked]>
Date: Tue, 3 Jun 2003 10:29:38 -0400

Hi,

It seems to me that you are talking about two issues relating to DoS.  One
is a TCP connection attack, the other is a depletion of resources due to the
information that is stored by the AAA server.

The first issue is a TCP issue and not a AAA issue.  A Server can not tell
what the IP address is until the socket is established.  Therefore any TCP
based server is suceptible to this attack.  Therefore, you have to use
something like a firewall to protect against that type of attack.

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.

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.

There are other examples such as above relating to security contexts etc.. 

To support the type of systems we want, I think its inevitable that we keep
transaction state at each AAA server.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: June 3, 2003 4:56 AM
> To: David Mitton; [email-masked]
> Subject: Re: [AAA-WG]: Diameter vulnerability to connection 
> depletion DoS attacks
> 
> 
> David,
> 
> Thanks for the reply!
> 
> I actually used the term "connection depletion" in a more 
> general context, it is my fault for not being more specific. 
> I didn't necessarily refer to TCP related connection 
> depletion attacks (I fully agree with your comment regarding 
> "connections vs. sessions"), but to whatever requires a state 
> to be maintained at a stage when the client hasn't been yet 
> authenticated. And this is demonstrated throughout section 
> 8.1 by the presence of state "Pending" in the client's state 
> machine (both stateless and stateful). 
> 
> More comments inline...
> 
> [...]
> > >The connection depletion problem is even more general because it 
> > >ultimately affects all AAA agents located along the path 
> between an 
> > >AAA client and an AAA server. The reason is that all 
> intervening AAA 
> > >agents (even relay agents) are required to match the AAA answers 
> > >against AAA requests (draft-ietf-aaa-diameter-12.txt 
> section 6.2.2).
> > >
> > >Since no solution is provided to this problem in the 
> current Diameter 
> > >specification, here is the one I suggest.
> > 
> > You have overlooked the transport method as described.
> 
> (Pls. also see my comment above). This assertion regarding 
> the AAA agents was justified in particular by the fact that 
> the hop-by-hop identifier (on the incoming TCP connection) 
> must be stored for each request that is forwarded, and 
> restored in the corresponding answer.
> 
> > >For AAA clients, the solution would be to create a AAA 
> session only 
> > >as result to receiving an (positive) AAA answer.
> > 
> > The AAA client still must hold the context of any AAA 
> attempt, or it 
> > won't
> > know what to do with the response when it receives it.  The request 
> > will///must be attempted via a real resource, it that 
> resource will be held 
> > during the resolution of this request.  For example a NAS 
> has a port.  An 
> > 802.1x client has a virtual or physical port.
> 
> This kind of information is what the AAA client must append 
> to request and the AAA server must echo back in the answer, 
> see first bullet below.
> 
> > >Additionaly,
> > >* the AAA server must include in the answer all those attributes
> > >  specified in the request the AAA client requires in order to
> > >  consistently setup the AAA session;
> > 
> > huh?  too vague
> 
> Well, this really depends on the application. The NAS port 
> you mentioned above is one example. In Mobile IP for instance 
> it may be the care-of address. The Session-Id, App-Id, Origin 
> Host/Realm, Destination host/Realm are also part of the 
> context but these will be included anyway.
> 
> > >* the AAA client must compute a hash over those fields 
> contained in 
> > >the
> > >  request that uniquely and consistently identify a 
> session and a local
> > >  timestamp, using a local key. The hash must be appended 
> to the request
> > >  and the AAA server is required to echo the hash along 
> with the answer.
> > >(see also "Stateless connections", T. Aura, P. Nikander, 
> ICIS 1997).
> > 
> > This is beginning to sound like a RADIUS authenticator.
> 
> Possibly, I am not aware about how Radius authenticators are 
> computed. This technique is however widely spread. JFK for 
> instance also uses it and the authors of the above mentioned 
> paper proposed it to be extended to ISAKMP as well (ISAKMP 
> doen't use it though, and this is the reason why some people 
> consider it "harmful").
> 
> > All said, any AAA client or like implementation will have a 
> finite set 
> > or
> > resources and, yes, they can be exhausted.  This is a real world 
> > implementation concern, but I'm not sure that's a wire 
> protocol issue, but 
> > more of a memory size and admission rate control issue.
> >
> > Wireless access points have limits on the number of associated 
> > stations
> > that would have to be factored into any robust 
> implementation.  The AID 
> > table is so large, and there are errors for too busy or 
> resources exceeded.
>  
> I agree there might be physical limitations and I am not 
> aware how different wireless technologies allocate "channels" 
> or "ports" (and especially whether they are bound to the MAC 
> address, for instance). The problem as I see it, however, is 
> that one won't be confronted with thousands of attackers 
> trying to attach to an access point, but with only one, that 
> uses one physical access port but injects thousands of faked 
> authentication requests (possibly spoofing MAC and IP addresses) 
> 
> > I'm not sure I'm convinced there is a problem here to be 
> solved at the
> > protocol level.
> 
> Myself I would incline to design authentication protocols as 
> robust as possible and ensure that at least all currently 
> known threats are somehow addressed. Anyway, thanks a lot for 
> your comments.
> 
> John.
>

---

From: [email-masked] (Floroiu John)
Date: Wed, 4 Jun 2003 12:57:03 +0200

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

> at a price.  You either have to give up functionality, or have message

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.

> 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