[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Greg writes...

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

This is a good list issues for the design guidelines.  Would you be
amendable to cross posting this at the RADEXT mailing list?

-- Dave