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