hi
just a small preamble: i perfectly understand your position and i do not
expect you to start a diameter implementation tomorrow :-) for me it's
merely a strategic discussion.
Alan DeKok wrote:
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.
perfect, apparently we've just closed the circle:
i started this conversation by the statement "what are the manufacturers
waiting for?" adding that we might be missing interesting opportunities
(as a cause of manufacturers not integrating diameter). you asked which
features i was talking about :-) and now you ask about devices. circle
completed.
according to this funny newsgroups discussion study, that's probably the
point where we start talking about god (since we have reached the
convergence).
- reliability (especially for accounting)
radsec from the NAS to the RADIUS server would solve this.
only partly, i think, since the reliability of accounting depends on
more than just on the reliability of transmissions. there are things to
specify in the implementations, especially when we start talking about
multi-party-accounting. you have to think about accountability,
integrity and non-repudiation. the fact that accounting support is not
obligatory in radius does not exactly help here.
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.
that's probably true. but, citing you: where are the client
implementations? do you know of any radsec-cacable 802.11 access point?
that would interest me personally.
and what is radsec anyway? it is not an RFC standard track and why would
i implement proprietary solutions when the sense is to enable a
multi-domain operation?
- 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!
hmmm?? well... PoD is probably the ugliest hack ever. imho, PoD is not a
solution but a proof that things have been badly overseen during the
Radius-design and especially re-design phases.
and anyway it only partially answers my question. disconnect is just ONE
possible application. what about a complete PBM solution?
- 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.
true and same as above: not a standard, no NAS.
- 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.
*provoke* why talking about drafts when we have a standard track
protocol which supports this? :-)
radius+kerberos: if it used used radius as a trusted third party, then
it does not surprise me that it has been abandoned...
ciao
artur
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
