Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Proxy RADIUS Overview

Steel-Belted Radius Carrier can forward a RADIUS request to another server for processing and relay the other server’s result back to its client. Steel-Belted Radius Carrier is acting as a proxy for the target server, and that Steel-Belted Radius Carrier is proxy-forwarding the request to the target server. The IP address of the client originating the RADIUS packet can be determined by one or more attributes: NAS-IPv6-Address, NAS-IP-Address, or NAS-Identifier. For NAS-Identifier, the address is determined from the setting in the configuration database. If none of the addresses match the source address of the UDP packet, it is assumed that the RADIUS request has been proxied.

Any Steel-Belted Radius Carrier server can act as proxy or target for authentication or accounting messages (or both).

Note: The change of authorization/disconnect message (CoA/DM) feature does not support proxy RADIUS.

Proxy RADIUS Authentication

Figure 48 illustrates how RADIUS authentication messages are forwarded by proxy:

  1. A network access server (RADIUS client) sends an authentication request to a RADIUS proxy server.
  2. The proxy RADIUS server forwards the message to a RADIUS target server.
  3. The target RADIUS server performs the authentication services indicated by the message, then returns a response message to the proxy RADIUS server.
  4. The proxy RADIUS server relays the response message to the RADIUS client.

    Figure 48: RADIUS Proxy Forwarding

    RADIUS Proxy Forwarding

Proxy RADIUS Accounting

RADIUS accounting messages are forwarded by proxy as follows:

  1. A RADIUS server receives an accounting request.
  2. Depending on its configuration, the RADIUS server forwards the accounting message to a target server, records accounting attributes locally on the proxy server, or records the information in both places.
  3. If the proxy server does not receive an acknowledgement of the forwarded packet, it periodically re-sends the packet according to its retry policy.
  4. When the target server acknowledges the request, the proxy server forwards an acknowledgement to the RADIUS client. SBR can also be configured to respond immediately to the NAS.

Proxy RADIUS Realms

Proxy RADIUS realms are pools of RADIUS servers to which Steel-Belted Radius Carrier can forward RADIUS requests. Proxy RADIUS realms can be configured to support workload distribution, redundancy, fault tolerance, retry policies, primary-secondary server roles, and separation of authentication and accounting responsibilities by server. A carrier with Steel-Belted Radius Carrier installed on its LAN might create a realm that consists of all the RADIUS servers owned by a particular service provider. In this case, the RADIUS servers are already owned and maintained by the service provider; the realm simply organizes the routing of RADIUS packets from Steel-Belted Radius Carrier to these servers.

The carrier might define several such realms, one for each service provider that employs its services. If a service provider’s network is extremely large, a carrier might decide to use several realms to represent a single service provider. For each of these realms, it is possible to define an independent set of conventions for storing, forwarding, routing, and filtering the RADIUS requests that enter the Steel-Belted Radius Carrier server.

For more information, see Figure 49 and Configuring a Proxy RADIUS Realm.

Figure 49: RADIUS Server and Proxy Realms

RADIUS Server and Proxy Realms

Target Selection within a Realm

For proxy RADIUS realms, after the destination realm is identified, Steel-Belted Radius Carrier must select a target within the realm. Target selection depends upon a number of factors, all of which you can set up in advance by editing the realm configuration files on the Steel-Belted Radius Carrier server: proxy.ini, radius.ini, filter.ini, and one RealmName.pro file per realm.

After the target is selected, Steel-Belted Radius Carrier matches the target name with a proxy entry in its database. Using the data in this entry (IP address, UDP port, shared secret) Steel-Belted Radius Carrier establishes a connection between itself and the target, and proxy-forwards the RADIUS request. You can configure the realm so that all realm routing information and delimiters are stripped from the Username before forwarding.

The target processes the request as it normally would for RADIUS authentication or accounting. In the case of authentication, Steel-Belted Radius Carrier waits for a response from the target, then relays this response to its RADIUS client.

