29 Oct
2003
29 Oct
'03
6:03 a.m.
At 09:45 AM 10/29/2003, Alexander Mayrhofer wrote:
On (28.10.03 10:46), Jiri Kuthan wrote:
point taken, put on the "someday" priority -- I focus most of our
effort on sanity now, see bellow.
Unfortunately, there is now no standard for use
of RADIUS along
with SIP. SER users leveraging the combination of these two
technologies are left with implementation of expired internet
drafts. There are some chances that the IETF community revitalizes
the document.
Thus, I would appreciate hearing if any of the active RADIUS/SIP/SER
users have had any issues with the RADIUS authentication in SER,
which is based on draft-sterman-aaa-sip.
Jiri,
as i told you in person on the VON, the module is quite useable at the
moment (and in production here), with the following issues:
- the readiusclient library which the module is using does not support
vendor-specific attributes, therefore you have to redefine existing
attribute space rather than defining new ones (this is what the draft
does). A revamp of the module should probably switch to a different
backend library (maybe there's something in the freeradius package?) - the module lacks failover to a secondary radius
server. failover seems
quite straightforward to implement for authentication, which is my major
concern, so i'd appreciate seeing that in the module. (We didn't have
problems with that yet because of the stability of our radius server,
but the day will come for sure ;). It may be more difficult for
accounting, but i'm fine with SQL accounting at the moment.
- I'd love to see my radius-alias-patch in the upstream sources. That's
more of a personal request, because it would save me lot of
backporting when switching to a new release. I'd appreciate to hear if
someone considers that stuff useful or even dares to use it ;)
I hope all of that will be addressed by changes we are planning. The idea
is to introduce RADIUS (and LDAP too) as database drivers. The drivers
would support fail-over and could be used for maintenance of the alias
database (that would solve also the problem with aliases, that don't
appear in in-memory databases before a user registers).
That's all a long-term effort which will not complete this year (guesstimate:
February).
(btw ad long-term efforts: the same for your favorite request, variables.
We'ld love to have them, preparation work for them already began. As
that is a big change, I plan to spend quite some time with it to keep it
sane.)
I'd volunteer to help on revitalizing the sterman
draft. SIP/SER/RADIUS
might have become a much more widespread solution over the last few
months, so there may be more attention at this time.
I will see if I can get you involved somehow.
-jiri