Thanks for writing this up.
As you note there are different considerations for a new attribute type,
depending on whether it is being sent or received, and what protocol
(Authentication vs. Accounting) it is being used in. The question is how
these considerations are reflected in Section 2.1.3 and Appendices A. Do
you have changes that you'd like to propose?
In terms of review of existing types, Section 2.1.1 goes over basic types
defined in existing RADIUS RFCs, and Appendix B surveys use of complex
attributes in existing RADIUS RFCs. The focus is on existing RADIUS RFCs,
since the guidelines are primarily focused on design of attributes within
the standard RADIUS attribute space.
-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On
Behalf Of Hannes Tschofenig
Sent: Wednesday, January 20, 2010 11:23 AM
To: radiusext@ops.ietf.org
Subject: The RADIUS Design Model
Hi all,
sorry for joining this discussion so late.
In Section 2.1.3 the document says:
"
One of the fundamental goals of the RADIUS protocol design was to
allow RADIUS servers to be configured to support new attributes
without requiring server code changes.
"
We need to differentiate at least four cases here:
1) RADIUS Server Data Provisioning
A RADIUS server consists of the RADIUS protocol implementation (often
implements a bunch of other protocols as well) and has access to a database.
Such a database can come in various flavors depending on the amount of data
being handled. In the simplest case it is a text file.
When new data is added to the database and then it may already at this point
in time relate somehow to the data types being used when transmitted over
the wire. Everything can be encoded as a RADIUS string data type so that it
can be transmitted in RADIUS; so that's not really a problem.
For testing purposes it might be useful to have additional a user interface
to enter data manually as well. This user interface might have certain
limitations regarding data types and hence some manual steps might be needed
before the data can be entered into the UI. This is particularly the case
with the encoding of "complex" attributes into a string.
So, is this issue relevant for the document?
Yes, I think so. There is one sentence in the document of Section 2.1.3:
"
* it is easier for the user to enter the data as well-known
types, rather than complex structures; "
It is not clear to whom the term 'user' refers to. How easy or complex it is
for a person operating a RADIUS server to insert values into a database may
depend on a number of things, including support of provisioning scripts or
even user interfaces (largely for testing purposes).
2) RADIUS Server Data Transmission to RADIUS Client
There are 2 cases that need to be considered here:
a) RADIUS server just takes values from the database (more or less without
any further evaluation), and
b) RADIUS server dynamically decide what to return depending on a number of
criteria. This category falls a bit under the item (4).
With item (a) there is not really big impact for the RADIUS server (and
consequently for the RADIUS design guidelines document) as long as the data
being fetched is already in the format that allows the RADIUS server to put
it into a RADIUS attribute.
3) RADIUS Server Receiving Data from RADIUS Client
There are two approaches when it comes to the processing of incoming data on
the RADIUS server side:
a) Treat everything as an opaque object and write to the some storage for
later processing.
b) Perform processing within the RADIUS server itself. This approach is
useful when one wants to make some policy decisions and potentially needs to
interact with other systems in order to react accordingly in response to an
incoming request.
Which approach is the right one depends very much on the intented usage of
the received info.
4) RADIUS Sever Policy Processing (i.e. the business logic)
Some RADIUS servers allow policy decisions to be made based, typically for
the purpose of authorization. These policy decisions need to be implemented
somehow in some programming language and if incoming attributes are used as
input to these policy decisions then their semantic needs to be understood.
How tighly the policy language itself is integrated into the core of the
RADIUS server implementation itself is an implementation choice.
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.
I guess the disagreement is with step (3 - b) and particularly with (4). So,
I believe that there is at least some agreement here.
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. We all have quite
different implementations that all vary from the "historically" defined
model (even thought it was never explicitly written down, I believe).
Unfortunately, it seems that the implementation internals and the
anticipated deployment model have an impact on the way how RADIUS attributes
are defined. I believe it makes sense to say that we want to give guidance
for standardization people to make it as simple as possible for implementers
(at least I hope so). In order to figure to figure out what worked well and
what didn't we would actually have to write code and to then see how
complicated it was (ideally in comparison to another approach). For some of
us it seems that the simplest implemention is to flatten the attributes out
into simpler onces. The down-side of that approach is that we run out of the
attribute space very quickly and defining these "simple" attributes already
requires a "complex attribute encoding" in the style of
http://tools.ietf.org/wg/radext/draft-ietf-radext-extended-attributes/. So,
there is a problem.
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?
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.
Ciao
Hannes
PS: A totally independent issue: Can someone configure the mailing list so
that it displays the working group name in the Subject line? Makes it easier
to recognize the mails belonging to RADEXT and is inline with what other
working groups do.
--
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/>
<<attachment: winmail.dat>>