Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft)

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

Emile van Bergen writes...

> It was half serious. What I'm after is to find out at which point you
> would start to agree that certain things are better only taken
together.

OK. I was reacting to your phrasing "all kinds of bad, bad magic".  That
doesn't move us forward, either.

> We're having a theoretical debate, and you're not answering the
> question. Let me try again. If RFC 2865 didn't have a time base type,
> how would you propose a session time to be conveyed? As an attribute
> consisting of subattributes allocated from a global IANA Type number
> space, however wide?

OK, theoretically speaking then.

If there were no RADIUS time data type, then I would search to see if
there were a standard one in common use, preferably one with a stable
reference, e.g. an RFC.  I would almost certainly choose Unix Epoch time
(seconds since January 1, 1970) which conveniently fits in an Integer.
If I were worried about the 2024 (or whenever) wrap-around, I'd find
another standard representation, and use that (maybe an unsigned long
long, i.e. 64-bit integer).  If I were *forced* to use the
representation you suggest, i.e. separate members of a structure for
each of the "units" of time, and there were no existing standard I could
reference, then I would look to the RADIUS Design Guidelines to see what
is recommended.

So, I haven't answered your question yet (but I will).  My point up to
this juncture is that the WG should reach a consensus on design
guidelines, and then each individual attribute design decision should be
made with the benefit of those recommendations, providing a certain
level of consistency.  This shouldn't be such an ad-hoc process, IMHO.
I suppose this is a controversial opinion, something like advocating
coding style standards.  :-)  While I have an opinion on this, I really
don't care so much as to what the WG decides, as long as it comes to a
consensus, and does so fairly quickly.  I would prefer that the
guidelines are substantive, and provide some real guidance, rather than
simply codifying the existing ad-hoc practices.

OK, so we're in an imperfect world, and the WG has not yet come to
consensus on design guidelines, so I'm left to my own devices.  How
would I propose to encode the structure that you've presented as a
hypothetical?  Toss a coin?  The problem is that in the absence of
guidelines, it's a matter of personal style.

How would I suggest that the design guidelines be worded to recommend
encoding of structured data representations?  My suggestion would be to
use the Extended RADIUS Attribute (however it is ultimately defined) and
use whatever grouping (data aggregation) method it supports to structure
the member elements into a logical structure.  This could be via
sub-attributes, or via tagged attributes, or via grouped attributes (as
in Diameter).

I think it's important to reiterate some thoughts expressed elsewhere in
this general discussion, however.  One of those concepts is the issue of
whether or not a RADIUS Server or RADIUS Client needs to take an action
that depends on the value of one or more individual members of a data
structure.  So far, much of this discussion has been from the view point
of RADIUS Servers, in terms of data dictionary implementations.  We
should also consider this from the NAS developer's viewpoint.

If a RADIUS entity (Server or Client) needs to take some action
dependent upon an element in a structure, it would be valuable and
desirable to have the individual elements easily addressable.  Having
sub-attribute IDs for these is one way, and in an Extended RADIUS
Attribute we can define this scheme without incurring any backwards
compatibility penalties.  We could also write custom string parser code
for each individual attribute, which could work from fixed octet
offsets, or could search for specified delimiter values in variable
length fields.  I personally find this kind of code more cumbersome,
less flexible, less re-usable, and more error prone.  It's certainly
good job security for RADIUS developers.  :-)

If no RADIUS entity needs to take action on the values of the structure
elements, e.g. it is passed to another entity (such as EAP), or it is
simply intended to be dumped verbatim into a RADIUS Accounting Server
log file, then it can perfectly well be densely packed into a string.
My only concern with this approach is that the author of a new attribute
*claims* that it can be treated as a string, because it's never parsed,
when in fact implementations of that application eventually *do* need to
have access to the individual data elements, and thus end up parsing
densely packed strings.

Another way to look at this issue, purely for the sake of analysis, is
to see how the same data items would be encoded in ASN.1, using SMIv2,
for a MIB.  Pretend that we're using SNMP to provision the NAS instead
of RADIUS.  How would you write the MIB?  You could easily see a
relationship between leaf OIDs and RADIUS attributes (or
sub-attributes).  Now before anyone starts the flames, I realize that
RADIUS is not like SNMP.  For one thing RADIUS doesn't have a formal
data model, like SNMP.  I think the exercise is potentially instructive,
none the less.

If the eventual consensus of the WG is that individually addressable
elements of a structure are not our cup of tea for attribute encoding
guidelines, and that we really want to formalize the custom octet
packing method for attribute encoding, then I could live with that, if
it were algorithmic and predictable, from one attribute to another.  One
way to make such a scheme predictable would be to mimic the way a
specified reference implementation of a C language complier, on a
specified reference CPU architecture, would encode a C structure
definition in physical memory, and simply clone that encoding method.
One could handle the on-the-wire endian-ness with a simple mechanism
such as the host-to-net and net-to-host macros (e.g. htonl, ntohl, etc).

Any way we go, I'd *much* rather reach consensus on design guidelines
and then be able to review proposed RADIUS extensions I-Ds against those
concrete best current practices, rather than make ad-hoc evaluations of
each new attribute against the personal opinions of the day.


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