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

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Wed, Mar 15, 2006 at 11:17:31AM -0500, Nelson, David wrote:

> Emile van Bergen writes...
> 
> > 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.

Ok. So if I understand you correctly, you would suggest the current
criteria?

1. does a widely accepted standard type for the information exist? If so, 
   any packing used in that is OK.

2. if not, and you're not *forced* to use separate members either, then
   ... (you did not address that situation).

3. if you're *forced* to use separate members, you'd look at the Design
   Guidelines to see eg. how you would use the facilities provided by the 
   Extended Attribute.

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

Agreed, without sacrificing correctness to speed; RADIUS in particular
shows that good formats tend to stay around for a long time, sometimes
even long after aspects of the originally intended applications and
corresponding use style have moved on.

> I would prefer that the guidelines are substantive, and provide some
> real guidance, rather than simply codifying the existing ad-hoc
> practices.

Agreed, however, if you want to get any kind of traction with
implementors, it should not be prohibitively hard, nor require a
complete redesign in a completely different paradigma, to migrate from
those practices to the new recommendations.

There is a reason DIAMETER hasn't received the attention people expected
it to get. There is also a reason it was agreed that there would be a
RADEXT WG. Its very existence is a testament that DIAMETER adoption
isn't going as well as intended, that vendors so far prefer RADIUS (and
I would venture to say, not just due to networking (in the economic
sense) effects), and that there are some problems in RADIUS that people
want fixed, and fixed in RADIUS' way, not by RADIUS starting to
transport DIAMETER.

[snip]

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

Well, I agree, but as said in our conference call, I don't think that
the current design guidelines draft should remain leading after the
Extended Attribute specification is done.

I view that document as a survey of issues and a proposed set of
requirements for the Extended Attribute format and an accompanying
usage recommendations document, if any.

The only section that comes up with guidelines is section 7, and that's
rather brief in comparison with the rest. I would also suggest that some
of those criteria depend on what the Extended Attribute format will be.

I think that the the next step is to specify the Extended Attribute
format, as one that should be flexible enough to be able to absorb
existing RADIUS practice, as well as providing a common solution for the
largest current problems: limited standard attribute number space and
size and incompatible internal VSA formats.

The most common cases of vendors not used the RADIUS attribute format
inside their VSAs are those that use wider attribute number fields and
multiple subattributes inside one VSA.

So if we address that, then together with tagging and structures, we
have most things covered, and encourages vendors to use the
Extended-Attribute to encapsulate all their attributes in a common
format (the Extended Attribute format), instead using the
Vendor-Specific attribute to encapsulate one or more of their attributes
in a vendor specific manner.

Client vendors worried about server support needn't worry, because a
server that does not support the Extended Attribute won't support their
specific internal VSA structure either, unless they use RFC 2865's
suggested format for values the Vendor-Specific attribute.
with vendor specific code, allow 

That way, dictionary based implementations can gain access to more
attributes, without either requiring vendor specific code or
dictionaries that define lots of encoding parameters.

The last step is to provide guidance on which features of the format to
use in which cases, including what data types new attributes should use,
to encourage sane practice and also to cater for a smooth migration to
DIAMETER later. This would be a much expanded version of Section 7 of
the current Design Guidelines.

The reason to do it in two layers is that structure evolves at a much
slower pace than style. We still use the same protocol structure and
packet structure as 9 years ago, but usage style has *much* evolved. And
the structure is so popular that we're still using it.

