Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) RADIUS - Blocking multiple logins by same user (fwd)
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.
My standard rant on this:
---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>
Follow-Ups: