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

From: jouni korhonen <[email-masked]>
Date: Mon, 2 Aug 2010 13:54:19 +0300

As discussed during the Maastricht DIME WG meeting, the chairs agreed to confirm the adoption of draft-zorn-dime-rfc4005bis-01 as the WG Item. The work regarding RFC4005bis has been around the corner for some time and discussed several times among AAA Doctors. There was support for the adoption during the WG meeting.

The one week poll ends 9-Aug-2010, 23:59 (CEST+1).. Silence counts also as "yes", so unless you have a strong reason to disagree (like the North Pole melts or Diameter will become obsolete due the adoption of this draft), then express your "no" on the list with a proper reasoning why. Technical details on the actual draft content can be handled later (if/when the document gets adopted).

- Jouni & Lionel

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 05 Aug 2010 15:50:21 +0900

Hello,

"[...] RFC 4005 in general and RADIUS-Diameter
interoperability in particular. In Anaheim we decided to just try removing
the RADIUS-it had ever actually been deployed) & see who screamed in
pain ;-)"

If the main rationale for this revision is just to remove the
RADIUS/Diameter translation explanations, as the above excerpt seems to
indicate, I would rather see the adoption of this document postponned
until a suitable mechanism for RADIUS/Diameter interaction is described
somewhere. And, for information, the mechanism described in 4005 is
implemented in freeDiameter, and so far, it works well :)

My 2 cents,

Best regards,
Sebastien.

Le 02/08/2010 19:54, jouni korhonen a écrit :
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 5 Aug 2010 09:21:36 +0200

Sebastien Decugis [mailto://[email-masked]] writes:

> somewhere. 

Would you then consider
http://www.ietf.org/id/draft-zorn-dime-radia-gate-01.txt to be unsuitable?
Be that as it may, however, the point is that it's very unclear whether such
functionality is actually useful...

> And, for information, the mechanism described in 4005 is
> > As discussed during the Maastricht DIME WG meeting, the chairs agreed
> to confirm the adoption of draft-zorn-dime-rfc4005bis-01 as the WG Item.
> The work regarding RFC4005bis has been around the corner for some time
> and discussed several times among AAA Doctors. There was support for the
> adoption during the WG meeting.
> >
> > The one week poll ends 9-Aug-2010, 23:59 (CEST+1).. Silence counts
> also as "yes", so unless you have a strong reason to disagree (like the
> North Pole melts or Diameter will become obsolete due the adoption of
> this draft), then express your "no" on the list with a proper reasoning
> why. Technical details on the actual draft content can be handled later
> (if/when the document gets adopted).
> >
> > - Jouni & Lionel

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 05 Aug 2010 16:52:09 +0900

Hello again,

> http://www.ietf.org/id/draft-zorn-dime-radia-gate-01.txt to be unsuitable?
Yes. That document describes how to use Diameter as a tunneling protocol
(I don't understand the purpose of this, but anyway), it does not
address the translation of the RADIUS messages to Diameter.

> functionality is actually useful...
First of all, not being useful is a good enough rationale to revise a RFC?

Secondly, I believe that yes, this mechanism is actually useful, to help
transition to Diameter. It provides a way to interconnect several realms
where some use RADIUS while others already moved to Diameter (example:
take a consortium like EDUROAM. How would you migrate someday to
something else that RADIUS, without a translation mechanism?)

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 5 Aug 2010 10:41:54 +0200

> address the translation of the RADIUS messages to Diameter.

Exactly.  Since it is manifestly impossible to perform the reverse
translation (from Diameter to RADIUS) it seems rather pointless.

> First of all, not being useful is a good enough rationale to revise a

Yes.

> something else that RADIUS, without a translation mechanism?)

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.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Aug 2010 10:46:14 +0200

> First of all, not being useful is a good enough rationale to 

Let me try to argue that yes, it is. A section in a Proposed Standard
that is not useful may lead to (at least) two counter-productive
effects: 
- efforts are being made for implementation that result in useless code
with the risk of bugs and wasting resources
- the function that is described by the 'not useful' section seems to
apparently solve what may be a real problem, discouraging search other
ways of solving the problem (as 'there already is a standard way')

I will let the RADIUS and Diameter experts decide whether the
translation mechanism between RADIUS and Diameter as described in
Section 9 of RFC 4005 belongs here.

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sebastien Decugis
> Sent: Thursday, August 05, 2010 10:52 AM
> To: Glen Zorn
> Cc: [email-masked]
> Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01
> 
> 
>  Hello again,
> 
> > Would you then consider
> Yes. That document describes how to use Diameter as a 
> tunneling protocol (I don't understand the purpose of this, 
> but anyway), it does not address the translation of the 
> RADIUS messages to Diameter.
> 
> > Be that as it may, however, the point is that it's very unclear 
> > whether such functionality is actually useful...
> Secondly, I believe that yes, this mechanism is actually 
> useful, to help transition to Diameter. It provides a way to 
> interconnect several realms where some use RADIUS while 
> others already moved to Diameter (example:
> take a consortium like EDUROAM. How would you migrate someday 
> to something else that RADIUS, without a translation mechanism?)
> 
> Best regards,
> Sebastien.
> 
> --
> Sebastien Decugis
> Research fellow

---

From: jouni korhonen <[email-masked]>
Date: Thu, 5 Aug 2010 18:20:49 +0300

Hi,

<not in a chair mode>

> implemented in freeDiameter, and so far, it works well :)

