Dealing with compound attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")

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

Bernard Aboba writes...

I've changed the topic (again) because I think we've wandered past
discussion of a particular draft in WGLC, and are effectively discussing
the RADIUS Design Guidelines draft.

> >As long as the compound format made sense for the actual entity
> >generating or processing the attribute's contents and as long as the
> >individual member values were not needed in any RADIUS policy nor
> >generated dynamically by the RADIUS server proper, there's never been
a
> >strong problem with such compound attributes, and I don't think there
> >necessarily should be any such problem now.
> 
> I think this is a very reasonable distinction.  If there is no need to
> distinguish the member values, compound attributes are ok.  However,
if
> there is such a need, compounding is problematic, requiring code to be
> written that would not otherwise be necessary.  Reducing the need for
> continual code updates was the original purpose of the Dictionary,
after
> all.

The classic case of a compound attribute where RADIUS does not need to
parse (separate or distinguish) or take action upon (create or react to)
the member values is EAP-Message.  This attribute is an opaque blob to
RADIUS, so the case is simple, and degenerate.  No arguments there.

The distinction that is being proposed here is when a RADIUS RFC (one
defining RADIUS protocol elements, such as attributes) specifies a
compound attribute (e.g. one containing a structure) for which the
RADIUS protocol engine does not "care" about the individual member
elements, the attribute may be formatted as conveniently packed
bit-fields and octet fields.  We presume some of these fields may be
further defined in the textual descriptions as integers, bit-vectors,
Booleans, strings, arrays, etc.

I find it hard to quantify the "care" vs. "don't care" status of the
data elements.  It would seem to me that if the RADIUS protocol engine
doesn't "care" about the member elements, it does not need to know their
boundaries.  Hence we are back to the opaque blob.  If it *does* need to
know the boundaries, then I claim that it "cares" about the data
elements.

Now, I suppose we could attempt to define "levels of caring".  For
example, in the RADIUS/GEOPRIV draft, there are attributes that contain
a number of data elements, that when reassembled form a GEOPRIV data
structure.  Is it necessary for the RADIUS protocol engine to know their
boundaries? Well, one reason for knowing the boundaries is that the
RADIUS protocol engine might be expected to perform the data packing,
from a set of discrete data elements.  I would liken this to the "UPS
Store" analogy. The customer brings a collection of loose household
objects to the UPS Store to be packed and shipped.  The UPS Store
employees don't really "care" much about the objects.  They only care
about the properties that affect packing into cardboard cartons.  This
might include size, shape, weight, whether or not the object is fragile,
and whether or not the material is hazardous or otherwise subject to
special shipping regulations.

I personally object to the notion of RADIUS as a packager and shipper
for arbitrary applications, i.e. RADIUS as transport mechanism.  I
realize that it has been, and continues to be, used in this fashion,
usually for applications at least vaguely related to AAA.

I think another way to look at RADIUS attribute data element fields is
that if the RADIUS protocol engine needs to know they exist, then they
should fall under the attribute design guidelines.  Conversely if the
RADIUS protocol engine does not need to know that individual date
elements exist, then treat the complex data structure in the same
fashion that RADIUS treats EAP messages, as an opaque blob.

I think the argument that RADIUS cares "enough" about the individual
data elements to warrant defining them in explicit sub-fields of a
RADIUS attribute, but not so much as to require any regularization of
their on-the-wire encoding, is problematic.   The only scenario that I
see that justifies this middle-ground "level of caring" is the RADIUS as
transport case, i.e. the UPS Store model.


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