1 / 12

Diameter NASreq (RFC 4005) and RADIUS Compatibility

Diameter NASreq (RFC 4005) and RADIUS Compatibility. 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

heller
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 David MittonRSA Security Inc. IETF 64, Vancouver Canada

  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 64, Vancouver Canada

  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 64, Vancouver Canada

  4. RADIUS VSAs vs Diameter Vendor Specific AVPs IETF 64, Vancouver Canada

  5. Goals • Provide a mapping that allows bidirectional communication through a translating gateway system or bilingual server • Minimize special cases and vendor specific knowledge • Allow mix of Diameter and RADIUS speaking equipment and servers that don’t use different AVPs for same information IETF 64, Vancouver Canada

  6. Proposal draft-mitton-diameter-radius-vsas-00.txt • RADIUS VSAs to Diameter AVP #26(not as described in RFC 4005 Sect 9.6) • Diameter VS AVPs to a new RADIUS attribute IETF 64, Vancouver Canada

  7. RADIUS VSAs as Diameter AVP 26 • No transformation of attribute data – avoids vendor specific knowledge for pass-through • Only consumer needs to know inner format • No additional encoding overhead IETF 64, Vancouver Canada

  8. Proposed RADIUS VSA to Diameter AVP 26 IETF 64, Vancouver Canada

  9. Diameter Vendor Specific AVPsin RADIUS • Add a new RADIUS attribute • Provide fields of the proper length • Define fragmentation and aggregation • Similar to EAP message attribute • Use V flag to indicate start of sequenceand suppress redundant VID and VType IETF 64, Vancouver Canada

  10. Proposed RADIUS Attribute for Diameter Vendor Specific AVPs IETF 64, Vancouver Canada

  11. Affects Documents: • Change Diameter Vendor EncapsulationAffects Diameter Base RFC 3588, and Diameter NAS Application RFC 4005 • Specify RADIUS format of Diameter TLVsAffects RADIUS documents ??? IETF 64, Vancouver Canada

  12. 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 AVPs • The two vendor spaces end up independent, but can be used by either. IETF 64, Vancouver Canada

More Related