Re: [aaa-doctors] Thinking about RADIUS data types....

[Greg Weber <gdweber@cisco.com>]

> > This issue came up in the IESG retreat, with respect to extensibility
> > issues.  I cannot think of another protocol where the data model itself is
> > different between the "enterprise" and "standards" space.  Certainly in
> > the case of SNMP, one can take an enterprise MIB and move it to the
> > standards space without having to change data typings.  This property of
> > "data model invariance" is quite important in practice, I think.
> 
> I agree.  The question is what to do about it.  I think that a
> rationalization of the data models will require both an extension to the
> "standard" data model and new restrictions on the "enterprise" data
> model.

Regarding the enterprise data model, guidance may be sufficient
where restrictions would be difficult to enforce.  The two data
models seem to be diverging, in part, due to simple lack of 
recommended route.

It might provide some insight to look at the specific ways in which
the VSA space is evolving.  Taking the SDOs as a microcosm of VSA usage,
here are some usages I see in IS-835, TS-129.061, and PacketCable 1.0.

  * Grouping data for
     .Compactness
       As with bit flags, multiply valued attributes (e.g. a list of IP
       addresses), and various overloaded strings which need parsing.
     .Logical relationship
       Attributes which describe multiple aspects of a single entity.
       RADIUS provides tags for this, but I haven't seen much usage of
       that mechanism in VSAs; sub attributes seem more popular and
       are probably more extensible.
     .Shared information
       As with a group of attributes related to a single timestamp or
       remote IP address.

  * Per-attribute encryption
     Perhaps a reaction to the overhead of IPsec or maybe to satisfy
     regulatory requirements for particular data items. 

  * Fragmentation across VSAs
     For single VSA values exceeding the valid length of one attribute.
     These schemes seem to rely on the packet ordering/reordering
     restrictions on proxies- as does EAP.

Diameter seems to accommodate most of these expressed needs- except
perhaps compactness which may be an inappropriate goal for a protocol
that uses self-described data (vs. GTP' or IPFIX).

For RADIUS, I think the RADEXT attribute design guide should address
at least these areas.  

Greg