220 likes | 345 Vues
This document discusses the evolution of RADIUS attributes, addressing limitations of current standards and proposing a new framework for extended attributes. It introduces TLV (Type-Length-Value) structures to support more than 1,000 new attributes, enhancing usability and future compatibility. The paper also outlines new naming conventions and the introduction of "long" attributes, including additional flags for better data management. This solution seeks to simplify implementation, with practical applications already seen in WiMAX, 3GPP2, and more, promoting a robust future for RADIUS based systems.
E N D
Extended Attributes • RADEXT - Interim Alan DeKok FreeRADIUS
Requirements • More RADIUS Attribute Types • 256 is too limited • Standard support for “long” attributes • > 253 octets • Better grouping • RFC 2868 tags are inadequate
Un-Requirements • Systems which were discussed and rejected • too complex • too limited • which can’t be applied to existing RFCs
That’s pretty much it. • “Steal” one octet of “value” for extended types • Allocate 4 attributes of this format • 241, 242, 243, 244 • Solves the “need more attributes” problem • Allows for ~1K new attributes
Naming • We need to name the new attributes types. • Use SNMP / IP Address style “dotted number” • 241.{1-255} • 241.1 “This-Is-A-New-attr” • Versus • 1 “User-Name” • Naming applies only for the IANA registry
Grouping • Better grouping by defining a TLV data type • Already in WiMAX, 3GPP2, and other SDOs / vendors.
TLV Properties • Can carry any existing or future data type • Including TLVs. • Multiple TLVs can be on in one Ext-Attr • Nested or concatenated • Nesting is limited only by TLV-Length field • 253 / 3 =~ 80 • Practicalities show a depth of 5 is sufficient
TLV Naming • Leverage the same “dotted number” notation! • 241.1.2 • RADIUS Attr 241, of type “ext-attr” • Extended Attr 1, data type “tlv” • TLV 2, data type “integer” • Allows for ~250 fields in a struct • Extends type space past 1K attributes
“Long” Attributes • Leverage the Ext-Type format • Allocate 2 attributes of this type • 245, 246 • Add another field: “flags” • Standard way to say “more than 253 octets of data”
Flags • 1 bit of “M” for More (or continuation) • Same meaning as existing ext-attrs / WiMAX • 7 bits of “reserved” • We have no idea what to do with these • It’s likely that these will never be used
Additional notes • 24{1-6}.26 are VSAs • Allows for many more VSAs • 24{1-6}.{241-255} are reserved • No “experimental” or “implementation-specific” • They have not been useful • Detail instructions for IANA are included
Motivation • RADEXT discussions have been long • We need a solution soon (i.e. within 2-3 years) • All other solutions are more complex • Attribute audit shows the needs to be simple
Attribute Audit • Public dictionaries • ~100 vendors • 55% or more are “short” (<20 bytes) • ~20 “long” attributes
Summary • > 1K of new attribute space • With TLVs, potentially 10’s of 1000’s • Grouping via TLVs • Proven to work in SDO VSAs • Standard way to have “long” attrs • No more “ad hoc method”
Implementations • In FreeRADIUS “stable” branch • http://git.freeradius.org • Implements TLVs, basic type • No support for “long attrs”