(RADIATOR) Possible Solution for Double Checking Simultaneous-Use Behind Proxy

[Hugh Irvine]

Hello Mike -

What you describe below has indeed already been implemented by various 
Radiator customers, and it will work modulo the caveats you describe. 
You may find mentions on the archive site from a couple of years ago.

And I don't think you will need any hook programming - just add a couple 
of columns to the example database schema and add the corresponding 
queries derived from the defaults in the manual.

regards

Hugh


>
> 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.
>
>
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

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