RE: RFC 2882 and new Service-Type

["david@mitton.com" <david@mitton.com>]

Let be re-iterate some of Dave's comments....

The purpose of RFC 2882 was to indicate the nature and scope of 
"extentions" to RADIUS that were seen in practice.  I have often called 
it by a name that is not part of IETF nomenclature, a "Worst Practices" 
document.

The goal of the document was to bring some of these issues to light, 
so that hopefully they would be addressed by the AAA movement at the 
time.  The politics of the situation at the time didn't seem to think 
there was much to be done in the area.   I was trying to illustrate the 
reality of the situation.  One prominent vendor objected vocally to his 
products being described there.

Also note that it preceeds RFC 3575, and some of the sections quoted 
below have probably been tweaked in response to it.


That said, being the author of the VSE concept, I still think it has 
merit.  But it does suffer the arguments given here and later in this 
thread.  If it were baked into the protocol somehow, then it would 
benefit from the standard.   

As an ad-hoc extention, VSEs can and will cause interoperability 
problems.   I ran into at least one RADIUS server that couldn't handle 
them at all because they exceeded the bit width of the variable they 
had carefully optimized to carry the known values.    While this is an 
example of a short sighted implementation, I think a standard should be 
very clear on what and where values can be extended.  And since the WG 
has not accepted the VSE scheme, I would not recommend it's use in a 
product today.


David Mitton.


----Original Message----
From: d.b.nelson@comcast.net
Date: Apr 10, 2007 7:19 
To: "Alan DeKok"<aland@nitros9.org>, "Victor Gamov"<vit@lipetsk.ru>
Cc: <radiusext@ops.ietf.org>
Subj: RE: new Service-Type

Alan DeKok writes ...

>   IANA performs the allocations itself.  You can request 
> that IANA allocate numbers for those Service-Type values.  
> But you cannot control which numbers IANA allocates.

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

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute.  Additional values can be
   allocated by the Designated Expert.  The exception to this policy 
is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute 
have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be 
accompanied
   by a published RFC.

Allocation of new Service-Type values requires IETF Consensus.

>   If there is only one application that uses these two 
> Service-Types, my suggestion would be to allocate a vendor-
> specific enumeration.  See RFC 2882, Section 2.2.1 for how this
> is done.
> 
>   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.

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

Regards,

Dave Nelson
--

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