Selecting an EAP Method - RADIUS Server Implications

With this blog entry, we conclude our series on factors involved in choosing the best authentication method for a 802.1X applications by discussing RADIUS servers. Like the supplicant software discussed last month, the choice of a RADIUS server is critical because it is one of the endpoints engaging in the EAP authentication and must therefore have direct support for the chosen EAP method. The RADIUS server must also have support for the directory or database being used to store the user profiles and credentials.

Platform Flexibility

In the vast majority of cases, wireless networking is an added feature rather than a function designed into the enterprise’s original network. If wireless security is to be achieved, then a RADIUS server compatible with existing enterprise networks and meeting corporate requirements must be selected. Enterprises with established IT departments often have standards for servers. Any new server must run on the standard platform and operating system whether it is Unix, Linux, or Windows. Smaller enterprises cannot afford the IT expertise necessary to support multiple platforms. In some of these cases, a turnkey RADIUS appliance may be the best choice. The choice of the best EAP method should not be further complicated or limited by a RADIUS server lacking in flexibility and power.

Legacy RADIUS Servers

The existing network may already include legacy RADIUS servers used to authenticate dial-in access and wired access to systems. The reasonable options are to either replace the legacy server that can do both EAP and standard RADIUS authentication, or to add a new RADIUS server, which can interact with the legacy RADIUS server to authenticate wireless users. The option of adding a dedicated RADIUS server for wireless access would complicate user management by requiring its own user database.

If the first option is chosen, then the new RADIUS server must support the existing user repository, whether it is flat files, an LDAP directory, kerberos, or SecurID. More significantly, the RADIUS server must be able to distinguish between wired and wireless RADIUS authentication requests for the same user and handle them appropriately. Interlink Networks’ RAD-Series RADIUS Servers has the flexibility and power to configure both wireless and wired authentication for the same user groups. The server uses the contents of the access request to determine the protocol being used and which configuration should be applied.

If the second option is chosen, then the two RADIUS servers must work together. The legacy RADIUS server does not support EAP, but it has access to the user profiles. The wireless authentication server supports EAP, but does not have direct access to the user credentials. In this scenario, TTLS is the EAP method of choice. The wireless RADIUS server authenticates the network to the supplicant using a digital certificate and establishes a TLS tunnel through which a legacy protocol can be used to authenticate the supplicant to the network. The wireless RADIUS server terminates both the TLS tunnel and EAP. The user authentication using PAP, CHAP, or MS-CHAP is then forwarded to the legacy RADIUS server as a standard RADIUS request that it can handle.

Digital Certificate Support

If the enterprise already has a Public Key Infrastructure (PKI), then EAP-TLS is the EAP method that can satisfy those requirements. Other enterprises will find EAP-TLS less attractive because of the significant overhead of generating and managing user certificates. To adequately support EAP-TLS, the RADIUS server should support certificate revocation lists (CRL).

Password Hashes

For many authentication methods, passwords are the keys that open the gates of the network. As such, network administrators take additional security measures to protect passwords. They avoid protocols like PAP, which involve transmitting the password, and store a one-way hash of the password in the user’s profile instead of the password itself. Commonly used hashes include crypt on Unix systems, nthash on Windows systems, and SHA-1 or MD5 in LDAP directories. Because a one-way hash cannot be decrypted, some hashes will not be usable in protocols where the RADIUS server is authenticated by proving to the supplicant that it has the user’s password. In particular, Cisco LEAP and PEAP-MSCHAPv2 will only work if the password is stored in cleartext or an nthash.

If the password is already stored in a hash other than nthash, then the solution is to use one of the tunneled EAP methods like EAP-TTLS or PEAP. By creating a TLS encrypted tunnel, these methods make it secure to use an inner authentication protocol, which involves transmitting the user’s password from the supplicant to the RADIUS server. The RADIUS server then performs the appropriate hash operation on the password and compares the result to what is stored in the user’s profile. For EAP-TTLS, PAP will work as the inner authentication method and EAP-GTC will work as the inner authentication method for PEAP. CHAP and MS-CHAP will not work as inner authentication protocols because they involve a series of challenges instead of transmitting the user’s password inside of the tunnel. Mutual authentication means both ends must prove that they have the password.

