chilli features...

[JB]

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