Subject: The RADIUS Design Model

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 20 Jan 2010 21:23:24 +0200

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 20 Jan 2010 12:28:32 -0800

WARNING: contains banned part

Subject: RE: The RADIUS Design Model
From: "Bernard Aboba" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Date: Wed, 20 Jan 2010 12:28:32 -0800
List-Id: <radiusext.ops.ietf.org>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Wednesday, January 20, 2010 11:23 AM
To: [email-masked]
Subject: The RADIUS Design Model 

Hi all, 

"

 
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; "

 

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.

1) How come did

Ciao
Hannes

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 21 Jan 2010 09:16:17 +0100

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

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

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

> http://tools.ietf.org/wg/radext/draft-ietf-radext-extended-attributes/ got

  I'll avoid that question.

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