[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: new Service-Type

I attempted to reply to this message last week, but my provider's webmail
failed me twice and then lost the draft copy.  Sigh....


On 4/10/2007 07:19 AM, David B. Nelson wrote:

Alan DeKok writes ...

...

IANA allocations for RADIUS are controlled by RFC 3575, which reads, in
part, as follows:

...

>   The benefit with the method suggested in RFC 2882 is that
> you do not need IANA approval for the allocation.

I personally consider vendor-specific enumerations, as described in RFC 2882
to be a very bad practice.  Please recall that RFC 2882 describes RADIUS
practices encountered in implementations, but does not necessisarily
recommend these practices.  Various versions of the RADIUS Design Guidelines
draft have included text recommending against using VSEs, in favor of
standard IANA allocations.

RFC 2882 says, in part:

   This technique has not seen any acceptance by the
   working group or other vendors, however, the vendor did accomplish
   the goal of not conflicting with working group additions or other
   vendor values.

In my opinion, which is based in part on discussions with the author of RFC
2882, that document lists certain practices which ought not to be
encouraged, in the interests of interoperability, but rather which vendors
have resorted to in order to bypass the normal IETF processes.


RFC 2882 was written in the NASREQ WG to provide information as to why RADIUS
as it was, needed more work. The re-reading the abstract I see it says it well: 


   This document describes current practices implemented in NAS products
   that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The
   purpose of this effort is to give examples that show the need for
   addressing and standardizing these types of ad-hoc functions.  Since
   many of these features require a matching server support component,
   the ability to deploy and manage interoperable NAS and AAA server
   products is severely hindered.


The document itself, is often called by me, as a "Worst Practices" document.
It is not an example of what to do, but to open peoples eyes to the types of
things people were trying to do, and the problems they create.

In any event, new values of Service-Type, VSE or otherwise, do require IANA
allocation and do require IETF consensus.



I will also point out that RFC 2882 was written before RFC 3575 was published.
And I'm sure some of the portions Dave N. quotes were probably tweaked to prevent some 
of the issues I documented in 2882.

W.r.t. VSEs, Since I created them, I am sympathetic to the rationale.
While they do work, they create the interoperabilty problems Dave points out later in this thread. I encountered at least one RADIUS server that couldn't deal with the attribute values because they'd 
used only a byte internally for the nominal 4 byte integer.
At the time, the code points I needed were additional Service-Types and Acct-Status-Types. Ultimately that product made the VSE code points an option that could be turned off.
In general I would not recommend this type of design, but at the time, the politics of the IETF 
made it seem impossible to get anything RADIUS related even discussed.

Some things have changed....

Dave.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>