RADIUS: Secure Authentication Services at Your Service - Page 4

 By Debbie Deutsch
Page 4 of 4   |  Back to Page 1
Print Article

Performance Issues

RADIUS performance can be sensitive to client retransmission or retry strategies. There is no explicit way for a RADIUS server to tell a client it is busy. Instead, RADIUS relies on the client to be well-behaved, waiting a reasonable amount of time before retransmitting the request to the same server, or contacting a different RADIUS server.

A badly configured client can quickly overload the servers with repeated requests. When planning a RADIUS deployment, you should remember that this is a client-side issue, not a problem in the server. Your goal should be to configure clients with a reasonable retransmission/retry strategy. That will depend on what is supported.

You should also aim to have sufficient server capacity so that the lack of a response is most likely due to a server’s being off the network rather than being overloaded. In addition, clients should be configured not to send test requests to RADIUS servers just to see if they are available.

Use of proxies is another consideration for RADIUS deployment design. Many small and medium-sized enterprises do not need proxies. However, using RADIUS proxies can help distribute administration in large or geographically dispersed organizations, or it can be a good means to gain quick response time for user database changes. Beware, however, that using proxies may represent a potential security concern, especially if they are not under your direct control.

RADIUS performance, availability, and scalability rely on good management of load and congestion. You need to look at total server capacity (based on hardware and software), the number and location of servers, balancing load across servers, and network connectivity/bandwidth between clients and servers. These design issues are common to many client-server architectures, not just RADIUS.

Future Directions

Just as TACACS was superceded by RADIUS, RADIUS itself may be replaced at some point in the future. Work on DIAMETER, a potential successor to RADIUS, has been going on for a number of years in the IETF’s AAA Working Group. DIAMETER’s improvements include a fail-over strategy, use of TCP for reliable transport (instead of UDP, as RADIUS uses), and more general support for transmission-level security (via IPSEC).

DIAMETER also adds required support for server-initiated messages (to handle unsolicited disconnects, for example) and includes optional capabilities for data object security, which is particularly important when proxies are involved. It also is more explicit about the behavior of agents, such as proxies. While many of these added capabilities are of interest to companies, they are of greater and more immediate value to ISPs.

Unfortunately, the DIAMETER protocol is not directly compatible with RADIUS. However, it has been designed to coexist with RADIUS in the same network, cooperating via a gateway or a server that implements both.


RADIUS can be very useful for ensuring that remote users are who they say they are, keeping track of their network usage, and securing your network infrastructure from intrusion. If you are not already using RADIUS, what are you waiting for? If you do not have the expertise in-house to deploy it, consider using a managed service or an appliance.

Is it time to start considering DIAMETER products for your future deployments? Not just yet — while it is something to keep on your radar screen, DIAMETER is not far enough along in terms of standard vendor support or market acceptance to merit consideration for near-term implementation.

Technical References

IETF specification for the RADIUS protocol: RFC 2865
IETF specification for RADIUS protocol accounting support: RFC 2866
IETF extension to RFC 2866 to include tunnel protocol support: RFC 2867
IETF extension to RFC 2865 to include tunnel protocol support: RFC 2868
IETF additional attributes that may be used with RFCs 2865 and 2866: RFC 2869
IETF specification for operation of RADIUS over IPv6: RFC 3162
IETF draft of DIAMETER base protocol (December 2002): draft-ietf-aaa-diameter-17.txt

Beth Cohen is president of Luth Computer Specialists, Inc., a consulting practice specializing in IT infrastructure for smaller companies. She has been in the trenches supporting company IT infrastructure for over 20 years in a number of different fields, including architecture, construction, engineering, software, telecommunications, and research. She is currently consulting, teaching college IT courses, and writing a book about IT for the small enterprise.

Debbie Deutsch is a principal of Beech Tree Associates, a data networking and information assurance consultancy. She is a data networking industry veteran with 25 years experience as a technologist, product manager, and consultant, including contributing to the development of the X.500 series of standards and managing certificate-signing and certificate management system products. Her expertise spans wired and wireless technologies for Enterprise, Carrier, and DoD markets.

» See All Articles by Columnist Beth Cohen

This article was originally published on Jul 29, 2003
Get the Latest Scoop with Networking Update Newsletter