Microsoft Active Directory Issues

Microsoft’s Active Directory Server (ADS) stores user passwords as an nthash. However, it takes user password security a step further in that it does not return any password hashes in response to an LDAP search. This does not necessarily restrict your options for EAP methods.

If the RADIUS server runs on a different machine from ADS, then the LDAP interface must be used and the same issues apply as were discussed for hashed passwords. In this case, either EAP-TTLS with PAP or PEAP-GTC should be chosen as the EAP method. Through the security of a TLS encrypted tunnel, they both provide a username and password, which can be authenticated by binding them to the ADS LDAP interface.

Conclusion

Through the course of this series of blog entries we have seen that the choice of an EAP method in wireless networking is essential in delivering both security and interoperability. Which EAP method is best for an enterprise can be determined by looking at its requirements for wireless station platforms, access points, and the network infrastructure. The choice of the right RADIUS server completes the security solution, provided that it is flexible and powerful enough to support the network’s platforms, databases, existing security systems, and desired EAP methods. Interlink Networks’ RAD-Series RADIUS Server supports the broadest range of platforms and EAP methods, making it possible to implement the strongest security with the greatest ease of use.

RADIUS & 802.1X: Selecting an EAP Method - Supplicant Software

In this blog posting, we continue our discussion of EAP methods and the factors involved in finding the best authentication method for a wireless application. We have already identified the components that must interoperate to deliver secure wireless communication and we have discussed the access point requirements. Our next topic is the supplicant software, which runs on the wireless station such as the laptop, PDA, or phone. It is critical because it is one of the endpoints engaging in the EAP authentication (along with the RADIUS server at the other end) and must therefore have direct support for the chosen EAP method.

Supplicant Availability

Supplicant software is available from a number of sources, supporting a variety of EAP methods and operating systems. Most supplicants support EAP-MD5, EAP-TLS, and EAP-PEAP. However, not all vendors have implemented the same version of EAP-PEAP and each vendor has a different approach to managing user profiles. To minimize interoperability and management issues, settle on a single source of supplicant software that supports all of your required platforms, if at all possible. Please note that Interlink’s RADIUS server is standards-based and is designed to interoperate with all leading supplicants.

In some cases EAP supplicants are provided with the operating system. In particular, Windows XP includes support for both EAP-TLS and PEAP. Some organizations will prefer the simplicity of configuring a native supplicant to managing the installation and set up of third party software on all workstations.

User Profile Management

Supplicant software differs in its approach to managing the user profile ranging from those that are set up once and forgotten to those offering a great deal of flexibility and power. Some supplicant software includes a utility for configuring and managing multiple user profiles. This is useful for stations that will be used by multiple users or in multiple environments requiring different authentication methods. The user profiles are configured in advance and the appropriate profile selected as needed. At the other end of the spectrum are those supplicants that store the user identity and credentials at set up and then never require any intervention by the user. These are very easy to use but are more difficult to reconfigure. This becomes a problem if you want a policy of regularly changing passwords. It is also a security liability should the station ever become lost or stolen.

Identity Hiding

The tunneled EAP methods such as EAP-TTLS and EAP-PEAP support a concept called identity hiding. Authentication between the supplicant and authentication server takes place in two phases. In the first phase, the supplicant presents an outer user identity, in response to which the authentication server establishes an encrypted tunnel. This outer identity is often an anonymous user. The supplicant then presents the true user name as the inner identity used by the authentication method transported through the tunnel. Because the encrypted tunnel has its endpoints at the supplicant and the authentication server, the users true identity is hidden from the access point. Only the outer identity is visible to the access point. This feature may be desirable when the station is roaming on a foreign network but undesirable when managing users on the local network. Each supplicant has a different approach to identity hiding. Some supplicants offer only an anonymous outer identity, others use the username for both the inner and outer identities, and others make the outer identity configurable. Which approach is best depends on the need to make the user’s true identity either hidden or visible.

