[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC 2882 and new Service-Type
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"
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
Date: Apr 10, 2007 7:19
To: "Alan DeKok"<firstname.lastname@example.org>, "Victor Gamov"<email@example.com>
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,
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
the Service-Type attribute (6), whose values define new modes of
operation for RADIUS. Values 1-16 of the Service-Type attribute
been allocated. Allocation of new Service-Type values are by IETF
Consensus. The intention is that any allocation will be
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
to be a very bad practice. Please recall that RFC 2882 describes
practices encountered in implementations, but does not necessisarily
recommend these practices. Various versions of the RADIUS Design
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
In my opinion, which is based in part on discussions with the author
2882, that document lists certain practices which ought not to be
encouraged, in the interests of interoperability, but rather which
have resorted to in order to bypass the normal IETF processes.
In any event, new values of Service-Type, VSE or otherwise, do require
allocation and do require IETF consensus.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.