[RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times

Heikki Vatiainen hvn at open.com.au
Thu Apr 5 07:00:01 CDT 2012


On 04/03/2012 07:45 PM, Karl Gaissmaier wrote:

Hello Charly,

> I've a problem with AuthBy RADSEC and the failure algorithm.
> 
> In the eduroam confederation it's nearly impossible to find proper
> values for NoreplyTimeout, MaxFailedRequests, ... for Access-Requests.
> 
> It takes sometimes many seconds (till 60s or more) to get an reply
> for an Access-Request.
> 
> It would be much better to use Status-Requests against the server to
> determine if the next server is dead and not an timeout for proxied
> Access-Requests down the lane.

So Status-Server would be used instead of NoReplyTimeout and
MaxFailedRequests? If Status-Server gets no response, then the server
would be probed infrequently to see when it gets back. Meanwhile the
requests would be forwarded to the secondary server?

Would the current behaviour of returning nothing (IGNORE) to the
previous server still be fine?

Another alternative would be to synthesise an Access-Reject to the
previous server.

Related to this, what is the current view of using Dead Realm Marking in
eduroam?

http://wiki.eduroam.cz/dead-realm/docs/dead-realm.html

If there are more than one next hop server, DRM can try all next hop
servers to see if the realm's server(s) are reachable. Has the
possibility of trying alternative paths found to be not useful in real
life. In other words, if a request for a certain realm times out, is
there any use for trying other servers?

If nothing is returned, then DRM could try alternative paths. If an
Access-Reject is synthesised, then DRM could not be used since the
timeouts and real rejects would look the same.

> Is this a new RFE? How is this solved in other eduroam sites with RADIATOR?

Comments would be appreciated.

Thanks!
Heikki


> Best Regards and thanks for RADIATOR, the best software I've ever bought!
> 
> 	Charly


-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.


More information about the radiator mailing list