Feature Description
In 5G architecture, the serving network authenticates the Subscription Permanent Identifier (SUPI) during authentication and key agreement between UE and the network. In addition, the secondary authentication is performed for data networks outside the mobile operator domain. For this purpose, various EAP-based authentication methods and associated credentials are among which the RADIUS protocol is one of the widely used authentication protocols.
The Remote Authentication Dial-In User Service (RADIUS) Client feature integrates with the SMF to enable the generic Cloud Native 5G RADIUS functionality for authentication purposes. When the RADIUS Client feature is enabled, the SMF performs secondary authentication with the configured external AAA server (for example, RADIUS Server) as per 3GPP TS 23.501.
Important | Only the RADIUS protocol is currently used for secondary authentication. |
The RADIUS Client feature supports the following functions:
-
Server Selection
RADIUS servers are configured with IP:Port as the key. The algorithm CLI specifies the fail-over or load balancing algorithm to select the RADIUS server to which the authentication or accounting request must be sent. Servers that are marked "dead" are not considered for selection until they are marked "alive". The supported algorithms are first-server and round-robin.
-
First-server — Specifies that the request must be sent to RADIUS server with the highest priority. If the server becomes unreachable, the request is sent to the server with the next highest configured priority. This is the default algorithm.
-
Round-robin — Specifies that the request must be sent based on load balancing in a circular queue manner. The server that is last used is stored to maintain the round-robin selection. The order of the list is based on the configured relative priority of the servers.
-
-
Monitor Server and Dead Server Detection
Monitor Server revisits the server database and marks the server which has not received response beyond the configured "timeout" value after the first request is sent. The server is marked "dead" and remains in dead-state for seconds configured as "deadtime". After the "deadtime" elapses, the server's dead-variable is reset again to mark it as ready to process requests. If the server is still not reachable, it is marked "dead" as part of the next request response timeout.
-
Timeout and Retry
After a server is selected and request is sent to the server, an entry is maintained in the request queue until response is received from the RADIUS server or until timeout occurs. Monitor Requests is called to check on the requests queue for response timeouts and retry. It walks through all the entries and checks if any request timeout value configured as "responseTimeout" is hit. For such requests, if the number of retries is less than the configured "maxRetries" value, the request is resent to the RADIUS server. Else, if the "maxRetries" count is reached, the request is deleted from the request queue. After a request is deleted, even if response comes for such requests, the response is discarded and not sent to the user.