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

["Glen Zorn" <[e-mail]>]

Stefan Winter [mailto://[e-mail]] writes:

>   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. 

I see.  Where did the actually usable implementation of RADIUS over TCP come
from?

> 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.

Of course, my mistake for not realizing that initial prototype == published
RFC.

> 
> 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. 

Yes.

> If the end auth server is a pure RADIUS server, someone else has
> to do it for him. 

Why (& how) would a Diameter message be delivered to a pure RADIUS server?

> 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? 

The only element relevant to authentication/authorization in a RADIA message
is the encapsulated RADIUS message; any other Diameter AVPs that may be
present are only for transport purposes.

> 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? 

Then the Diameter server in question is broken; nevertheless, what happens
if a NASREQ app server does the same thing today?

> 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.

Because it's unnecessary; if there is no RADIA app server in the destination
realm, a standard "undeliverable message" error must be returned.  That
point should be made in the draft.

> 
> 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. 

OK.  How, then, is RFC 4005 (one-way) translation a transition mechanism?
As I have pointed out many times, the end NASREQ server must understand how
to respond to the request in a translatable way; if transition is complete,
that dead code undoubtedly remains.  OTOH, the RADIA servers can be retired,
along with the associated RADIUS servers.

> 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.

& is precisely what RADIA supplies, but w/o the overhead of "translation".

> 
> 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.

Lots of people are curious about lots of things...

> 
> 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]
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime