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

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

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

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

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

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

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

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

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

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

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

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

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

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 email to list/Weber March 2006 IETF 65, Dallas