So, following the charter, I think the extended attributes (and I hope
we'll have one draft to consider for adoption as a WG item, not two),
should use a format (inside a space created by concatenated RADIUS
attributes), that:

a. is able to absorb existing practice (eg. in terms of most of the
   Informational RFCs we have on RADIUS) without paradigm shifts or
   other nontrivial transformations (ie. no wholesale encapsulation
   of the DIAMETER protocol in a way as done for EAP)

b. addresses at least 90% of the reasons vendors didn't use the standard
   RADIUS format inside their VSAs (larger Type field, longer
   attributes), removing the need for packet parsers to contain vendor
   specific code or the need for parsers to be supplied with much
   knowledge from the dictionary;

c. encourages harmonization by creating large common attribute number 
   spaces, governed by shared policies instead of the current situation
   where you either need standards action or rely on another vendor's
   private assignment policy. Also note that our charter specifically adds
   the SDO-specific attribute class to the IETF and Vendor specific
   classes of attributes;

d. paves the way for a smooth migration to DIAMETER by allowing DIAMETER
   code points to be used and by strongly recommending the use of the
   DIAMETER data types for all basic scalar types. 

   (In practice, that doesn't narrow things down much; *everything* at
   the level we're working at uses 2's complement big-endian values with
   sizes of either 1, 2, 4, 8 octets, or a variable length octet string
   that's either not interpreted at all or interpreted as UTF-8).

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

Agreed, but there the situation is often much easier, because NASes
already have specific code to implement the actual services that are
controlled by the RADIUS attributes that apply to them.

Therefore, service specific value encodings seem much less of a problem
for NAS vendors, and I think that's also the reason that we see so many
today.

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

That was exactly the point in my suggested format. It allows all
elements to be addressed 1. as a flat list of attributes, 2. as a flat
list of tagged attributes, 3. as an ordered list of attribute sets (by
splitting in sets based on tags), and 4. as an arbitrarily nested tree
of attributes.

Which addressing style depends on what the entity wants to do with the
attribute and the attribute's semantics when it occurs at one particular
level in the tree as opposed to another.

> 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.  :-)

I wholeheartedly agree with your point there. 

I personally even so thorougly hated that approach that I spent the
effort of making the OpenRADIUS dictionary able to deal with almost all
non-delimited formats, both fixed offsets and length field based, and
the policy language to easily allow splitting on delimiters.

However, after moving the format variation out of the code, the
complexity is in the dictionary, so I'd still rather see a more
harmonized approach to TLV formats. But for that to be successful, it
needs to be flexible and not requiring the adoption of a different
style, as DIAMETER does.

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

Agreed.

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

SNMP, including traps and writes (RFC 1067) predates RADIUS (RFC 2058)
by 9 years (1988 vs. 1997).

Using SNMP traps as RADIUS requests and SNMP writes as RADIUS responses,
SNMP could have done the whole trick of dynamic service provisioning;
nothing like RADIUS would theoretically be needed at all.

I don't believe it was just an historic error or a case of
not-invented-here on the part of Livingston that RADIUS was designed.
If it was an error, that error surely has never seen any attempt of
correction in the market place so far.

Even when RADIUS was reaching some of its limits, people came up with
DIAMETER, instead of encouraging people to use SNMP instead.

If you want to spend time on another research on the reasons for that
(hint: RADIUS is successful because it's so terribly *pragmatic*; we may
need to limit that a bit, but not too much or we'll suffocate it), then
that's fine, but if you suggest we embark on that I never want to hear
one deadline or time based argument to end a technical discussion again.
;-)

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

Splitting of values at arbitrary octet boundaries can be defined with
two parameters and two flags per subvalue, without looking at CPUs or
compilers at all.

a. You have the offset of each subvalue, either given in octets relative to
the beginning or the end of the outer value; and 

b. you have the length of each subvalue, given in octets relative to the
beginning or the end of the outer value.

That's it. No reference to anything else is neccesary. If you have those
values, then *why* those values were chosen (because data type X wants
to be aligned at multiples of Y and has width Z) is irrelevant; you can
still obtain or position the data. Also keep in mind that interpretation
of the obtained octets as a certain data type happens at a higher level.

Then, if multiple subvalues are to have variable lengths, the value
effectively either contains a set of TLVs (possibly with implicit Ts) or
a set of delimited values (less optimal in many cases, because the
values cannot contain the delimiter, requiring an encoding layer on top
to deal with (un)escaping).

The parameters to walk any sane list of TLVs consist of:

a. the offset of a big-endian length field, 
b. the size of that length field, 
c. the offset of the value itself, 
d. the size of the value relative to the value given by the length field, and 
e. the offset of the next TLV given as an adjustment and padding count 
   relative to the value given by the length field.

(all offsets and sizes in octets, all offsets relative to the start of
the TLV).

Those parameters allow you to walk RADIUS, DIAMETER, EAP, my Extended
Attribute proposal and almost all RADIUS VSAs seen in the wild, without
any specific code.

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

That's also a nonambiguous mathematical operation that is easily defined
without reference to any (reference) implementation. Network order is
Network order, that is, most significant octet first, and I don't see
why anyone should use anything else on the Network.

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

Agreed. My most important issue is that I think that Section 7 of the
design guidelines draft depends on the extended attribute format, not
the other way around.

The main substance of the draft provides guidance for the design of that
format, but after the format is agreed upon, then the format should provide
the framework for further style documents and design recommendations for
attributes that use the new format.

(Legenda, for people that have just tuned in and haven't gone away or
fallen asleep yet: those are 'Extended [RADIUS] Attributes', which have
a new attribute header format (which is under debate), of which one or
more exist in a single virtual field in the RADIUS packet, created by
the concatenation of all instances of the 'Extended-Attribute', a la
EAP-Message -- at least that much we agree upon, I think).

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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