Need help

[Frank Cusack]

On January 16, 2007 4:35:52 PM +0200 Valts Mazurs <valts at bsdradius.org> 
wrote:
> On Mon, 15 Jan 2007 09:33:29 -0800
> Frank Cusack <fcusack at fcusack.com> wrote:
>
>> On January 15, 2007 4:24:52 PM +0200 Valts Mazurs <valts at bsdradius.org>
>> wrote:
>> > What I mean is that I would like to process all authorization requests
>> > before accounting requests. That means if there are any auth requests
>> > in queue, working thread takes the youngest auth request. The logic is
>> > that it is more reasonable to give answer to the youngest auth request
>> > and deliver the answer in time. Older auth requests might be already
>> > unworthy and there is no point of processing them.
>>
>> That's a pretty bad method.  Under a dos attack, where dos traffic
>> is substantially greater than good traffic, real auths will tend
>> to get dropped in favor of processing attack auths.  It's better
>> to process them in order, short-circuiting the hard work by testing the
>> age of the request before going on to do any work, including sending
>> a response at all.  You could even set up a new queue every second
>> and simply drop all requests older than 3s without even looking at
>> the timestamps on them.  (Although you'd probably want to use 12s
>> as the cutoff, to allow for retransmission.  That way the age of
>> the packet is established from the first transmission.)
>
> In my implementation requests from unauthorized clients (as in
> FreeRADIUS - whose IP address is not found in clients.conf) are not put
> into the queue at all. I decided to ignore them completely. It seems
> safer for DOS attackers. But anyway... if there are 1'000'000 zombed
> windows pc's attacking the site, nothing can be done in RADIUS server
> software to prevent it.

That has nothing to do with what I'm talking about.  I am only talking
about requests that get queued for processing, not requests from
unauthorized clients.  I thought that was obvious.

On January 16, 2007 5:54:03 PM +0200 Valts Mazurs <valts at bsdradius.org> 
wrote:
> On Tue, 16 Jan 2007 15:50:28 +0100
> Alan DeKok <aland at deployingradius.com> wrote:
>
>> Valts Mazurs wrote:
>>
>> > In my implementation requests from unauthorized clients (as in
>> > FreeRADIUS - whose IP address is not found in clients.conf) are not put
>> > into the queue at all. I decided to ignore them completely.
>>
>>   That's what the RFC's say, because it's a good idea.  But look at the
>> following scenario, which actually happened in a FreeRADIUS installation.
>>
>>   Something went wrong in a customer site, and they continually tried to
>> login.  As soon as they logged in, they logged off again.  The result
>> was a DoS from a *known* client.
>
> I haven't had such scenario yet :)

Ah, since you haven't experienced it, you don't have enough forward
vision to handle it?  Sounds like some great software you have there.

Sorry, I don't really mean to be so caustic, but I hope it does make
my point.

>>   Using a FILO queue means that it's likely that most of the "new"
>> requests are from the broken user, so *good* users get blocked.  A FIFO
>> queue isn't a whole lot better, but FreeRADIUS also limits the queue
>> size.  So the bad user is more likely to get blocked than good users,
>> and if users wait long enough, they get on the net.
>
> Queue size is limited also in my implementation. However I don't see
> clear evidence that FIFO is definately better than FILO. In both cases
> there is lot of garbage between "normal" auth requests, and that garbage
> has to be processed. The server anyway will be busy to get those
> requests done. It seems for me that it is a greater chance that "normal"
> request will be answered in time if it is taken from the fresh ones.

It is clear (seems obvious to me) that answering requests in order is
the best approach.  If you're so busy that you are dropping requests
for sitting on the queue too long, handling the first request makes
you handle that much more retransmission traffic, and pushes old
requests into the bin thus causing the client to present a new request,
again increasing the load.

Handling the oldest packet STILL gives you the chance to handle that
newer packet even under load.

This is pretty well understood in the network -- are you aware of any
routers that deliver packets out of order when output queues get busy?
(Sometimes they do, but under priority criteria, not FILO.)  That would
be a disaster.

-frank