On Apr 18, 2020, at 2:05 PM, Rick van Rein <r...@openfortress.nl> wrote: > The reason for Diameter is that it scales up to the Internet (in terms > of connection pooling / efficiency and in terms of security). RADIUS is > really useful for internal networks, but becomes rather clumsy when > crossing the Internet -- it is not suited for worldwide public service.
Uh.... what? RADIUS is used in Eduroam, which is a worldwide public service. There are many other roaming groups using RADIUS. It seems to be fine. I'm not sure why you think otherwise. >> TBH, I can't recall seeing many WiFi deployments which use Diameter. None >> of the access points support it. Similarly, EAP over LAN is implemented in >> most switches, but they definitely don't do Diameter. > > Catch-22 -- no use case, no software. That's why I'm describing the use > case here. That is definitely *not* the reason people avoided Diameter. The reason is simple: RADIUS does everything that the enterprises and ISPS need. Even Telcos use RADIUS for many things. Diameter won in the Telco space because (at a high level) it was mandated in the 3G standards. And even it seems to be dropped in 5G, in favour of JSON over QUIC. So your starting assumptions are wrong, which makes it easier for your conclusions to end up in the wrong place. > A patchy solution is possible for closed routers; RADIUS and Diameter > can crossover, so a local node doing that is possible. The Diameter protocol is about 100x more complex than RADIUS. It will take *years* before router vendors release inter-operable Diameter clients. Their best bet is to just do RADIUS, and rely on a Diameter server in order to do RADIUS to Diameter translation. There is just too little benefit for vendors to implement this in their client products. >> Is there a specific reason why Diameter was chosen? > > Certainly, > > - It enforces mutually authenticated TLS for peer-validation There is a RADIUS over TLS transport, which is widely implemented and deployed. There's also dynamic peer discovery. Less widely implemented, but definitely used. > - It does not silently assume a profile but negotiates at startup A profile for... what? > - It can pool validated TLS connections for reuse RADIUS implementations already do this. Source code is available. > - It runs over SCTP for realiability without head-of-line blocing It *theoretically* runs over SCTP. In practice, SCTP is not widely used. > Yes it is separate, and just here to give you some context. There are > several AVP sets for tunneling in RADIUS / Diameter, and making a choice > would probably help the crossover to work in general. In RADIUS, those attributes provide for VLAN assignment. They don't provide for secure tunnels to "home" networks. Diameter may be different, as I haven't looked at in detail. The short summary is that if you want this to be widely used in the short term, you should define a RADIUS transport. While freeDiameter exists, it doesn't seem to have an active mailing list. It's policy capability appears small. It seems to be mainly a proxy. Which means that you are limiting the market for this idea to people who are willing to pay $100K+ for a commercial Diameter product. Such a strong limitation means that this idea is likely to be dead in the water even before it starts. I would therefore suggest expanding the use-case for this proposal. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
