: RE: draft-mitton-diameter-radius-vsas-00.txt

Maybe we should talk a bit about the problem this draft was trying to
solve.

As I understand it, we have a number of potential translation issues in
NASREQ and Diameter EAP:

1. Translation of specific RADIUS VSAs to Diameter standard attributes.
This is an issue in Diameter EAP for translation of RFC 2548 keying
attributes to Diameter keying attributes.

2. Translation of RADIUS VSAs in the illustrated RFC 2865 VSA format to
Diameter VSAs and back.

3. Translation of RADIUS VSAs *not* conforming to the proposed RFC 2865
VSA format to Diameter VSAs and back.

Note that I'm not including the problem of translating from an arbitrary
Diameter VSA to a RADIUS VSA because as you point out, this is not
possible.

The question is how one can handle these cases together within a
Diameter/RADIUS gateway.

One way to think about it is a hierarchy of potential translations:

a. Specific translations.  If you find a particular RADIUS VSA that's on
the specific list, the gateway executes the translation for that
particular VSA.

b. Generic RFC 2865 VSA format translations.  If the SMI for a particular
VSA is on the "Generic" list then it is translated to a Diameter VSA as
specified in the original NASREQ document.

c. Default case.  If the SMI for a particular VSA is *not* on the
"Generic" list, what do you do?  This is what I thought your proposal was
addressing.



> ---------- Forwarded message ----------
> Date: Tue, 05 Apr 2005 22:55:17 -0400
> From: David Mitton <[email protected]>
> To: Bernard Aboba <[email protected]>,
>      John Loughney <[email protected]>
> Subject: draft-mitton-diameter-radius-vsas-00.txt
>
> Bernard, John,
>
> 	Take a quick look at this and I can submit it.
>
> Next I'll do a change edit for draft RFC 4005, Section 9 that
> references this.

This draft looks amazingly similar to a solution I proposed, but now
repudiate.  I had thought that the simplest way to deal with the
attribute translation would be not to do it: to (essentially) tunnel
the RADIUS attributes through Diameter & vice-versa, which is
basically what this draft seems to do.  Since, however, I've come to
the conclusion that RADIUS-Diameter NASREQ interworking is, in the
general case, impossible without seriously restricting Diameter
semantics, making major changes to RADIUS or both.  The problem is
simply one of arithmetic, something this draft has a little problem
with as well: section 3.2 says "Diameter AVPs data field can be 16K
bytes long (length 24 bits)", but the last time I checked the
maximum 24-bit value was around 16 _megabytes_, not 16 _kilobytes_,
but that's really immaterial.  Even if the maximum length of a
Diameter AVP was roughly 16K, that's still more than 4 times the
maximum size of a RADIUS _message_.  It just won't fit.  Note that
this problem is there even with the "standard" NASREQ AVPs (the ones
numbered to coincide with the RADIUS standard attributes).  Suppose,
for example, that I want to use a 6 KB string representation of a PK
cert as my user name.  A Diameter client might have no problem with
this, but it certainly would fail at the first RADIUS-Diameter
gateway.  Similarly, a Diameter server has no way to know (AFAIK,
please correct me if I'm wrong) that the client at the other end is
actually a RADIUS client.  Therefore, it would be perfectly
reasonable for it to return an 8 KB AVP, which would never get to
its proper destination.  The only way I can imagine this working is
if there was a "RADIUS compatibility mode" for Diameter in which the
RADIUS rules were followed (including maximum message length).

>
> Dave.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel