Subject: RE: [Sipping] New version of the SIP-AAA reqs draft

From: [email-masked]
Date: Fri, 21 Feb 2003 20:13:48 +0200

Henry,

> > What you appear to be saying is that DIAMETER should not have 
> > been created in the first place (presumably with a view that 
> > RADIUS should have been enhanced to deal with its 
> > shortcomings). That is an issue you must take up with the 
> > IESG and the WG responsible, not try and blame 3GPP for it.
> 
> On this we can agree. 3GPP is not the problem for us. DIAMETER is.

Do you have technical reasons for this?  Diameter running in 
RADIUS compatability mode should allow NAS's and RADIUS servers
to talk to Diameter servers.

I understand your reasons for not wanting to upgrade everything
to Diameter, but I still don't see what reasons you have for
being dismissive of Diameter.

br,
John
_______________________________________________
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: Fri, 21 Feb 2003 14:43:45 -0600

> I understand your reasons for not wanting to upgrade
> everything to Diameter, but I still don't see what reasons 
> you have for being dismissive of Diameter.

Thanks for clarifying the fact that we have two issues. 

The 2nd item, why DIAMETER is not the best option for NG: It is too
little, too late.

AAA is a natural part of e-commerce, that is of the web services
architecture, as defined in W3C and numerous industry consortiums. It
makes little sense for all the world to make payments and conduct
transactions in the 'web services currency' and only phone calls to be
paid in 'DIAMETER currency'. Actually two types of phones call
'currencies': Wired using RADIUS and mobile using DIAMETER. Not that
DIAMETER is inherently evil or poorly engineered. It is just too little
too late, when looking beyond RADIUS and its limitations. My two cents.

I would see the design jobs therefore this way:

1-Near term: Use RADIUS-SIP to accommodate the huge isntalled base. The
I-D's mentioned here. Including the OSP token for SIP.

2-Longer-term: The Web services architecture.

It appears the present discussion stems from the fact that we only have
volonteers for a DIAMETER-SIP draft. None of the mentioned RADIUS-SIP
authors have volunteered any work here, and this is the problem. So
unless the no RADIUS or web services volonteer steps up, we will have
neither 1 nor 2.

And this is not any fault of 3GPP :-)

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Friday, February 21, 2003 12:14 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] New version of the SIP-AAA reqs draft
> 
> 
> Henry,
> 
> > > What you appear to be saying is that DIAMETER should not have been

> > > created in the first place (presumably with a view that RADIUS 
> > > should have been enhanced to deal with its shortcomings). That is 
> > > an issue you must take up with the IESG and the WG responsible, 
> > > not try and blame 3GPP for it.
> > 
> RADIUS compatability mode should allow NAS's and RADIUS 
> servers to talk to Diameter servers.
> 
> I understand your reasons for not wanting to upgrade
> everything to Diameter, but I still don't see what reasons 
> you have for being dismissive of Diameter.
> 
> br,
> John
> 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: [email-masked]
Date: Sat, 22 Feb 2003 07:20:47 +0200

> being dismissive of Diameter.

henry may have points why he doesn't like diameter, but for me, it is
nto really that big deal IF diameter AAA infrastructure some day becomes
wide spread.  today, however, that is not the case.  instead everybody
is using radius as the protocol between NASes (includifn sip proxies)
and AAA servers and also between AAA servers themselves.

examples of the latter are gric and ipass, which provide roaming service
for hundreds of isps literally all over the world.  if radius is so bad
that what you say IESG claims, i don't understand how this is possible.
the roaming services run radius over ipsec which solves the security
issues.

-- juha

---

From: Jari Arkko <[email-masked]>
Date: Sat, 22 Feb 2003 10:54:18 +0200

> and AAA servers and also between AAA servers themselves.

Right. That's why DIAMETER has been designed to be able to work
with RADIUS. Naturally new features in DIAMETER are not necessarily
accessible in RADIUS, but things that run on RADIUS should also run
on DIAMETER, such as current NAS or AP authentication.

(This is by the way one reason why I don't believe web services
will be successful in this space; I see the RADIUS - DIAMETER line
continuing for network access, telephony even if some other apps do
something else.)

> the roaming services run radius over ipsec which solves the security

The limitations of RADIUS have been documented in various places.
Running IPsec does actually help in some of the security-related
limitations, though not all. Everyone knows RADIUS has problems,
but it was the only thing people had.

To recap: Let's plan for a solution that provides the functions
required in the requirements document (using DIAMETER), but
allows for some amount of compatibility with RADIUS.

Jari

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 23 Feb 2003 20:52:54 -0600

> To recap: Let's plan for a solution that provides the 
> functions required in the requirements document (using 
> DIAMETER), but allows for some amount of compatibility with RADIUS.

We may live to see neither in the near future, but a new one, based on
web services, a la .NET or Liberty Alliance. As mentioned, it makes no
sense for telephone calls to be AAA-ed and purchased in some exotic
RADIUS or DIAMTER "currency", while everything else is purchased and
AAA-ed with web services.

The problem in this WG at present is there are no volunteers for this
alternative. I will desist trying to stop DIAMETER if it meets someone's
needs, but just wanted to share the possibility mentioned above.

Thanks, Henry

> On Behalf Of Jari Arkko
> Sent: Saturday, February 22, 2003 2:54 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] New version of the SIP-AAA reqs draft
> 
> 
> everything  > 
> > to Diameter, but I still don't see what reasons you have 
> for  > being 
> > dismissive of Diameter.
> > 
> > nto really that big deal IF diameter AAA infrastructure some day 
> > becomes wide spread.  today, however, that is not the case. 
>  instead 
> > everybody is using radius as the protocol between NASes 
> (includifn sip 
> > proxies) and AAA servers and also between AAA servers themselves.
> 
> Right. That's why DIAMETER has been designed to be able to 
> work with RADIUS. Naturally new features in DIAMETER are not 
> necessarily accessible in RADIUS, but things that run on 
> RADIUS should also run on DIAMETER, such as current NAS or AP 
> authentication.
> 
> (This is by the way one reason why I don't believe web 
> services will be successful in this space; I see the RADIUS - 
> DIAMETER line continuing for network access, telephony even 
> if some other apps do something else.)
> 
> > examples of the latter are gric and ipass, which provide roaming 
> > service for hundreds of isps literally all over the world.  
> if radius 
> > is so bad that what you say IESG claims, i don't understand 
> how this 
> > is possible. the roaming services run radius over ipsec 
> which solves 
> > the security issues.
> 
> The limitations of RADIUS have been documented in various 
> places. Running IPsec does actually help in some of the 
> security-related limitations, though not all. Everyone knows 
> RADIUS has problems, but it was the only thing people had.
> 
> To recap: Let's plan for a solution that provides the 
> functions required in the requirements document (using 
> DIAMETER), but allows for some amount of compatibility with RADIUS.
> 
> Jari
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>