Radius, Radsec, Diameter [was: Silly question - secure Radius?]

[Artur Hecker]

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