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

[email protected] <mailto:[email protected]> supposedly
scribbled:

...

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

No, it's not -- see below.

> Several people have, at various times,
> mentioned that we need a document on how to generally interoperate
> and interwork Diameter and RADIUS.  

John, have you read the NASREQ draft?  It _is_, AFAICT, that
document; in fact, others are using it as a template (or worse,
incorporating it by reference (i.e., "just do what NASREQ does")
already.

> Is this something that people
> have the energy or interest to work on?   
> 
> John

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