I guess we need such document that describes the basics of the RADIUS/Diameter interactions eventually. However, I just do not believe a generic translation works in situations that actually are interesting and non-trivial.

One approach that can be done already today (and to my best knowledge is already used) is just documenting the RADIUS/Diameter interactions per application within a specific system deployment.

- Jouni

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 06 Aug 2010 10:31:07 +0900

Hello,

> translation (from Diameter to RADIUS) it seems rather pointless.
I tend to disagree. If the attributes your AAA server is sending to the
AAA client can be conveyed in RADIUS (a requirement for the tunneling
mechanism) then they can also be translated from Diameter to RADIUS. I
see absolutly no situation where the tunneling mechanism would perform
better than the translation mechanism, from a functional point of view.
Would you care putting some light on this for me?

> Diameter and it appears as if nobody ever will.
I am not so pessimistic about Diameter :)

>   Regarding EDUROAM, Diameter
You are implying that each domain can retire its RADIUS server only when
*all* the domains have moved all their clients to Diameter... This
reasoning may be possible in a single-domain context, but it does not
hold in a multi-domain roaming consortium case.

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 06 Aug 2010 10:47:21 +0900

Hello Dan,

> Let me try to argue that yes, it is.
It is good to know for the general case.

>  A section in a Proposed Standard
That would be the case if that section was claimed as "mandatory to
implement". It is not the case in RFC4005. So, people will implement it
only when they plan to actually use it.

> ways of solving the problem (as 'there already is a standard way')
I personnally believe that the solution presented in RFC4005 is as good
as it can be, and there will be no better solution for solving this
particular problem. Hence, I would rather keep this text around, until a
new draft comes to present a better solution and update the RFC4005 at
that time. It was the intent of my initial comment.

> Section 9 of RFC 4005 belongs here.
Since this section describes how to translate RADIUS to Diameter NASREQ
application (and not the general translation case), I think it makes
sense to have this inside this document. But I have no objection should
the group decide to reorganize the set of documents to group all
RADIUS/Diameter translation sections from all documents into one big
guideline. It is a large work.

Best regards,
Sebastien.

---

From: <[email-masked]>
Date: Fri, 6 Aug 2010 10:43:17 +0200

[chair-hat out] 

Hi Sebastien,

See below.  

Lionel

