FreeRADIUS and EDUROAM timeout issues

[Arran Cudbard-Bell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Eriksson wrote:
> 
> Alan DeKok wrote:
>> Peter Eriksson wrote:
>>> The default setting seems to be less than optimal since if a remote site
>>> have problems with their home RADIUS servers then we risk having our
>>> local servers mark the upstream servers as "dead" since it's not
>>> receiving answers for a specific 'realm'...
>>   That's been a bit of a problem in RADIUS proxying.  The specification
>> says that serves MUST answer Access-Requests.  But some implementations
>> don't do that when they're proxying.  This causes all sorts of problems.
>>
>>> Perhaps increase the 'response_window',
>>> and lower 'zombie_period' and 'revive_interval'
>>> and 'check_interval' values...
>>   If you're using "status-server", then "revive_interval" isn't used.
> 
> Hmm.. When I have been testing stuff here it feels like it was that
> (review_interval) timeout that was being used before the server first
> sent a 'status-server' check after having marked it 'down'. But I might
> have been mistaken. Gonna do some more tests...
> 
> I wonder how low I can set things to lessen this issue. Perhaps set
> zombie_period and check_interval to one second...
> 
> 
>>> Best would probably be if FreeRadius kept a
>>> separate timeout for each 'server/realm' tuple...
>>   Ugh.  That's adding complexity to work around bugs in other RADIUS
>> servers, IMHO.  Rather than keeping track of N realms && M home servers,
> 
> Well, it doesn't necessarily have to be bugs in RADIUS server. It can be
> a multitude of stuff that causes a far away home server to not respond.
> Like a network outage. It doesn't feel right to have a system where a
> network outage in (for example) Australia can take out all the EDUROAM
> service for people at our university, just because we happen to have a
> guest from that Australian university that made an attempt to connect
> to the EDUROAM system...
> 
> 
> 
>> it now has to keep track of (N x M) combinations.  That's expensive.
> 
> Yes... But that is what I think the EDUROAM people that use 'Radiator'
> does use.
> 

Really in an system of chained proxy servers like EDUROAM you only want
to be testing first hop connectivity.

One way to do this (as there is no guarantee your NRPS will accept
Status-Server packets) is to use the 'request' status_check and specify
local credentials, so that the requests get looped back round your NRPS
to your servers.

Alan, do you think it might be a good idea to provide an option to
disregard failures from standard authentication requests, and instead
use periodic status_checks to mark servers alive or dead?

This would make the EDUROAM problem go away...

Thanks,
Arran


- --
Arran Cudbard-Bell (A.Cudbard-Bell at sussex.ac.uk),
Authentication, Authorisation and Accounting Officer,
Infrastructure Services (IT Services),
E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT
DDI+FAX: +44 1273 873900 | INT: 3900
GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjtyKgACgkQcaklux5oVKKysgCfe1wnU+vJeoKes/4ovNXS/vnQ
OxQAnRa0EcMItBQ192ZsaLYrtYgNX8PX
=JQ0q
-----END PGP SIGNATURE-----