RADIUS

RADIUS uses the User Datagram Protocol (UDP) as the transmission protocol, and therefore it has outstanding real-time performance. RADIUS also has high reliability because it uses the retransmission mechanism and allows backup server deployment. RADIUS is easy to implement and can use the multi-threading structure of the server when there are a large number of users.

The NAS can function as a RADIUS client to perform the following functions:

Supports the standard RADIUS protocol and extended attributes.
Actively detects the status of the RADIUS server. After the NAS receives an authentication or accounting message but finds that the connected server is Down, it starts server detection and sends a detection packet carrying the message to the server. If the detection packet is responded to by the RADIUS server, the NAS considers the server available again.
Automatically switches traffic to another RADIUS server in the server group. If the current server is unavailable or the number of retransmissions exceeds the upper limit, the NAS sends packets to an alternate server in the server group.
Communicates with the RADIUS server using IPv4 or IPv6.

Authentication and Authorization

The RADIUS server builds a unique database to store user names and passwords required for user authentication.

The RADIUS client provides authentication and authorization for administrators.

Figure 1 shows how the RADIUS server and client exchange RADIUS messages for authentication and authorization.

Figure 1 Message exchange between the RADIUS server and client

A user logs in to a network device, such as the Device or NAS and sends a user name and password to the network device.
Upon receipt of the user name and password, the RADIUS client on this network device sends an authentication request to the RADIUS server.
If the request is valid, the RADIUS server completes the authentication and responds with the requested authorization information to the client.
The user goes online, and the RADIUS server starts accounting.
Transactions between the RADIUS client and server are authenticated using a shared key, which is never sent over the network. In addition, user passwords are encrypted and exchanged between the RADIUS client and server to prevent the passwords from being tampered with on insecure networks.

The RADIUS client supports the following key configurations:

If RADIUS servers in a server group require the same key, a shared key can be configured for the server group.
If RADIUS servers in a server group require different keys, a key can be configured for each server.

A shared key can be configured for a server template so that all servers in the template can use the same shared key.

Accounting

The RADIUS client supports accounting for users who have logged in. The client uses Start and Stop services and records the elapsed online time.

Figure 2 shows how the RADIUS server and client exchange RADIUS messages for accounting.

Figure 2 Message exchange between the RADIUS server and client

If authentication and authorization are successful, the RADIUS server starts accounting.
The RADIUS client on the network device receives a Start message and sends an Accounting-Start request to the RADIUS server.
If the request is valid, the RADIUS server records the information in its database and sends a reply to the client.
When the user logs out, the NAS receives a message with the elapsed time and logout cause and sends an Accounting-Stop request carrying this information to the RADIUS server.
The RADIUS server records the information in the database.
Transactions between the RADIUS client and server are authenticated using a shared key, which is never sent over the network. In addition, user passwords are encrypted and exchanged between the RADIUS client and server to prevent the passwords from being tampered with on insecure networks.

Primary/Secondary Mode

A RADIUS server template can have one primary server and none or several secondary servers configured. RADIUS selects the primary server if it is present and in the Up state. Otherwise, RADIUS selects a secondary server to respond to user requests.

After the RADIUS client receives an AAA request, it checks whether the primary server is present and in the Up state. If so, the RADIUS server selects it to respond to user requests. If the primary server is not present or in the Up state, the client selects the first secondary server that is Up to respond to user requests. The primary server processes user requests as long as it is available.

Load Balancing Mode

In load balancing mode, traffic is balanced between the multiple RADIUS servers so that more user requests can be processed more quickly, effectively leveraging the RADIUS servers. RADIUS servers are selected for load balancing based on user requests and are maintained through a server template. Upon receiving a request or reply, the RADIUS client sends it to the servers in the server template for load balancing.

After the RADIUS client receives an AAA request, it selects an Up server with the least load from the specified server group. If all servers in the group are Down, the RADIUS client still selects the one with the least load. After the server is selected, its load increases and its sequence in the server template updates. When the server starts receiving replies, its load decreases and its sequence in the server template updates as well.

Retransmission

RADIUS uses UDP as the transmission protocol. The RADIUS client supports packet retransmission to improve reliability.

If the RADIUS client sends a request to the RADIUS server but does not receive any reply before the timer expires, timeout occurs and the RADIUS client retransmits the request. Specifically, the RADIUS client retransmits the request to the same server for a specified number of retransmission times. If no reply is received, the client sends the request to a different server, irrespective of whether the primary/secondary or load balancing mode is used.

The number of retransmission attempts and the response timeout time for a server group and servers in the server group can be configured on the RADIUS client.

Server Status Detection

RADIUS clients can detect the status of RADIUS servers during login and determine the real-time status of RADIUS servers based on responses from the RADIUS servers. This helps identify which servers are in the Up state so as to process user request packets in real time.

When the detection time of the server group expires, RADIUS clients send detection packets according to the status of the server group.

In active/standby mode, the detection packets are sent to the master server and some backup servers. If all the servers are Down, the detection packets are sent to all servers in the server group. In load balancing mode, the detection packets are sent to all servers. When the detection starts, a RADIUS client sends Access-Request packets to servers. The packets contain the user name and a random password. If a server returns an Access-Reject/Access-Challenge packet, the RADIUS client considers the server Up. Otherwise, the RADIUS client considers the server Down.

Vendor-specific Attributes

The RADIUS client supports a set of Huawei-proprietary attributes. The Structure of Management Information (SMI) Network Management Private Enterprise Code for Huawei is "2011". This vendor ID is used to identify Huawei vendor-specific attributes (VSAs). After the RADIUS client receives VSAs from the RADIUS server, the RADIUS client determines the rights and services for user access. The RADIUS client supports the following vendor-specific attributes:

