Re: ESVA radius and Radius 2.0

Stephen Zedalis (tintype@exis.net)
Thu, 19 Dec 1996 08:49:50 -0500 (EST)

On Thu, 19 Dec 1996, Larry Vaden wrote:

> Why has Livingston not supported limiting simultaneous logins to date?

I would assume it is because Livingston RADIUS is stateless. Ie. It has
no idea at a particular point in time who is logged on. All it does is
send udp packets for particular events. Ie. Is this guy an authorized
user? Yes, he is. User Joe started a session at 0915 (logged only), User
Fred stopped a session at 0916 (logged) There is no database of current
users. That would introduce an extreme amount of complexity to radiusd.
Its not as simple as merely maintaining a online user table. What if
power is lost to the authorization server, the accounting server, or one
of the terminal servers? How can we be sure that those users are removed
from the user table? All this happens via udp where packets can get lost.
So some add and remove records could be lost. Establishing the connection
via tcp instead would introduce at least a 3 packet overhead for each
transaction. What about multiple terminal servers? Also there may be a
need for SOME accounts to allow multiple logins. So then you would have
to implement a query/update function for radius to periodically ask each
terminal server who is online to update its database independent of normal
RADIUS authentication. It CAN be done (see Merit Radius or ESVA Radius)
However, Merit radius can be very complex with its multiple realms, etc.
(not to mention more expensive) and ESVA may not be robust enough for a
huge ISP with tens of thousands of users and multiple POP's (nor was it
meant to be).

To be stable, accurate, and conform to the RADIUS RFC, Livingston has not
to this point supported the prevention of multiple logins. It has always
been in "the next version of RADIUS". I'm sure RADIUS 2.0 will be patched
to prevent them before Livingston comes out with it. Or you can look to
solutions like pmmon that effectively maintains its own user list while
doing a "show sessions" on each portmaster to query who is on. If it
finds a duplicate login it resets the port. (Hopefully it does this fast
enough to prevent someone accidentally being knocked off because the
last caller on that port was a duplicate login and just logged off a few
seconds before)