Hi,
Am 15.07.2013 09:15, schrieb a.l.m.bu...@lboro.ac.uk:
> Hi,
>
>> 1272017248108...@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
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
