[RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward

Karl Gaissmaier karl.gaissmaier at uni-ulm.de
Mon Jul 15 02:32:54 CDT 2013


Hi,

Am 15.07.2013 09:15, schrieb A.L.M.Buxey at lboro.ac.uk:
> Hi,
>
>> 1272017248108413 at wlan.mnc001.mcc262.3gppnetwork.org
>
> 3gppnetwork realms are invalid. ..just like hotmail, gmail, yahoo etc -
> until a notice comes from eduroam stating that these realms now have agreed
> relationship, they are public realms and not within the private scheme of eduroam.

thats's not the point, I had (again) a wrong example choosen.

Some users have just typos in their realms, an endpoint eduroam SP
can not handle all typos, we proxy it upstream. If the upstream
Rejects it, it should not strip the Proxy-State Attribut.


>> RFC 5997, saying that Status-Server MUST NOT be proxied and therefore
>> the Proxy-State attribut isn't allowed.
>
> status-server musnt be proxied....its only for the first-hop check of
> a remote proxy and not the end target - but that surely isnt the issue?
> a Status-Server message is easy to deal with - you just send something back
> to show you are alive - RADIATOR has been sending a basic statts page back
> for status-server queries to it for years.

Radiator doesn't proxy the Status-Server requests, he generates it and
has a wrong scheme to deal with the limited 8-Bits of Request
Identifiers.

Again:

1.)    Radiator has to fix AuthRADSEC. The user has to choose to use
        extended-Ids in the Proxy-State Attribut if the upstream proxy
        will handle this. By default it should use 8 Bit Identifiers.

2.)    radsecproxy has to fix the self generated Access-Rejects.
        If a Proxy-State Attribut was present in the Access-Request, the
        generated Access-Reject must copy this attribut and send it back.

Best Regards
     Charly


-- 
Karl Gaissmaier
Universität Ulm / Germany


More information about the radiator mailing list