Open Stack

Hello Rick,

First, we jumped into a different discussion as i was pointed out by Carl
so lets continue this on another thread (Sorry everyone)
But to your question:

There are two topics here, first on a Neutron API level there is no way to
define rate-limit for ports (at least that i know of).
There are two efforts trying to tackle this:

1. QoS API work that is being done [1]
2. New security rule classes spec i have written about in the previous
email [2]

What you are describing is the implementation aspects of the QoS effort,
and i agree with you
there are challenges (for example we are aware of HTB being problematic on
high thoughtputs)

What i was describing in [2] is different, maybe the name "rate-limit" is
wrong here and what we are doing is more of
a "brute force prevention" .
We are trying to solve common scenarios for east-west security attack
vectors, for example a common vector is a compromised
VM trying to port scan the network.
By matching these port-scanning with "rate-limit" security rules we can
detect this and either block
that traffic or alert the admin/user.
(An example of a "rate-limit" rule would be a VM pinging the same IP with
different ports on a short period of time)

For that there is the security API extension that is needed and the
reference implementation, and we should discuss
them both on the session [3] and how to support extending the API furthur
for other user cases/vendors, hope to see you there!

[1] https://review.openstack.org/#/c/88599/
[2]  https://review.openstack.org/#/c/151247/
[3] https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction

On Fri, May 15, 2015 at 10:01 PM, Rick Jones <rick.jones2 at hp.com> wrote:

> On May 14, 2015 9:26 PM, "Gal Sagie" <gal.sagie at gmail.com<mailto:
>> gal.sagie at gmail.com>> wrote:
>> Hello Ryan,
>>
>> We have proposed a spec to liberty to add rate limit functionality to
>> security groups [1].
>> We see two big use cases for it, one as you mentioned is DDoS for
>> east-west and another
>> is brute force prevention (for example port scanning).
>>
>> We are re-writing the spec as an extension to the current API, we also
>> have a proposal
>> to enhance the Security Group / FWaaS implementation in order to make it
>> easily extendible by such
>> new classes of security rules.
>>
>> We are planning to discuss all of that in the SG/FWaaS future directions
>> session [2].
>> I or Lionel will update you as soon as we have the fixed spec for review,
>> and feel free to come to the discussion
>> as we are more then welcoming everyone to help this effort.
>>
>> Gal.
>>
>> [1] https://review.openstack.org/#/c/151247/
>> [2]
>> https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction
>>
>
> Isn't there already described a way to rate-limit instances (overall) by
> putting qdiscs onto their tap devices?
>
> Having looked only briefly at the spec, I would say you want to have the
> option to "MARK" that traffic which is EDN enabled the rate limiting might
> have otherwise dropped.
>
> The extant mechanism I mentioned uses HTB in one direction (instance
> inbound/tap outbound) and a policing filter in the other.  I've used it (as
> a mostly end user) and have noticed that as described, one can introduce
> non-trivial bufferbloat inbound to the instance.
>
> And I've always wished (as in if wishes were horses) that the instance
> outbound throttle were actually implemented in a way where it becomes
> immediately apparent to the instance by causing the tx queue in the
> instance to build-up.  That wouldn't be something on a tap device though.
>
> Does there need to be both a packet and bit rate limit?  I've some
> experience with bit rate limits and have seen otherwise rather throttled
> (bitrate) instances cause non-trivial problems with a network node.
>
> rick jones
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

The G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150516/5759a044/attachment.html>