[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RADIUS attribute design: some thoughts
In thinking about the RADIUS design guidelines work item
from the current proposed charter, I thought it might provide
some insight to look at some specific ways in which the VSA
space is evolving. In part, it appears to be diverging from
the data type encodings of the standard space due to simple
lack of recommended route.
Taking the SDOs as a microcosm of VSA usage, here are some
usages I see in IS-835 (3GPP2), TS-129.061 (3GPP), and
PacketCable 1.0 (CableLabs).[*]
* Grouping data for
As with bit flags, multiply valued attributes (e.g. a list of IP
addresses), and various overloaded strings which need parsing.
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.
As with a group of attributes which share a common timestamp, or
a group of counters related to a common 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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.