[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