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

2 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 completion Originally Dec ‘04 IETF-65, Dallas JFMAMJJASONDJFMAMJJASOND WG LC1 IESG Submissions Guide-00 Guide-01 Guide-02 Draft Revisions Milestones ExtAttr-00

3 RADIUS Attribute Guidelines draft-weber-radius-attr-guidelines-02.txt draft-wolff-radext-ext-attribute-00.txt draft-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 IETF-65, Dallas Simple TLV

6 RADIUS Attribute Guidelines Data Model Alignment Vendor space somewhat varied :-) IETF-65, Dallas Simple TLV GROUPING COMPACT SHARED COMPLEX DATA ENCRYPT FRAGMENT Tags 3GPP VSAs 3GPP2 Vendor 3GPP2 Microsoft Packet Cable Vendor

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 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 of RFC 2882 SHOULD NOT be used. Instead, vendors should comply with the recommendations of RFC 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 syntax First & most important – what information is to be represented? Display syntax How the info is presented to a human; also useful for inter- application transfer Transfer syntax Bits on the wire; derived from Abstract syntax, not vice versa! Internal syntax Implementation determined, nobody else’s business IETF-65, Dallas

11 RADIUS Attribute Guidelines Criteria for evaluating extended attribute format Top priorities Remove 255 limit on attribute type number Remove 253 limit on attribute value length Support rich set of standard attribute value types Support grouping Easy transition of attributes from VSA to standard Mid priorities Ease of gatewaying to Diameter Support multi-level (nested) grouping M-bit (mandatory attributes) build on / re-use existing work Low priorities Minimal attribute header size Elegance, 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: IETF-65, Dallas | 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

14 RADIUS Attribute Guidelines IETF-65, Dallas 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?