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

From: <[email-masked]>
Date: Fri, 12 Mar 2004 09:16:10 +0200

Hi Jari,

> 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?

I agree with your comments above.  This makes me think that the
proposed RADIUS extensions should have a 'Diameter' considerations
section, where applicable.

John

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Mar 2004 10:10:07 +0200

> section, where applicable.

Yes. To be more exact, a AAA extension should belong to one
of the following classes:

- Common definition that applies to both RADIUS and Diameter.
   Attributes, for instance. In some cases there might be
   a specific guideline about a specific attribute, but most
   of the time its exactly the same definition. No
   Diameter Considerations section needed, but the introduction
   of the document must explain that it applies to both
   protocols.

- A RADIUS-only definition with a specific mapping to an
   existing Diameter definition. Example: RADIUS SIP. Here
   we need a Diameter Considerations or Diameter Translation
   section.

- A Diameter-only definition with a specific mapping to an
   existing RADIUS definition. Example: Diameter EAP. Here
   we need a RADIUS Considerations or RADIUS Translation
   section.

- A Diameter-only definition, with no intent to be RADIUS
   compatible. This may be possible in some cases (3GPP?)
   where there is no intent to run RADIUS infrastructure
   at all, and no need to interoperate with one (that does
   not always apply to even 3GPP).

- A RADIUS-only definition, with no intent to be Diameter
   compatible. I'd rather not allow these, in order to
   ensure that its possible to upgrade to Diameter.

--Jari