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?