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

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

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.

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