Subject: RE: [AAA-WG]: Question about RADIUS/Diameter gateway

From: <[email-masked]>
Date: Fri, 12 Mar 2004 06:15:57 +0200

Hi Bernard,

> In looking at the RADIUS/Diameter gateway specification again, it seems
> like it is not able to handle several of the newly proposed RADIUS
> "extensions" utilizing sub-attributes, or changes to the 
> RADIUS attribute format.

Which drafts are proposing non-compatible sub-attribute formats? My
assumption that such proposals were not going to be considered in
RADext.

> Should the RADIUS/Diameter gateway specification be updated to handle
> those "extensions"?  If so, what restrictions need to be imposed to
> maintain future compatibility?  If not, what prohibitions need to be put
> in place against future changes to RADIUS?

What is the real potential for these extentions? Wouldn't these break
existing RADIUS compatibility?  My assumption is that we should
not allow extensions that break RADIUS compatibility or RADIUS/Diameter
gateway compatibility.  

John

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Mar 2004 09:06:44 +0200

I believe there are two parts to the conversion. First, the
converter has to figure out the right set of command codes
to map to (or from). Secondly, attributes need to be translated.

Generally speaking, the NASREQ translation model is for NASREQ
only. I do not believe it has been specified to work for, say,
RADIUS SIP, if it were defined later. Thus I believe that its
the task of the RADIUS SIP document to specify how the translation
should work towards DIAMETER SIP. (My logic is that the document
that comes last is responsible for defining the mapping, just like
Diameter NASREQ defines the mapping from plain RADIUS since NASREQ
was defined after plain RADIUS.)

If there is no corresponding "application" in the other protocol,
the conversion is obviously not going to be possible.

For attributes, the mapping is usually trivial, i.e., there's a
default rule to map all RADIUS attributes in the same way. But
there are exceptions, some attributes that need to be represented
in a different way in Diameter. There are some in NASREQ and
some in EAP.

I guess part of the discussion about the subtype attributes
(in addition to whether it needs new code in RADIUS) is how
to translate them to Diameter. Will the resulting Diameter
AVP be from the RADIUS code space and more or less treated
as an "octet string"? Or will it be mapped to a Grouped AVP
with better structuring and possibilities for Diameter nodes
to understand and act on the contents?

--Jari