FTP Directory (26–28)
User Level (26–29)
User Group Name (26–251)
User Service Type (26–252)

26 denotes a VSA in the RADIUS packet and 26–x denotes Vendor type x in the VSA.

Dynamic Authorization

The RADIUS server changes the service attributes of online users through CoA packets. CoA packets have the same format as RADIUS packets. In a CoA packet, the Code field has the following values:

43: CoA-Request packet
44: CoA-ACK packet
45: CoA-NAK packet

Figure 3 shows the dynamic authorization process.

Figure 3 Dynamic authorization

The dynamic authorization process is as follows:

A user goes online and accesses the portal server to subscribes to a service.
The portal server sends information about the service that the user subscribes to the RADIUS server.
The RADIUS server makes or modifies the service policies according to the service and user information. The RADIUS server then sends a CoA-Request packet to the BRAS and requests to modify the authorization information of the user.
After receiving the CoA-Request packet from the RADIUS server, the BRAS modifies the authorization information of the user without changing the online status of the user. If the modification is successful, the BRAS returns a CoA-ACK packet to the RADIUS server. If the modification fails, the BRAS returns the CoA-NAK packet to the RADIUS server.
If the modification is successful, when the user uses the service, the BRAS controls the service based on the modified authorization attribute.

Disconnect Message

Disconnect Messages (DMs) are sent by the AAA server to log users out. In a DM, the Code field has the following values:

40: Disconnect-Request
41: Disconnect-ACK
42: Disconnect-NAK

Figure 4 shows the DM process.

Figure 4 DM

The DM process is as follows:

The administrator forces the user to log out. The portal server then sends this information to the RADIUS server.
The RADIUS server sends a DM-Request packet to the BRAS and requests the user to go offline.
After receiving the DM-Request packet from the RADIUS server, the BRAS processes the DM without changing the online status of the user. If the processing is successful, the BRAS returns a DM-ACK packet to the RADIUS server. If the processing fails, the BRAS returns a DM-NAK packet to the RADIUS server.
If the processing is successful, the BRAS instructs the user to go offline.

Dynamic ACL Delivery by the RADIUS Server

The RADIUS server can send RADIUS Access-Accept or CoA packets that carry the Hw-Data-Filter (26-82) attribute to deliver ACLs or dynamically change ACLs it previously delivered to the BRAS.

The dynamic ACL delivery process is as follows:

A user sends an access request to the BRAS by PPP dialup or sending IP or DHCP packets.
The BRAS responds to the access request and obtains the user name and password after exchanging packets with the user. The BRAS then functions as a RADIUS client to send an authentication request to the RADIUS server.
The RADIUS server receives the authentication request and authenticates the user name and password.
After the user name and password are authenticated, the RADIUS server sends a RADIUS Access-Accept packet that carries user authorization information and the Hw-Data-Filter attribute to the BRAS.
The BRAS parses the Hw-Data-Filter attribute in the RADIUS Access-Accept packet and automatically delivers the traffic classifiers and behaviors carried in the attribute to all boards that support dynamic ACL delivery.
When the user accesses the Internet or other network resources, the BRAS performs the traffic policy delivered by the RADIUS server on the user traffic.
When the user is online and the network administrator configures, deletes, or changes traffic classifiers and behaviors on the RADIUS server, the RADIUS server sends a CoA packet that carries the Hw-Data-Filter attribute to deliver the traffic policy. After the BRAS receives the CoA packet, it parses the Hw-Data-Filter attribute in the CoA packet and delivers the traffic policy that carries the new, deleted, or changed traffic classifiers and behaviors. The BRAS then performs the traffic policy delivered by the RADIUS server on the user traffic.

Dynamic Command Line Delivery by the RADIUS Server

The RADIUS server can send CoA packets that carry the HW-Command-Mode (26-34) and HW-AVpair (26-188) attributes to deliver command lines.

The dynamic command line delivery process is as follows:

The level of command lines that can be delivered by the RADIUS server is configured on the BRAS. If this configuration is not performed, the RADIUS server cannot use CoA packets to deliver command lines.
The network administrator configures the RADIUS server to carry the administrator user name and command lines to be delivered in the HW-Command-Mode (26-34) and HW-AVpair (26-188) attributes in CoA packets.
The RADIUS server sends CoA packets that carry the specified user name and command lines to the BRAS.
Upon receipt, the BRAS parses the CoA packets and performs administrator user authorization based on the user name carried in the CoA packets and the configured level of command lines that can be delivered by the RADIUS server. If the authorization is successful, the BRAS issues command lines.
After the command lines are executed, the BRAS sends CoA-ACK packets carrying the command line execution results to the RADIUS server.

Flexible Interoperation of RADIUS Attributes

Secondary development using python scripts can be conducted for supported and unknown RADIUS attributes so that RADIUS clients (router or access servers) can flexibly interoperate with RADIUS servers.

The process of flexible interoperation of RADIUS attributes is as follows:

The system calls a python script to perform logic processing of specified supported RADIUS attributes in packets to be sent to the RADIUS server and then sends them to the RADIUS server.
The system calls a python script to perform logic processing of specified supported RADIUS attributes in the packets received from the RADIUS server so that the attribute format is the same as that supported on a RADIUS client (router or access server). The system caches unknown RADIUS attributes in packets received from the RADIUS server and carries the attributes in subsequent packets to be sent to the RADIUS server for interoperation.