Comparison of the RADIUS and Diameter Protocols

Mladen Stanke, Mile Sikic PBZ d.d., Rackog 6, Faculty of Electrical Engineering and Computing, Zagreb, Unska 3

mladen.stanke@pbz.hr, mile.sikic@fer.hr

Abstract. In this research, the differences between the Diameter and the RADIUS protocols were studied on a practical example, and their behavior was tested in a real life situation. Diameter and the RADIUS test environment was created via the VitalAAA program which supports the RADIUS server and client, and the Diameter server and client. The reaction time for individual measurements was read from the log file. The following measurements were made: connection times for RADIUS and Diameter protocols, client reaction time in case primary server is unavailable, transport reliability for Diameter and RADIUS, and node search capability for Diameter. The results are presented both tabular and graphically

Keywords. RADIUS, Diameter, server, client, authentication, accounting.

1. Introduction

In the present-day information society, the life has become unthinkable without the internet, mobile phones, and services provided through various networks. The availability of services and network resources is limited by institutions that provide such services, and it is very significant to keep track and check who can access a particular service, and for how long the service is used. The AAA protocols were created as a means to meet such specific demands. They enable us to identify the user, to recognize which service he is allowed to use, and for how long. In this paper, we will compare two AAA protocols operating in network environment: RADIUS and Diameter. These two protocols are standard AAA protocols for use in networks. The Diameter protocol was created by the IEEE organization in order to eliminate deficiencies of RADIUS, and to eventually replace RADIUS with the Diameter protocol.

2. Methods

In this research, we used the VitalAAA program[6]. The RADIUS[2] and Diameter[3]

server, and the RADIUS and Diameter client, were implemented in the program. The diameter/RADIUS server was started on one computer, while the Diameter/RADIUS client was started on another one. The Client sent to the server the AAA packages encapsulating the EAP package [1], [4] (EAP-TTLS), authentication request sent from NAS, and the accounting request. Time intervals needed to start or stop the session under pre-defined conditions were measured. The time intervals were read from the server and client log file.

3. Comparison of RADIUS and Diameter connection times

The purpose of this measurement was to show which AAA protocol, either RADIUS or Diameter, would establish the session faster. The measurement time is defined as the time from the start of the NAS simulator to the last event that the server reports as successful start of the session. The measurement was done with AAA packages encapsulating the EAP package (DER package), with AAA packages sent from NAS (NASREQ package), and with Accounting packages (ACCOUNTING package). Ten measurements for every package type were made for each of the AAA protocols. The mean value of the measured time intervals was taken as comparison time for session establishment. Mean connections times for Diameter and RADIUS protocols are presented, for individual package types, in Table 1.

Table 1. Session establishment times for Diameter and the RADIUS for different type of packages

DER NASREQ ACCOUNTING

DIAMETER 0,272 0,046 0,040

RADIUS 0,204 0,040 0,022

A more vivid graphical presentation of session establishment times is given in Figure 1.

893Proceedings of the ITI 2008 30th Int. Conf. on Information Technology Interfaces, June 23-26, 2008, Cavtat, Croatia

0,0000,0500,1000,1500,2000,2500,300

DER

NASREQ

ACCOUNTING

Types of packages

Con

nect

ion

time

/ sec

DIAMETER

RADIUS

Figure 1. Session establishment times for Diameter and the RADIUS for different type of packages

It can be seen from Figure 1 that the session establishment time is the longest when EAP package is encapsulated in the AAA package. In our case, this situation occurs in the EAP-TTLS package. In EAP-TTLS communication, data is exchanged between the client and server in several phases, and so it is quite logical in this case that connection time is longest. The shortest connection time is registered in case of the Accounting process.

The connection was in all cases faster with the RADIUS protocol then with the Diameter protocol. There are several reasons for this. Firstly, RADIUS uses the UDP transport protocol, while Diameter uses the TCP transport protocol. Secondly, Diameter starts its communication by the exchange of CER-CEA packages. In case of RADIUS, there is no data exchange among nodes: the RADIUS communication starts right away. It can be seen in Figure 1 that the establishment of the Diameter session can last up to 40 percent longer when compared to the time needed to establish the RADIUS session.

4. Client reaction time if primary server is not available

The goal of measurement was testing if a failure of the primary server influences the client authentication time. The time for client authentication was measured for individual AAA protocols in case the primary server was unavailable. Ten successive measurements were made for Diameter and RADIUS. Measurement results are given in Figure 2 and Figure 3.

