RSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition:  8.6 early release and later, including AM 8.8
Product Name: FreeRADIUS

When Authentication Manager, 8.6 is released in 2021, the AM upgrade will migrate from Pulse SRB RADIUS to FreeRADIUS, which will make some changes in how customers can configure load balancing for RADIUS clients.

AM 8.6 no longer uses the RADIUS TCP ports 1812 or 1813 (and 1645 and 1646). They are no longer needed because RADIUS replication is now accomplished through AM replication services (and RADIUS accounting was never implemented). 

Load balancers such as F5, and Citrix NetScaler send various Keep-alive packets to RADIUS servers and determine availability based on the responses to those Keep-alives.  These keepalive packets can be as simple as a TCP port 3-way SYN handshake, which is the beginning of any reliable network connection.  The load balancer just needs a TCP port number, such as 1813 or 1812 for RADIUS.

For example, the load balancer sends a SYNchronize →     to AM server port 1813
                             ←  SYNchronizeACKnowledgement  AM server responds
ACKnowledgement →

A good load balancer would close this connection after the third ACKknowledgement packet to save the AM server from having to time out the connection.

See also KB article # 000073573

Considerations when using F5 of other load balancer for MFA and REST API agents. How to configure F5 or other load balancing.

Keepalives can also be as complex as a full authentication request with user ID and passcode.  In order to be successful, the user ID and passcode must be valid.  A fixed passcode can be used here; though, it is less secure, and is not two-factor authentication.

Depending which keepalive method is selected, AM administrators need to be aware of scalability, reporting and performance issues that could affect the AM servers.  For example, a TCP port touch with the 3-way SYN, SYN-ACK and ACK packet sequence Handshake has the least impact on the AM servers resources.  TCP SYN packets do not show in the RADIUS <date>.log files (e.g. /opt/rsa/am/radius/20210331.log for March 31, 2021) and do not show in the AM Authentication Real Time Monitor or reports.  Depending which port is chosen, a response can indicate that either the AM server is up, or that the RADIUS Service on the AM server is up.

The most resource intensive keepalive would be a full authentication Request with UserID and Passcode.  These keepalives would show in both the RADIUS <date>.logs and in the AM Authentication Real Time Monitor or reports.  The frequency of these Keepalives also comes into play.  

Concepts for configuring load balancing for RADIUS also apply to REST based agents like the RSA MFA Agent for Windows, which sends authentication requests to TCP port 5555 on the AM servers by default.  See KB article # 000073573

Considerations when using an F5 or other load balancer for MFA and REST API agents. How to configure F5 or other load balancing.

Your tasks here are to:

1. Decide which load balancer approach scales best for your site/realm.
2. Configure one of the five approaches to RADIUS Client load balancing.

Depending on your requirements, you might configure user test logons with a fixed passcode every 600 seconds (5 minutes), with resulting log entries; or you might configure a TCP port keepalive touch with no log impact.

As you will see in the Resolution section, F5 provides a third approach, kind of a middle approach between the TCP port and full authentication with user ID.

Depending on your requirements, you might configure user test logons with a fixed passcode every 600 seconds (5 minutes), with resulting log entries; or you might configure a TCP port keepalive touch with no log impact.

In general, you have five approaches or options to RADIUS keep-alives:

1. TCP SYN to specific AM port. By default AM 8.6 RADIUS does not use RADIUS accounting and replicates RADIUS within AM replication; therefore, TCP ports 1812 and 1813 are not up and listening on AM 8.6 servers (nor are TCP 1645 and 1646, the alternate RADIUS ports.  You might use TCP 7002 replication port, or 5550 auto-registration port, or 5580 Offline authentication ports and a simple way to determine that an AM server is up and can be used in a RADIUS load balance.  Refer to documentation from the RADIUS Client to determine specifics on how to configure this, but typically it's just a TCP port number and frequency (see Notes for frequency cautions). Note: Minimal AM server impact with no AM configuration needed.
2. AM 8.6 does not use RADIUS TCP ports 1812 or 1813 anymore. They are no longer needed because RADIUS accounting was never used and RADIUS replication is now through AM replication services.  In AM 8.5 and earlier these two ports; 1812 and 1813 were responsible for many Vulnerability scan warnings.  However AM 8.6 will implement an option in the Operations Console to enable TCP port 1813 and open iptables Firewall for load balance keepalives.  This would let your load balancer monitor situations, however unlikely, where the AM services are all running except RADIUS. Note: Minimal AM server impact, but configuration changes to  Operations Console to enable TCP port 1813.

A full Authentication Request with UserID and Fixed Passcode, such as the F5 RADIUS Monitor or Citrix NetScaler User logon for High Availability.  The load balancer is looking for a response to indicate RADIUS is up and processing authentication requests, even if the response is Access Denied.  Note: Maximum AM server impact so be careful with the frequency of these authentication.  In a large network with thousands of RADIUS clients, you want to be careful so that your high availability RADIUS test authentications do not make your AM RADIUS server unavailable by overusing the resources that were planned for real users. See Notes for real world impact story,

1. 
   
   
   4. The UDP Monitor on F5 can send a null string to a UDP port such as 1812, which triggers reject response and puts the following  entry in the RADIUS date log "Truncated authentication request," but shows nothing in the Authentication Manager Real Time Monitor or Authentication reports. 
   
   
   
   This option scales better than a full authentication request, but you still need to be careful when dealing with thousands of RADIUS load balancers or frequencies less than every 5 minutes with a dozen or more Load balancers.  This is a simple math problem, (frequency of test) * (number of load balancers) will give an idea of the load your testing is putting on the AM servers.  Default on F5 is 300 seconds.
   5. AM 8.6 may implement a restricted user ID for RADIUS testing/load balancing only. Engineering is investigating a restricted account configured in FreeRADIUS that is not an AM user account, but would touch the RADIUS UDP port to determine if RADIUS is responding without triggering an Authentication Manager logon. Impact not known yet, estimated to be more than a TCP port touch three-way handshake from 2 above, and more than UDP monitor from F5 described in 4 above, but less impact than a full authentication to AM through RADIUS as described in 3 above.
    

Note 1:
 Load balancers use the term 'stickiness' or persistence to refer to using the same servers from the load balance pool for multi-step procedures. What this means is, Authentication is typically a single step, discreet action. That is,

1. A user sends their user ID and passcode to any AM server to authenticate.
2. A single response from an AM server completes the transaction. 

However, with New PIN Mode or a PIN Change Policy in effect, some transactions become multi-step;

1. A user sends their user ID and passcode (or tokencode if in New PIN mode) to any AM server to authenticate.
2. The AM server authenticates user, but includes prompt for something else, e.g., a request for the user to create New PIN or enter Next Tokencode Mode.
3. This second response from the RADIUS client, with the new PIN, must go to the same AM RADIUS server that authenticated the user in steps 1 and 2.  This is the concept of stickiness.  See your load balancer's documentation for configuration details.

Note 2
A real world impact story
A real world example of frequency and keepalive impact was a customer support case where 9 Citrix NetScalers were configured to send authentication requests every 10 to 15 seconds.  This resulted in over 92,000 authentication requests every 24 hours.  The NetScalers were not configured with an actual user ID. They simple select the user ID 'test' with a made up or invalid fixed passcode.  This meant every day the AM servers process 92,000 failed authentication requests for non-existent user, all of which failed to resolve the user name after performing name lookups in both the internal AM database and all external LDAP Identity sources.  The Real Time Authentication monitor was overflowing with these failed authentication messages, making it difficult to nearly impossible to search for real authentication failures.  The fact that the authentication failed did not matter, the NetScalers only needed a response to maintain the AM servers in their active server list.