> I tend to disagree. If the attributes your AAA server is 
> sending to the AAA client can be conveyed in RADIUS (a 
> requirement for the tunneling
> mechanism) then they can also be translated from Diameter to 
> RADIUS. I see absolutly no situation where the tunneling 
> mechanism would perform better than the translation 
> mechanism, from a functional point of view.

I think that the idea is not to say that RADIUS/Diameter interworking is
not possible at all. The idea is more about to acknowledge the fact that
RFC 4005 can not remain the de-facto and the only reference for
RADIUS/Diameter translation as this section is under specified and not
applicable anyway to all RADIUS/Diameter interworking scenarios. As
something has to be done, it is proposed to remove anything about
RADIUS/Diameter translation from RFC 4005. The NASREQ application is
self-consistent without this part.

If any interworking solution between RADIUS and NASREQ needs to be
standardized (some people have doubts about it), it would have to be
documented in a separate document. After, any new application that would
require interworking with RADIUS will have to describe how to do it in
its own documentation. 

> 
> > The problem is that apparently nobody has _ever_ transitioned from 
> > RADIUS to Diameter and it appears as if nobody ever will.
> *all* the domains have moved all their clients to Diameter... 
> This reasoning may be possible in a single-domain context, 
> but it does not hold in a multi-domain roaming consortium case.

About roaming issues, I think that we should make the difference between
inter-domain and intra-domain. If there exists a solution for
RADIUS/Diameter interworking, each domain could rely on either RADIUS or
Diameter, and the interworking solution would be applied *only* between
AAA servers/proxies. In intra-domain, if a single AAA server can support
both RADIUS and Diameter clients, the migration path is quite simple,
no?

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 06 Aug 2010 18:12:46 +0900

Hi Lionel,

Thank you for answering my comments. Please see bellow.

> both RADIUS and Diameter clients, the migration path is quite simple,
Yes, my concern was about interconnecting different domains together,
when some of the domains want to move to Diameter. In this situation, a
translation mechanism is mandatory, I think.

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Aug 2010 12:43:40 +0200

Sebastien Decugis [mailto:[email-masked]] writes:

> mechanism) then they can also be translated from Diameter to RADIUS. 

Precisely the problem: the necessity to provide for RADIUS compatibility
unnecessarily constrains the content of the Diameter AVPs.  In fact, NASREQ
is not so much a Diameter application as RADIUS in a Diameter wrapper.

> I

Removing the need to artificially limit the length of the NASREQ AVP
payloads to 253 (or even 4073) octets would make NASREQ into a _real_
Diameter application.

> RADIUS to

I'm not pessimistic, just realistic: virtually the only Diameter deployments
of any consequence of which I'm aware have been green-field.  Rumors come
from WiMAX about migration from RADIUS to Diameter but I'll believe that
when I see it ;-).

> hold in a multi-domain roaming consortium case.

Care to give some sort of rationale for this statement?

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Aug 2010 14:23:39 +0200

> translation mechanism is mandatory, I think.

Justification, please?

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 09 Aug 2010 10:19:29 +0900

Hi,

>> translation mechanism is mandatory, I think.
Well, if domain A "speaks" only Diameter, I don't see how domain B who
speaks RADIUS can interconnect, except with a translation mechanism.

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 09 Aug 2010 10:34:32 +0900

Hi again Glen,

> is not so much a Diameter application as RADIUS in a Diameter wrapper.
This holds only when the Origin-AAA-Protocol AVP is present; otherwise
there is no such limitation in the RFC, as far as I know.

> payloads to 253 (or even 4073) octets would make NASREQ into a _real_
(see previous comment)

> Care to give some sort of rationale for this statement?
Well, assume domain A is still using RADIUS and domain B has moved all
its equipment to Diameter.
Now a user from domain B is accessing the network through a NAS in domain A.

NAS-A -> RADIA agent (in RADIUS)
RDR -> domain B in Diameter.
Now, one needs to de-tunnel the RADIUS message from the RDR and then
have a RADIUS stack to interpret this message, right?
Hence my comment that we cannot get rid of RADIUS in domain B until all
domains in the consortium have moved to Diameter...
In addition, with RADIA you loose the benefit of Diameter applications
allowing to route different applications to different servers.

