chilli features...

[sophana]

I think the reply message is not a very good idea. As david say, it WILL 
be shown to the user. That's it.
Having an unknown attribute in a message does not bother anyone, as it 
will simply be ignored by all software that don't know about it.

JB a écrit :
>
> 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.
>
> JB
>
>
> 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 access
>>    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.
>>
>> David
>>
>> On Feb 10, 2008, at 9:44 AM, JB wrote:
>>
>>> Hi,
>>>
>>> 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 ([1] and [2]). 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.
>>>
>>> JB
>>>
>>> [1] http://rfc.net/rfc2865.html#p20
>>> [2] 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.
>>>>
>>>> David
>>>>
>>>> On Feb 9, 2008, at 8:08 PM, JB wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> 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 "failed"
>>>>> 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?
>>>>>
>>>>> JB
>>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: chilli-unsubscribe at coova.org
> For additional commands, e-mail: chilli-help at coova.org
> Wiki: http://coova.org/wiki/index.php/CoovaChilli
> Forum: http://coova.org/phpBB3/viewforum.php?f=4
>
>