3.71. <AuthBy RADSEC> Previous topic Parent topic Child topic Next topic

<AuthBy RADSEC> proxies RADIUS requests to a <ServerRADSEC> clause on remote Radiator using the RadSec (RFC 6614) secure reliable RADIUS proxying protocol. It can be used instead of <AuthBy RADIUS> when proxying across insecure or unreliable networks such as the internet. For more information about the RadSec protocol, see Section 16. RadSec (RFC 6614).
<AuthBy RADSEC> attempts to establish a RadSec connection to the server Hosts when Radiator start up. If the connection subsequently fails or is disconnected, it will attempt to reestablish the connection at ReconnectTimeout intervals.
<AuthBy RADSEC> can be configured for multiple target hosts by specifying multiple Host clauses inside the <AuthBy RADSEC> clause. Normally when a packet is to forwarded, <AuthBy RADSEC> attempts first to send it to the first Host. If no reply is received from that Host within NoreplyTimeout seconds, it attempts to send the request to the next Host and so on. If no reply is heard from any Host, the NoReplyHook is called.
For compliance with RFC 6614, <AuthBy RADSEC> defaults to a Secret of RADSEC. Transport of ‘tcp’ and UseTLS enabled.
<AuthBy RADSEC> supports TLS. For more information about TLS parameters, see Section 3.11. TLS configuration.

Failure algorithm

<AuthBy RADSEC> implements a configurable algorithm to detect failed RadSec hosts, and to temporarily disregard failed hosts. The algorithm uses the MaxFailedRequests, MaxFailedGraceTime, and FailureBackoffTime parameters to customise the operation of the algorithm. For more information, see Section 3.38.15. MaxFailedRequests, Section 3.38.16. MaxFailedGraceTime, and Section 3.38.14. FailureBackoffTime. It also uses KeepaliveTimeout and UseStatusServerForFailureDetect in order to use only Status-Server requests for failure detection, instead of any request. For more information, see Section 3.38.9. KeepaliveTimeout and Section 3.38.13. UseStatusServerForFailureDetect.
<AuthBy RADSEC> initially assumes that each Host is not failed. After a request is sent to a RadSec server, if no reply is received after the NoreplyTimeout, that request is deemed to have failed for that Host. <AuthBy RADSEC> keeps track of how many consecutive requests failed for each Host since the last time a reply was heard from that Host. If more than MaxFailedRequests consecutive requests are deemed to have failed within MaxFailedGraceTime seconds of that last reply heard from that Host, that Host is deemed to have failed.
When the Host is deemed to be failed, <AuthBy RADSEC> does not attempt to send any requests to it until FailureBackoffTime seconds have elapsed. In the meantime, <AuthBy RADSEC> attempts to connect or reconnect to the host according to ReconnectTimeout. It also skips sending requests to that Host, and instead attempts to send to the next Host in its list of Hosts (if any).
The default values for these parameters are:
MaxFailedRequests 1
MaxFailedGraceTime 0
FailureBackoffTime 0
These values mean that by default <AuthBy RADSEC> declares the Host failed after a single packet transmission failure, but that it always tries to transmit the next request to the Host. This means that <AuthBy RADSEC> always tries to send every request to the first Host, and if nothing is heard from that Host within NoreplyTimeout, it attempts to send to the next Host.
Judicious use of these parameters allows you to implement a RadSec Host fallback policy, where if one RadSec Host fails to respond to requests, then it will automatically temporarily fall back to the next RadSec Host and so on.

Certificate validation

When a RadSec Server presents a server certificate to an <AuthBy RADSEC> Client, the Client performs a number of checks to validate the server certificate. The server certificate is checked for valid start and end dates, and it also checks the chain of validity back to the issuing Certificate Authority, using the root certificates specified in TLS_CAFile or TLS_CAPath. If TLS_PolicyOID parameter is defined, the OIDs must be present in the certificate path. Also a server certificate is accepted only if at least one of the following conditions are true:
  • The Host name used to connect to the server matches a subjectAltName with type IPADD (IP Address) or DNS (DNS name) in the certificate. Exact or wild card matches are permitted, so a subjectAltName type DNS of ‘*.xyz.com’ matches for any Host in xyz.com.
  • If there are no subjectAltNames of type DNS in the certificate, if one of the Subject CN (Common Names) in the certificate matches the Host name used to connect to the RadSec server. Exact or wild card matches are permitted.
  • The Subject in the certificate matches the pattern specified by the TLS_ExpectedPeerName parameter in this <AuthBy RADSEC> clause.
  • If TLS_SubjectAltNameURI parameter is defined in the <AuthBy RADSEC> clause, the certificate must contain a subjectAltName of type URI that matches the TLS_SubjectAltNameURI regular expression.
  • If TLS_CertificateFingerprint parameter is defined in the <AuthBy RADSEC> clause, the certificate's fingerprint must match at least one of the TLS_CertificateFingerprint options.
Note that the default TLS_ExpectedPeerName pattern is undefined, which means that by default <AuthBy RADSEC> requires that the Host name used to connect to the RadSec server matches the subjectAltName or CN in the Server Certificate.
These certificate validation rules are consistent with RFC 2595.
Normally, an <AuthBy RADSEC> clause completes as soon as the request has been forwarded to the remote RadSec server. It does not wait for a reply before moving on to other AuthBy clauses, or handling new requests. <AuthBy RADSEC> always returns IGNORE for AuthByPolicy.

Gossip support in AuthBy RADSEC

The RadSec Hosts can now distribute information about next hop proxy reachability with Gossip. Instead of the current IP address, the configured host name is used as the key when determining if the current report must be processed.