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 Jari.Arkko@ericsson.com

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

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

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

Some Potential New Approaches for RADIUS

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

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

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

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: http://ops.ietf.org/lists/radiusext/2004/msg00441.html http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-01.txt (Appendix A)

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

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