Subject: RE: [AAA-WG]: digest issue 11 closure (fwd)

From: "Nelson, David" <[email-masked]>
Date: Mon, 4 Apr 2005 10:33:49 -0400

Miguel Garcia writes...

> So the point I want to make is that, due to the lack of grouped
> attributes in RADIUS, you do need translation rules in RADIUS in order
> to generate the appropriate HTTP/SIP digest header.

Why in RADIUS?  IMHO, the RADIUS protocol engine should not have to
understand the SIP server functions.  It would seem to me that this
function belongs in the "glue layer" code between the SIP server and the
RADIUS client.

While I agree that grouped AVPs are a nice feature of Diameter, they
don't in and of themselves obviate the need for "glue code" between the
RADIUS client and another layer that is using its services.  I suppose
that statement makes some assumptions on where you draw component
boundaries in your implementation, but my assumption is that a RADIUS
client implements the RADIUS protocol, and that various interface layers
marshal the attributes in and out of other protocol formats.

I think the *goal* of having "exception-less" RADIUS/Diameter gateways
is a good one.  If the gateway is always part of the Diameter [home]
server implementation, then it doesn't matter so much.  On the other
hand, if the gateway is a standalone function, or part of a RADIUS proxy
or Diameter proxy, then it may be significant issue.  The issue, of
course, is version synchronization.  If you add a new feature in your
RADIUS client and Diameter server, it might be nice to not need to also
version upgrade all of the gateways that exist somewhere in the proxy
server chain.

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Tue, 5 Apr 2005 10:02:24 +0200

Miguel wrote:
> I believe that Jari was trying to say that the gateway will
> need a rule: "the only thing the GW has to know is, what 
> RADIUS attributes must be placed into grouped AVPs".
Ok, now I understand.

> And I believe Jari was oposing to have this rule. But I argued that
> a RADIUS implementation will need rules to translate these
> attributes to SIP, or to Diameter. So the problem remains even
> if we haven't got Diameter into the picture.
I don't think that such a rule would be hard to implement or
resource-intensive.

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany

---

From: <[email-masked]>
Date: Thu, 7 Apr 2005 09:49:50 +0300

Bernard, Jari,

> Ok, this is mostly as I wanted it to be in the Radius document.
> However, I wonder if the current Diameter document should
> use individual AVPs instead of Grouped AVP:
> 
>       SIP-Authenticate ::= < AVP Header: xx12 >
>                            { Digest-Realm }
>                            { Digest-Nonce }
>                            [ Digest-Domain ]
>                            [ Digest-Opaque ]
>                            [ Digest-Stale ]
>                            [ Digest-Algorithm ]
>                            [ Digest-QoP ]
>                            [ Digest-HA1]
>                          * [ Digest-Auth-Param ]
>                          * [ AVP ]
> 
> 
> Because translating this grouped AVP appears to require
> additional work from a gateway, no? Bernard/Miguel, can
> you file on issue to the Diameter document on this.

This is a much more general issue than just for the SIP document.
Diameter has improved over RADIUS in a number of areas, one
being support for Grouped AVPs.  What you are suggesting is
that we should dumb-down Diameter SIP so that it can live
with RADIUS.  However, I don't think we have a requirement for
this.  I actually think that in any real deployments of this,
there will need to be specialized support from the gateway
anyway.  I don't think putting a generic Diameter-RADIUS
gateway (even if there were such a thing) would work.  Also,
I think the deployment scenarios for this interworking have
not really been thought through - is there any need at present
for this?  I see this as a non-issue.

John

---

From: <[email-masked]>
Date: Thu, 7 Apr 2005 19:17:19 +0300

Avi,

> I have my doubts about Diameter SIP.  Why did 3GPP not adopt it? Is the
> model that Diameter SIP supports originates from 3GPP, but does it have
> general applicablity?  

Because 3GPP needed a solution for Release 5. The Diameter SIP application
would have needed to have been ready in 2002.  I guess 3GPP showed good sense
not to wait on the IETF for a solution.

> Can I take the Diameter SIP and use it for other SIP architectures? 

I think Miguel has tried to make it more generally applicable for other SIP
architectures, and I have talked to some people (outside of 3GPP) who've 
implemented it, so I think it is possible to use Diameter SIP outside of
3GPP.

John

---

From: Avi Lior <[email-masked]>
Date: Thu, 7 Apr 2005 14:37:05 -0400

Jari,

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, April 07, 2005 2:34 PM
> To: Avi Lior
> Cc: 'Nelson, David'; [email-masked]
> Subject: Re: [AAA-WG]: digest issue 11 closure (fwd)
> 
> 
> Avi Lior wrote:
> 
> >Jari,
> >
> >It's a pretty safe bet that you will *not* have to buy me a 
> beer.  That 
> >is why I said we need RADIUS SIP document.  Lets get the 
> harmonizing there.
> >  
> >
> Ok. Either you are right or you get beer. Sounds good, no?

Hmmmmm, Yes!!!! You don't get many of those...

> >And I agree since we came this far lets harmonize the authentication 
> >part. But we need 3GPP2  Digest Auth quickly now.  We are delaying 
> >publication. And by Digest Auth I mean just Digest Auth 
> nothing to do 
> >with SIP.
> >  
> >
> It looks like the issues that we are discussing right now are 
> in the Diameter SIP part, like adding the nonce thing or 
> keeping/removing the grouped AVP. In that sense its not 
> delaying RADIUS SIP, although obviously it would be good to 
> ensure that the two can be in sync before we commit one of 
> them to an RFC...

Great...as long as we can wrapup RADIUS Digest.

> --Jari
> 
> >
> >
> >  
> >
> >>-----Original Message-----
> >>From: Jari Arkko [mailto:[email-masked]]
> >>Sent: Thursday, April 07, 2005 2:16 PM
> >>To: Avi Lior
> >>Cc: 'Nelson, David'; [email-masked]
> >>Subject: Re: [AAA-WG]: digest issue 11 closure (fwd)
> >>
> >>
> >>Avi Lior wrote:
> >>
> >>    
> >>
> >>>So the answer to your last question: "...are these disjoint
> >>>      
> >>>
> >>solutions
> >>    
> >>
> >>>sets that need not interoperate?" They answer is yes.
> >>>
> >>>      
> >>>
> >>Yes... but its not really a yes/no question. It is true that
> >>the function set in Diameter SIP is significantly bigger. But 
> >>both can do Digest (and exactly at the same manner, if we can 
> >>harmonize the nonce handling in Diameter SIP). You could hope 
> >>for interoperability in this part*.
> >>
> >>And the translation gateway issue isn't black and white
> >>issue either. We are debating whether it should take
> >>X amount of effort to do the gateway, or X - epsilon.
> >>
> >>And to answer John's question on whether there's a current
> >>requirement for interoperability... probably not in terms of 
> >>a specific customer case. But as Dave noted there's an IETF 
> >>requirement on making these techniques compatible. And 
> >>experience has shown that where people think their systems 
> >>are entirely self sufficient, in the next customer 
> >>case/specification release/business reorg they find out that 
> >>they do, in fact, need to interoperate with something else.
> >>
> >>--Jari
> >>
> >>*) I'll buy you a beer if within a year, we are not
> >>discussing the RADIUS version of what exists in Diameter SIP 
> >>beyond RADIUS Digest.
> >>
> >>    
> >>
> >
> >  
> >
>