Table of Contents

NAS requirements

This page contains information about Network Access Server (NAS) requirements for connecting to SyCes.

SyCes uses a RADIUS server for centrally authenticating users and for accounting. Authentication of users against RADIUS is described in RFC2865. How accounting is done is described in RFC2866.

These are the specifications for implementing a Network Access Server (NAS) that communicates with SyCes. Within this document the two terms NAS and gateway are used in same meaning.

Captive Portal

A captive portal (CP) redirects unauthenticated users to a login form. Two different types (internal, external) of CPs may be implemented. At least one CP should be configurable per Gateway. In enterprise environments it should be possible to define multiple CPs and assign them to SSIDs (wireless), VLANs (wired) or physical interfaces.

Common Requirements

Independently of implemented CP type following features should be implemented.

Internal Captive Portal

This type of CP is located on the NAS. Users enter username and password and submit form to NAS. The NAS performs an authentication request to the configured RADIUS server. For internal captive portals following information needs to be stored on NAS:

External Captive Portal

This type of CP is located on SyCes-Server. Therefore we need only following information on Gateway:

For external CPs an optionally API should be implemented which speeds up login process.

RADIUS configuration

Radius Packets

  1. No Keep-Alives
    No Keep-Alive packets should be sent to test if the server is alive. This adds to load without providing useful information.
    Monitoring will be done by Synergy Systems GmbH. In case of a system crash the team willl start working on regaining the functionality anyway.
Use NAS tools like radtest to find out whether the radius server or your implementation causes problems.

Radius Authentication

Access Request

The access-request packet sent by the NAS needs the folllowing attributes :

Any other attributes will currently be ignored.

Access Accept

In case of a successful authentication the radius server sends an acces-accept packet that may contain the following attributes::

The NAS should use one of the following method:

  1. Either use the received attributes to find out when to stop the session
    or
  2. the NAS regularly retries to get users authenticated and stops the session when this fails

The manufacturer may decide which method to chose. The first one produces less traffic, but doesn't keep up to the frontend functionalities like a volume check. The second one is more flexible. The NAS can't rely on receiving one of the above attributes (see RFC2865 4.2. Access Accept). Other attributes are currently not used.

Access Reject

Radius Accounting

Accounting Start

The Accounting-Start packet needs to be generated right after a successful authentication.

It consists of an Accounting-Request (RFC 2866 4.1) with the following atttributes:

Apart from the attributes marked as optional all other attributes have to be implemented due to §113 TKG.

Interim Update

With Interim Updates volume based accounts can be handled. They are optional, but recommended. With UDP protocol it is possible that packets get lost, therefore it is recommended to always send interim-update packets. And it is possible to contiunally inform the user about the reamining volume and time.

In an Accounting-Update packet the following attributes have to be sent:

Accounting Stop

The Accounting-Stop-Paket must be sent directly after session end. It consists of an accounting-Request (RFC 2866 4.1) with the following attributes:

Apart from the attributes marked as optional all other attributes have to be implemented due to §113 TKG.