Dynamic Authorization in a Cluster

Change of Authorization

Change of Authorization (CoA) is a feature which extends the capabilities of the Remote Authentication Dial-In User Service (RADIUS) protocol and is defined in RFC 5176. CoA request messages are usually sent by a RADIUS server to a Network Access Server (NAS) device for dynamic modification of authorization attributes for an existing session. If the NAS device is able to successfully implement the requested authorization changes for the client, it will respond to the RADIUS server with a CoA acknowledgement also referred to as a CoA-ACK. Conversely, if the change is unsuccessful, the NAS will respond with a CoA negative acknowledgement or CoA-NAK.

For tunneled clients, CoA requests are sent to the target client’s user designated Gateway (UDG). The UDG will then return an acknowledgement to the RADIUS server upon the successful implementation of the changes or a NAK if the implementation was unsuccessful. However, a clients UDG may change during normal cluster operations due to reasons such as maintenance or failures. These scenarios can cause CoA requests to be dropped as the intended client would no longer be associated with the Gateway that received the CoA request. HPE Aruba Networking has implemented cluster redundancy features to prevent the scenario.

Cluster CoA Support

The primary protocol used to provide CoA support for clusters in AOS 10 is Virtual Router Redundancy Protocol (VRRP). In every cluster there are the same number of VRRP instances as there are nodes and each Gateway serves as the conductor of an instance. For example, a cluster with four Gateways would have four instances of VRRP and four virtual IP addresses (VIPs). The VRRP conductor receives messages intended for the VIP of its instance while the remaining Gateways in the cluster are backups for all other instances where they are not acting as the conductor. This configuration ensures that each cluster is protected by a fault-tolerant and fully redundant design.

AOS 10 reserves VRRP instance IDs in the 220-255 range. When the conductor of each instance sends RADIUS requests to the RADIUS server, it injects the VIP of its instance into the message as the NAS-IP by default. This ensures that CoA requests from the RADIUS server will always be forwarded correctly regardless of which Gateway is the acting conductor for each instance. For example, the RADIUS server sends CoA requests to the current conductor of a VRRP instance and not to an individual station. From the perspective of the RADIUS server, it is sending the request to the current holder of the VIP address of the instance. Here’s a depiction of sample architecture that will be used for the duration of the CoA section:

This sample network consists of a four-node cluster with four instances of VRRP. The assigned VRRP ID range falls between 220 and 255, therefore the four instances in this cluster are assigned the VRRP IDs of 220, 221, 222, and 223. The priorities for the Gateways in each instance are dynamically assigned where the conductor of the instance is assigned a priority of 255, the first backup is assigned a priority of 235, the second backup is assigned a priority of 215 and the third backup is assigned a priority of 195.

GW-A is the conductor of instance 220 with a priority of 255, GW-B is the first backup with a priority of 235, GW-C is the second backup with a priority of 215 and GW-D is the third backup with a priority 195. Similarly, GW-B is the conductor for instance 221 due to having the highest priority of 255, GW-C the first backup with a priority of 235, GW-D is the second backup with a priority of 215 and GW-A is the third backup with a priority of 192. Instances 222 and 223 follow the same pattern as instances 220 and 221.

CoA with Gateway Failure

The failure of a cluster node can adversely impact CoA operations if the network doesn’t have the appropriate level of fault tolerance. If a user’s anchor Gateway fails, the RADIUS server will push the CoA request to their UDG with the assumption that it will enforce the change and respond with an ACK. However, if a redundancy mechanism such as VRRP hasn’t been implemented then the request will go unanswered and will not result in a successful change. In such a scenario, the users associated with the failed node will failover to their standby UDG as usual. However, the UDG will never receive the change request from the RADIUS server since the server is not aware of the cluster operations. VRRP instances must be implemented for each node to prevent such an occurrence and maintain CoA operations in the cluster.

In the figure below, GW-A is the master of instance 220 with GW-B serving as the first backup, GW-C serving as the second backup and GW-D serving as the third backup. A client associated to GW-A has been fully authenticated using 802.1X with GW-D acting as the client’s standby UDG. When communicating with ClearPass, GW-A automatically inserts the VIP for instance 220 as the NAS-IP. From the perspective of ClearPass, it is sending CoA requests to the current conductor of VRRP instance 220.

If GW-A fails, the client session will failover to GW-D. The client’s session moves over to GW-D as it’s the standby UDG. GW-D then assumes the role of UDG for the client. Since GW-B has a higher priority than GW-C or GW-D, it will assume the role of conductor and take ownership of the VIP.

Any CoA requests sent by ClearPass for client 1 will be addressed to the VIP for instance 220. From the perspective of ClearPass, the VIP of instance 220 is the correct address for any CoA request intended for the client in the example. As GW-A has failed, GW-B is now the conductor of VRRP instance 200 and owns the VIP. When ClearPass sends a CoA request for the client, GW-B will receive it and then forward it to all nodes in the cluster. In this case GW-B forwards the request to GW-C and GW-D.

After the change in the CoA request has been successfully implemented, GW-D will send a CoA acknowledgement message back to ClearPass.