1

The name of the protocol is a play on the word Diameter, which is twice the RADIUS of a circle - in other words, the author is trying to say it is twice as good and has more features.

It seems like the pros outweigh the cons, and according to this website the pros are pretty good (note, I can't vouch for all of the information, I was referring to the table).

For example, Diameter uses TCP, has good scalability (which is aided by TCP), supports IPSec and TLS for clients, and has an error reporting scheme.

However, I've never heard of the protocol until today. The book says that many companies are upgrading to Diameter. I also couldn't see any reference to Microsoft supporting Diameter OOTB, and I know they are not backwards compatible. I would think that Microsoft would want to move to Diameter, and that it would be possible to have a transitioning phase to support both protocols.

However, I do know Microsoft has an RFC for Microsoft Vendor-specific RADIUS Attributes but I'm not sure how relevant most of it is since it's mentioning CHAP (not v2) and was written in 1999. However, if RFCs are your thing, go you.

The books says more organizations are moving to Diameter over RADIUS, but I've never heard of it. Is there a reason people aren't doing so or am I just out of the loop?

cutrightjm
  • 1,714
  • 4
  • 18
  • 31

2 Answers2

5

Diameter was designed to supersede RADIUS. There is no doubt Diameter provides superior functionality. Unfortunately, upgrading old RADIUS environments can be tricky.

“There is a large RADIUS deployment base out there and unless a proper migration plan that includes deployment of translation agents and co-existence of RADIUS and Diameter, migration to Diameter will not be simple.” [1]

The “translation agents” mentioned above are software or devices acting as adapters between new Diameter servers and legacy hardware that only supports RADIUS. Translation agents could relieve the effort required to upgrade, but they bring their own problems too.

“... there can be many variants and implementations of translation agents in proprietary non-IETF manners. Also due to the simultaneous standardizations of RADIUS and Diameter, various RADIUS messages may be handled differently by different translation agents along the process, while none of those translation agents can be assumed to have access to complete and accurate session state information.” [1]

That sounds hard. So RADIUS extensions have proven to be the easier option.

“… The uptake of Diameter has been very slow though, and RADIUS still remains the de facto standard for the foreseeable future. A major reason for this is probably the fact that the many enhancements that Diameter was supposed to bring are already covered by the various RADIUS extensions. There is, for instance, the RadSec protocol that transports RADIUS over TCP and TLS.” [2]

Of course, there are limitations to RADIUS extensions. Diameter can provide far superior support for 4G LT-Advanced mobile networks, for which RADIUS would be a very poor choice [3].

TACACS+ is also available, but

“TACACS+ overall function is similar to that of RADIUS but RADIUS has enjoyed a more widespread use since it is not a proprietary (sic) of Cisco.“ [3]

Some also argue that TACACS+ is more suited to network administration than general network access for a large user base (e.g. ISP, Telco) [4].

I appreciate that some of my references are old and my be out of date. Although, I have recently seen new, small-scale network deployments choose RADIUS over Diameter/TACACS+. In these cases, the staff know RADIUS; extensions provide required security; and RADIUS has no ties to Cisco.

I think it's matter of time before Diameter overtakes RADIUS, but it's very hard to tell just how much time.

[1] Nakhjiri, M. & M., AAA and Network Security for Mobile Access: Radius, Diameter, EAP, PKI and IP Mobility, Section 7.4, John Wiley & Sons, 2005

[2] van der Walt, D., FreeRADIUS Beginner's Guide, Packt Publishing, 2011

[3] Håkan, V., Diameter: Next generations AAA protocol, Institutionen för systemteknik, 2001

[4] Woland, A., RADIUS vs TACACS+, retrieved from http://www.networkworld.com/article/2838882/radius-versus-tacacs.html

1

In my opinion it is simply a practical reason. Diameter has been around long. I think I heart of it like 10 years ago. In fact the first RFC is from 2003.

The RADIUS protocol is totally everywhere. Each router, firewall, switch, VPN... All even the smallest devices are using RADIUS as a RADIUS client. And small might also be a reason here, because it is lightweight. Switching to a non compatible protocol... where? Replace the RADIUS server with a Diameter server? Fine - but then there are no clients in your network capable of speaking diameter?

Don't get me wrong, I would love to have another more secure authentication protocol. RADIUS is offering a lot of extensions to compensate this like EAP, EAP-TLS... The extensibility is one of the strengths of RADIUS. (It is not an advantage against diameter, but a reason it does not simply die ;-)

Besides - like diameter - RADIUS is not simply an authentication protocl but also a protocol to do authorization and accounting - quite well.

cornelinux
  • 1,993
  • 8
  • 11
  • Good points. I added in the part about them both being able to run side by side for a while to include a kind of transition phase - so for the clients that were able to use Diameter could, but the others could use RADIUS. However, in the long run, it's probably simpler just to modify RADIUS instead of switching to a different protocol – cutrightjm Sep 20 '16 at 07:42
  • Or could it replace TACACS+ for example. – hspaans Sep 20 '16 at 12:11