Virtual Private Network Authentication System Featuring High Extensibility and Availability: AAA

2.1 Configuration

The overall configuration of our system is shown in Fig. 1. The AAA consists of three parts. The AAA authentication server performs authentication and authorization. The AAA log/SO server collects and formats logs, processes service orders (SOs), which are users’ service provisioning requests, in collaboration with the operations system (OpS), and manages session information. The AAA database stores information about authentication derived from service orders, information about equipment, and information about established sessions.

Fig. 1. Overall configuration of AAA.

In preparation for serious disasters, the AAA is duplicated at two sites. The number of AAA authentication servers can vary depending on the number of connected network termination units (NTUs), which control user terminals.

2.2 Authentication and authorization functions

The AAA exchanges authentication information with NTUs using RADIUS (Remote Authentication Dial-In User Service), which is a user authentication security protocol. The basic operation of the system up to the establishment of a VPN connection is as follows (Fig. 2):

Fig. 2. Basic authentication operation up to VPN connection establishment.

In this way, the AAA authenticates and authorizes VPN users in a highly secure manner on the basis of the user ID, password, and line identification (in this example).

2.3 VPN session management function

The AAA holds the session information about the user who has been connected to the VPN after authentication has been completed. This session information is used to prevent double logins from the same user and is also referred to when maintenance staff check the connection state to deal with a complaint from the user.

As the user’s connection state changes (connection establishment or release), the session information held by the AAA is updated on the basis of information contained in RADIUS messages sent by the NTU. If the RADIUS messages fail to reach the AAA owing to packet loss or a fault in the NTU, the session information held by the AAA may become different from the user’s actual connection state.

To resolve such a discrepancy, the AAA collects the user’s connection information from the NTU and automatically corrects the session information concerned. Specifically, this function operates as follows (Fig. 3):

Fig. 3. Operation of session information correction.

This session information correction can be executed without suspending the operation of the AAA and enhances the reliability of the session information. Session information can also be sent to devices other than the AAA for use in authentication by upper-layer applications, such as ASP (application service provider) services and SaaS (software as a service).

2.4 SO function

The SO function updates the SO information needed for VPN authentication in collaboration with the OpS. It registers, updates, deletes, or refers to SO information in the AAA database in response to an SO request sent by the OpS. In addition, it asks the NTU to release the user’s session.

The SO function and the OpS exchange messages written in XML (extensible markup language) using the message exchange protocol SOAP (simple object access protocol) to ensure versatility and extensibility in authentication.

3.1 Provision of usage history reports

The AAA can provide the history of each user’s authentication and authorization in the form of a report.

The VPN authentication server normally outputs the information included in RADIUS messages sent from NTUs, to the authentication and authorization log. However, in a VPN service, which can be accessed from lines of various types, the NTUs used may also vary. Attributes included in RADIUS messages can vary depending on the type of NTU. Therefore, it is not straightforward to generate a usage history report from authentication and authorization logs.

To solve this problem, items that are output in usage history reports (events, such as the start and end of usage, date and time when each event occurred, user ID, line number, etc.) are defined for each type of NTU.

3.2 Extensibility of authentication and authorization function

The number of items that the authentication and authorization function must check is growing. To be able to cope with such an increase flexibly through the simple addition of necessary functions, the AAA has extended interfaces (Fig. 4).

Fig. 4. Extensibility of the authentication/authorization process.

The extended processing part obtains or changes information needed in the processing of authentication and authorization, such as user ID, password, and network information, through an extended interface. When a new authentication and authorization module is added, the module obtains the necessary information and returns processing results to the basic processing part through the extended interface so that the processing results will be reflected in the authentication and authorization. Since extended functions can be added without modification of the AAA’s basic processing part, new authentication and authorization capabilities can be easily added to meet new user needs.

An extended interface is available for each of the three stages of processing: processing concerning all users, processing concerning only legitimate users, and processing concerning authorization. This arrangement makes it possible to select an extended interface appropriate for a specific processing operation or to select an appropriate method of adding functions in order to achieve high-speed processing. For example, processes executed for only legitimate users, such as authentication and authorization processes, for which the occurrence number is proportional to the number of user sessions, can be applied after the authentication of individual users. This will limit the number of users handled by these processes and thus eliminate wasteful processing.

3.3 Compatibility of availability and high-speed processing

In preparation for major disasters, the AAA has a redundancy configuration in which a system is installed at each of two sites: the primary site and the secondary site (Fig. 5). Both systems are kept active. If the system at the primary site is disrupted, all NTUs switch over to the system at the secondary site, which continues to provide authentication and authorization.

Fig. 5. Redundancy configuration of the AAA system.

To support the switchover to the secondary-site system, the databases at the two sites must be synchronized in real time to ensure consistency in the checking of double logins and other processing. To meet this requirement, database updating is executed at the two sites simultaneously so that the contents of the two databases are always synchronized. To enhance the authentication response performance, access to the databases is minimized. For example, the system that has received a request for authentication refers only to its own database, and it sends an authentication reply to the requesting NTU only after it has successfully updated its database. The other database will be updated after the authentication reply has been sent. This arrangement makes it possible to keep duplicate data for authentication and authorization at two sites while ensuring high-speed authentication. For even higher availability, each site has a cluster of two data servers.