ITT Tech | Week 7 Comparison of RADIUS and DIAMETER | [Type the document subtitle] |

Jackie Cooper
2/5/2014
|

Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users that connect and use a network service. RADIUS was developed by Livingston Enterprises, Inc. in 1991 as an access server authentication and accounting protocol and later brought into the Internet Engineering Task Force (IETF) standards.
Because of the broad support and the ubiquitous nature of the RADIUS protocol, it is often used by ISPs and enterprises to manage access to the Internet or internal networks, wireless networks, and integrated e-mail services. These networks may incorporate modems, DSL, access points, VPNs, network ports, web servers, etc.
RADIUS is a client/server protocol that runs in the application layer, using UDP as transport. The Remote Access Server, the Virtual Private Network server, the Network switch with port-based authentication, and the Network Access Server (NAS), are all gateways that control access to the network, and all have a RADIUS client component that communicates with the RADIUS server. RADIUS is often the backend of choice for 802.1X authentication as well.
The RADIUS server is usually a background process running on a UNIX or Microsoft Windows server.

Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from and replaces the much less capable RADIUS protocol that preceded it. Diameter Applications extend the base protocol by adding new commands and/or attributes, such as those for use of the Extensible Authentication Protocol (EAP).

Differences between RADIUS and DIAMETER Characteristic | RADIUS Deficiency | DIAMETER Improvement | Strict limitation of attribute data | Only 1 byte reserved for the length of a data field (max. 255) in its attribute header | Reserves 2 bytes for its length of a data field (max. 16535) | Inefficient retransmission algorithm | Only 1 byte as identifier field to identify retransmissions. This limits the number of requests that can be pending (max. 255) | Reserved 4 bytes for this purpose (max. 2^32) | Inability to control flow to servers | Operates over User Datagram Protocol (UDP) and has no standard scheme to regulate UDP flow | Scheme that regulates the flow of UDP packets (windowing scheme) | End-to-end message acknowledgment | Client expects a successful or failed response after a request, but does not know whether the server has received the request | Client expects a success of failed response or an acknowledgment of the received request by the server | Silent discarding of packets | Packets that do not contain the expected information, or that have errors, are silently discarded. This might cause the client to operate as if the server is down because it does not receive any response. It would then try to send packets to a secondary server | Server can notify the client of problem by sending an error message | No failover server support | Server has no way of indicating that it is going down or is currently running | Supports keep-alive messages and messages that indicate that a server is going down for a time period | Authentication replay attacks | When using PPP CHAP any RADIUS client can generate a challenge response sequence, which can be intercepted by any RADIUS client or proxy server in the chain. Another RADIUS client can then replay this challenge response sequence at any time (partly solved by the RADIUS extension using the EAP protocol) | Challenge/response attributes can be secured using end-to-end encryption and authentication | Hop-by-hop security | Supports only hop-by-hop security; every hop can easily modify information that cannot be traced to its origin | Supports end-to-end security, which guarantees that information cannot be modified without notice | No support for user-specific commands | Supports vendor-specific attributes, but not vendor-specific commands | Supports vendor specific command codes | Heavy processing costs | Does not impose any alignment requirements, which adds an unnecessary burden on most processors | Has a 32-bit alignment requirement, which can be handled efficiently by most processors |