RFC compliance in sanitizing Access-Reject responses
needacoder at gmail.com
Sat Aug 26 07:15:25 CEST 2006
On 8/23/06, Alan DeKok <aland at deployingradius.com> wrote:
> > I would like to suggest at least two small changes to make
> > freeradius an even better tool than it already is. The first is
> > really simple and would take practically no work at all: can we please
> > have a log message here that notifies the user of this operation when
> > running with -X?
> That's not a bad idea. Even better, have module do for
> Access-Reject *and* Accounting-Response, and document what it does.
> > The second request is also trivial to implement: make the above code
> > configurable/optional. Yes, there is a great deal of strength and
> > respect in supporting the RFC to the dot - and without a doubt, that
> > should be the default out-of-the-box configuration. But not all
> > devices are created equal - and in my case, as I'm sure in some
> > others, useful information is passed in the Access-Reject message in
> > attributes other than Reply-Message.
> I agree. The goal of the server is to have as much configurable as
> The only things that are ot open for configuration are security
> issues that will destory your network if configured incorrectly.
> > The third "request" or "option" perhaps, is a bit more complex. I
> > would propose that the above code is actually a hack to comply with
> > RFC, and that the appropriate mechanism of accomplishing this effect
> > is through an appropriate set of attribute filters (enabled by
> > default).
> That's probably the best response. When the server was originally
> written, there wasn't an "attr_filter" module, so that wasn't an
> We'll put this on the roadmap for 2.0.
Glad to hear it. Is there an estimate on 2.0 release date? I haven't
been able to find this on the web site or in the faq.
More information about the Freeradius-Devel