1 / 23

Expanded RADIUS Attributes for Better Grouping and Naming

This proposal suggests extending RADIUS attributes beyond the current limitations to allow for more types of attributes, better grouping using TLV data types, and improved naming conventions. It addresses the need for more attributes and proposes allocating new attribute numbers, such as 241, 242, 243, and 244, for extended attribute types. By leveraging OID-style naming and introducing long attributes with flags for data continuation, it aims to simplify attribute management and increase the total attribute space. The motivation behind these enhancements is to offer a standardized and practical solution within the next few years, catering to the evolving needs of RADIUS implementations.

zedekiah-louis
Download Presentation

Expanded RADIUS Attributes for Better Grouping and Naming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extended Attributes • RADEXT - IETF 79 Alan DeKok FreeRADIUS Avi Lior Bridgewater

  2. Requirements • More RADIUS Attribute Types • 256 is too limited • Standard support for “long” attributes • > 253 octets • Better grouping • RFC 2868 tags are inadequate

  3. Un-Requirements • Systems which were discussed and rejected • too complex • too limited • which can’t be applied to existing RFCs

  4. Current Attributes

  5. Extended Attributes

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

  7. Naming • We need to name the new attributes types. • Use OID style “dotted number” • 241.{1-255} • 241.1 “This-Is-A-New-attr” • Versus • 1 “User-Name” • Naming applies only for the IANA registry

  8. Grouping • Better grouping by defining a TLV data type • Already in WiMAX, 3GPP2, and other SDOs / vendors.

  9. TLV Data Type

  10. TLV in Ext-Attribute

  11. TLVs in Ext-Attribute

  12. TLV Properties • Can carry any existing or future data type • Including TLVs. • Multiple TLVs can be carried 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

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

  14. “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”

  15. Long Ext Attributes

  16. Flags • 1 bit of “C” for 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

  17. 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 • Detailed instructions for IANA are included

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

  19. Attribute Audit • Public dictionaries • ~100 vendors • 55% or more are “short” (<20 bytes) • ~20 “long” attrs (253+ octets) • a “simple” solution seems to be best

  20. Implementations • In FreeRADIUS “stable” branch • http://git.freeradius.org • Implements TLVs, basic type • No support for “long attrs” • IEA Software • http://www.iea-software.com/products/radlogin4.cfm • Full support

  21. To Do • Define a “VSA” data type • To be used by the 6 new “VSA” attributes • Easier than repeating attribute definitions • More “guideline” recommendations • Hopefully simple • More examples • More clarifications

  22. Summary • > 1K of new attribute space • With TLVs, potentially many 1000’s • Grouping via TLVs • Proven to work in SDO VSAs • Standard way to have “long” attrs • No more “ad hoc method”

  23. Questions?

More Related