On May 14, 2015 9:26 PM, "Gal Sagie"
<gal.sa...@gmail.com<mailto:gal.sa...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