0,0000,5001,0001,5002,0002,5003,0003,5004,0004,500

1 2 3 4 5 6 7 8 9 10

Number of trials

Res

pons

e tim

e / s

ec

Figure 2. Diameter protocol reaction time

0,0000,5001,0001,5002,0002,5003,0003,5004,0004,5005,0005,5006,0006,5007,0007,5008,0008,5009,0009,50010,00010,500

1 2 3 4 5 6 7 8 9 10

Number of trials

Resp

onse

tim

e / s

ec

Figure 3. Radius protocol reaction time

It can be seen from measurement results that in case of RADIUS the authentication time is twice as long as that of the Diameter. This is quite expectable, as the RADIUS protocol does not have a mechanism to detect that the primary servers is out of operation, but rather it sends three requests to primary server and, when there is no reply, it reroutes its request to the secondary server. In this case Diameter reaction is much faster because of using the CER-CEA packages.

5. Reliability of transport for the Diameter and RADIUS protocols

An another difference between the Diameter and RADIUS protocols lies in the transport protocol used by individual AAA protocols. The RADIUS uses UDP for transport protocol, while the TCP transport protocol is used by the Diameter. The reliability of transport of an

894

individual transport protocol directly influences transport reliability of the AAA protocol. This measurement was made to determine transport reliability of the Diameter protocol as compared to the RADIUS protocol. The test environment consisted of the VitalAAA program and four routers. The client was situated four hops away from the server. The test environment is presented in Figure 4.

Figure 4. Test environment

The bandwidth of links between the routers amounted to 2Mbit/s, and the routing was realized via static routes. The measurement was conducted by sending 540 Mbytes of traffic from the client towards the server. EAP packages encapsulated in the corresponding AA package were used. The quantities of EAP packages sent by the client in 30 minutes, and the quantity of EAP packages received by the server in these 30 minutes, were measured. Measurement results are presented in Table 2.

Table 2. Reliability of transport in AAA protocols in the networks without congestion

RADIUS DIAMETER generated / Mbyte 540 540 sent (30 min) / Mbyte 256,82 227,93 received (30 min) / Mbyte 190,66 223,88 total ratio / % 35,31 41,46 30 min ratio / % 74,24 98,21

In the second measurement a network hub was inserted into the communication route. In addition to AAA traffic, the hub also received other traffic, so in that way we simulated network congestion. Measurement results are presented in Table 3.

Table 3. Reliability of transport in AAA protocols in the networks with congestion

RADIUS DIAMETER generated / Mbyte 540 540 sent (30 min) / Mbyte 255,72 184,95 received (30 min) / Mbyte 111,57 138,37 total ratio / % 20,66 25,62 30 min ratio / % 43,63 74,82

It can be seen from Table 2 and Table 3 that the RADIUS sends packages faster than the Diameter. In both measurements, i.e. in the network without congestion and in the network with congestion, the Diameter is more reliable in transport. We can see that from the last row in the Table 2 and Table 3. In networks without congestion in 30 minutes Diameter transported 98 percent of sent packages comparing with RADIUS who transported 74 percent of sent packages. In networks with congestion in 30 minutes Diameter transported 74 percent of sent packages and RADIUS transported only 43 percent of sent packages.. When we look at the total traffic to be operated by both AAA protocols, we can see that the Diameter transports more traffic than the Radius. This can be read in the second-last row of the results table.This measurement shows that the Diameter is dominant in reliable transfer of packages. In this case, the use of TCP as transport protocol has really proven worthwhile.

6. Quantity of traffic operated in network during session establishment

The quantity of traffic operated via network during client connection to the server was also defined as a parameter for comparing the Diameter and RADIUS protocols. During the measurement we used the AAA package with the encapsulated EAP package, the AAA authentication package, and the accounting package. The measurement was made for two cases. The first one is when the client succeeds to authenticate at the primary server, and the second is when the client succeeds to authenticate at the secondary server. Measurement results are presented in Figure 5 and Figure 6.

01000

2000300040005000

60007000

AAA-EAP

AAA-NAS

ACCOUNTING

Type of packages

byte DIAMETER

RADIUS

Figure 5. Traffic operated during connection to the primary server

895

0100020003000400050006000700080009000

AAA-EAP

AAA-NAS

ACCOUNTING

Types of packages

byte DIAMETER

RADIUS

Figure 6. Traffic operated during connection to the secondary server