Message-Authenticator Support

The Message-Authenticator attribute enables Steel-Belted Radius Carrier to determine whether the packet received is from an actual proxy server. It might also sign the forward request.

Steel-Belted Radius Carrier can be configured to use the Message-Authenticator attribute when forwarding packets using proxy RADIUS. It can also be configured to validate or ignore the Message-Authenticator if included in the packets received.

Proxy Fast-Fail

During proxy forwarding, Steel-Belted Radius Carrier acts as the RADIUS client of another RADIUS server. Since RADIUS clients take responsibility for delivering RADIUS packets, all of them have a retry policy that determines how often and for how long they continue to try to deliver a packet until they receive the response that they expect from the RADIUS server. This includes the Steel-Belted Radius Carrier server when it acts as the RADIUS client of a proxy RADIUS target server.

Steel-Belted Radius Carrier provides a fast-fail option for proxy RADIUS realms. This fast-fail feature saves Steel-Belted Radius Carrier from continuing to send packets to a target server that appears to be down temporarily. For example, if Steel-Belted Radius Carrier is sending a packet to a target and it is not getting the timely response it expects, it periodically tries to send the packet until it reaches the number of tries in its retry policy. If it still has not received a response from the target at that point, Steel-Belted Radius Carrier removes the target from the active list and places it on the fast-fail list.

Once a target is presumed down (on the fast-fail list), Steel-Belted Radius Carrier directs proxy requests to another target in the same realm, if available. It does not wait for responses from the failed target. However, Steel-Belted Radius Carrier can be configured to send strobe requests periodically to the failed target server to detect when that server comes back up. Once a response is received to one of these strobe requests, the target server is removed from the fast-fail list. When the fast-fail timer expires for a target, it is placed back on the active list. Strobe requests are sent to the failed target server only if there are proxy requests addressed to its realm, the StrobeEnable parameter is set to 1, and the RetryInterval has been met or exceeded.

We strongly recommend that you specify a [FastFail] section in each proxy RADIUS realm configuration (.pro) file. The [FastFail] section permits you to fine tune retry policies for individual realms, or for specific targets within realms. Any [FastFail] settings that you supply in a .pro file override the current ProxyFastFail setting.

The radius.ini file offers a ProxyFastFail setting for single-target proxy entries that are not a member of any realm. ProxyFastFail has an integer value, usually 1800. If a target remains on the fast-fail list longer than this number of seconds, it is automatically removed from the fast-fail list. If conditions warrant, a target may be returned to the fast-fail list at any time.

For information about configuring the radius.ini file to support the fast-fail feature, see the SBR Carrier Reference Guide.

Static Proxy Accounting

Static proxy accounting allows you to send copies of certain types of accounting messages to proxy RADIUS realms, as well as to the normal routing of the original accounting message. The number of copies is not limited.

Static proxy accounting does not prevent the request from being dynamically routed for RADIUS accounting services based on Username decoration, DNIS number, or attribute mapping, nor does it prevent local logging or other accounting methods from occurring. If static proxy-forwarding fails (due to a lack of response from the target), this does not prevent the original RADIUS accounting request from being acknowledged.

An important function of static proxy accounting is to ensure that Accounting-On and Accounting-Off messages can be routed to realms. A NAS (RADIUS client) normally issues these accounting messages to its RADIUS server when it goes online (Accounting-On) and offline (Accounting-Off). In such cases, all connections previously made by this NAS are considered invalid, and the RADIUS server can free resources that it allocated to those sessions.

Static proxy accounting is necessary to deliver Accounting-On and Accounting-Off messages to realms, because these messages do not contain the User-Name or Called-Station-Id attributes that Steel-Belted Radius Carrier would normally use to route packets to realms.

For example, assume the original Access-Request, an authentication message, was used to determine the realm destination for both authentication and accounting for a particular session. The attribute used to route the Access-Request may have been the User-Name, the Called-Station-Id, or any other RADIUS attribute in the Access-Request, depending on how you have configured request routing for authentication messages.

