Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ASCEND) RADIUS - Blocking multiple logins by same user (fwd)

On Sat, 9 Aug 1997, MegaZone wrote:

> Once upon a time RG shaped the electrons to say...
> >If you are using 1 authentication server, you may consider 
> >building a hash table that RADIUS will build upon authenticating,
> >and checks the table to see if the login exists.  If so, it will 
> >not proceed with the login.
> 

I never said it would work....nor have I seen it work...but I have been told by people they have done that sucessfully.

We are accomplishing our goals buy finding the multiples, disabling them and dropping them, but we would simply like to prevent it from happening....

Rob

> ---cut---
> RADIUS is NOT good at simultaneous user restrictions - at the protocol level.
> 
> ALL of the RADIUS servers that attempt it have major failure states.  This
> is unavoidable.  RADIUS was *deliberately* designed to *not* be a resource
> management protocol.  It was designed explicitly to be good at authorization
> and accounting.  
> 
> Issues:
> RADIUS auth does NOT have ack packets from the NAS, nor does it have ANY way
> of knowing the user has logged out.
> 
> Only RADIUS accounting says that a user logged in or logged out on the NAS.
> That means you have to weld both servers together, when the protocol was
> designed not to need this.
> 
> And even then it isn't good enough.  RADIUS accounting packets have a 
> completely different - lower - priority than auth on all the NASes I know of.
> That means the notification that someone logged out may lag for several
> *minutes*, possibly quite a few, as retries are not as agressive.  Acct was
> written to NOT be time sensitive - to get the info there, eventually.
> 
> So there is a VERY common state where a user logs off, or is dropped, turns
> around to log back in - and RADIUS thinks they are still in!  So it denies 
> them.
> 
> If you offer ISDN connections this is *easy* - ISDN can take less than a 
> second to connect.  Even if we used auth packets, they can take up to 30
> seconds to get through.  
> 
> And what if the NAS hard crashes?  There is no provision in RADIUS for
> keep alives - and quite deliberately so.  They are not needed for what the
> protocol is designed to do.  If the NAS crashes uses will be dumped, and the
> server receives no notice of this.  So ALL of them will be denied when they
> dial into another NAS to reconnect.
> 
> 
> And there are more issues.  This is just with one server - try coordinating
> multiple servers for fallback.
> 
> People don't seem to understand these issues, so they keep asking the 
> protocol to do things it was deliberately designed NOT to do.
> 
> ESVA RADIUS has simultaneous limits - and you can only run ONE server to
> use it.  Even then all of the above failure states can, and will, bite you.
> 
> Merit RADIUS is a more robust, yet still doesn't adress most of issues.
> 
> RADIUSNT also has major failure states.
> 
> 
> This has come up in the IETF WG several times and the basic agreement is 
> there needs to be another protocol to handle resource management - RADIUS is
> not suited to it and should not be kludged to do it.
> 
> No one, as of yet, has seriously pursued forming another WG to address this.
> ---cut---
> 
> -MZ
> --
> Livingston Enterprises - Chair, Department of Interstitial Affairs
> Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com
> For support requests: support@livingston.com  <http://www.livingston.com/> 
> Snail mail: 4464 Willow Road, Pleasanton, CA 94588
> 
> ++ Ascend Users Mailing List ++
> To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
> To get FAQ'd:	<http://www.nealis.net/ascend/faq>
> 

++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>
References: