Re: NO multiple logins !! Livingston won't listen
charley@esslink.com
Mon, 24 Jun 96 23:06:22 -0500
On Mon, 24 Jun 1996, Leo Savage <leo@esva.net> wrote:
>I'm not sure why I feel compelled to adress this thread. . .
>
>Limiting multiple logins is a feature of interest only, or at least
>primarily, to ISP's which offer unlimited access accounts (which is the
>topic for a whole other argument I DO NOT want to get involved in again!)
>ISP's who have connect time limits or who otherwise bill for excessive
>usage generally have no need for this feature. Generally speaking, that
>is the distinction between people who feel that it is important and people
>who don't care.
>
>Okay, given that, there are technical issues involved in supporting it
>that are non-trivial, especially in cross-platform code. To the point
>where I'm almost sorry I added it. The ESVAnet hack of Livingston radiusd
>was originally done for a completely different reason (I like our
>interpretation of DEFAULT much better). Carl Rigney described an approach
>to limiting multiple sessions that sounded easy enough to add, so I did,
>but the following technical issues are unresolved at present:
>
>1) Who is on is collected in memory by the radiusd that handles accounting
>records, so the same instance of radiusd must also approve the callers.
>This means that the forking model cannot be used, which places a limit on
>how busy radiusd can get and still answer queries in a timely manner.
>
>2) Due to reason (1), radiusd also cannot spend an excessive amount of
>time on any given caller. This makes it difficult or impossible to
>support external security devices.
>
>3) It is possible (likely, in ComOS 3.3.1) for the accounting "stop"
>record for a disconnected user to be delayed until after the caller has
>redialed and tried to log in again. This causes radiusd to think that the
>caller is still connected, and hence to disallow the "multiple" logon.
>One answer would be to sleep for some period of time to see if a "stop"
>record is received (a better alternative than an immediate refusal), but
>due to reason (2) this cannot be done.
>
>There are other minor shortcomings that I'll get to in a minute, but these
>are the main problems as I see it.
>
>The answer, or at least AN answer, is for radiusd to track current
>sessions in a shared memory segment or in a file instead of in memory.
>That way radiusd could use the forking model, and any given instance of
>radiusd could take as long as it needed to approve a caller. (I'm
>assuming that it doesn't matter if a caller times out while you're
>deciding to deny access.)
>
Boy, this is getting to be a pretty interesting subject..... I have myself asked
in the past about this problem with mutiple users as well. The problem is,
basically lets say X user gets an account, and gives it out to quite a few
people, enough to cause problems, such as the next paying customer gets a busy
tone. I have also tried the "static IP" approach, which did not work so well,
and was more of a problem than a solution... What I have not seen from anyone is
possibly something to act as a front end before radius. Maybe something that
would basically check a file to see if a person is already connected, of course
there would be problems with that, such as time delays and if that file was not
updated fast enough, a user can get disconnected because it thinks they are
still on..... Anyhow,, it doesn't seem so far fetched to do, I am not the
greatest at programming, but am in the process of trying this....
At least this way, it wouldn't be dependent on each portmaster, and runs off of
a main server, possibly even using pmwho to kick off and make a file with the
list of currently connected users, if the program see that the user is already
in another session, bounce them off.......
I think there are more ISP'S that are starting or already have run into the
problem of X user being connected in 20 sessions at the same time, sure if all
those sessions check for mail at the same time, they have got a problem, but can
still get onto the internet and use most of it... Imagine if all the end users
who rely on the ISP'S figured this out,,, I would bet someone would come up with
something pretty darn quick.......