chilli features...

[JB]

Another idea: Why not add a configuration parameter to chilli.conf  
which activates this feature in the first place and additionally tells  
Chilli where to look for the trigger in the Access-Reject response?  
Let's call it "dropmactrigger" for now.

dropmactrigger = Chilli-Drop
dropmactimeout = 120
or
dropmactrigger = Reply-Message
or
dropmactrigger = What-Ever

If dropmactrigger is not defined, then packet dropping is not activated.

What do you think?
JB


JB (11.02.2008):
> sophana (10.02.2008):
>> 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.
>
> Again, Chilli does not enforce this message, it just listens for it.  
> And only Chilli. So why would a developer configure his RADIUS to  
> send this message aloong with the response, when there is no Chilli  
> in use??
>
> Peter Nixon (10.02.2008):
>> The other option of course is to use a radius accept with a VSA  
>> that says to
>> drop all traffic...
>
> While I'm not against using a VSA per se, sending an Access-Accept  
> although I don't want to hear anything from that MAC address again  
> anytime soon is really not what an Access-Accept response is  
> intended to be. Why misemploy this mechanism? Green means go, red  
> means stop. Additional information comes with an (vendor specific)  
> attribute.
>
>
>>>> 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