Jiri,
Our implementation does not use RADIUS. I am a long time RADIUS user for my ISP. It did not seem to be a good fit for us.
I will explain (skipping many of the details)...
We use a feedback loop. We set the group flag for the customer, For example "local", "cont_us", "sip". We check to see if the customer is in one of these groups before routing the call. If the customer attempts a "cont_us" (continental USA) call, and they do not belong to the "cont_us" group, we simply redirect the SIP connection to a recording that tells them their account needs attention.
By default, the customer does NOT belong to ANY groups. Our backend processing constantly evaluates group membership, and if It is deemed appropriate, the customer is placed in or removed from groups.
The grp table is updated (via serctl now) at these times :
1) Just after they complete a call. 2) At the end of the month. 3) During an audit.
I know that many use RADIUS, and it seems to work for them. It seemed like an added complexity that wasn't necessary for us.
So what this means is that when a call is placed we can authenticate quickly by checking the group membership. Then, after the call (when we have more time to think about it) we authenticate the next call.
It is our intention to relax the SER cache, and make all REGISTRATIONs hit the database (rather than internal cache). We will then be able to run multiple SER servers sharing a common database.
It has been pointed out that the database is a single point of failure, But, I can live with that. We will use replication and keep a hot standby For the inevitable database failure (although, I have been running some applications for over a year without a database failure).
---greg
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jiri Kuthan Sent: Thursday, August 07, 2003 12:48 PM To: serusers@lists.iptel.org Subject: [Serusers] Fwd: Re: AW: AW: [Sipping] FYI: RADIUS & SIP
Dear SER users,
I would like to collect feedback on use of RADIUS with SIP.
There is a concern in the IETF that RADIUS is not good enough for accounting due to its lack of reliability. On the other hand, use of RADIUS for us has been one of the most frequently asked SER features.
Can people with hands on real deployments share their experience with me? I'm interested in aspects like how the missing reliability has been stressing your operation, how much they are interested in fixing it, and what kind of fixes they would welcoyme (transition to Diameter? adding fail-over capabilities?)
-Jiri
There is a believe in the IETF that lack of reliability in RADIUS determines this work to be dropped. (Authentication is a different story, though.)
The point of this particular discussion is to understand whether specification of RADIUS transport behavior might be helpful in that regard, or whether we've have to go further (such as
specifying failover
behavior).
Reading RFC 2865, one of the reasons that RADIUS was not
made to run over
TCP in the first place was that it was desired that failover
occur in a
timeframe prior to connection failure. RFC 3539 handles
this issue by
defining application-layer timers and heartbeats that allow the AAA application to re-send an accounting packet over another
connection before
tearing down a suspect one.
Via the heartbeat mechanism, the AAA client can determine whether the issue is due to its immediate connection, or something downstream. Failover only occurs if the immediate connection is found to
be suspect,
so failover occurs on a hop-by-hop basis.
RFC 3539 cannot be applied to the RADIUS protocol as it
stands because
RADIUS does not support a heartbeat. As a result, a RADIUS
client can
failover even where its immediate proxy is healthy, because
of a problem
on a downstream RADIUS server. Since RADIUS failover is typically end-to-end, there may be no failover in proxies, even if a server is not responding to requests proxied to it.
Even if one were to define appropriate RTT/RTO measurements,
and use traffic
from the proxy as a demonstration of "liveness",
inappropriate failover
can still happen in cases where the time between proxy
traffic is greater
than the failover timer.
The end result is that to be able to apply RFC 3539, one
would need to add
a heartbeat command to RADIUS. This is a fairly major step, since it would require changing both RADIUS client and server implementations.
So the question is:
"If a major protocol change were to be made to RADIUS to improve reliability, would such a change be deployed on RADIUS clients and servers and would it be acceptable for the SIP accounting
specification
to depend on such a change?"
If the answer is yes, then a RADIUS failover spec might be worth discussing further. If no, then it seems to me that a RADIUS
failover spec it might
not be worth doing -- it's not considered important enough
to get over the deployment hurdles.
That raises the question of whether a dependency even on transport behavior improvements is possible, since even this would
still require
changes on RADIUS clients (though not servers).
Comments?
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers