1. RADEXT WG RADIUS Attribute Guidelines Greg Weber IETF-63, Paris

2. 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: Dec ’04 completion IETF-63, Paris

3. 3 RADIUS Attribute Guidelines draft-weber-radius-attr-guidelines-00.txt Have you read the draft? :-) Aimed at charter item Initial revision primarily collects data points from early radius-ext threads (many) Strawman recommendation Guidelines (when to do what) largely absent so far IETF-63, Paris

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

5. 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-63, Paris Simple TLV

6. 6 RADIUS Attribute Guidelines Data Model, vendor enhancements Somewhat more varied :-) IETF-63, Paris Simple TLV GROUPING COMPACT SHARED COMPLEX DATA ENCRYPT FRAGMENT Tags 3GPP VSAs 3GPP2 Vendor 3GPP2 Microsoft Packet Cable Vendor

7. 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-63, Paris

8. 8 RADIUS Attribute Guidelines Recommendations IETF-63, Paris 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length |V|E|C| (reserved flags) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Standardize existing VSA recommendation Ease vendor to standard transition Accommodate most VSA behavior Plan for increased attribute number space

9. 9 RADIUS Attribute Guidelines Guidelines When to use which format (SHOULD/MUST) When to move from vendor to standard When to define vendor specific values When to use the extended type space IETF-63, Paris

10. 10 RADIUS Attribute Guidelines To think about, get consensus, do... Diameter translation Agree on recommended approach Actual guidelines Address vendor specific values IETF-63, Paris

11. 11 RADIUS Attribute Guidelines Finally, Is this a reasonable starting point for this charter work item? Volunteers for this work? Discussion IETF-63, Paris