RE: : Re: authors 48 hours: RFC 4005 <draft-ietf-aaa-diameter-nasreq-17.txt>

Hi,

> The easiest way to deal with translation, though, is to avoid it
> altogether, so the option I much prefer is to extend Dave's I-D
> regarding RADIUS VSAs to the entire RADIUS message and simply
> encapsulate it in a single Diameter AVP in the gateway.

Having the Radius-Diameter translation as specified currently
in RFC 3588 and nasreq-draft does not prevent you implementing
this kind of protocol encapsulation. I find the translation
more useful and we should keep it.


BR,
Mikko


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> ext Glen Zorn (gwz)
> Sent: 20 April, 2005 06:02
> To: 'Bernard Aboba'
> Cc: 'David Mitton'; Loughney John (Nokia-NRC/Helsinki); 'Pat Calhoun';
> 'Bert Wijnen'; Kessens David (Nokia-NET/MtView); [email protected]
> Subject: RE: [AAA-WG]: Re: authors 48 hours: RFC 4005
> <draft-ietf-aaa-diameter-nasreq-17.txt>
> 
> 
> Bernard Aboba <mailto:[email protected]> supposedly scribbled:
> 
> >> Are you serious?
> > 
> > Yes, I am.
> > 
> > You have raised an issue with the NASREQ document that David has
> > attempted to correct.  Apparently, you don't feel his proposed
> text
> > makes sense.  The document is now in AUTH48, so if you would like
> to
> > propose alternative text, there's no better time to do so.   
> 
> There are actually a couple of problems here: the first, which I
> think is pretty well solved by Dave's other draft, has to do with
> translating RADIUS VSAs that do not conform to RFC 2865's
> recommended format.  The other, much more fundamental, problem is
> that of general interoperability between RADIUS & Diameter.  For
> example, in order to be able to respond reliably to requests from
> RADIUS clients (or Diameter requests that have been translated to
> RADIUS and back to Diameter, if this is allowed), a Diameter
> "server" must adhere to the RADIUS rules regarding both attribute
> (AVP) and message length.  Unfortunately, there doesn't appear to be
> any way for a Diameter "server" to tell whether a given request was
> originated by a RADIUS client.  There are a couple of ways to deal
> with this issue: we could use one of the unused flags in the
> Diameter packet header and set it when a Diameter message passes
> through a RADIUS->Diameter gateway; this would require special
> purpose logic in the Diameter "server", however it would ensure that
> the RADIUS rules were followed (if possible).  OTOH, section 4.1 of
> RFC 3588 states that "AVP numbers 1 through 255 are reserved for
> backward compatibility with RADIUS, without setting the Vendor-Id
> field.  AVP numbers 256 and above are used for Diameter, which are
> allocated by IANA (see Section 11.1)".  If we were to take this
> passage seriously and literally, we should define (in NASREQ) that
> AVPs 1-255 have a maximum data length of 252.  Of course, we would
> then need to define new, equivalent Diameter AVPs without this
> restriction or live with it.   The easiest way to deal with
> translation, though, is to avoid it altogether, so the option I much
> prefer is to extend Dave's I-D regarding RADIUS VSAs to the entire
> RADIUS message and simply encapsulate it in a single Diameter AVP in
> the gateway.  A RADIUS message will easily fit into a Diameter AVP,
> after all, and this technique would ensure that all the RADIUS rules
> were followed.  Of course, some may object that this would just turn
> the Diameter server into a front-end processor for a RADIUS server,
> but the alternative seems to be to turn the Diameter server _into_ a
> RADIUS server (of sorts, at least).  This would fulfill what I
> recall to be the original goal of enabling a graceful transition
> from RADIUS to Diameter (server first) -- that is, enabling RADIUS
> clients to use a Diameter server with as little reconfiguration as
> possible.  If we insist that Diameter "clients" be capable of
> communicating with RADIUS servers or that Diameter messages be
> forwarded through RADIUS-based AAA networks then I suspect that a
> far greater number of translation rules than are included in the
> current NASREQ draft will be necessary, but I consider that that is
> non-starter anyway since in general it is not possible to translate
> Diameter into RADIUS.
> 
> 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
>