Re: ESVA radius and Radius 2.0
Larry Vaden (vaden@texoma.net)
Thu, 19 Dec 1996 08:07:35 -0600
At 08:49 AM 12/19/96 -0500, Stephen Zedalis wrote:
>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).
OK, so 21 lines later, back to my original question ... keeping in mind
that this is one of an ISP's major sources of lost revenue. BTW, limiting
here is key, not PREVENTING.
>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)
We use pmmon. We have to in order to prevent one of our valuable resources
from being stolen. Yes, it has all the problems you mentioned, including
irritating the hell out of bona fide customers in bona fide situations, and
one you omitted -- ts passwords are transmitted in clear text every n minutes!
Sincerely,
Larry Vaden, founder and CEO
Internet Texoma, Inc.
bringing the real Internet to rural Texomaland