Best regards,
Sebastien.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 11 Aug 2010 13:10:28 +0300

Hello all,

Chairs (and the WG) have decided to adopt draft-zorn-dime-rfc4005bis-01 as a Dime WG document. Glen, go ahead and post the -01 as the draft-ietf-dime-rfc4005bis-00.

- Jouni & Lionel

---

From: Stefan Winter <[email-masked]>
Date: Fri, 13 Aug 2010 11:12:17 +0200

Hi,

> pointless tunneling protocol, retiring their RADIUS server when the

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

-- 
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: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 13 Aug 2010 11:17:15 +0200

> self-consistent without this part.

That seems like a good reasoning.

So: I support adoption of this document.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 15 Aug 2010 16:37:27 +0700

Stefan Winter [mailto://[email-masked]] writes:

> 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

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

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

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.

> 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

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

> need not look any further.

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

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 15 Aug 2010 17:03:34 +0700

> speaks RADIUS can interconnect, except with a translation mechanism.

If 'A' is the VAAA & 'B' is the HAAA, translation is impossible anyway
unless A respects the RADIUS rules WRT AVP & message length.  IIRC, though,
we're talking about the opposite case, where 'B' is the VAAA & 'A' is
transitioning from RADIUS to Diameter.  This implies that there _is_ a
RADIUS server in the 'A' realm (otherwise it would not be in transition) so
I fail to see why the RADIA approach wouldn't work...

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 15 Aug 2010 17:19:17 +0700

>  Hi again Glen,

Hi, sorry for the slow reply!

...

> have a RADIUS stack to interpret this message, right?

Yes; presumably this would be the RADIUS server that they are retiring.

> domains in the consortium have moved to Diameter...

OK, but it was the assertion that "This reasoning may be possible in a
single-domain context, but it does not hold in a multi-domain roaming
consortium case" that I was questioning.

> allowing to route different applications to different servers.

I'm confused: isn't the only Diameter app that deals w/RADIUS stuff NASREQ?

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 15 Aug 2010 17:48:53 +0700

> only when they plan to actually use it.

This would be true only if all NASREQ implementations are custom jobs.  I'm
not that pessimistic about Diameter ;-).

> particular problem. 

Obviously, I disagree :-).  A possibly interesting historical note: but for
political reasons, the RADIA approach would be the one in RFC 4005.

...

> guideline. It is a large work.

Actually (as Stefan noted) the work is very slight: "It doesn't work".

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 16 Aug 2010 10:37:41 +0900

Hi,

Le 13/08/2010 18:12, Stefan Winter a écrit :
>  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.
Ideally, the RFC4005 bis will contain this sentence, with an explanation
of why it would not work.
Personnally, I still don't see why is that. I agree that in a few cases
there are untranslatable attributes, but then:
- as long as the Diameter server is aware of a RADIUS end point, it can
avoid these attributes.
- in any case if we require to send this large data, RADIA will not help.

But, now the draft has been accepted as a WG item, so I guess there is
little interest in continuing this argument ^^.

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 16 Aug 2010 10:44:39 +0900

Hi Glen, all,

> consortium case" that I was questioning.
This implies that when you are part of a consortium, you are to maintain
your RADIUS equipment as long as at least one of the domains in the
consortium has not completed its transition to Diameter -- which costs
money. This certainly will discourage any member of the consortium to be
the first to transition, and so it will (did) not happen...

> I'm confused: isn't the only Diameter app that deals w/RADIUS stuff NASREQ?
No. See for example RFC4740 section 12.1 (Diameter SIP).

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 16 Aug 2010 10:56:16 +0900

Hi again Glen, all,

> political reasons, the RADIA approach would be the one in RFC 4005.
It is indeed an interesting note, thank you for telling. It would tend
to indicate that both mechanisms are wanted, right?

