On January 16, 2007 4:35:52 PM +0200 Valts Mazurs <valts@bsdradius.org> wrote:
On Mon, 15 Jan 2007 09:33:29 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
On January 15, 2007 4:24:52 PM +0200 Valts Mazurs <valts@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@bsdradius.org> wrote:
On Tue, 16 Jan 2007 15:50:28 +0100 Alan DeKok <aland@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