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.jon...@hp.com> wrote: > 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 > -- Best Regards , The G.
__________________________________________________________________________ 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