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

[Karl Gaissmaier]

Hello Heikki,

Am 05.04.2012 21:19, schrieb Heikki Vatiainen:
...
>
> Thanks for clarifying this. I see what you mean. The interest is not in
> dead realm marking or determining the reachability of a realm somewhere
> down the proxy chain, but just the health of next hop. In other words,
> is radius1.dfn.de responding to Server-Status or not. If not, the
> radius2.dfn.de should be used. This is how I understand it.

yep thats what I'm looking for. This is similar done in radsecproxy
with the 'statusServer' option, please see in their implementation:

http://software.uninett.no/radsecproxy/ and serverStatus

...

>
> What I am thinking if an option to return Access-Reject would be needed
> when your server sees a timeout while trying to forward the request. In
> other words, there are two things I am thinking of:
>
> 1) Status-Server to poll next hop

I suggest a new implementation for this case similar to radsecproxy

> 2) what to do when a request times out.

yep this are two cases, I'm looking for case 1.) since I'm
the first one in the proxy chain.

Maybe you should allow the users of radiator to choose what
algo to use. The current algo is OK in a peer2peer situation and
the new statusServer algo is needed in a proxy chain.

Stay with algo 2 as is and allow to choose statusServer as an
option. If the user enables statusServer the failure algo no
longer uses NoreplyTimeout as a switchover, thats all.

Instead use a StatusServerTimeout, and let all other hooks
as is. Then we users can determine what to do when the next-server
is down (StatusServerTimeout) and what to do if the Access-Request
times out (NoreplyTimeout), but don't use NoreplyTimeout inherently
for next-hop failure algo if StatusServer is choosen by the user.

>
> About 2): Currently nothing is done. If an Access-Reject is returned
> then at least the server that forwarded us the request (previous server)
> would see as being alive. If it can use Status-Server, then
> Access-Reject would not be needed to signal your server is still alive
> and was not the reason for the timeout.

I don't think you should change this behaviour, stay with it.

...

> Ok. How about using Status-Server to see if the next hop is alive and
> DRM to try if the destination realm is reachable by some other route? I
> am trying to get an idea if DRM has been deemed unnecessary in eduroam use.

As I know, our NREN next-hop radius (DFN, german research network) is
using radsecproxy. Interestingly, radsecproxies uses serverStatus and
RADIATOR - as the next hop - answers properly as a server but don't
uses Status-Requests as client.

BTW, all what I wrote about AuthBy RADSEC belongs also to AuthBy RADIUS
or all other AuthBy proxies!

...

> I think I understand what you need. I was just trying to clarify if
> Status-Server would be enough or if anything else is needed too.

Thanks Heikki for your patience and the rest of your team for RADIATOR too.

Best Regards
     Charly