RADIUS Disconnect support

[Alan DeKok]

Peter Nixon wrote:
> 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
> }

  That could be replaced with rlm_perl, I think.  That would remove most
of the startup overhead of forking a separate program & starting perl.

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

  That's not hard.

> 2) Query the radacct table to find disconnect attributes based on a supplied 
> attributes (username, callingstationid etc)

  That's more complicated.  I'll say why later.

> 3) Send disconnect packet(s) to NAS with a shared secret and return status

  That's not hard.

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

  Yes.

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

  As an admin, it's easier for me to send disconnect packets to a RADIUS
server than try to figure out which NAS the user is on.  But that's just
my $0.02.

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

  Allowing home servers to disconnect people is horrid.  Have you read
the text in the RFCs's for how to handle trust?  i.e. Is this home
server really supposed to be sending a disconnect for that user?  Or how
 to handle the whole reverse proxy chain?  It's disgusting, and almost
impossible to do right.

  If FreeRADIUS is the server the NAS talks to, disconnect is awkward,
but not impossible.  If it's a proxying server, disconnect is horrid.

  I have some ideas to make it easier, but they require all RADIUS
servers to implement the same updated algorithm.  If that's OK, we can
move ahead.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog