addition to policy.conf
p.mayers at imperial.ac.uk
Mon Jun 4 11:45:53 CEST 2012
On 06/03/2012 08:38 PM, Brian Candler wrote:
> The same argument applies to RADIUS proxying IMO.
As others have suggested, this is not a great idea.
One specific technical problem is that, for a given source port &
destination proxy, you can only have ~255 radius packets in-flight at
any given moment, because of the limited radius ID space.
If you don't sanitise input before proxying, an accidental or malicious
attempt to authenticate to a roaming consortium member could potentially
cause denial of service on one or more proxies in the hierarchy (and in
fact, this very thing has happened in eduroam).
I do agree that blacklisting specific domains (a "bogon" list) isn't a
good idea, because they get out of date; but the syntactic checks are a
no-brainer (optionally enabled, of course) because such rules are
specified in some (many?) roaming consortia as a matter of policy.
One possible middle ground would be for an upstream proxy to return a
specific error attribute / message format if the target realm is
invalid, and for edge radius servers to cache these bad realms and
locally execute an immediate reject. We have implemented this in a basic
fashion using an SQL insert in "post-proxy", and a SQL query summing the
fails per-realm over a time range in "authorize".
You could probably do this better with an "rlm"; maintain a hash table
of key/value pairs, the value being a list of timestamps of failures,
allowing you to sum over timeranges. Do people think this would be useful?
More information about the Freeradius-Devel