chilli features...

[wlan at mac.com]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.coova.org/pipermail/chilli/attachments/20080210/2de32fe6/attachment.htm>