chilli features...

[JB]

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
>>