Possible Solution for Double Checking Simultaneous-Use Behind Proxy Radius Servers Date: Thu, 15 Aug 2002 04:30:26 -0400

[Mike Walker]

We are authenticating users coming from NAS's on other networks via proxy
radius.  Our problem is the reliability of stop packets, many of which get
dropped for various reasons (thanks UDP).  The methods used to double-check
the accuracy of the data in the sessions table are designed for non-proxy
implementations (like finger and snmp).  Actually, the only option that will
work is "NasType ping", but that is about as inconsistent as it gets,
especially when certain NAS's start replying to pings from framed-addresses
within a few seconds after user disconnect - usually with latency 20 times
the usual dialup latency - possibly from a NAS reconfiguring its routing
table.  Plus you need 5000 IP Addresses in your Client clauses for every NAS
on every network.  After coming up with several hard to implement
out-of-the-box approaches, it finally hit me...

My idea is not fool proof, but in my opinion, with the homework I have done,
will yield about 95% accuracy.  Basically, the only data that truly
identifies the user is the username and calling-station-id.  The checking of
NAS Port and NAS Identifier doesn't seem to do the trick for those users who
drop and reconnect.  So, my solution involves two things:  an additional
column in the RADONLINE table for calling-station-id and a PreAuthHook
statement.  I am also working off the assumption that there can only be 1
username for 1 calling-station-id.  If this is true, then before the actual
authentication, a PreAuthHook could check the RADONLINE table for the
existence of the user and see if the calling-station-id is null or zero,
then if the user exists and the value calling-station-id is not null or
zero, delete the record if the calling-station-id in RADONLINE matches the
calling-station-id of the pending authentication.  If the calling-station-id
is null or zero, exit the subroutine.  Then the pending AuthBy clause does
its usual thing.

The only way this won't work is if the calling-station-id is either null or
zero.  However, parsing through our logs shows that over 92% of the logins
contain valid calling-station-id data.  I suspect some of the remaining 8%
are either caller-id blocking or telcos not giving it up.  If this approach
works about 95% of the time, it will stop 95% of the tech support calls for
hung radius sessions that need to be manually cleared.  This will also
negate the need for a cron job to search the sessions table for stale
records - this is particularly hard if only some of the NAS's or networks
give out the checkpoint packets.  For the caller-id blocking folks, tech
support will recommend removing the *67 or whatever.  No solution for the
slack telcos, but I suspect there are only a few of those.

Please let me know if I am missing something major that will crush my idea.
If someone thinks its valuable, and has the Perl expertise to contribute,
please post the PreAuthHook subroutine that would make this happen.  If you
think you can take my idea and pretend its yours, and you think you can make
it better, I release all rights to it.  ;-)

Also, if this is a good idea, could this or similar functionality be added
as a feature in a future release?  There just does not seem to be a another
alternative for the wholesale crowd.

Thanks!!!


Mike Walker
Director of Network Operations
Network Operations Center
US Express.net, Inc.
800-695-3636 x130
noc at usexpress.net

-------------------------------------------------------

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
Phone +61 3 9598-0985                       Fax   +61 3 9598-0955

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc 
on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X etc etc

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