Conclusion

The choice of supplicant software is important. Because it must be distributed on all wireless stations, it may be difficult to change and manage once it is in the field. The EAP methods supported, platforms supported, ease of use, and flexibility can all be factors in making the right decision.

Interoperability between the supplicant and the RADIUS server is a critical factor being assured through testing by organizations like InteropNet Labs and the Wi-Fi Alliance. You can be assured of interoperability today by using an independent RADIUS server like Interlink’s RAD-Series RADIUS Server, which have been designed to conform to the latest industry standards and interoperate with leading supplicants and the widest range of EAP types in the industry. Interlink’s RADIUS Server supports both PEAP v0 promoted by Microsoft, and PEAP v1 implemented by Cisco, and are so flexible that you can mix and match supplicant software and EAP types – for example Alfa-Ariss’ TTLS supplicant and Cisco PEAP – and use them concurrently.

How the RADIUS server manages the user credentials and interacts with the supplicant will be continued in the next blog posting.

High Performance RADIUS Server

The RAD-Series RADIUS Server is the high end, high performance RADIUS server specifically designed for Carrier, Service Provider and OEM applications that require high throughput and carrier class reliability. Interlink Networks' RADIUS server delivers well over 2000 authentications per second on the Intel-based Linux platforms and Sun-based Solaris platforms.

Network Computing's independent Real-World Labs tested the RAD-Series RADIUS Server against four other popular RADIUS Server products: Cisco ACS, Lucent NavisRadius, Funk Steel-Belted Radius and IEA running on a common hardware platform. In Network Computing's words, Interlink's RADIUS Server delivered a "jaw-dropping" 1900 authentication and accounting transactions per second, compared to between 170 and 320 transactions per second from each of the other RADIUS servers. Their test results are shown below.

RADIUS Server	Performance
Interlink RAD-Series RADIUS Server	1900 trans/sec
IEA RadiusNT RADIUS Server	170 trans/sec
Lucent NavisRadius RADIUS Server	170 trans/sec
Cisco ACS RADIUS Server	170 trans/sec
Funk Steel-Belted Radius Server	320 trans/sec

Interlink's RADIUS Server outperformed Funk Steel-Belted Radius server by a factor of almost 6 to 1. Interlink's RAD-Series outperformed Cisco ACS and Lucent NavisRadius by over 1000%. These tests were run by Network Computing in their Real-World Labs on a Dell PowerEdge 2450 PCs with 1 GB of RAM, 25-GB SCSI hard drives and 993-MHz dual processors running against Windows Active Directory.

The RAD-Series RADIUS Server delivers similar performance on Sun Solaris. Running on a Sun v240 1.2GHz CPU against an LDAP directory server RADIUS delivers over 2400 authentications per second.

Of course, performance is both hardware and application dependent, varying on factors that include hardware platform, software configuration and the data store interface.

802.1X Terminology and the RADIUS Server

Many networking terms such as client and server have become overloaded, leading to confusion. In order to clear some of the confusion, here are some of the basic terms frequently used in 802.1X discussions and how it relates to the RADIUS Server.

802.1X

The IEEE 802.1X standard, Port Based Network Access Control, defines a mechanism for port-based network access control that makes use of the physical access characteristics of IEEE 802 LAN infrastructure. It provides a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics. The 802.1X specification includes a number of features aimed specifically at supporting the use of Port Access Control in IEEE 802.11 Wireless LANs (WLANs). These include the ability for a WLAN Access Point to distribute or obtain global key information to/from attached stations, following successful authentication.

Extensible Authentication Protocol (EAP)

