Thanks,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yohannes Aries Sulistyono email : aries@idola.net.id
Internet Service http://www.idola.net.id
PT Aplikanusa Lintasarta http://www.lintasarta.co.id
Menara Thamrin 12th fl. ph. +62-21-2302345
Jl. MH Thamrin kav 3 fax. +62-21-2303883
JAKARTA 10340
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Tue, 5 Aug 1997, MegaZone wrote:
> Once upon a time Yohannes A Sulistyono shaped the electrons to say...
> >What is the radius that supports session limit?
>
> Don't call it session limit - there is something else entirely that is
> already called that (limits the session time) so it'll confuse the issue.
>
> Concurrent login preventin is *not* possible to do cleanly in RADIUS alone -
> period. The protocol does not handle it. There are some hacks that work
> with varying degrees of success, but all have failure states. IEA's
> RadiusNT, Merit RADIUS, and ESVA RADIUS all have similar ways to do it I
> believe.
>
> Livingston's next generation server, which is a few months out yet, does
> it using an external SNMP check. This avoids the racew conditions inherent
> in the RADIUS protocol that all other systems to date suffer from.
>
> Here's a little rant I wrote on this a while back.
> ---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 the 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
>
>