Artur Hecker <[EMAIL PROTECTED]> 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html