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

[Heikki Vatiainen]

On 04/05/2012 04:07 PM, Karl Gaissmaier wrote:

Hello Charly,

>> Would the current behaviour of returning nothing (IGNORE) to the
>> previous server still be fine?
> 
> Hm, I didn't catch you?

I was just thinking the case when a request times out and all retries
have been tried. Should something sent back (reject) or not. This is
related to timeout behaviour, not how polling is done.

> My suggestion would be and additional Parameter like CheckServerStatus:

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.

> <AuthBy RADSEC>
> 
>     Host                        radius1.dfn.de
>     Host                        radius2.dfn.de
> 
>     PollServerStatus            on             # use Server-Status Requests
>     Pollfrequency               5              # any 5s
>     FailureBackoffTime          2
> 
>     ...
> </AuthBy>
> 
> 
>>
>> Another alternative would be to synthesise an Access-Reject to the
>> previous server.
> 
> I don't understand what you mean with 'previous server'.
> Maybe I'm wrong, but the current failure algo is broken for
> a radius chain and only useful between peers.

Previous server would be the one that forwarded the request to your
server. Your server is the one that needs to decide if the request
should be forwarded to radius1.dfn.de or radius2.dfn.de.

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
2) what to do when a request times out.

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.

>>
>> Related to this, what is the current view of using Dead Realm Marking in
>> eduroam?
> 
> Maybe it's useful for NREN radius servers and not for universities.
> And by the way it's the wrong end to solve the problem.
> We need an algorithm to check the status of the next-hop
> radius server and not indirect via a reply timeout from a totally
> different server down the proxy lane.

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.

> Maybe I can't explain the problem due to my bad english, but please
> try to solve this problem in correspondence with me, since it's a real
> problem. Please see in your history, I don't claim often and when I claim
> it's normally a real world problem.

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

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