Re: Simultaneous Logins

Brian Moore (bem@cmc.net)
Mon, 3 Mar 1997 12:00:29 -0800 (PST)

>
>
> On Sun, 2 Mar 1997 owner-portmaster-radius-digest@livingston.com wrote:
> >
> > From: MegaZone <megazone@livingston.com>
> > Date: Sun, 2 Mar 1997 18:19:06 -0800 (PST)
> > Subject: Re: Simultaneous Logins (fwd)
> >
> > Once upon a time Livingston Portmaster shaped the electrons to say...
> > >Point me to one. Do not suggest to cry in mailing list. Do you have
> > >some on ftp.livingston.com?
> >
> > No we don't, and I don't bother tracking the myriad of scripts users
> > create.
> > You either ask in the portmaster-users list or go without.
> >
> > Or setup your billing to bill the people abusing the service for the
> > services they are using - which is the only solution I'll advocate.
> >
> > I don't believe in any of the 'scripting' or 'RADIUS' so-called solutions
> > out there and won't help with them.
> >
> > - -MZ
> > - --
>
> Dear MZ (Brian, isn't it?),

Nope, his Mom calls him Megazone, so that is his name.

> I tire of your repeated disdain for the very frequent requests for a
> multiple-login solution. The attitude evidenced in the above post
> crosses the line and borders on rude.

But he's right and explained why. RADIUS isn't set up to stop multiple logins.
You can certainly hack it yourself to try, but you get into dangerous
situations where you risk denying services to users. The prioritization of
authentication packets over accounting packets is a simple reason as to why
it's a Bad Thing. Yes, perhaps RADIUS should have a way of doing it, but the
standards don't have it. You're welcome to look at the standards yourself and
see if you can figure a way to add it without breaking things.

> The energy you expend rejecting the requests probably has far exceeded
> that required to solve the problem. I have, at length, concluded that a
> reasonable solution is not that hard and can be made reasonably reliable
> by being conservative. "Reasonable" is the key here, your myriad
> "what-ifs" not withstanding.

The problem isn't solvable without coming up with RADIUSng. (Which will be
about as effective as IPng, no doubt.)

> As I read the list, it appears that ISPs are a significant revenue stream
> for Livingston. You and I both know that your business depends on solving
> problems. Clearly ISPs are begging you to solve this problem. Quit
> telling them how to run their business and do it.

Megazone has repeatedly pointed people to programs that deal with this. It's
really not doable in RADIUS, and even a hackish 'log into all my portmasters
and find who is on, booting dual logins' is risky: what happens if a user is on
PM-1 when it's scanned, loses link, and just logs into PM-5 when it is scanned:
do you bounce him for what appears to be a dual login?

> Similarly, Livingston should be dealing with "ping-o-death" and
> IP-spoofing vulnerabilities. Did I understand that ComOS has no filter
> that restricts packets to the assigned IP? Is that really hard?

I wasn't aware that PM's were vulnerable to the ping-o-death. As for
IP-spoofing, there are numerous changes in the routing code I'd like to so.
For one, it would be nice if ComOS, upon issuing an IP would only recognize
packets from that IP (or subnet for the general case). I would also like to
see ComOS better handle what happens when it's asked to route to a dynamic IP
that is not in use, returning a 'no route to host' instead of passing things to
its default route and creating a neat ringing unless you filter it.

But Megazone doesn't write ComOS, so I don't pester him for it.