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

Glen,


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

So this point is good.

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

This sounds like new work.  Several people have, at various times,
mentioned that we need a document on how to generally interoperate
and interwork Diameter and RADIUS.  Is this something that people
have the energy or interest to work on?

John