5. Request Comparison Methods

The basic notions about comparison of the incoming requests and why it is necessary were given in Checking for Duplicate Requests. This chapter concentrates on extended methods of request comparison and on the configuration issues.

5.1 Extended Comparison

The default comparison method may fail to recognize duplicate requests. if the originating NAS has modified the request authenticator or request identifier before retransmitting the request. If you happen to use such NASes, you will have to enable extended request comparison to compensate for their deficiencies.

The extended request comparison consists in comparing the contents of both requests. However, blindly comparing each A/V pair from both requests won't work, since many attributes do change their values between successive retransmits. Therefore, radiusd uses only comparable attribute, i.e. a user-defined subset of such attributes that can safely be used in comparison. Thus, extended request comparison works as follows:

1. The comparable attributes are extracted from each request. They form two sorted attribute lists.
2. If lengths of both lists differ, the requests are considered different.
3. Otherwise, the value of each A/V pair from the first list is compared against that of the corresponding A/V pair from the second list. If at least one A/V pair differs, then the requests are considered different. Notice, that values of Password and CHAP-Password are decoded prior to comparison.

To use the extended comparison, follow the procedure below:

1. Select user-defined attribute properties.

   The syntax of dictionary file allows for nine user-defined properties, denoted by characters ‘1’ through ‘9’. You should select one of them to mark comparable attributes for authentication and another one to mark those for accounting. It is strongly suggested that you use PROPERTY statement in your main dictionary file (see section PROPERTY statement), instead of modifying ATTRIBUTE statements in the underlying dictionary files.

   See section ATTRIBUTE statement, for detailed description of attribute property flags.

2. To enable the extended comparison for requests coming from any NAS, declare extended comparison flags in ‘raddb/config’.

   To enable the extended comparison for authentication requests, add to your auth block the statement

   compare-attribute-flag flag;

   The flag is the same symbol you used in the dictionary to mark comparable attributes for authentication.

   To enable the extended comparison for accounting requests, insert compare-attribute-flag statement into the acct block.

3. To enable the extended comparison for requests coming from selected NASes, declare extended comparison flags in ‘raddb/naslist’.

   Add the following statement to the declaration of those NASes, that require using the extended comparison (in flags column):

   compare-auth-flag=flag,compare-acct-flag=flag

   See section NAS List — ‘raddb/naslist’, for a description of naslist file syntax.

5.1.1 An example of extended comparison configuration

In this example configuration, the user-defined flag ‘1’ marks authentication comparable attributes, and the flag ‘2’ marks the accounting comparable attributes.

‘raddb/dictionary’

PROPERTY       User-Name               +12
PROPERTY       Password                +1
PROPERTY       NAS-Port-Id             +12
PROPERTY       State                   +1
PROPERTY       Called-Station-Id       +12
PROPERTY       Calling-Station-Id      +12
PROPERTY       Acct-Status-Type        +2
PROPERTY       Acct-Session-Id         +2
PROPERTY       Acct-Session-Time       +2

‘raddb/config’

        auth {
                max-requests 127;
                request-cleanup-delay 2;
                compare-attribute-flag 1;
        };
        acct {
                max-requests 127;
                request-cleanup-delay 2;
                compare-attribute-flag 2;
        };                

5.1.2 List of attributes that can be declared comparable.

The following attributes can be declared as comparable:

• User-Name
• Password
• CHAP-Password
• NAS-Port-Id
• State
• Called-Station-Id
• Calling-Station-Id
• NAS-Identifier
• Acct-Status-Type
• Acct-Session-Id
• Acct-Session-Time
• User-UID
• User-GID

Notice that this list is by no means an exhaustive one. Depending on a particular NAS other attributes may be safe to be used in comparisons, or, vice-versa, some attributes from this list may not be used. You should carefully analyze packets coming from your NAS before deciding which attributes to mark as comparable.

5.2 Fine-Tuning the Request Queue

As described in Checking for Duplicate Requests, each request is added to the request queue when radiusd starts processing it and is removed from there a certain amount of time after its processing was finished. The configuration parameter request-cleanup-delay defines how long each already processed request is kept in the queue. Its value must be synchronized with the NAS settings.

Each NAS allows to configure two parameters:

Ntimeout

The amount of time in seconds during which the NAS is waiting for a response from radius server.

Nretries

The number of times the NAS tries to re-send the request if it received no response from the radius server.

Of course, these parameters are named differently for different makes of NASes. Refer to your NAS documentation to find out where these values are configured.

In general, these parameters must satisfy the following relation:

     request-cleanup-delay = Nretries * Ntimeout + const

where const is an empirical constant that depends on the average time of processing a single request. Usually its value lies between 0 and 10 seconds.

For example, if the configuration of your NAS sets

   Nretries = 3
   Ntimeout = 10

then your raddb/config should contain:

auth { 
        request-cleanup-delay 40;
};
acct { 
        request-cleanup-delay 40;
};

Notice the duplication of request-cleanup-delay: radiusd uses distinct values for authentication and accounting requests, however most existing NASes do not make such distinction.

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