RE: : Re: authors 48 hours: RFC 4005

On 6/1/2005 02:04 PM, Glen Zorn (gwz) wrote:
>Bernard Aboba <> supposedly scribbled:
>
> > This looks fine to me.  Any objections?
>
>I give up.  In the message containing my non-suggestions
>(non-suggestions because they didn't begin with the word "Issue" --
>talk about quibbling!) I listed 3 options for (partially) fixing
>this problem: a flag in the Diameter header signifying that the
>packet had been translated from RADIUS, the creation of a new AVP
>signifying the same, or the artificial limitation of the length of
>Diameter AVPs w/codes <= 255.  Of these, the last was clearly (to
>me, anyway) the worst possible choice, included only for
>completeness.  I suppose that I shouldn't be surprised that that was
>the route taken...

Well, before I sent my message, I went back and re-read the list, and your 
email of 4/19/05.
Let's look at it again....


>From: "Glen Zorn (gwz)" <[email protected]>
>To: "'Bernard Aboba'" <[email protected]>
>Cc: "'David Mitton'" <[email protected]>, <[email protected]>,
>         "'Pat Calhoun'" <[email protected]>,
>         "'Bert Wijnen'" <[email protected]>,
>         "'Kessens, David'" <[email protected]>, <[email protected]>
>Subject: RE: [AAA-WG]: Re: authors 48 hours: RFC 
>4005  <draft-ietf-aaa-diameter-nasreq-17.txt>
>Date: Tue, 19 Apr 2005 20:01:36 -0700
>
>Bernard Aboba <mailto:[email protected]> supposedly scribbled:
>
> >> Are you serious?
> >
> > Yes, I am.
> >
> > You have raised an issue with the NASREQ document that David has
> > attempted to correct.  Apparently, you don't feel his proposed
>text
> > makes sense.  The document is now in AUTH48, so if you would like
>to
> > propose alternative text, there's no better time to do so.
>
>There are actually a couple of problems here: the first, which I
>think is pretty well solved by Dave's other draft, has to do with
>translating RADIUS VSAs that do not conform to RFC 2865's
>recommended format.  The other, much more fundamental, problem is
>that of general interoperability between RADIUS & Diameter.  For
>example, in order to be able to respond reliably to requests from
>RADIUS clients (or Diameter requests that have been translated to
>RADIUS and back to Diameter, if this is allowed), a Diameter
>"server" must adhere to the RADIUS rules regarding both attribute
>(AVP) and message length.  Unfortunately, there doesn't appear to be
>any way for a Diameter "server" to tell whether a given request was
>originated by a RADIUS client.  There are a couple of ways to deal
>with this issue:

(1)

>  we could use one of the unused flags in the
>Diameter packet header and set it when a Diameter message passes
>through a RADIUS->Diameter gateway; this would require special
>purpose logic in the Diameter "server", however it would ensure that
>the RADIUS rules were followed (if possible).

Well, I'm not convinced that the server MUST know the origin of the request.
Operationally that would depends on whether the response would violate 
RADIUS rules.
I'm not sure what service the server would return to a NAS that wouldn't 
work, but there is
a possibility, so lets say there's something we want here.

Some RADIUS systems solve this (in particular for VSAs) by having the 
network admin configure a NAS model table along with the IP address.  They 
could add a RADIUS/Diameter protocol type.  But that's out of protocol.

But I've actually always liked identifying information in 
requests.  Instead of a flag, I would think an Origin-Host-Protocol AVP 
would be useful.  (personally, I'd love to see Make, Model, and version 
number too)  With a protocol enumeration, heck someone could build a TACACS 
to Diameter gateway.

I think this is a good idea.  It should probably be re-fitted into the 
Base, and included in all
Diameter requests.  Likewise, a RADIUS equivalent attribute could be created.



>  OTOH, section 4.1 of
>RFC 3588 states that "AVP numbers 1 through 255 are reserved for
>backward compatibility with RADIUS, without setting the Vendor-Id
>field.  AVP numbers 256 and above are used for Diameter, which are
>allocated by IANA (see Section 11.1)".  If we were to take this
>passage seriously and literally, we should define (in NASREQ) that
>AVPs 1-255 have a maximum data length of 252.  Of course, we would
>then need to define new, equivalent Diameter AVPs without this
>restriction or live with it.

(2)
I did add this, but there is the cavet, that a Diameter system COULD send 
an VS AVP with data longer than 252, it just will NOT be forwarded to RADIUS.


>   The easiest way to deal with
>translation, though, is to avoid it altogether, so the option I much
>prefer is to extend Dave's I-D regarding RADIUS VSAs to the entire
>RADIUS message and simply encapsulate it in a single Diameter AVP in
>the gateway.  A RADIUS message will easily fit into a Diameter AVP,
>after all, and this technique would ensure that all the RADIUS rules
>were followed.  Of course, some may object that this would just turn
>the Diameter server into a front-end processor for a RADIUS server,
>but the alternative seems to be to turn the Diameter server _into_ a
>RADIUS server (of sorts, at least).

(3)
Well this latter suggestion is silly, since it creates two methods of 
attribute encapsulation: RADIUS and Diameter.  The translation agent will 
take care of this problem so that the Diameter system can concentrate on 
semantics of the data.  This is were the problems are.

>  This would fulfill what I
>recall to be the original goal of enabling a graceful transition
>from RADIUS to Diameter (server first) -- that is, enabling RADIUS
>clients to use a Diameter server with as little reconfiguration as
>possible.

Since NASreq covers all basic RADIUS attributes, I think this would be 
possible today.
Since authorization attribute sets are typically tailored to the NAS, I'm 
not sure where/when this becomes a problem.

>If we insist that Diameter "clients" be capable of
>communicating with RADIUS servers or that Diameter messages be
>forwarded through RADIUS-based AAA networks then I suspect that a
>far greater number of translation rules than are included in the
>current NASREQ draft will be necessary, but I consider that that is
>non-starter anyway since in general it is not possible to translate
>Diameter into RADIUS.

I don't see the problem with wanting Diameter clients to be capable to 
communicate with RADIUS servers, and I disagree with your conclusion.  I 
think it is possible and not that hard.
That is not to say that there will not be untenable situations, but that 
really depends on what you are trying to do.

Diameter has more capabilites than RADIUS, almost by definition, so 
expecting all situations to work without some compromises is 
unreasonable.  But the intersection of capabilities I'm sure is very useful.


So where does that leave your 3 suggestions:

1) Origin-Protocol-Type - I think that deserves consideration either in my 
draft or at the Base level.
2) VS AVP < 252 was included.
3) Rejected.

But that's my opinion.  The WG consensus counts for more.

I would also like to point out that, last I looked, Proposed Draft status 
is not the end of the process.   There are two more stages to go 
though.   There were subtantial changes made to RADIUS between RFC 2058 and 
2138. But practically speaking, I'm sure people have already built products 
on NASreq some time ago.  At this time we have to move this forward just to 
solidify our support.

More importantly if there are problems, the WG should be pursuing workable 
solutions, not throwing hand grenades or giving up.

Dave.





Dave.

...