1 / 22

Extended Attributes

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

caia
Download Presentation

Extended Attributes

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 - Interim Alan DeKok FreeRADIUS

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

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

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

  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 • Detail 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” attributes

  20. 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”

  21. Implementations • In FreeRADIUS “stable” branch • http://git.freeradius.org • Implements TLVs, basic type • No support for “long attrs”

  22. Questions?

More Related