1 / 14

Extended Attributes for Enhanced RADIUS: A Solution for Future Needs

This proposal suggests a new format for RADIUS attributes, adding flexibility with TLV data grouping, naming conventions, and extended attribute types to accommodate increasing demands. The goal is to simplify attribute management for future interoperability and scalability. With proven implementations in production systems, the draft outlines practical solutions to address evolving requirements.

waneta
Download Presentation

Extended Attributes for Enhanced RADIUS: A Solution for Future Needs

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 81 Alan DeKok FreeRADIUS Avi Lior Bridgewater

  2. Motivation • RADEXT discussions have been long • We need a solution soon (i.e. within 2-3 years) • Other proposals were complex • Attribute audit shows the needs to be simple

  3. One Octet of Change Now Extended format

  4. That’s pretty much it. • “Steal” one octet from “Value” for extended types • Allocate 4 attributes of this format (241..244) • 256*4 =~ 1K new attributes • Should be enough for the forseeable future

  5. Grouping • Flexible grouping by defining a TLV data type • Already in WiMAX, 3GPP2, and other SDOs / vendors. • Code is widely deployed in production systems

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

  7. Naming: Not just 8 bits • We need to name the new attribute 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. 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

  9. “Long” Attributes • Leverage the Ext-Type format, and add “flags” • Allocate 2 attributes of this type (245, 246) Extended format with flags

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

  11. Additional notes • 24{1-6}.26 are VSAs, with fixed format • Allows for many more standardized VSAs • 24{1-6}.{241-255} are reserved • No “experimental” or “implementation-specific” • They have not been useful • Detailed instructions for IANA are included

  12. Implementations • Two interoperable implementations: • In FreeRADIUS “master” branch • http://git.freeradius.org • IEA Software • http://www.iea-software.com/products/radlogin4.cfm • BSD licensed library will be released this year • Looking for more!

  13. Summary • ~1.5K new attributes (many 1000’s with TLVs) • Grouping via TLVs (proven to work in SDOs) • Standard way to have “long” attrs (to 4K of data) • Vendors have ~1.5K new VSAs to work with • draft includes simple test encoder • Helps with interoperability checks

  14. Questions? • Who has read the draft? • Any feedback? • Who will implement it soon?

More Related