In both cases the Diameter generates more traffic than the RADIUS. The increase in traffic generated by the RADIUS is significant in case when the client connects to the secondary server. The reason for this is that the RADIUS first sends three requests to the primary server and then sends its request to the secondary server. The greatest quantity of traffic is generated when the AAA package - with the encapsulated EAP packages - is sent.

7. Diameter's node finding capacity

One of the drawbacks the RADIUS protocol is absence of checking whether its neighboring nodes have the capacity to support specific applications. This deficiency was noted by the Diameter creators who improved the Diameter protocol in such a way that its node can detect the neighboring node, and exchange with it information about specific applications and levels of security supported by the node.

The Diameter server and client were started in the test environment, and the time needed for the two nodes to recognize one another and establish the Diameter connection was measured. The measurement was made for two cases. In the first case, the objective was to determine how much time the Diameter needs to recognize the node when it is connected to the network for the first time. In the second case, the testing was done to see how long does it take for the Diameter to recognize the node connected once again to the network. Ten measurements were

made for each case. The results are presented in Figure 7 and Figure 8.

0,014

0,0150,016

0,0170,018

0,019

1 2 3 4 5 6 7 8 9 10

Number of measurements

Tim

e to

est

ablis

h co

nnec

tion

/ sec

Figure 7. Time to recognize node for the first time

0,014

0,015

0,016

0,017

0,018

1 2 3 4 5 6 7 8 9 10

Number of measurements

Tim

e to

est

ablis

hco

nnec

tion

/ sec

Figure 8. Time to recognize node for the second time

In this section, we took our attention on a mechanism used in the Diameter protocol to detect the neighboring node[5]. Hence, the node detection mechanism used by the Diameter protocol will be described in greater detail. In the Diameter protocol, the connection between two notes is described with three variables. The first one indicates whether to connection is closed, opened, or whether it is waiting for a package. The closed and opened states are the stationary states of the session, while the states in which the waiting for a package occurs are transit states, i.e. the states that are on the way of becoming stationary. The second variable is the network status. This variable indicates the intention or the connection's inclination towards an individual state. Some of the values are: INTIAL, OKAY, DOWN, and REOPEN. The third variable is the event itself. It shows us what action is taken at an individual connection. The action causes the change in a connection. The entire mechanism of detecting the node and the changes at individual variables is presented in Figure 9.

896

Figure 9. Node detection in Diameter protocol

Let us now take a closer look at how the mechanism actually operates. Once the application is started at the side of the server and client, the connection state is closed but with the tendency of becoming active. The event is the "start" event, and it wishes to activate connection between the client and server. The "Start" event changes the server's connection state to the state in which server expects confirmation that the connection has been established. At the client level, the start event initiates the sending of the Capabilities-Exchange-Request (CER) package towards the server. The client's host name is entered in the package, and the client reads the package destination from the configuration file which contains the IP address or the host-name of the server. Before sending the CER package the client gets confirmation from the TCP protocol that the TCP connection has been established and that the dispatch of the Diameter packages can start. The state changes into the state in which the client expects conformation that the connection has been established. Once the server has received the CER package, it starts the CER package processing activity and generation of the Capabilities-Exchange-Answer (CEA) package. The client changes the automatic device's state into the state in which it awaits the server's answer/reaction to the CER package that has been sent. Once the CEA

package has been received, the client changes the state into the stable state "Open", and it starts sending other Diameter packages. The server awaits confirmation for the CEA package it has sent in reply. The confirmation arrives in form of a Diameter package and now it also changes the connection state into the state Open. Once the Diameter connection has been established, the exchange of other Diameter packages starts so that the authentication and authorization can be made. If at any time the connection between the client and server is interrupted, the state of the session at the server level passes into the closed state (Closed), the session status moves to the DOWN position, and the event realized is the disconnection of nodes. If the client connects to the network once again, then the procedure restarts from item 1, the only difference being that, once the Diameter connection among nodes at the server level is established, the connection status is REOPEN. The interruption event is presented more clearly in Figure 10.

Figure 10. Interruption of the Diameter protocol

In both cases, the node finding time is the same. The fact that the node used to be active in the network does not accelerate its detection procedure. The RADIUS does not have this mechanism for detecting whether the node is "alive" or not. The RADIUS just sends request to the next node. In case of no reply after three consecutive requests, it reroutes the request to the secondary node. The fact that the RADIUS can not detect the node results in additional waiting time during the RADIUS communication and increases the network authentication time.

8. Discussion

In this study, the RADIUS and Diameter servers were compared based on practical examples. The RADIUS protocol is by 40

STATE: Closed STATUS: DOWN EVENT: Peer_Disc

