chilli features...

[JB]

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



JB