- scalability
- supports 10's or 100's of PM's
- support multiple RADIUS servers
- robustness
- fault tolerant
I am a consultant for a couple of ISP's. They have purchased
Livingston equipment and are now facing this exact problem and are also
looking for a solution. After considering this for some time I have
devised a solution that I will likely be "hacking" into the RADIUS code. Now
I have developed this solution without actually looking at the RADIUS
code very closely, but I am sure it is implementable.
Specificially, this matter came up with an ISP that charges for connect
time by the hour and is now implementing "umlimited access" (as unlimited as
reasonably implementable - basically a bad term coined to mean not billed
hourly). It turns out that when billing hourly it was a don't care situation.
That is, if an account was logged in on 5 ports then that account gets
billed for the connect time for all 5 ports. Pretty simple, this model
did not necessary address the issues of identity on the 'net, etc but assumed
the identity as a billing entity only. Now with unlimited access, the situation
changes. Now for xxx $, the 14 year old kid and all his buddies collect
all there quarters and buy a single "umlimited" account. Now there is
a problem as 5 guys using 5 lines with access granted via a single userid,
with a business model that assumes the yearly fee per account is for a single
phone/modem/port.
It appears that billing by the hour per port has been a wonderfull artifical
or "psycological" barrier to this problem. Unfortunatly competitive pressures
result in new marketing strategies that result in horrendously difficult
technical issues to deal with.
Thus, for those ISP's in a "unlimited access" situation multiple simultaneous
session's control is mandatory if resaonable service is to be applied to all
customers.
Other situations of course apply where the ISP is not offering unlimited
usage but the acceptable use policy only permits one port per userid.
Second to all this is a matter of port management for selling multiple ports
for load balancing or MLPPP. How do you limit user X to only use 2 lines
instead of 4? You will probably see more on this from me later!
Anyhow, a proposed solution:
WARNING: this is a preliminary discussion and does not constitute a full
scale design.
First off, this solution has a basic assumptions which are sometimes
are overlooked.
- You are doing authentication with a RADIUS server.
Thus, the RADIUS server WILL know about all login's. It has to,
else the ackowledgement will never be sent to the PM allowing the
user on.
- You are doing accounting with a RADIUS server. This is a must. I look
at the fact that if you are an ISP and you aren't doing accounting
then you are a charity!
- The RADIUS accounting server see's ALL 'Acct-Status-Type = Stop'
reports from the PM. Think about, if you are not getting the stop
records, how are you actually accounting for an individuals connect
time.
One can use the model I have used with TACACS using wtmp files, that
if you have a login record, but no logout record, you can assume a
logout with the next login record for the port and vice versa. This
method is not accurate for situations where all your lines are not busy
all the time. Depending of the degree of "logout record" loss, those
sessions are sometimes forgotten about - a freebee for the user.
I still consider the case of any record loss a bad thing as you cannot
bill for your maximum potential.
- If you are running multiple RADIUS (authentication/accounting) on
multiple computers that they are UNIX based and all can share a NFS
mounted disk.
I don't need to hear about the security issues of NFS. There are things
you can do about this - and besides I beleive that the authentication
and accounting severs should be behind a firewall anyway!
It appears that much of the concern of this kind of control is ensuring
sycnronization of state data between NAS and the RADIUS servers. I have never
liked the fact that these two entities can get out of sync. This may be
partially to do with using a connectionless protocol like UDP aot TCP (but that
is another debate!).
Here is my proposal:
- Create a directory 'pm-users' in the UNIX filesystem that is shared via NFS
(or any other file sharing mechanism) by all servers.
- Modify RADIUS server for authentication functions, after correctly validating
the user (more on this later), to create (touch) a file of the form
NAS-PORT-USERID
where NAS = NAS id, PORT = the NAS port, USERID = the userid
in the directory 'pm-users'. This file need be only 0 bytes in size but tells
alot. From this single file, the following can be determined:
- login time (file modification date)
- what user is on what port
- what NAS the user is on
- what NAS port the user is on
The quantity of files here should be small and manageable. For 100 PM30's
that would be a maximum of 300 files. I would think that this would work
fine for up to approx 1000 ports (330 PM's). variations of this can be
applied here for larger scalability. ie use a directory for each NAS.
thus in a directory pm-users/NAS create files of the form
PORT-USERID
You get my point!
- Modify RADIUS server for accounting functions to remove the above mentioned
file upon receiving a stop record.
- The RADIUS authentication functions need to be modified to include the
appropriate algorithms for restricting access by userid. That is, reject
the authentication request if the user is already logged in on a NAS. Simply
put in pseudo code (shell notation):
if ( `ls pm-users/*userid` != "" ) then
userid is already logged in
endif
If the 'pm-users' directory show the port in use by another use, then clear
the file. In this case, the state information has gotten out of sync and
the PM is more authoritative.
- Somehow the RADIUS authentication or accounting server needs to determine
when a PM is rebooted or reset. Is anything sent up? I don't know, I don't
have any of my Livingston stuff online right now! If so, then use this
"boot" information as an indicator to clear all entries for that specific
NAS. for exmaple:
rm pm/users/NAS*
- External programs can be written to scan the 'pm-users' directory and act
on over use conditions. One example is that access is unlimited on a single
port as long as all lines are not all busy. When all lines are busy (easily
determined by checking the artifical port status as refelected in the
'pm-users' directory) then maximum connect time will be limited to 4 hours.
In this case the algorithm is simply:
periodically do the following (ie every 15 minutes)
determine if all lines are in use
ie if ( `ls pm-users | wc -l` = max # ports ) then
all lines are in use
endif
if all lines are in use then
- find oldest session that is greater than 4 hrs using timestamps of
files in pm-users directory.
- reset the users port on the designated NAS
Now a sensitive issue can occur here. That being the user actually selected
may actually logoff at the exact time of determination. This is not a real
issue, as if the line is reset at this point, one of the following is likely
true:
- modem is resetting itself and no new calls can come in anyway
- modem is reconnecting - approx 10-20 seconds for training
If the above process cannot complete in 10 seconds there is problem and
algorithm for doingthe search and destroy need be optimized.
There are some critical sections that need be handled here, except I haven't
thought this through yet to see if they really matter:
- same userid trying to be authenticated from different NAS's using
different RADIUS servers.
I am not sure if the RADIUS server single threads the authentication
requests as they are pulled off the socket (my HDD with the Radius
source is offline right now!). If the RADIUS server spawns a process
for each request then the matter of same userid on different ports
on same NAS on same RADIUS server applies as above for multiple
NAS's.
There is a race condition here, but I am sure a simply "universal"
locking mechanism could be used to single thread the write activity
in the directory.
- "slow" accounting server that needs the delete the file for a freed
up port which may prevent the port from being assigned or for that
matter even allow the user to login on another port even.
This could be the biggest problem in this implementation. On the
other hand if every thing is working fine there shouldn't be a
problem. It is actually quite amazing how there is such a strong
desire to keeps things working perfectly when there are underlying
problems impacting your ability to get anything done! An example
being the case where the RADIUS server is at the other side of
a WAN link to the PM. Really, if the WAN link is down or semi-
operational such that you can't get accounting information down it,
does it really matter if anyones is on the ports/ph ones - they are
not going anywhere either!
Well, those are my thoughts ( and just that ) on this matter so far.
Please don't flame me on any flaws or holes in this mechanism. I have only
thought of this as one potential solution and haven't done anything about
implementing it yet. I have only presented this here as I beleive there is
interest in this problem and I open this method to discussion.
I only subscribe to the pm-users-diegest, so I would appreciate a CC
on any responses so that I can see them as they happen.
In addition, if sufficient desire exsists I can setup a mailing list to take
this discussion to another forum to keep this issue out of the mainstream
portmaster-users/portmaster-radius flow. I have noticed that this issue gets
somewhat emotional at times.
-- Darren R Besler PO Box 2207 Stn Main Beehive Enterprises Winnipeg, Manitoba, Canada, R3C 3R5 Ph: 204-896-6103 Fax: 204-896-4168 Email: dbesler@beehive.mb.ca