The Extensible Authentication Protocol (EAP), specified in RFC 2284, is a method of conducting an authentication conversation between a Supplicant and an Authentication Server. Intermediate devices such as Access Points and proxy servers do not take part in the conversation. Their role is to relay EAP messages between the parties performing the authentication. The EAP messages are transported between a wireless station and an 802.1XAuthenticator using EAPOL. The EAP messages are transported between an 802.1XAuthenticator and the Authentication Server using RADIUS. The EAP framework supports the definition of Authentication Methods. Currently implemented EAP Authentication Methods include MD5, TLS, TTLS, PEAP, and Ciscos’s LEAP.

Supplicant

The Supplicant is the client authentication software/firmware. It runs on the station seeking WLAN access and conducts an authentication conversation with the Authentication Server (RADIUS Server) using EAP Until authenticated, the Supplicant can only communicate with the Authentication (RADIUS) Server.

Authenticator

An Authenticator performs port-based access control on a Network Access Server such as a Wireless Access Point. During authentication it relays EAP messages between the Supplicant and Authentication (RADIUS) Server and discards all other traffic from the Supplicant.

Once notified of successful authentication by the Authentication (RADIUS) Server, the Authenticator establishes the session and provides network access to the Supplicant using any session keys provided by the Authentication (RADIUS) Server.

Authentication Server (RADIUS Server)

The Authentication Server (typically a RADIUS Server) provides authentication services to the Authenticator. The Authenticator and Authentication (RADIUS) Server have a trusted (client/server) relationship over the secure (usually wired) portion of the network. The Authentication (RADIUS) Server conducts an authentication conversation with the Supplicant using EAP. The Authentication (RADIUS) Server authenticates the Supplicant based upon a user profile that can be maintained either locally or remotely. The Authentication (RADIUS) Server may also perform authorization, collect accounting, and provide session keys to the Authenticator.

A Primer on Using Interlink’s Powerful RADIUS Server Software Developer’s Kit (RADIUS SDK)

Interlink’s RADIUS Server SDK is ideal for customers wishing to customize and enhance the RAD-Series RADIUS Server to meet their specific application requirements. The RADIUS Server SDK provides a set of easy-to-implement, modular tools to develop extensions to the core RADIUS architecture. The tool kit provides APIs (Application Program Interfaces) that make it easy to build custom modules for unique RADIUS authentication, authorization, or accounting methods; modify the internal RADIUS processing engine; set user-based policy; and to customize user interfaces.

With the SDK, you can write capabilities to:

• Authenticate users stored in any data source, including off-the-shelf and proprietary databases
• Track and control usage based on unique billing systems
• Implement highly customized authorization schemes
• Add support for unique network access hardware

RADIUS plug-in modules allow feature enhancements without editing, recompiling, and retesting all of the server code, providing for speedy development of additional functionality. The RADIUS Server SDK functions follow standard ANSI C, so there is no specialized programming or scripting language to learn.

Major system integrator and mobile communication companies throughout the world have used our RADIUS SDK to customize their RADIUS server to meet their specific application needs.

Achieving Ease of Use in RADIUS Management While Maintaining Network Security

The need for ease of use in network management has never been greater. The ever-increasing pace of technical innovation has made it impractical for some of the most technical IT personnel to keep up with the innumerable configuration options and syntaxes. This has led to the widespread use of Graphical User Interfaces (GUIs). This allows the user navigates through a sequence of configuration screens and be presented with a list of options, instead of having to remember what configuration details are required and how to type the corresponding commands at the console prompt. Everyone is familiar with this style of interface on their desktop computer. The same ease of use has been extended to remote network devices through web-based graphical interfaces and the HyperText Transfer Protocol (HTTP).

With this ease of use come a number of security problems.

1. HTTP uses clear text making it easy to intercept passwords.
2. Default passwords for well-known applications become “back doors” to the system if they are not changed or disabled.
3. Well-known port numbers for administrative interfaces make themselves subject to attack.
4. Managing security issues becomes more difficult when each device must be managed by its own independent interface.

