Subject: Re: AW: AW: [Sipping] FYI: RADIUS & SIP

From: Jiri Kuthan <[email-masked]>
Date: Thu, 07 Aug 2003 18:11:01 +0200

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.)

As for us, we took freedom not to wait until a solid answer exists
and implemented this draft.

-jiri

At 10:17 AM 8/6/2003, Liess, Laura wrote:
>What about the accounting draft draft-schulzrinne-accounting-sip-01.txt? Any reason for not working on it? 
>Laura 
>
>>-----Ursprungliche Nachricht-----
>>Von: Jiri Kuthan [mailto:[email-masked]]
>>Gesendet: Dienstag, 5. August 2003 18:00
>>An: Jonathan Rosenberg; Bernard Aboba
>>Cc: Liess, Laura; [email-masked]; [email-masked]; Dumler,
>>Alexander; Wolff, Christian
>>Betreff: Re: AW: [Sipping] FYI: RADIUS & SIP
>>
>>
>>Thanks, I very much agree; we have received identical feedback so far.
>>
>>-jiri
>>
>>At 08:12 PM 7/29/2003, Jonathan Rosenberg wrote:
>>>I know of several carriers with RADIUS infrastructures that 
>>want to use them to support SIP. They are currently using 
>>expired I-Ds and proprietary attributes. As a result, I would 
>>strongly advocate work on standardizing RADIUS usage with SIP.
>>>
>>>There are two areas of work that I see a need for:
>>>
>>>1. Digest authentication. The sterman draft 
>>(http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-si
>>p-00.txt) is used quite a bit, it seems. It would be nice to 
>>standardize on this.
>>>
>>>2. Prepaid calling. Many folks are using vendor proprietary 
>>radius extensiosn to support prepaid calling. It would be nice 
>>to bring those  forward and standardize on them.
>>>
>>>-Jonathan R.
>>>
>>>Bernard Aboba wrote:
>>>
>>>>Is there some particular set of draft(s) that you are 
>>advocating work on?
>>>>On Fri, 18 Jul 2003, Liess, Laura wrote:
>>>>
>>>>>I think most carriers currently use some kind of RADIUS 
>>platform to do user authentication and they would like to 
>>reuse it in the future to authenticate their SIP customers.
>>>>>My colleagues who are responsible for the RADIUS Platform 
>>of the Deutsche Telekom (CC)are currently on vacation so I 
>>could not check with them now about how to answer this mail, 
>>but we already talked about this issue a number of times and 
>>my strong opinion is that "yes, Deutsche Telekom cares a lot 
>>about SIP and RADIUS". Reusing the existing RADIUS platform 
>>for SIP authentication is a strong requirement for the 
>>development of SIP services within the Deutsche Telekom.
>>>>>
>>>>>Laura (T-Systems/Deutsche Telekom Group)
>>>>
>>>>_______________________________________________
>>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>>This list is for NEW development of the application of SIP
>>>>Use [email-masked] for questions on current sip
>>>>Use [email-masked] for new developments of core SIP
>>>
>>>-- 
>>>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>>>Chief Technology Officer                    Parsippany, NJ 07054-2711
>>>dynamicsoft
>>>[email-masked]                     FAX:   (973) 952-5050
>>>http://www.jdrosen.net                      PHONE: (973) 952-5000
>>>http://www.dynamicsoft.com
>>>
>>>
>>>_______________________________________________
>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>This list is for NEW development of the application of SIP
>>>Use [email-masked] for questions on current sip
>>>Use [email-masked] for new developments of core SIP
>> 

--
Jiri Kuthan            http://iptel.org/~jiri/ 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Aug 2003 09:20:54 -0700 (PDT)

> determines this work to be dropped. (Authentication is a different

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?

---

From: Jari Arkko <[email-masked]>
Date: Fri, 08 Aug 2003 12:32:53 +0300

> to depend on such a change?"

Given that RADIUS and DIAMETER can work together for dial-in, I
think we can make them work together in SIP. Folks who need a
reliable & extensible protocol can already deploy DIAMETER.
Therefore, my suggestion would be to provide the basic functionality
in RADIUS, but NOT start any work on fundamental and possibly
non-backwards compatible RADIUS enhancements. That is, lets
publish Digest for RADIUS, SIP Accounting attributes for RADIUS*,
corresponding versions for DIAMETER, allow these to work
together, and let folks decide which protocols their particular
situation needs.

--Jari

*) This one may have to be informational, as is RADIUS accounting
base RFC.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 09 Aug 2003 11:26:33 -0700

I agree with Jari that we should be able to define extensions that are
parallel definitions that carry the same semantics in Radius or DIAMETER and
avoid many arguments about what the future will be. It should be the
semantic information we want to transfer that is important to the SIPPING
group, not the transport.

I think we should keep the Authentication work somewhat separate in our
minds from the Accounting work - they have little in common.

I agree with the comment that no one is asking for Diameter - the requests I
have heard have all been for Radius Accounting. I have not had requests for
Diameter or really for Authentication / Authorization outside of 3GPP. I
think it is worth doing, Cisco implemented an Authentication scheme for SIP
over Radius a long time ago but I don't believe it has ever been used in a
production network. A ton of people are using Radius for SIP billing in
production networks - I think Accounting is a higher priority, but less
interesting, issue than Authentication.

I find the arguments of why Radius should not be used for Accounting
somewhat compelling but until service providers request it, it is not likely
to be real high priority. Because of this, I like Jari idea of getting the
semantic information done for both in a way that allows Radius to work today
for providers that use it but minimizes the changes to move to Diameter.

Cullen