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

From: [email-masked]
Date: Thu, 7 Aug 2003 05:30:22 +0300

Hi All,

I just want to plug a draft we are working on in the AAA WG:

 Diameter Credit-control Application
 draft-ietf-aaa-diameter-cc-01.txt

This is primarily Diameter based, though interworking with
RADIUS is somewhat covered.  This is losely based on 
some 3GPP solutions, but we are trying to generalize it and
make it more useful for the Internet. I do know that there are also
some individual drafts covering RADIUS prepaid. I don't have the time, 
nor energy to specify RADIUS prepaid work.  

One of the largest problems that I currently see about RADIUS
is the under-specified nature of RADIUS.  I understand that
many different organizations and vendors have defined, but
not documented, vendor-specific VSAs.  In trying to do any
meaningful work with RADIUS, I think we need to document
some of this first.

Oh, a note to Henry, I have heard some horror stories from
various folks (and talking to different IT support people)
of how large-scale RADIUS deployments react after a power-
outtage.  Since backoff is not specified in RADIUS, if
multiple NASes comeup at the same time, they can flood
the network, causing all sorts of fun things happening ...
This is one area in which RADIUS would need fixing.

br,
John

> -----Original Message-----
> From: ext Liess, Laura [mailto:[email-masked]]
> Sent: 31 July, 2003 17:41
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Dumler, Alexander; Wolff,
> Christian
> Subject: AW: AW: [Sipping] FYI: RADIUS & SIP
> 
> 
> I agree with Jonathan. Support for prepaid calling seems to 
> me a very good idea.  
> Laura
> 
> Laura Liess
> T-Systems/Deutsche Telekom Group
> Am Kavalleriesand 3
> 64295 Darmstadt
> 
> >-----Ursprungliche Nachricht-----
> >Von: Jonathan Rosenberg [mailto:[email-masked]]
> >Gesendet: Dienstag, 29. Juli 2003 20:13
> >An: Bernard Aboba
> >Cc: Liess, Laura; [email-masked]; [email-masked]; Dumler,
> >Alexander; Wolff, Christian
> >Betreff: Re: AW: [Sipping] FYI: RADIUS & SIP
> >
> >
> >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

_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Thu, 07 Aug 2003 07:08:04 -0500

> outtage.  

Since we know of no significant DIAMETER deployments at ISPs (except in the
minds of its IETF champions), sure, there are no horror stories possible for
DIAMETER :-)

The SIPPING WG charter is to look out for what is good for SIP applications.
Promoting DIAMATER should be done elsewhere. The fact that SIPPING folks are
too busy to work on _real_ SIP-AAA should is not a good reason to accept the
DIAMETER pitch at face value. 

One option is to postpone SIP-AAA work until we have some I-D's based on
real deployments. Or does anyone come forward?

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, August 06, 2003 9:30 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: AW: [Sipping] FYI: RADIUS & SIP
> 
> Hi All,
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Aug 2003 16:08:45 +0300

Hello folks,

I'm not really sure if its productive to debate RADIUS vs.
DIAMETER deployment status or deficiences. I don't see
them as competing alternatives as much as I see them
as complementary approaches.

Here's what I'd like to have:

1. Published (RFC) specifications for carrying HTTP
    Digest over RADIUS. Maybe start from draft-sterman.
2. Published specifications for the same thing and
    a few additional features over DIAMETER. Start from
    draft-belinchon, but make it less 3GPP-specific.
3. As a part of 2, interworking specification
    between RADIUS & DIAMETER (possibly limited
    to the scope of features supported under 1).
4. Prepaid support module for DIAMETER that can
    work with any application, such as SIP or network
    access. This is work in progress, as John noted.
5. Optionally, a prepaid module for RADIUS,
    constructed in a manner which makes translation
    to 4 possible.

This will enable folks with either RADIUS or
DIAMETER servers to put them together with their
SIP nodes, and will enable gradual transition from
RADIUS to DIAMETER, which will likely take time. The
idea is that AAA proxies start supporting both
protocols, so you don't have to switch your NASes/
SIP proxies all at the same time.

Please also note that SIP is not the only thing
where RADIUS vs. DIAMETER issues arise. In network
access, for instance, the AAA WG has produced a
specification which works over DIAMETER in a manner
compatible with the current RADIUS network access
usage. Similarly, in EAP authentication over RADIUS
can interwork with EAP authentication over DIAMETER,
albeit with DIAMETER the security issues related to
key transport are easier.

