Date: Mon, 17 Jan 2000 14:03:07 +0100 (MET) From: Marcin Cieslak <saper@system.pl> To: Brian Somers <brian@Awfulhak.org> Cc: freebsd-net@FreeBSD.org Subject: Re: RADIUS support in ppp(8) Message-ID: <Pine.GSO.4.20.0001171338250.3541-100000@tricord.system.pl> In-Reply-To: <200001171109.LAA17525@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Jan 2000, Brian Somers wrote:
I see that RADIUS accounting information:
* user port
* user name
* throughput stats
* IP address
* disconnection reason
* (you name it :)
can be collected from various sources.
What about adding a small (struct radacct) which will be collecting them
for accounting purposes? If IPCP layer sets an IP address, it
updates it, if MP opens another link, it sets some data there
(namely data link id), when authentication is completed (RADIUS or not),
PAP/CHAP updates authentication data.
> This is a problem. In MP mode, there's more than one port. At the
> moment, ppp doesn't mention a port unless there's a tty involved, and
> if there is, uses ttyslot() to get a number.
Well, actually, an already present code uses ttyslot. That's fine
for now, perhaps an option to "set device" or something will
do for other "ports".
> > 5. Which variable to use as a best unique session
> > identifier (peerid is apparently set only for MP sessions)?
>
> Dunno, maybe the current time with our pid appended, or maybe even
> just our pid ?
I think that PID is nice, I usually use it to grep my logs
to identify a session.
It seems that RADIUS is quite well suited for MP sessions.
I am reading Ascend RADIUS documentation and their added MP and
MP+ (their BACP) support for RADIUS. In general, there is
a "multi session id" -> it identifies a "bundle", and a
"session id" -> for datalink. Along with "link count", it gives
a pretty overview what's going on with the MP session. RFC2139
point 5.12 has a nice example of use.
The downside is that we have to collect all stats ("struct radacct"
mentioned above at the datalink level, no bundle - and still
some bundle-level data (like IP address or User-Name) have to be
be present in the accounting data sent to server.
Yet another advantage of separate accounting structure is the
implementation of RADIUS checkpointing -> ppp daemon would
dump it's current session data at a given interval in
the accounting format to RADIUS server, and one would generate
a nice stats about the modem sessions currently open, etc. -
you name it:)
I think that thoroughput struct can be extended and incorporated
here (for example we have octets in/out but we don't have
packets in/out).
Few things TODO after my accounting code will be at least publishable:
1. Support more attributes, including some proprietary ones,
like DHCP server setting, NETBIOS servers, etc.
2. Carefully add some FreeBSD-specific attributes of ppp.conf
(only if really necessary)
The goal - please comment on it - would be to be able to completely
configure ppp(8) with RADIUS. ppp.conf already has a notion of "label",
close to the Ascend RADIUS pseudo-user concept.
And finally a note about limiting the access to one/few sessions:
there is no easy solution for that. radiusd-cistron (or FreeRADIUS)
people use a separate script analyzing accounting data and/or
grabbing SNMP stats from NAS.
Oh, well, SNMP... perhaps we can extend our "radacct" infrastructure
to report also to SNMP?
This is because I've had a really wonderful experience running BSD boxen
for analog dial-in support, and I don't really need another out-of-the-box
commercial solution. Anyone found a PRI/E1 card supported on our system? :)
--
<< Marcin Cieslak // saper@system.pl >>
-----------------------------------------------------------------
SYSTEM Internet Provider http://www.system.pl
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.20.0001171338250.3541-100000>