addition to policy.conf

[Phil Mayers]

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?