5

DER

BREAK DOWN

STATE: Open STATUS: OKAY EVENT: Rcv_Message

4

CLIENT SERVER

STATE: Close STATUS: INITIAL EVENT: Start

1

STATE: Wait_I_CEA STATUS: INITIAL EVENT: Rcv_CEA

3

STATE: Open STATUS:OKAY EVENT: Send_Message

4

STATE: Close STATUS: INITIAL EVENT: Start

1

CER

CEA

STATE: Wait_Conn_Ack STATUS: INITIAL EVENT: Rcv_Conn_Nack

2

STATE: Open STATUS: OKAY EVENT: Rcv_Message

4

DER

DEA

STATE: Closed STATUS: INITIAL EVENT: R_Conn_CER

3

STATE: Open STATUS: OKAY EVENT: Rcv_Message

5

STATE: Wait_Conn_Ack STATUS: INITIAL EVENT: Rcv_Conn_Ack

2

STATE: Open STATUS:OKAY EVENT: Send_Message

5

897

percent faster in performing the authentication, and 80 percent faster in performing the Accounting, when compared to the Diameter server. Compared to Diameter, the RADIUS needs eight times less traffic to perform the authentication activity. However, the Diameter reacts two times faster when the primary server is unavailable, as it has its own packages for the neighboring peer detection. In networks without congestion, Diameter transported 98 percent of sent packages and RADIUS transported 74 percent of sent packages. In networks with congestion Diameter transported 74 percent of sent packages and RADIUS transported 43 percent of sent packages. The Diameter's great improvement when compared to RADIUS lies in the possibility of detecting the neighboring peer and exchanging information with this peer. For performing this operation Diameter need from 0.015 to 0.018 seconds. The fact that the RADIUS does not have this possibility causes a considerable standstill in the RADIUS protocol authentication, including possible authentication failure. If the RADIUS is improved by adding messages that can be initiated by the server and directed towards the client, then the RADIUS would be able to control network congestion and interruptions. Thus, the server-blockage waiting time would be reduced by as many as 10 seconds, and it would become possible to control data transfer via crowded networks.

The Diameter is at its best in wireless networks, where the bandwidth is limited and the user must make authentication at every cell change. In this environment, its reliability of data transfer is exploited to its full potential, and the Diameter is more favorable even when the client authentication velocity is measured. Thus, due to unreliability of the UDP, which is used by the RADIUS as transport protocol, the waiting time the RADIUS needs to realize that the package is lost and to send a new request, exceeds by far the time the Diameter needs to authenticate the user. In such circumstances, the use of the Diameter protocol is highly recommended for the authentication, authorization and accounting.

9. Conclusion

The RADIUS protocol identifies the user faster and with fewer packages than the Diameter protocol. However, its downside is the fact that is unable to control its traffic and peers in the

communication chain, and has thus been proven ineffective in overly crowded networks where frequent client re-authentication is required. The RADIUS protocol can be improved in the traffic and peer control segment.

The Diameter protocol is recommended for congestion networks because it can control their traffic, as well as the communication among their peers. Because of this developed control over the peers, the Diameter solves the server inaccessibility problems much faster, and would in such cases authenticate the client much sooner than the RADIUS protocol. Compared to RADIUS, the Diameter protocol is better equipped for dealing with problems that are encountered in the present-day networks. In case RADIUS assumes some new functions, while keeping its good properties, it could become competitive with the Diameter protocol. In that case there would be no needs to replace RADIUS with Diameter protocol.

10. References

[1] B. Aboba, P. Calhoun. RADIUS for EAP. IETF; 2003.

http://www.ietf.org/rfc/ rfc3579.txt [2] C. Rigney, S. Willens, A. Rubens, W.

Simpson. RADIUS. IETF; 2000 http://www.ietf.org/rfc/ rfc2865.txt [3] P. Calhoun, J. Loughney, E. Guttman, G.

Zorn, J. Diameter Base Protocol. IETF2003.

http://www.ietf.org/rfc/ rfc3588.txt [4] P. Eronen, T. Hiller, G. Zorn. Diameter

EAP Application. IETF; 2005. http://www.ietf.org/rfc/ rfc4072.txt [5] Wen-Ting Wu. Design and Implementation

of WIRE Diameter. WIRE Laboratory, 2004.

http://wire.cs.nthu.edu.tw/WIREDiameter/ Design and Implementation of WIRE Diameter.pdf

[6] VitalAAA Server Management Tool Manual.

Lucent Technologies 2006.

898