1 / 14

Diameter NASreq (RFC 4005) and RADIUS Compatibility

Diameter NASreq (RFC 4005) and RADIUS Compatibility. draft-mitton-diameter-radius-vsas-01.txt. David Mitton RSA Security Inc. Overview. Diameter designed to be upwards compatible with RADIUS There will be encodings in Diameter that are not expressible in RADIUS

romney
Télécharger la présentation

Diameter NASreq (RFC 4005) and RADIUS Compatibility

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. Diameter NASreq (RFC 4005) and RADIUS Compatibility draft-mitton-diameter-radius-vsas-01.txt David MittonRSA Security Inc. 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) 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 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 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 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. 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. IETF 65, Dallas

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

  9. Diameter Vendor Specific AVPsin 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 IETF 65, Dallas

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

  11. Affects Documents: • Changing Diameter Vendor EncapsulationAffects Diameter Base RFC 3588, and Diameter NAS Application RFC 4005 • Specify RADIUS format of Diameter TLVsAffects RADIUS document ???Need to make one ! 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 IETF 65, Dallas

  13. Proposed RADIUS Diameter AVP Attribute Diameter Vendor Attribute RADIUSDiameter VSA 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. IETF 65, Dallas

More Related