list.coovachilli at mac.com
Sun Feb 10 21:30:22 UTC 2008
Counterquestion: Why would an administrator or developer activate/
implement the "chilli:drop" response, although there is no Chilli in
use at all? I still think that Reply-Message would perfectly suit our
needs, but don't get me wrong: While I also think that RFC compliance
is very important, if having this feature in one of the next releases
means to add a CoovaChilli VSA, that's fine with me.
Just let me know if I can be of any assistance.
wlan at mac.com (10.02.2008):
> Admittedly, it wouldn't be the first time I've gone outside the
> scope of the noted RFCs for vendor specific features. While I agree
> RFC compliance is important and should be maintained as much as
> possible, I also believe RADIUS is now being used for more than it
> was intended and bending the rules are sometimes necessary. My
> opinion is that it's better to interoperate with RFC compliant
> vendors rather than being RFC compliant yourself. Meaning, if a non-
> chilli RADIUS client got an Access-Reject with a Chilli VSA, I doubt
> it would care much. But, if given an Access-Reject with reply-
> message "chilli:drop", it'll likely show this message to the user.
> What is better, changing the meaning of an attribute for a feature
> or extending RADIUS (which was designed to be extendable)? I suppose
> the right answer is to raise these issues in the working group,
> which could happen, but that doesn't mean it can't be tried and
> tested first.
> That notwithstanding, one could argue the extra VSA fits into the
> RFC 5080 clause:
> Attributes within an Access-Reject are
> restricted to those necessary to route the message (e.g., Proxy-
> State), attributes providing the user with an indication that
> has been denied (e.g., an EAP-Message attribute containing an EAP-
> Failure), or attributes conveying an error message (e.g., a Reply-
> Message or Error-Cause attribute).
> Ok, not really, but maybe a little.
> On Feb 10, 2008, at 9:44 AM, JB wrote:
>> you're welcome.
>> I guess using a chilli VSA would break the RADIUS RFCs, which say
>> that only very few attributes are allowed in an Access-Reject
>> response ( and ). Reply-Message is one of them.
>> You're right, having an optional parameter like "droptimeout" is
>> probably a good idea. Not sending a "normal" Access-Reject (with an
>> explanatory message) means that nothing good came from this MAC
>> address. Administrators may like to block them for a longer period
>> than the normal session/dhcp/idle timeouts without increasing the
>> load of the RADIUS server or its database backend.
>> Just let me know if I can help testing this feature.
>>  http://rfc.net/rfc2865.html#p20
>>  http://rfc.net/rfc5080.html#s2.6.1.
>> wlan at mac.com (10.02.2008):
>>> Hi, and thanks for your feedback.
>>> I have been working with the feature, but it still needs more
>>> testing before I put it in the wild.
>>> Your suggestion for using the Reply-Message is a good one. Though,
>>> might as well use a different attribute; probably a new chilli VSA.
>>> 'Sessions' are maintained in chilli, subject to various timeouts
>>> for dhcp lease, idle timeout, etc. So, sessions (or 'connections',
>>> as referred to in the code) are handled the same way - keyed on
>>> the client's MAC address. When a session is in drop state, of
>>> course, all packets are immediately dropped until the session gets
>>> cleared. Perhaps it would be an idea to set a specific time period
>>> for this state.
>>> On Feb 9, 2008, at 8:08 PM, JB wrote:
>>>> I just stumbled across this idea for a new feature for CoovaChilli:
>>>> wlan at mac.com wrote:
>>>>> Right now, when you use MAC authentication, if an access-reject
>>>>> is returned, the user will still get assigned an IP address and
>>>>> will then be given the captive portal. This is good as a way to
>>>>> have certain devices bypass the captive portal. But, it would
>>>>> also be nice to use MAC authentication as a way to manage
>>>>> blocked devices. I'm considering an option which will have
>>>>> chilli drop all traffic from clients that get an access-reject
>>>>> during mac authentication. When clients are in the 'drop' state,
>>>>> all traffic from them is ignored.
>>>> I think that would be a great feature! Or has this been already
>>>> implemented? If not, here are my two cents:
>>>> Why not (mis)use the Reply-Message attribute from RADIUS to
>>>> achieve this? If the value of Reply-Message is a certain "code",
>>>> like "chilli:drop", then Chilli knows it should ignore all
>>>> further requests from this MAC address. Basically, there would be
>>>> three ways to handle a response from an Access-Request request
>>>> (apart from errors or the like):
>>>> Access-Accept -> UAM "success"
>>>> Access-Reject and Reply-Message is not "chilli:drop" -> UAM
>>>> Access-Reject and Reply-Message is "chilli:drop" -> Drop request(s)
>>>> This way, we would neither break the current behaviour nor the
>>>> RFCs. No need to turn this feature on or off in chilli because
>>>> the logic (maybe along with black-/white-lists) resides in the
>>>> RADIUS server.
>>>> Would there still be some sort of session handling? How long
>>>> would chilli drop requests until it "asks" RADIUS again?
More information about the Chilli