1 / 6

Extending RADIUS Attribute Type Set: Mechanisms and Compatibility Goals

This document outlines a mechanism to extend the base RADIUS attribute type set while ensuring backward compatibility with existing RADIUS and Diameter protocols. The primary goal is to define a standardized way to accommodate larger attributes and facilitate attribute grouping through type extension mechanisms. It discusses the allocation of vendor codes, the use of fragmentation for large attributes, and the requirement of tag fields for attribute grouping. Key features include packing small sub-attributes and ensuring multiple large attributes of the same type can be sent within a single message.

edric
Télécharger la présentation

Extending RADIUS Attribute Type Set: Mechanisms and Compatibility Goals

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. RADIUS Attribute Type ExtensionIETF 69 Y. Li Lior G. Zorn

  2. Goals • Primary Goal • define a mechanism to extend base RADIUS attribute type set • backward compatibility with RADIUS • Diameter compatibility • Secondary Goals • big attributes • attribute grouping

  3. Type Extension Mechanism • Allocate a vendor code for the IETF • 0 specified • Use of one vendor code doubles the standard attribute space • If we run out, request another vendor code • Small sub-attributes can be packed into one extended attribute • Like RFC 2865 VSAs

  4. Large Attribute Support • Uses Fragmentation flag in header • One bit • Attributes > 246 octets in length fragment into multiple extended attributes • On reception, attributes w/same type & ’F’ flag set concatenated in order • Allows multiple big attributes of same type to be carried in one message

  5. Attribute grouping • Uses Tag field in header • Derived from RFC 2868 scheme • Tag MUST be present • 126 distinct attribute groups possible in a message • 0x00 means no tag • 0x7F reserved • Nested groups not supported

  6. Discussion?

More Related