FreeRADIUS and EDUROAM timeout issues

[Alan DeKok]

Peter Eriksson wrote:
> I wonder how low I can set things to lessen this issue. Perhaps set
> zombie_period and check_interval to one second...

  That's not a good idea.  It means that the server will be marked dead
MORE quickly.

>>> 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.

  That isn't the problem.  The problem is that the NEXT hop isn't
responding,  The RFC's say it MUST respond.  Some implementations don't
respond if they're also proxying the request, and the home server
doesn't respond to them.

> 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...

  The eduroam servers SHOULD respond to the local university if
Australia is down: "Authentication failed.  Couldn't reach Australia!"

  Instead, some implementations don't respond.  So your local university
can't tell the difference between Australia being down, and the Eduroam
servers being down...  because the eduroam server is pretending it's
down, too.

>> 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.

  Radiator is part of the problem.  The only reason they implement that
N x M combination is because *their* implementation behaves poorly.
i.e. A radiator proxy doesn't respond to a local server if the upstream
home server doesn't respond to radiator.

  Their solution?  Add complexity.  This is supposed to make things more
"stable".

  Ugh.

  I think the preferred approach is what I said in my other message.
Have FreeRADIUS start pinging the proxy as soon as the proxy MIGHT be
down.  That way, network outages are minimized.

  Alan DeKok.