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

[Stefan Winter <[e-mail]>]

  Hi,

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

That's a good question. Back in the day, I thought we might have been 
the trigger for the Radiator guys (since the prototype system existed 
before I joined the club), but after all I heard, it wasn't us. There 
were apparently actual clients requesting that feature. It did fit quite 
nicely into our requirements, though, and that's why we picked it up.

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

This has nothing to do with published RFCs. You said "Diameter existed 
long before EDUROAM " and I pointed out that you are wrong.

Deployers of IETF standards don't usually have to announce themselves by 
writing an RFC describing their deployment, so I'm completely lost why 
you are talking of a "published RFC" here.

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

That's the point: if one realm in the consortium only speaks RADIUS and 
some other device has wrapped RADIUS into Diameter with RADIA, then 
there needs to be another RADIA-supporting Diameter server somewhere in 
the path to do the unwrapping.
Of course not the Diameter message needs to be delivered, but only the 
contents of the Radius-Message AVP, unwrapped and transformed into plain 
RADIUS.

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

There's a " * [ AVP ] " in the command definition of Radia-Req and 
-Answer. I had the impression that this enables one to send 
non-transport-related content. I may be wrong with that; am I?

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

Why would the Diameter server in question be broken? RFC4005 mentions 
that it is well possible that a Diameter crafts messages with 
untranslatable attributes. That's not brokenness; it is just something 
that might happen. The RFCs answer for oversized attributes, for example 
(which also answers your own question, above, is: "a Result-Code of 
DIAMETER_INVALID_AVP_LENGTH should be returned."

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

Into what does this error message get translated to the originating 
RADIUS NAS? I would guess into an Access-Reject? With a Reply-Message 
containing some hint that it wasn't actually the user's fault? Or a new 
RADIUS attribute to convey the error condition? Or should it just be 
silently discarded? Difficult to say if the draft doesn't specify any 
handling for such error conditions.

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

It is not. As I wrote earlier, the much more honest answer to the 
transition question is "It's not possible."

> As I have pointed out many times, the end NASREQ server must understand how
> to respond to the request in a translatable way

That's not what RFC4005 says. In the above-quoted section 9.5 it is 
acknowledged that untranslatable attributes can occur. There is no "must 
understand how to respond to the request in a translatable way"in the 
RFC. If there were, it would be easier to build a deterministic 
transition path with it. In it's current state, the answer "it will 
often work, but sometimes it just won't" is not a satisfactory answer. 
Funny, 4005bis could have been used to make such a point; but instead, 
now the content gets purged in its entirety. But I'm happy either way.

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

And it may very well be good for this particular and narrow purpose. The 
Abstract and Intro make much higher and undue promises to the reader 
though. How about calling this "transporting RADIUS messages over 
Diameter routing".

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

And if this curiosity originates from them using an SDO's spec, then it 
might be a good idea if the SDO supplies the answer to them.

Greetings,

Stefan Winter

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


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