110 likes | 117 Views
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
E N D
Thoughts on RADIUS Data Model Issuesand 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 • Strict type and allocation control • 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
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 • 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