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

2. March 2006IETF 65, Dallas2 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)

3. March 2006IETF 65, Dallas3 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

4. March 2006IETF 65, Dallas4 RADIUS VSAs vs Diameter Vendor Specific AVPs Type: 8 != 32 Length: 8 != 24 RADIUS VSA format Diameter Vendor AVP format Suggested format

5. March 2006IETF 65, Dallas5 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

6. March 2006IETF 65, Dallas6 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.

7. March 2006IETF 65, Dallas7 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.

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

9. March 2006IETF 65, Dallas9 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

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

11. March 2006IETF 65, Dallas11 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 !

12. March 2006IETF 65, Dallas12 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

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

14. March 2006IETF 65, Dallas14 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.