Keeping network devices such as a RADIUS Server behind a firewall does not solve the problem. Not all employees are intended to have administrative access to network resources. Security must be applied on the inside of an organization as well as outside. In addition, any successful attempt to hack through the firewall now has access to hack any device behind the firewall, creating yet more holes.

Interlink Networks RAD-Series RADIUS Server Manager

The RAD-Series RADIUS Server Manager addresses all of the above security issues.

1. The RADIUS Server Manager is easily configured to use HTTPS instead of HTTP. This is the same protocol used by commercial web sites to provide secure encrypted communications for sensitive information like credit card numbers.
2. Unlike many administrative interfaces, the RADIUS Server Manager requires an administrative username in addition to a password. To further protect against a default password being used as a back door, the RADIUS Server Manager installer prompts for the Administrator’s login name and password instead of always starting with a default.
3. The RADIUS Server Manager is easily configured to use any desired port number rather than being limited to a fixed default port.
4. A single Server Manager can manage multiple RAD-Series RADIUS Servers. This contributes to ease of use and the assurance that all servers will be managed in a consistent and secure fashion. Communication between the RADIUS Server Manager and the servers is further secured through the use of a shared secret.

Ease of use and secure operations are both important goals in managing the corporate network. With the RAD-Series RADIUS Server Manager, both of these goals can be achieved without diminishing the other.

Defining RADIUS Attributes to Create Groups and Services

RADIUS Attribute-Value Pairs are the building blocks of RADIUS. They identify users, specify network components, configure services, and report session details. The RADIUS RFCs define a set of standard attributes such as User-Name, User-Password, NAS-Identifier, Session-Timeout, and Acct-Output-Octets. In addition to the standard RADIUS attributes, RADIUS can be extended with Vendor Specific Attributes (VSAs) to support proprietary features. What service providers and enterprises may not realize is that VSAs are not just for hardware vendors and networking software developers. VSAs can be used by service providers to create new services and by enterprises to gain better control of their networks.

What would I do with a Vendor Specific Attribute if I had one?

Service providers can use their own RADIUS attributes to define multiple levels of service with each at a different price point and each serving a different market segment. Platinum, Gold, and Standard service levels with their associated pricing plans will appeal to different users. By moving past the “one size fits all” approach new markets can be entered and new profits realized.

Another approach to expand the service provider’s sales reach is to sell services ala Carte. RADIUS attributes can be defined for each service component making it possible to enable and sell them independently of each other. RADIUS attributes can be created to access services such as e-mail, priority support areas, special downloads, and to grant toll free access.

In the enterprise, RADIUS attributes can be used to define departments, group memberships, and roles in the organization. For example, only the accounting department should have access to the financial system and only the engineers to the lab environment. Members of the outside sales team are entitled to toll-free remote access while on the road. Only system administrators are permitted access to network administrative consoles.

Vendor Specific Attributes – where do I get mine?

Step One in defining your own VSAs is to get an enterprise number for your organization. These numbers are managed by the Internet Assigned Numbers Authority (IANA) and serve to uniquely identify your VSAs as belonging to your organization. The current list of assigned numbers can be found at

http://www.iana.org/assignments/enterprise-numbers

If your organization does not already have a number than you can apply for a free enterprise number at

http://www.iana.org/cgi-bin/enterprise.pl

Step Two is to configure your organization as a definer of VSAs in the RAD-Series RADIUS Server vendors file. An Internet Service Provider, NewISP has just received an enterprise number of 123456. NewISP will modify its vendors file to add:

#
# New ISP, Inc.
#

NewISP.attr NewISP.value 123456 NewISP

Where:

NewISP.attr will be used to define NewISP’s VSAs in the dictionary

NewISP.value will be used to define values to assign to NewISP’s VSAs

123456 is NewISP’s enterprise number

NewISP is the label specifying support for NewISP VSAs

