(RADIATOR) Tarpitting agressive users

[Robert Blayzor]

Dave Kitabjian wrote:
> The first thing to consider is whether the NAS will be doing the
> tarpitting or Radiator. Since RADIUS is UDP, if Radiator waits too long
> to send a reply, the NAS will simply send a reject or go to a backup
> Radiator box. In essence, you would be tarpitting the NAS as much as the
> user.

Not really.  I'm saying inspect the request for user at realm and keep 
track of it, then reply to the NAS immediately with a NAK.  The idea is 
to keep it from creating endless amounts of accounting requests.... 
authorization requests use almost no time, however, millions of SQL 
INSERT records gobble up tons of resources.

> However, if you have a long enough failover threshold on the NAS,
> tarpitting via Radiator will work fine.

I don't want to cause a failover or just ignore the request, I want to 
NAK it immediately.

> I'd be surprised if NASes offer any type of explicit "tarpitting"
> feature, but it might be nice :) If there is such a feature, I'd love to
> know.

Hugh suggested this but I've yet to see a NAS that will tarpit based on 
attributes received or specific requests.

> There may also be clever, inadvertent ways of tarpitting the user using
> some clever choice of RADIUS Reply Items. What if, eg, we send him back
> some sort of Filter-Id or some other attribute that makes him feel like
> he's connected, but nothing works. Other choices might include a
> black-hole Framed-Route or Framed-Address. Thoughts?

That won't work really.  The problem we have is the client IS 
connecting, but then hanging up immediately, then reauthing.  So even if 
we give him a bogus IP address or a filter, it will probably do the same 
thing.

-Robert

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.