Re: Object identifier and type spaces in a rationalized RADIUS data model

[Bernard Aboba <aboba@internaut.com>]

> > defined in Diameter are automatically also defined in RADIUS? Some
> > of those attributes may rely on facilities that are not defined
> > in RADIUS.
>
> I can imagine that there are a few such attributes, as there
> are a few RADIUS attributes that don't get translated into
> Diameter.

One way to handle this is to have an explicit specification that describes
which Diameter AVPs are supported in RADIUS.  That way the behavior will
be well-defined.

> We could do this either way.

I'd suggest that the new attribute space is only usable if the NAS
indicates support for it, so as to address backwards compatibility issues.
So I think that to use the new Vendor-Specific space, you'd need the NAS
to be able to advertise support for vendor-extensions in the new space.
This wouldn't be that hard -- a specific Code could be used for that
purpose, and multiple attributes could be sent, listing the supported
VendorIDs.

> But my thinking was that we need a "fresh start" for both VSAs and
> standard attributes. Defining a new, somewhat more powerful format
> and deprecating the old space would achieve this pretty well. Of
> course, old VSAs would not stop working so no one's products would
> be in danger. But we would send a message to vendors and SDOs
> and ourselves that we have a new format that should be used for
> new work.

I'm not sure that deprecation is possible, given the widespread deployment
of RADIUS.

> > c. How do we deal with differences in attribute length between RADIUS and
> > Diameter?  My assumption is that we would concatenate attributes of the
> > same code and Vendor-ID.  But this might not work correctly for
> > all attributes - some can be present more than once.

I think you may need to handle this on an attribute-by-attribute basis.
Hence the need for a spec describing how each supported Diameter AVP is
handled in RADIUS.

While this is somewhat tedious that advantage of unifying the
AVP/attribute space is that we might save a lot of potential
Diameter/RADIUS compatibility headaches -- and also that we get to
leverage the work already done in RFC 3588.

It *might* even obsolete the need for new RADIUS work in some areas --
some existing Diameter applications might be reusable.  That
is a huge win if it is possible.

> As we think about this issue, we should remember that
> RADIUS runs over UDP, and to avoid too many problems
> with fragmentation one shouldn't put too many >255
> byte attributes to the messages in the first place --
> so there are some underlying limitations and relaxing
> the attribute length limit may not help that much.

I agree.  The next step is probably to think through the implications of
the proposal in more depth.  At this point I would say it appears quite
attractive.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>