Note that although I think RADIA needs some more design work (e.g. how
the RADIUS security is handled) I believe it is useful. It simply solves
a different problem than the translation mechanism. I think both
approaches are useful, and my initial comment was only that I don't see
the benefit of discarding the translation mechanism.

> Actually (as Stefan noted) the work is very slight: "It doesn't work".
I'd like to ask: "prove it" if I dare ;) We are using it (in a very
small environment, agreed) and it works quite well...

Best regards,
Sebastien.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Aug 2010 08:27:48 +0200

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

  Radiator, for quite a while now.  Radsecproxy for quite a while.
FreeRADIUS (~1 year, available only in "stable" branch of revision control).

  The TCP draft (draft-ietf-radext-tcp-transport) was first submitted in
November 2008, well after the Radiator and Radsecproxy implementations
had been written.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Aug 2010 11:52:45 +0200

Hi,

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

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.

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

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.

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

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

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

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

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

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

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

> 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

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Aug 2010 12:09:59 +0200

Hi,

> small environment, agreed) and it works quite well...

It can translate back and forth in many cases, but not all. Example: at 
some point, your Diameter server wants to send Filter-Rule AVPs to 
restrict the client's access to some resources. The total length of all 
filter rules which the Diameter server adds to the reply is 4100 Bytes 
long. RADIUS messages can't exceed 4096 Bytes. Translation will fail. 
QED. :-)

(BTW, I looked up whether RFC4005 discusses the 4096 bytes boundary, but 
Ctrl+F for "4096" didn't give any match at all. I assume it has to be 
somewhere... anyone care to hint me at the appropriate section?)

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 17 Aug 2010 10:26:53 +0900

> It can translate back and forth in many cases, but not all. Example:
> at some point, your Diameter server wants to send Filter-Rule AVPs to
> restrict the client's access to some resources. The total length of
> all filter rules which the Diameter server adds to the reply is 4100
> Bytes long. RADIUS messages can't exceed 4096 Bytes. Translation will
> fail. QED. :-)
Thank you for the real-life example :)
Anyway since the server receives an indication that RADIUS translation
is happening (thanks to Origin-AAA-Protocol AVP) the server is (at
least, should be) able to handle this situation in a not-too-ugly way.
Put otherwise: if we are using pure RADIUS (or RADIA), we face the same
problem to convey this Filter Rule. What is the solution in that case?

Sebastien.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 17 Aug 2010 12:40:04 +0200

Hi,

> problem to convey this Filter Rule. What is the solution in that case?

There is none. In a RADIUS world, such complex filter rules can't exist 
(or at least, not be transmitted from server to client).
In a Diameter world, they can; which is the source of the translation 
problem.

Of course a Diameter server can act thoughtfully, check the 
Origin-AAA-Protocol, and craft less complex filter rules which don't 
fill 4096 Bytes for that retarded RADIUS NAS. It will lead to different 
permissions for the connecting end users though, depending on which NAS 
they connect to, which is at least confusing.

Note also that even if that Diameter server manages to cram its 
Filter-Rule into say 3900 Byte, there is still the problem that on the 
end (back translation to RADIUS for the NAS), a new RADIUS packet is 
constructed, with an unknown number and unknown size of attributes 
besides the ones that the Diameter server had. The resulting RADIUS 
packet could then be beyond 4096 again, even if the home Diameter server 
paid attention. This creates these highly unsatisfying "sometimes, it 
just doesn't work" situations.

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 17 Aug 2010 19:48:38 +0900

Hi Stefan,

> It will lead to different permissions for the connecting end users
> though, depending on which NAS they connect to, which is at least
> confusing.
I see, thank you for the detailed explanation.

But, I still believe that "works sometimes" is better than "never works"
-- although it might be confusing and needs to be properly reported by
implementations when the situation occurs.
I guess it is a matter of taste here.

Best regards,
Sebastien.