1 / 11

August 2004 at IETF-60 Jari.Arkko@ericsson

This document discusses shortcomings in the RADIUS data model in terms of attribute allocation and control compared to Diameter. Various potential new approaches to address these issues are explored, including using IETF VSAs with extended attributes and merging the IETF Extended and Diameter AVP data models. Detailed attribute formats and implications for implementations and interoperability are discussed.

sunh
Télécharger la présentation

August 2004 at IETF-60 Jari.Arkko@ericsson

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 • Strict type and allocation control • 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 NewApproaches 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 = 26 | 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: • http://ops.ietf.org/lists/radiusext/2004/msg00441.html • http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-01.txt (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 • 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

More Related