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/
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
At 09:45 AM 10/29/2003, Alexander Mayrhofer wrote:
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?)
point taken, put on the "someday" priority -- I focus most of our effort on sanity now, see bellow.
- 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
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
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@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------
On Mon, 3 Nov 2003, Juha Heinanen wrote:
Jesus Rodriguez writes:
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?
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@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------
-
Alexander Mayrhofer -
Jesus Rodriguez -
Jiri Kuthan -
Juha Heinanen