--Jari

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 07 Aug 2003 08:59:39 -0500

> DIAMETER deployment status or deficiences.

I agree, and we should add WEB SERVICES to the list - probably the most
important contender. To get away from this discussion, the draft on SIP-AAA
needs an additional chapter with an objective comparison on various options,
and to discuss the pros and cons of such as RADIUS, DIAMETER and WEB
SERVICES. (BTW: Is there a lack of expertise on web services in the SIPPING
WG? Some well know WEB SERVICES vendors come to my mind...Invite them?)

A discussion of options is the only basis on which to proceed IMHO.

Comments?

Thanks, Henry 

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, August 07, 2003 8:09 AM
> To: Henry Sinnreich; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: AW: [Sipping] FYI: RADIUS & SIP
> 
> 
> Hello folks,
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Aug 2003 23:18:31 -0700 (PDT)

> In trying to do any

RFC 2882 does some of this, but it's a moving target, unfortunately.

> Since backoff is not specified in RADIUS, if
> the network, causing all sorts of fun things happening.

"Fun" is not the first word that comes to mind to describe several
thousand APs retransmitting once a second with no backoff.  About the only
saving grace was that RADIUS accounting packets are relatively small
so that the result wasn't congestive collapse in the entire network, only
the RADIUS servers.  However, if RTOmin had been 300 ms instead of
1 second, that might have happened too.

> This is one area in which RADIUS would need fixing.

The problem of course is that one cannot "fix" these problems without
upgrading deployed implementations.

And without a heartbeat, it is not clear whether the "fix" can include a
conservative failover algorithm such as the one specified in RFC 3539.

So overall, we need to be realistic about what is achievable.  It's
probably too ambitious a goal to try to truly fix RADIUS
transport behavior -- without major surgery about all we can do is remedy
the most egregious mis-behavior.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Aug 2003 07:11:27 -0700 (PDT)

>     constructed in a manner which makes translation

This is a summary of the work that is being proposed or ongoing (in AAA
WG).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Aug 2003 11:46:09 -0400

> upgrading deployed implementations.

I suspect that, given the huge problems that have occurred with 
RADIUS, operators would be amenable to upgrading these boxes if 
vendors could provide fixes that were backwards compatible and gave 
them a path towards improving overall performance as other boxes were 
upgraded too. I also suspect RADIUS server vendors would welcome 
standardized ways to achieve those goals.

It seems to me that exponential backoff in retransmits is certainly 
possible in a backwards compatible way. I'm not enough of a RADIUS 
expert to know whether the watchdog mechanism as described in rfc3539 
is possible in a backwards compatible way.

BTW, while on the subject of rfc3539, I am aware of many sip 
implementations which perform watchdog operations very similar to 
those described in section 3.4. I wonder if it would be useful to have 
a sipping specification that describes how to properly do this in sip? 
  There are many ways to do this wrong, and we could leverage the 
thinking Bernard has put into the AAA document to write up a version 
for SIP that works well.

-Jonathan R.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Aug 2003 09:54:46 -0700 (PDT)

> possible in a backwards compatible way.

Yes, this part of the issue can be handled in a backwards compatible way.
Since only the RADIUS client retransmits, the RADIUS server code does not
have to change.

> I'm not enough of a RADIUS

For the watchdog, both the RADIUS client and server would have to
change.

The objective of a watchdog would be to get an immediate response from the
next hop RADIUS proxy/server; no forwarding of the watchdog is permitted.
This would imply a new command, since there is no existing command that
cannot be forwarded.

It's probably possible to do this in a backward compatible way.
One possibility would be to run the new command on a new port.
Since RADIUS has no capabilities negotiation, the RADIUS client can send
the new command to a new port and conclude that the command is not
supported if it receives an ICMP port unreachable.  This is
what is done with the dynamic authorization extensions, for example (RFC
3576). Not elegant (wouldn't want to do this with every new command!) but
it would work.

> thinking Bernard has put into the AAA document to write up a version

RFC 3539 sends a watchdog after a given elapsed time without evidence of
liveness (no traffic).  Somewhat better scalability can be obtained if you
wait until there is traffic to be sent; establishing liveness without the
need to actually make use of it is somewhat wasteful.