Step Three is to define in the RADIUS dictionary the VSAs and any special values that they can take. NewISP has decided that it needs a VSA to store the subscribed service plan in each user’s profile. They have defined three levels that are referred to as Platinum, Gold, and Silver. NewISP will modify its RADIUS dictionary to add:

#
# New ISP VSAs
#
NewISP.attr Service-Level 1 Integer (0,0,0)

#
# New ISP Service Levels
#
NewISP.value Service-Level Platinum 1
NewISP.value Service-Level Gold 2
NewISP.value Service-Level Silver 3

Where:

Service-Level is the name of New ISP’s VSA

Integer indicates that the VSA is of type integer

(0,0,0) are the pruning rules indicating that Service-Level is not returned in any RADIUS responses

Platinum
Gold
Silver are the values defined for Service-Level

Step Four is to apply the new RADIUS attributes to the user profiles. For example in the users file:

jsmith Password = JohnsPASSWORD

NewISP:Service-Level = Platinum

Tbrown Password = TomsPassworD

NewISP:Service-Level = Silver

Now that I have my VSAs how do I make them go to work for me?

The power behind these organizational VSAs is the business rules associated with them. These rules are commonly called policy and can be implemented using the RAD-Series RADIUS Server Policy Engine. In our next blog entry, we will discuss how to write the RADIUS policies associated with these Vendor Specific Attributes

Implementing Simultaneous Session Control in a AAA RADIUS Server

One of the most frequently requested features of the RAD-Series RADIUS Server is simultaneous session control. Service Providers selling low cost flat rate Internet access cannot afford the abuse of users sharing accounts. Simultaneous session control addresses this problem by limiting the number of sessions granted to an account at any given time. The RAD-Series RADIUS Server goes beyond a check box implementation by making the number of simultaneous sessions allowed a configurable item on a per user basis.

As an example, let us look at a small ISP that wants to limit its users to two simultaneous sessions, maintains its users list in a Unix password file, and whose users logon as user@isp.com.

There are four configuration steps to restrict simultaneous session use:

1) Simultaneous session control requires the active session management provided by the LAS (Local Authentication Service). Therefore the realm, isp.com must be defined in las.conf as follows:

Realm isp.com
End-Realm

2) The realm must also be configured in the authfile. In this example the realm is configured for Unix password file authentication.

isp.com UNIX-PW

3) The RAD-Series RADIUS Server must load a finite state machine (FSM) table that supports the LAS (has las in its name). If the RADIUS server was installed with the default FSM table, check+policy+las.fsm, then the LAS is already supported.

4) By default, simultaneous use is set to one session when the LAS is enabled. To change this default to two sessions for our example, Simultaneous-Use will be added as a Check-Item to the DEFAULT entry in the users file.

DEFAULT Authentication-Type=Realm, Simultaneous-Use = 2

Simultaneous session control is an example of Authorization, the second A in AAA. As illustrated by this simple example, authorization adds value beyond simple authentication by further defining the conditions and limits of authorized use.

Protecting AAA RADIUS Accounting Information

The third A of AAA – RADIUS Accounting - often does not get as much attention as Authentication and Authorization, but it is vitally important. The RADIUS server accounting session logs provide usage information for billing in commercial applications and an audit trail in all cases. Because RADIUS is transported by UDP, a datagram protocol that does not guarantee delivery, it is possible for valuable accounting information to be lost in the network. In particular, the loss of RADIUS Accounting-Stops creates several problems including:

1) Incomplete billing information for metered services resulting in lost revenue.

2) Valid users are locked out where Simultaneous Session Control is implemented because the end of their last session was not received. This results in unhappy customers and increased customer support overhead.

3) Incomplete audit trails.

These are important problems. The RAD-Series RADIUS Server cannot always know when a RADIUS Accounting-Stop has been lost in the network but there are several steps that can be taken to improve the situation.

1) Probably the first and most important thing to do is to find out where and why the RADIUS Accounting-Stops are being lost and then fix the root cause of the problem. Do you have problems with NASs crashing? Do you have infrastructure problems where the NAS loses contact with the RADIUS Server for long periods of time? Do you have network congestion problems where packets are lost? Is the machine where the RADIUS Server runs overloaded and running behind?

