1. August 2004 at IETF-60 Jari.Arkko@ericsson.com
Thoughts on RADIUS Data Model Issues and Some Possible New Approaches -- Including Diameter Compatibility
August 2004 at IETF-60

2. Not All Attributes Are Created Equal
RADIUS IETF Attributes
Strict type and allocation control
Restricted type and number space
RADIUS VSAs (vendor and SDO)
Less strict control of typing
No allocation control
Unrestricted number space
Diameter AVPs
Powerful type system and unrestricted number space

3. The Implications... This is fine; the spaces have different purposes
However, movements between spaces are complicated:
It may be hard to adopt a VSA as an IETF attribute, even if we wanted to, if there is a type difference
Question: what types do VSAs use?
A definition of an attribute in Diameter can not be used in RADIUS, two different attributes lead to translation difficulties
Only designed movement is RADIUS attribute => Diameter VSA
Some people argue that current type system is too limiting
Attribute number availability may be a problem too

4. How Other Protocols Deal with This
SNMP
Unrestricted numbering system (OIDs)
Strict type control
A private MIB branch can be moved to IETF space just by assigning new numbers

5. Some Potential New Approaches for RADIUS

6. Approach 1: Use an IETF VSA with an Extended Data Model
Allocate a vendor number (maybe != 0) for IETF
Extend the data model/have more attribute numbers available for this attribute
Use this attribute for new work

7. The Attribute Format
| Type = | Length | Vendor-Id = IETF
Vendor-Id (cont) |M|R| Extended IETF type |
| Extended IETF Data ...

8. Approach 2: Merge the Extended IETF and Diameter AVP data models
Allocate a new attribute, “IETF Extended”
Contents are Diameter AVPs (or subset of them)
“IETF Extended” and Diameter AVPs share the same number system

9. The Attribute Format
| Type = TBD | Length | Diameter AVP Code
| V M r r r r r r | Vendor-ID (opt)
Vendor-ID (opt, cont) | Diameter Data ...
Note: data types include Grouped
More information:
(Appendix A)

10. Discussion (1/2) Implications to implementations:
In any case, existing VSAs must continue to work
Only new work would use the new format
New code not needed if attributes fed in using hex
New code needed if cleaner input/processing is required
Implications to attribute spaces:
Approach 1 creates a new, fourth attribute space
Approach 2 merges two of the existing attribute spaces
Implications for RADIUS - Diameter interoperability:
Approach 2 makes it possible to use existing AVPs in RADIUS

11. Discussion (2/2) Bits on the wire Feature set
Goal: a translation agent needs no per-AVP information to do a conversion
Implies that format must be exactly as in Diameter or self-describing so that an automatic conversion can be done
Feature set
If we do, think hard about how powerful the scheme should be
Attribute number space extension -- probably useful
Attribute type space extension -- maybe some
Not all Diameter attribute types are currently used
Length extension -- not sure