[RADIATOR] AuthBy DIAMETER

[Sami Keski-Kasari]

Hello Stefan,

On 08/05/2013 04:04 PM, Stefan Winter wrote:

>> We are now preparing initial release of Radius to Diameter translation
>> gateway for Radiator.  Currently we have implemented limited support for
>> DIAMETER base RFC 6377 and full support for NASREQ RFC 4005.
>
> You should probably not care about RC4005 any more. Its successor is
> almost ready, and was specifically created to address major deficiencies
> in RFC4005. The deficiencies were to such an extent that common belief
> in the IETF is "nobody uses this".
>
> See here for the successor draft spec:
>
> http://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/

Thanks for pointer to that draft.

It appears there are people using 4005.

Almost all of our Diameter customers are using Diameter in 3GPP 
environments. Those specs use RFC 3588 and RFC4005 as their base.
The new Diameter Base RFC 6733 is good because it is backward compliant. 
If upcoming NASREQ RFC is not backward compliant then I think that we 
need to support 4005 for a long time.

>> Our implementation is ready for public beta testing and we are looking
>> for volunteers for testing our translation gateway.
>>
>> If you are willing to test our Radius to Diameter translation gateway,
>> please reply directly to me and tell me about your intended test
>> environment and test plans.
>
> Out of curiosity: one of the many problems of RFC4005 was that it was
> syntactically impossible to translate a Diameter attribute of length
>> 253 Bytes into a RADIUS attribute; for obvious reasons.
>
> RADIUS has meanwhile specified "long" attributes, making this
> translation possible. Does your Diameter gateway already include support
> for extended RADIUS attributes? I'm speaking of RFC6929:

If you take a look of section 8 (Diameter Considerations), it seems not 
to agree with your view of using that RFC in Radius to Diameter 
translation :).

I think that problem with RFC6929 is that IANA has allocated only vendor 
specific attributes. So if we start using them we have to use it under 
vendor specific field and it will never be compliant with anybody. It is 
not a problem if you are processing things locally but it is problem if 
you need to proxy them.

So if upcoming NASREQ RFC will remove all radius<->diameter translation 
instructions I think that we will need separate RFC addressing to that. 
Otherwise all vendors starts using own solutions or we will continue to 
support RFC4005 instead of newer RFC. If there is some group doing 
translation RFC we will be happy to contribute.

I think we will add support for RFC6929 to Radiator in the near future
so that people can use it in local translations.


Best Regards,
  Sami

-- 
Sami Keski-Kasari <samikk at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.