RADIUS Disconnect support

Peter Nixon listuser at peternixon.net
Mon Jan 22 23:30:01 CET 2007


Hi Guys

I have been playing with (read: using in production) RADIUS disconnect 
support and I have a few ideas about how we can/should integrate it into 
FreeRADIUS server which I thought I would share with you all for your 
comments.

Firstly let me explain how I am using it. I have the following defined:

exec radsqlkill {
   wait = yes
   program = "/usr/local/bin/radsqlkill.pl %{Calling-Station-Id}"
   shell_escape = yes
   output = none
   packet_type = Access-Request
}
authorize {
   radsqlkill 
}

Now, radsqlkill.pl is designed to kill any active sessions with a Disconnect 
packet based on info from the radacct table. It can be provided with a 
username, or in my case Calling-Station-Id.

Basically this lets me do simultaneous use limiting but instead of rejecting 
the second login it disconnects the first and allows the second.

I think that this functionality and more needs to be rolled into radiusd. 
Basically we need to be able to do the following things:

1) Receive a disconnect packet on port 1700 and check a shared secret (New 
listen type in radiusd.conf)
2) Query the radacct table to find disconnect attributes based on a supplied 
attributes (username, callingstationid etc)
3) Send disconnect packet(s) to NAS with a shared secret and return status

Now the shared secret in 1) is different from the shared secret in 3). They 
are both NEW config options and need to be saved somewhere. I think to keep 
things simple 1) should be an additional option in each realm in proxy.conf 
(as Disconnect senders will _mostly_ correspond with home servers) and 3) 
should be an additional option in each client in clients.conf (as Disconnect 
receivers will _mostly_ correspond with client NAS)

It is technically possible that we would want to allow disconnect packets 
from non home servers, and send them to NAS which are not clients (think 
where you have chained RADIUS proxies) but I think it will make things 
unnecessary complicated. What do others think?

I think the 3 steps I have listed above will allow everyone to be able to do 
what they want with Disconnect packets. Basically in the situation where 
radius is acting as a proxy and you want to allow a home server to 
disconnect a user on a NAS client you will need all 3 steps (in order). To 
do what I am doing above with my perl script you will only need steps 2) and 
3). People who want to generate disconnect attributes from arbitrary input 
(a script or custom module) will simply use 3).

In all cases the module should look up the appropriate shared secret from the 
NAS table or clients.conf.

Does anyone have anything to add to this? I plan to start implimenting this 
as I have time as my perl script causes a 500ms Authentication delay (mostly 
due to perl startup) which I would like to get rid of :-)

Cheers
-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20070123/62e525dd/attachment.pgp>


More information about the Freeradius-Devel mailing list