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

Greg

[*]
http://www.3gpp2.com/Public_html/specs/X.S0011-005-C_v1.0_110703.pdf
http://webapp.etsi.org/action%5CPU/20031007/ts_129061v050700p.pdf
http://www.packetcable.com/downloads/specs/PKT-SP-EM-I09-040402.pdf

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