Re: The RADIUS Design Model

[Alan DeKok <aland@deployingradius.com>]

Hannes Tschofenig wrote:
> The draft points to this policy language but only hints that there is a
> "simple" policy language in place that understands some basic data types and
> is also able to perform some simple processing actions. 

  RADIUS servers going back to Livingston have had a "simple" policy
language: the "users" file.  I'm not aware of any major server
implementation that has *less* functionality than that.

> The initially considered RADIUS model did not consider the policy aspect, I
> believe, and without describing of what existing implementations do in that
> space it will be difficult to come to an agreement.

  I'm not sure why.  Do you have specific issues with the document where
you think that the text doesn't apply to most RADIUS server
implementations?  If so, that would mean the text needs fixing.

> Unfortunately, it seems that the implementation internals and the
> anticipated deployment model have an impact on the way how RADIUS attributes
> are defined.

  I'm not sure how.  The document describes a high-level and simplistic
model of RADIUS attribute definitions.  If this model does not apply to
most implementations, the model needs to be fixed.

  As Dave has pointed out, RADIUS has *never* had a standard way to
describe and transport complex data structures.  So the model continues
the traditional practice of recommending simple structures.

  We cannot require the document to describe how to define complex
structures in RADIUS, because that would mean re-defining the protocol,
which is out of scope of the document.

> Unfortunately, I don't have a good idea on how to quickly solve the issues
> raised above. To make it worse I have two additional questions: 
> 
> 1) How come did
> http://tools.ietf.org/wg/radext/draft-ietf-radext-extended-attributes/ got
> stuck again? 

  I'll avoid that question.

> 2) Why does nobody write a document with a punch of commonly used RADIUS
> data types that most of the implementations are using already? It would make
> the design of attributes so much easier! Every RADIUS dictionary
> implementation already offers more than just the basic data types. Maybe the
> specifications should catch up with implementation practice here. 

  That document could be useful.  I've pointed out before that the data
types defined in the specifications (e.g. "address") do not match the
implementations (e.g. ipaddr).

  But I'm wary of that effort.  The "guidelines" text which suggested
RFC 3162 defined an IPv6 address type was the target of much hostility.

  One reason I'm so surprised at the request to describe a more
complicated RADIUS model is that there's usually opposition to
describing the current model.  Since one depends on the other, it would
seem that describing a more complicated model is impossible, too.

  Alan DeKok.

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