Check the RADIUS Server logfile to see if it is discarding accounting messages because the queue is full. If it is, then you need to address the overload by either getting a faster machine/disk or by implementing another RAD-Series RADIUS Server. If these are only momentary overloads, then another option is to increase the size of the RADIUS accounting request queue in engine.config from its default value of 2000:

global_acct_q.limit=3000

2) If the packet loss is out of your control or cannot be quickly fixed, then the next step is to configure the NASs to retransmit more effectively. In RADIUS the client is responsible for retransmitting requests for which it receives no reply. Most NASs have parameters to configure the timeout between retransmissions and the number of retransmissions to attempt.

Increasing the retry limit improves the chances of a request getting through. The overall time attempting to get the request through is also increased, giving congestion due to traffic spikes a chance to clear.

Increasing the timeout before retransmitting also increases the overall time attempting to get the request through. Additionally, it has the advantage that by waiting longer to retransmit, the NAS is not contributing as much to the congestion.

3) Configure the NASs to send RADIUS Accounting Interim-Updates. This has two advantages:

a) If the RADIUS Accounting-Stop at the end of the session is lost, then you at least have the accounting information up to the point of the last Accounting-Interim-Update.

b) If the RAD-Series RADIUS Server has received at least one Accounting-Interim-Update, but has not received one within the last 15 minutes + 15 seconds, then the server will move that session to the "suspended" state. If a session is in the suspended state, then it will not count toward the simultaneous session limit and the user should be able to reconnect.

Before enabling RADIUS Accounting-Interim-Updates, be sure to check that your accounting software can handle them correctly. Accounting-Interim-Updates report the cumulative session totals, not incremental amounts. To bill accurately, the accounting software must process only the RADIUS Accounting-Stop or the last RADIUS Accounting-Interim-Update for any given session.

Also note that enabling this RADIUS Accounting-Interim-Updates message will increase the traffic between the NASs and the RADIUS Server.

To log RADIUS Accounting-Interim-Updates, the RAD-Series RADIUS Server’s finite state machine table must be modified at state ACCTlog from:

ACCTlog:

*.*.ACCT_START REPLY Hold

*.*.ACCT_STOP LOG REPLYHold

*.*.ACCT_ALIVE REPLY Hold

to:

ACCTlog:

*.*.ACCT_START REPLY Hold

*.*.ACCT_STOP LOG REPLYHold

*.*.ACCT_ALIVE LOG REPLYHold

4) Set the Session-Timeout attribute as a reply item in the user profile. If the RADIUS Server has not received the RADIUS Accounting-Stop by the end of the Session-Timeout period, (plus a delay factor), then it will move the session to the suspended state where it will not count toward the Simultaneous Session Control Limit.

5) Configure your NAS/telco to hunt in a round robin fashion instead of filling in the first available port. If the RADIUS Server finds a new session connected to the same port, it will close out the old session. Configuring your NAS to hunt round robin insures that all of your ports get reused instead of the first ports getting most of the calls.

Session logging is a crucial aspect of managing a network. An understanding of both the limitations and capabilities of RADIUS, a good handle on network performance, and a few key NAS and RAD-Series RADIUS Server configuration parameters can put you in control of collecting this network asset.

New RADIUS Server Support Blog

This RADIUS Server Support blog is a new approach from the customer support and application engineering teams at Interlink Networks. Over time, this blog will provide commentaries, application examples and support information about RADIUS servers in general and Interlink's RAD-Series specifically.

By nature, this blog can be considered vendor-specific. We'll share our experiences and discuss RADIUS requirements and applications for Carriers and ISPs that are working with high volumes of users and connections into their networks that need to build unique, differentiated service offerings to their customers.

If there are specific topics you'd like to see our teams cover, feel free to leave a comment with your suggestions.