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

David Mitton <> supposedly scribbled:

> Ummm... I'm not sure who all is involved in this discussion.

I was rather surprised (to put it mildly) to find my private reply
forwarded to half the world, as well.

> 
> I initially disclosed a draft copy to the AAA chairs for comment
> before submission, but there seems to be some included text and
> trailers that don't correspond to the headers, or my intended
> recipients.   
> 
> The draft has not been posted to the Secretariat at this writing,
but
> I guess I might do it as-is now, so that everyone can join in. 

I suppose so.

> 
> FYI:  RFC 4005 is Diameter Nasreq, currently in Auth48 state.
> 
> Dave.
> 
> ----- Original Message -----
> From: [email protected]
> To: [email protected], [email protected]
> Subject: RE: [AAA-WG]: RE:
draft-mitton-diameter-radius-vsas-00.txt
> Date: Thu, 7 Apr 2005 09:43:38 +0300
> 
>> 
>> Bernard,
>> 
>> Bumping it up a level, still.  I do not think that there is a
perfect
>> solution for interworking RADIUS and Diameter.  Interworking will
>> always be interworking.  Toss in VSAs and all bets are off.
>> 
>> I think we should have some basic, default case (which I think
the
>> draft is trying to address).  This may cover some cases, but not
all,
>> but I don't see how we can guarentee 100% interworking.  I think
>> there will be some need for some interworking boxes that may need
to
>> normalize or translate between RADIUS and Diameter, but that kind
of
>> thing probably is more implementational than standards-based.
>> 
>> Some time ago, there was discussion about working on a BCP or
>> information draft on Diameter-RADIUS interworking; perhaps that
is
>> something that is still needed.  However, its not reasonable to
hold
>> NASREQ (or any other Diameter document) up based on this issue.
>> 
>> John
>> 
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]]On
>>> Behalf Of ext Bernard Aboba
>>> Sent: 07 April, 2005 08:03
>>> To: [email protected]
>>> Subject: [AAA-WG]: 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

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