A.1 A brief description of Currently Used Approach

When I started to write GNU Radius, back in 1998, I had two major aims. The first and primary aim was to create a flexible and robust system that would follow the principle of Jon Postel:

Be liberal in what you accept and conservative in what you send.

This, I believe, is the main principle of any good software for Internet.

The second aim was to be backward compatible with the implementations that already existed back then. This seemed to be important (and the time has proved it was), because it would allow users to easily switch from older radius daemon to GNU Radius.

An important part of every complex program is its configuration file. Traditional implementations of RADIUS servers (beginning from Livingston Radius) used a configuration suite consisting of several files, usually located in ‘/etc/raddb’ subdirectory. Its main components were:

‘dictionary’

A file containing translations of symbolic names of radius attributes and attribute values to their integer numbers as specified by RADIUS protocol.

‘hints’

This file was intended to separate incoming requests in groups, based on the form of their login name. Traditionally such separation was performed basing on common prefixes and/or suffixes of login names.

‘huntgroups’

The purpose of this file was to separate incoming requests depending on their source, i.e. on the NAS that sent them and the port number on that NAS. It also served as a sort of simplified access control list.

‘users’

This file contained a users database. It described criteria for authentication and reply pairs to be sent back to requesting NASes.

Among these files, the first two were used for requests of any kind, whereas ‘users’ was used only for Access-Request packets.

Though this configuration system suffered from many inconsistencies, the second aim required GNU Radius to use this approach.

To compensate for its deficiencies and to fulfill the first aim, this configuration system was extended, while preserving its main functionality. A number of additional internal attributes were added, that control radiusd behavior. A new language was created whose main purpose was to modify incoming requests (see section Rewrite). The support for GNU's Ubiquitous Intelligent Language for Extensions (see section Guile) was added, that allowed to further extend GNU Radius functionality.

The present operation model(7) of GNU Radius and its configuration file system(8) emerged as a result of the two development aims described above. Since 1998 up to present, GNU Radius users contributed a lot of ideas and code to the further development of the system.

However, it became obvious that this system presents strong obstacles to the further development. The next section addresses its deficiencies.

This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.