Accounting packets for this same session can be matched with the realm destination only if the server knows which session is involved (as it does in Start, Stop, and Interim messages). The Accounting-On and Accounting-Off messages are independent of specific sessions; therefore it is impossible to route them to realms without additional information.

By setting up static proxy accounting, and listing all realms as targets for Accounting-On and Accounting-Off messages, you can ensure that network information (such as NAS status) is sent to everyone who might require it.

Proxy AutoStop Feature

A user session can be removed from the Current Sessions table in ways other than the usual Accounting-Stop message from the NAS:

  • An Accounting-On or Accounting-Off message received from the NAS causes all sessions originating from the NAS to be purged, as these messages signal that the NAS has been restarted or is going down.
  • The administrator can remove users by means of the LDAP configuration interface (LCI).
  • The administrator can remove users by means of the Web GUI.

Termination information must be passed on if the users exist as proxied sessions on downstream RADIUS servers because these servers must free the resources previously allocated to the sessions, which have now been terminated.

The Proxy AutoStop feature handles such cases. In addition, if you use the LCI command or dynamic authorization to free resources from the central administrative server, the appropriate messages are propagated so that the resources associated with the user in each of the downstream servers are automatically freed.

Routed Proxy Authentication

Routed proxy authentication enables you to select an authentication realm based on information in an external SQL or LDAP database and determine the routing of the authentication request. You can use this information to preauthenticate the user, select a target realm for a subsequent proxy, modify the User-Name in the proxy request, and insert attributes into the response. You can configure a proxy target statically (see Proxy RADIUS Authentication and Accounting), or have it determined based on information in the packet, such as NAI (decorated user-name), DNIS, or other computations (attribute mapping).

You can use this feature to:

  • Allow the User-Name to determine the realm without requiring decoration.
  • Centralize the mapping of attributes to the realm (the attribute mapping feature, but off-loaded to LDAP or SQL).
  • Allow the User-Name to be decorated only with a final realm, mapping it to the Next-Hop realm through LDAP. This allows an enterprise to change their ISP without requiring reconfiguration of user clients. (Also, by storing shared-secret information for the Next-Hop realm in LDAP, Secure Peer Discovery functionality is available.)

Operation

Routed proxy authentication occurs when certain information is returned from an external SQL or LDAP database. The operation is determined by two variables:

  • %ProxyRealm
  • %ProxyUser-Name

These variables are accessible by authentication methods through the SQL and LDAP authentication plug-ins:

  • If %ProxyRealm is not set, routed proxy authentication does not occur.
  • If %ProxyRealm is set to a directed realm, then handle it as a directed realm request.
  • If %ProxyRealm is set to a proxy realm, then send the request off to that proxy realm.
  • If %ProxyUserName is set to the User-Name attribute, which must be sent in the proxy request. If %ProxyUserName is not set, the User-Name from the original request packet is used.

For more information about the SQL authentication plug-in, see Configuring SQL Authentication. For more information about the LDAP authentication plug-in, see Configuring LDAP Authentication.

Routed proxy authentication supports RADIUS authentication, including the RADIUS challenge process and RADIUS accounting. Password authentication may happen when the external database is accessed, or later by the proxy target itself, depending on whether the values of the %Password and %ProxyRealm variables returned from the database are blank or non-blank (see Table 25).

Table 25: Four Scenarios for Routed Proxy Authentication

%Password value returned from database

%ProxyRealm value returned from database

Action

blank

blank

Authentication fails.

blank

non-blank

Authenticate at proxy target.

non-blank

blank

Authenticate password now; no proxy.

non-blank

non-blank

Authenticate password now; direct to appropriate realm if successful.

Note: Only one routed proxy is allowed per transaction; transactions cannot be nested.

Modified: 2017-03-07