Need help

[Valts Mazurs]

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

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

>   Again, your ideas are interesting, but not realistic.  Many of the
> FreeRADIUS developers have been working with RADIUS for over a decade
> (nearly 15 years for some), and there are often good reasons why
> "optimizations" are not done.

I don't push anyone to use these optimizations. This is just how my
implementation works.
Btw, BSDRadius is not "ready" yet. It has to survive some serious tests
before I can call it BSDRadius 1.0

I really appreciate your experience and critics. But there are real
business requirements and needs why I have made such decisions. The
time will show if I am totally wrong or not :)

Valts.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20070116/42115409/attachment.pgp>