: RFC 4005 AUTH48 Review

Glen recently summarized the discussion on proposed changes to RFC 4005,
which is now in AUTH 48:

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

As I read the above recommendation, it boils down to the following:

a. Go ahead with Dave's separate document on translation of RFC 2865
non-conformant VSAs.

b. Add text to NASREQ restricting the length of AVPs 1-255 OR add
a header flag for use by RADIUS/Diameter gateways.

c. Consider an alternative Diameter/RADIUS interoperability mechanism,
such as encapsulation.

IMHO, recommendations a and b are worth considering.  I would like to hear
the opinion of WG participants on these items.

Item c is a more difficult issue.  Here are some thoughts.

From the very beginning RADIUS/Diameter compatibility has been one of the
most difficult problems that Diameter has had to tackle.  The original
Diameter proposals, based on UDP, were designed to tackle this problem by
extending the RADIUS packet format in a backward compatible way.  However,
because of IESG feedback, Diameter moved to reliable transport, and as a
result, the "gateway" approach described in NASREQ was taken.

Having operated email "gateways", it has become painfully obvious to me
that translating one protocol to another, particularly when that
translation does not have perfect fidelity is not a viable long term
solution.

As a result, I am sympathetic to Glen's point of view -- the gateway
described in NASREQ is at best a temporary solution.  Given the continued
evolution of RADIUS, it is very difficult to convince myself that it will
remain viable for the medium term, let alone long enough to allow for
large scale "Diameter only" networks to arise.

However, at the same time it is hard to argue that the NASREQ document
should be held up pending development of a more viable approach to
RADIUS/Diameter interoperability.

Therefore my recommendation is that only items a) and b) should be
considered blocking for the publication of RFC 4005, and that c) be
pursued in a separate document on RADIUS/Diameter interoperability.

Comments welcome.