RADEXT WG RADIUS Attribute Guidelines

1. RADEXT WGRADIUS Attribute Guidelines draft-weber-radius-attr-guidelines-02.txtdraft-wolff-radext-ext-attribute-00.txt Greg Weber March 21st, 2006 IETF-65, Dallas v1

2. J F M A M J J A S O N D 2005 J F M A M J J A S O N D 2006 RADIUS Attribute Guidelines • WG Charter Item: “RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues.” • Milestone: Oct ’06 completionOriginally Dec ‘04 ExtAttr-00 Guide-01 Guide-02 Guide-00 DraftRevisions Milestones IESG Submissions WG LC1 IETF-65, Dallas

3. RADIUS Attribute Guidelines • draft-weber-radius-attr-guidelines-02.txtdraft-wolff-radext-ext-attribute-00.txtdraft-evbergen-radext-extended-attribute-02.txt • Aimed at charter item • The Guidelines draft collects data points from early radius-ext threads: current behavior, solution scope, and guidelines • The Wolff draft proposes a Diameter-based encoding • The Van Bergen draft proposes a RADIUS-like tagging mechanism • Have you read the drafts? :-) IETF-65, Dallas

4. RADIUS Attribute Guidelines Motivation – why do we need guidelines? • Divergent data models • Attribute space exhaustion • Diameter alignment IETF-65, Dallas

5. RADIUS Attribute Guidelines Data Model • Two attribute spaces: standard & vendor • Small number of data types • Consistent TLV payload use enables: • interoperability, intermediate nodes (proxies) • simple implementation: attributes can be added without new parsing code • Many exceptions Simple TLV IETF-65, Dallas

6. RADIUS Attribute Guidelines Data Model Alignment • Vendor space somewhat varied :-) Vendor PacketCable Vendor Vendor 3GPPVSAs Microsoft 3GPP2 Tags Vendor 3GPP2 FRAGMENT ENCRYPT COMPACT SHARED Simple TLV COMPLEX DATA GROUPING IETF-65, Dallas

7. RADIUS Attribute Guidelines Scope • Backwards compatibility • Intermediate nodes • Dictionary based implementations • Unaware endpoints • Existing VSA usage • Transport Impact • Non-AAA applications • Diameter compatibility IETF-65, Dallas

8. RADIUS Attribute Guidelines New Section 7: new attributes SHOULD comply with the attribute design guidelines given in RFC 2865 unless one or more of the following applies: • The standard attribute space for new attributes has been exhausted. • The proposed maximum attribute length exceeds that available for attributes specified by RFC 2865. • The native data type of the data element is defined for Extended attribute, but not standard RADIUS, e.g. Integer64. • Logical grouping is required. In the cases above, it is RECOMMENDED that the extended attribute encoding specified by the Wolff draft be used. IETF-65, Dallas

9. RADIUS Attribute Guidelines Further recommendations: • The Vendor-Specific Enumeration (VSE) encoding mechanism as proposed by Section 2.2.1 of RFC 2882 SHOULD NOT be used. Instead, vendors should comply with the recommendations of RFC 3575. • Per-attribute encryption mechanisms other than specified by RADIUS standards SHOULD NOT be used. • The message lengths specified by RADIUS standards MUST NOT be exceeded. • Variable attribute content SHOULD NOT be specified. Separate attributes SHOULD be defined instead. • SDOs are RECOMMENDED to use the standard attribute space for attributes that are intended to be supported by multiple vendors. IETF-65, Dallas

10. RADIUS Attribute Guidelines From the Wolff draft: Four distinct types of syntax • Abstract syntaxFirst & most important – what information is to be represented? • Display syntaxHow the info is presented to a human; also useful for inter-application transfer • Transfer syntaxBits on the wire; derived from Abstract syntax, not vice versa! • Internal syntaxImplementation determined, nobody else’s business IETF-65, Dallas

11. RADIUS Attribute Guidelines Criteria for evaluating extended attribute format • Top prioritiesRemove 255 limit on attribute type numberRemove 253 limit on attribute value lengthSupport rich set of standard attribute value typesSupport groupingEasy transition of attributes from VSA to standard • Mid prioritiesEase of gatewaying to DiameterSupport multi-level (nested) groupingM-bit (mandatory attributes)build on / re-use existing work • Low prioritiesMinimal attribute header sizeElegance, alas IETF-65, Dallas

12. RADIUS Attribute Guidelines From the Wolff draft: Advantages of a Diameter-based encoding • Satisfies all top & mid priority criteria • All new RADIUS features need Diameter spec too; minimizes author work • Grouped sub-attributes are together in specified order, making validation & display straightforward IETF-65, Dallas

13. RADIUS Attribute Guidelines Diameter AVP header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ • Larger code & length fields • Optional Vendor-ID • M-bit • More standard data types IETF-65, Dallas

14. RADIUS Attribute Guidelines Issues addressed by the Wolff draft: • Extended-Space attribute encaps extended attributes • Diameter-based AVP encoding • EAP-Message like concatenation • Alignment & padding • Additional data types • M-bit support Questions: • Extended attributes in Access-Reject? • Range of Diameter code points? IETF-65, Dallas