Artur Hecker <hecker@enst.fr> wrote:
well, from my perspective the main arguments would be: ...
Those are all nice arguments for diameter, and good reasons why the protocol was designed. But I keep coming back to: Where are the client implementations? There are few to none client implementations.
- reliability (especially for accounting)
radsec from the NAS to the RADIUS server would solve this.
udp is generally not very handy when you want more control over the NAS, even if i understand the initial motivation to base radius on it. however, today you run in all those problems with NAT, session initiation in firewalled environments, reliability, security and so on.
radsec solves this, too.
- server-initiated messaging the strict client-server design of radius (imho amplified by the use of the conn-less UDP) does not allow for server-initiated commands such as "disconnect" or "force re-authorization on profile changes" (very important with PBM)
Huh? See the "disconnect request" packets. Radclient even supports this!
- NAS management radius-typical fqdn/shared secret based security simply does not scale. it is too complicated to manage NAS in this manner and often results in network-wide radius passwords.
radsec with per-NAS certificates solves this.
- security with proxying in Radius proxies can modify packets. this is often not a good thing to do. diameter has a far better and more extensive support for TLS, especially for roaming scenarios. security might not be an issue in the way radius is typically used, but its security definitions are completely obsolete (strange md5-based hashing is not exactly the state of the art, and right now ipsec support is as improbable with NAS as diameter-support itself :-)).
radsec doesn't support this, but there was a radius + kerberos draft which did. Recent opinions in the radius working group indicate that dropping this might have been a mistake.
well, we have seen a lot of implementations (especially in the hotspot management area) where people use HTTP from server to NAS to trigger radius-requests to be sent towards the server (!). it's nonsense.
Yup. Alan DeKok.