RE: : Re: authors 48 hours: RFC 4005

Hi,

> Instead of a flag, I would think an Origin-Host-Protocol AVP 
> would be useful.

I agree.


> It should probably be re-fitted into the Base, and included in all
> Diameter requests.

I think it must not be mandatory in all Diameter requests.
There is no need for it if the Origin-Host-Protocol id
is Diameter.


BR,
Mikko


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> ext David Mitton
> Sent: 03 June, 2005 08:43
> To: [email protected]; 'Bernard Aboba'
> Cc: [email protected]
> Subject: RE: [AAA-WG]: 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.
> 
> ... 
> 
>