Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01

[Stefan Winter <[e-mail]>]

  Hi,

> The problem is that apparently nobody has _ever_ transitioned from RADIUS to
> Diameter and it appears as if nobody ever will.  Regarding EDUROAM, Diameter
> existed long before EDUROAM but they chose to hack RADIUS in their own way.
> In any case, if they decided to migrate to Diameter they could use the
> pointless tunneling protocol, retiring their RADIUS server when the
> transition was complete.

For the record: Yes, Diameter-the-protocol existed before going into 
production service, and we looked at it. 
Diameter-the-actually-usable-implementation didn't exist, and still 
doesn't - at least not with our requirements. Sebastien's software is 
the first thing that gets vaguely close (too many EAP types missing 
though), and yes, we are evaluating it. Also the 4005 part of it.

More for the record: the first eduroam prototype was online June 2003; 
RFC3588 dates September 2003. Your definition of "long before" violates 
temporal continuity.

The pointless tunneling protocol doesn't help at all. As I pointed out 
at the mic at earlier occasions: the authentication can only take place 
if the final auth server is able to *unwrap* the message into plain 
RADIUS. If the end auth server is a pure RADIUS server, someone else has 
to do it for him. The outer Diameter message might have been decorated 
with untranslatable extra attributes on the way; creating a highly 
ambiguous state of the auth (unwrapped RADIUS might have conflicting 
values to the added genuine Diameter ones? Even if unwrapping works, 
what if a (Diameter) auth server crafts a (Diameter) answer, with 
untranslatable attributes which can never be translated back to a RADIUS 
NAS? If forwarded along multiple proxies, the wrapping entity would need 
signalling on whether there will be an entity along the line to unwrap 
the message at all. If there is none, the tunnel has no other end. 
Signalling of this along multiple hops is unspecified in your draft, if 
I'm not mistaken.

I don't think your draft has answers to these questions.

Anyway, the tunneling requires both ends of the tunnel to understand 
RADIUS. It is thus not a transition mechanism. It's an alternative 
transport. And a not very useful one, IMHO. I acknowledge your point 
that there are apparently some organisations which have hardwired the 
use of Diameter in their specs, while actually wanting to speak RADIUS 
on some paths, and for these organisations, RADIUS disguised as Diameter 
is a tool they might need.

Your point "noone ever transitioned" is true; but for reasons of lack of 
options to do so. It's not exactly fair to blame the RFC for it. FWIW, 
if were to write about RADIUS<->Diameter translation, it would be one 
very short paragraph "This doesn't work." Note that I think that this 
sentence is necessary IMHO; merely not writing *anything* about the 
topic, because "noone ever used it", is not enough. You know, some 
people might be *curious* about the topic, and could be *told* that they 
need not look any further.

Greetings,

Stefan Winter

>> Best regards,
>> Sebastien.
>>
>> --
>> Sebastien Decugis
>> Research fellow
>> Network Architecture Group
>> NICT (nict.go.jp)
>>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]