hi alan
sorry for the delay.
you might be right. yet i think that we might ignore some opportunities
which would be possible/supported by diameter.
Like... what?
well, from my perspective the main arguments would be:
- reliability (especially for accounting)
in every related implementation we always had to tweak around the
timeouts etc. just because you can't be sure that the accounting-stop
arrives correctly when the user is disconnected. especially in an
environment with a lot of connects and disconnects, this results in
"stalled" sessions which have to be explicitly treated and where the
relation to the real network usage is principally lost. this is boring.
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.
- 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)
- 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.
- 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 :-)).
that's what bothers me personally, in this order. i think there are much
more of those in the diameter RFC.
i really believe that current usage produces demand in the same
manner as demand influences the usage. using additional web-based
"touches" to trigger server solicitations by the client is indeed
quite ridiculous.
I'm not sure what you're referring to here.
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.
It shouldn't be too hard to write a radsec implementation. Ideally,
it could leverage the TLS code in rlm_eap.
that wouldn't be enough for roaming cases.
ciao
artur
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
