RE: Rationalizing the RADIUS data model

["Nelson, David" <dnelson@enterasys.com>]

Jari Arkko writes...

> But let's talk about the specifics. What, exactly, is the
> current problem?

The current problem is that the RFC 2865 "SHOULD" rules for VSA format
are not universally followed, and even when they are followed, they
don't match the rules for standard attributes.  There is currently
nothing prohibiting a VSA from containing *anything* that will fit
within the approximately 250 available data payload octets of a VSA.
This has been repeatedly pointed out by various implementers who have
taken advantage of this "artistic license".

> Clearly, we have been impacted by the
> small attribute space. This can be solved.

Assuming that RADIUS has a sufficient useful lifetime remaining that the
current standard attribute space is consumed, then, yes, this can be
relatively easily solved.

> Structured data within an octet string, subfields in text
> strings, subattributes? There's probably more to discuss
> there.

Yes, indeed.

> I would rather not have structured
> data as "records", but subattributes might be doable,
> particularly if they could be mapped to grouped AVPs
> in Diameter. 

That sounds like a potential avenue to explore.

> The rest could then be labeled as an
> octet string; is there a reason why this type of a
> model could not be adopted as _the_ model, for all
> attributes?

I'm really opposed to "string" and "sub-string" based protocols.  RADIUS
and Diameter are AVP based protocols, and I think it would be a major
mistake to deviate from this design paradigm.  If sufficiently well
described, string based protocols can be made interoperable, but it's
generally much easier to achieve interoperability with AVP based
protocols.

I would support adopting the "universal" data model for all attributes,
including VSAs.  However, I suspect that the implementers who have
enjoyed the vast freedom of "artistic expression" under the current VSA
rules (basically none) would object.  It would likely make some existing
VSAa non-compliant. 

-- Dave



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