RFC compliance in sanitizing Access-Reject responses

[Mike]

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
> possible.
>
>   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
> option.
>
>   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.