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:
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.
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 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.
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.
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.
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.
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.
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 Messages (DMs) are sent by the AAA server to log users out. In a DM, the Code field has the following values:
Figure 4 shows the DM process.
The DM process is as follows:
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:
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 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.
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: