28 Oct
2003
28 Oct
'03
10:46 a.m.
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.
Thanks,
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
29 Oct
29 Oct
9:45 a.m.
On (28.10.03 10:46), Jiri Kuthan wrote:
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'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.
cheers
axelm
12:03 p.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
1:43 p.m.
Alexander Mayrhofer writes:
- 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.
i remember seeing an announcement of a new version of radiusclient that
supports more than one radius server.
-- juha
3 Nov
3 Nov
11:40 a.m.
On Tue, 28 Oct 2003, Jiri Kuthan wrote:
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.
Ser radius authentication works quite well. Radiusclient library has something
similar to redundancy that allows use more than one radius frontend with the
same backend (database, ldap, etc).
We are using Radiator as radius server and we just needed to make some
modifications in the dictionary files to make work SER and Radiator together.
I think authentication is ok and i only would like to see added a timestamp
attribute in the Start/Stop accounting records.
Saludos
JesusR.
-------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------
12:01 p.m.
On Mon, 3 Nov 2003, Juha Heinanen wrote:
Jesus Rodriguez writes:
Yes, sure. But, would be nice if the timestamp comes from SER in the
start/stop packets :)
Saludos
JesusR.
-------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------
I think authentication is ok and i only would
like to see added a timestamp
attribute in the Start/Stop accounting records.
can't you add the timestamp by radiator when it receives the accounting
messages?
7483
days inactive
7489
days old
6 comments
4 participants
participants (4)
-
Alexander Mayrhofer -
Jesus Rodriguez -
Jiri Kuthan -
Juha Heinanen