1. RADEXT WG RADIUS Attribute Guidelines draft-weber-radius-attr-guidelines-01.txt
Greg Weber
November 8th, 2005 v1
IETF-64, Vancouver

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-64, Vancouver

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

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

5. RADIUS Attribute Guidelines
Recommendations
| 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
IETF-64, Vancouver

6. RADIUS Attribute Guidelines
00 to 01
Largely editorial changes
Would like to get some confirmation that the problem statement is captured before proceeding much further.
Open Issue: 106, Vendor Specific Values
Standardize a method for vendors to define custom values for standard attributes?
IETF-64, Vancouver

7. RADIUS Attribute Guidelines
Vendor Specific Values
VSE (enumerations) described in RFC 2882 embeds vendor ID in value, e.g. val=((vendor-id << 16) | num)
Require revision of RFC 3575 (RADIUS IANA policy) and therefore a standards track doc?
IETF-64, Vancouver

8. RADIUS Attribute Guidelines
Fragmentation
Simpler method than attribute flagging?
EAP-Message is a non-AAA endpoint conversation, so opaque assembly makes sense. For AAA endpoint, the less opaque, the more checking that can be performed.
DHCP (RFC 3396) Encoding Long Options. Concatenate any adjacent attributes of the same type.
Do we need to support long & short attributes of the same type in the same message?
How much do we rely on attribute ordering (consecutiveness)?
How does this apply to VSAs –which are already the same type?
IETF-64, Vancouver

9. RADIUS Attribute Guidelines
Grouping
Named vs. unnamed tagging
Known contents vs. arbitrary contents
Can newly defined groups of data contain previously defined (standard) attributes?
IETF-64, Vancouver

10. RADIUS Attribute 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
How to translate to/from Diameter (see draft-mitton-diameter-radius-vsas-00.txt)
IETF-64, Vancouver

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

12. RADIUS Attribute Guidelines
Finally,
Is this a reasonable starting point for this charter work item?
Volunteers for this work?
Discussion
IETF-64, Vancouver

13. RADIUS Attribute Guidelines
Backup Slides
IETF-64, Vancouver

14. RADIUS Attribute Guidelines
Motivation – why do we need guidelines?
Divergent data models
Attribute space exhaustion
Diameter alignment
IETF-64, Vancouver

15. 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-64, Vancouver

16. RADIUS Attribute Guidelines
Scope
Backwards compatibility
Intermediate nodes
Dictionary based implementations
Unaware endpoints
Existing VSA usage
Transport Impact
Non-AAA applications
Diameter compatibility
IETF-64, Vancouver