chilli features...

Sun Feb 10 22:53:44 UTC 2008

The other option of course is to use a radius accept with a VSA that says to 
drop all traffic...

-Peter

On Mon 11 Feb 2008, sophana wrote:
> 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.
>
> JB a écrit :
> > 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
> >
> > ---------------------------------------------------------------------
> > 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
>
> ---------------------------------------------------------------------
> 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

-- 

Peter Nixon
http://peternixon.net/