RFC compliance in sanitizing Access-Reject responses

[Nicolas Baradakis]

I thought a little about filtering access-reject packets. Perhaps
it's not very useful, but here is my personal opinion.

1. Allowing VSA in the reply packets is really a bug: if you have an
existing username with a wrong password, the VSA useful to set up a
connection were pulled from the database during autorize and are send
in the reject packet.

2. Making the option user-defined may bring more confusion. Too many
options make the server more difficult to configure. Moreover the
administrator may not figure out easily that turning this option
on will hit the bug in (1).

3. Moving the function to a module is a bit dangerous. The modules
are optional, and I don't want the server to do something crazy
when removing one of the modules.

4. I like software that figure out themselves what to do ;-)
Apparently the users complaining about the problem are using FreeRADIUS
as a proxy for RFC-ignorant third party servers. That's why I think
we could relax the filter on proxy replies *only*.

The rationale is when FreeRADIUS is acting as a home server, it's hard
to configure it to intentionally reply VSA in access-reject, therefore
the current behaviour should be fine. When FreeRADIUS is acting as
proxy, we are not really responsible if the incoming packets are not
RFC-compliant. Then perhaps it makes sense to allow the VSA in the
latter case.

-- 
Nicolas Baradakis