1. Diameter NASreq (RFC 4005) and RADIUS Compatibility
draft-mitton-diameter-radius-vsas-01.txt
David Mitton RSA Security Inc.
March 2006
IETF 65, Dallas

2. Overview Diameter designed to be upwards compatible with RADIUS
There will be encodings in Diameter that are not expressible in RADIUS
Most RADIUS attributes are supported in RFC 4005, exceptions are noted in Section 9.
Difficulty arises with Vendor Specific Attributes (VSAs)
March 2006
IETF 65, Dallas

3. Problems
RADIUS VSA typical practice involves unknown formats for sub-types and lengths. Gateway must know format to translate
RFC 4005 Section 9.6 only works for some RADIUS VSAs
Imposes limitations on Vendor type space
Diameter VS AVPs must be restrained to fit into RADIUS
Diameter AVP type space larger than RADIUS suggested format
Diameter AVP data can be longer
Diameter AVPs have flags
March 2006
IETF 65, Dallas

4. RADIUS VSAs vs Diameter Vendor Specific AVPs
RADIUS VSA format
Suggested format
Length: 8 != 24
Type: 8 != 32
Diameter Vendor AVP format
First block show suggested RADIUS VSA format, but many do not follow the Type and Data Length suggestions
Cause Issues mapping into Diameter
March 2006
IETF 65, Dallas

5. Goals
Provide a mapping that allows bidirectional communication through a translating gateway system or bilingual server
Minimize special cases and vendor specific knowledge in gateways
Allow mix of Diameter and RADIUS speaking equipment and servers that don’t use different AVPs for same information
no point in devising schemes for encoding data in ways
March 2006
IETF 65, Dallas

6. Proposal draft-mitton-diameter-radius-vsas-01.txt
Translate RADIUS VSAs as Diameter AVP #26. This is NOT as described in RFC 4005 Sect 9.6
Translate Diameter VS AVPs to a new RADIUS attribute.
March 2006
IETF 65, Dallas

7. RADIUS VSAs as Diameter AVP 26
No transformation of attribute data – Avoids vendor specific knowledge which allows transparent pass-through
Only end clients & servers need to know inner format
No additional encoding overhead
Length must be constrained to RADIUS limits.
March 2006
IETF 65, Dallas

8. Proposed RADIUS VSA to Diameter AVP 26 mapping
March 2006
IETF 65, Dallas

9. Diameter Vendor Specific AVPs in a RADIUS attribute
Add a new RADIUS attribute
Provide fields of the proper length
Define fragmentation and aggregation
Similar to EAP message attribute
Add segment number for concatenation
Suppress redundant VID and VType on non-first segment
March 2006
IETF 65, Dallas

10. Proposed RADIUS Diameter VS Attribute
Diameter Vendor Attribute
RADIUS Diameter VSA
March 2006
IETF 65, Dallas

11. Affects Documents:
Changing Diameter Vendor Encapsulation Affects Diameter Base RFC 3588, and Diameter NAS Application RFC 4005
Specify RADIUS format of Diameter TLVs Affects RADIUS document ??? Need to make one !
March 2006
IETF 65, Dallas

12. Generic Diameter AVP to RADIUS Attribute
While we’re at it, why not define a way to map Diameter AVPs (Type > 255) to RADIUS and vice versa.
Use same format as VS mapping without Vendor stuff
March 2006
IETF 65, Dallas

13. Proposed RADIUS Diameter AVP Attribute
Diameter Vendor Attribute
RADIUS Diameter VSA
March 2006
IETF 65, Dallas

14. Conclusion
If we get rid of the RADIUS VSAs transformation in RFC 4005 Section 9 and add AVP #26 can transit Diameter with no transformational knowledge or loss of data
Add a RADIUS attribute to hold Diameter VS and regular AVPs
The two vendor spaces end up independent, but can be used by either.
Add for RADIUS group – generic Diameter to RADIUS format? – format suggested in to list/Weber
March 2006
IETF 65, Dallas