________________________________________ From: Carl Baldwin [c...@ecbaldwin.net] Sent: Thursday, May 14, 2015 9:10 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [neutron] Neutron API rate limiting
@Gal, your proposal sounds like packet or flow rate limiting of data through a port. What Ryan is proposing is rate limiting of api requests to the server. They are separate topics, each may be a valid need on its own but should be considered separately. @Ryan, I tend to agree that rate limiting belongs in front of the api servers at the load balancer level. That is not to say we couldn't eventually use our own lbaas for this someday and integrate rate limiting there. Thoughts? Carl 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 On Fri, May 15, 2015 at 2:21 AM, Tidwell, Ryan <ryan.tidw...@hp.com<mailto:ryan.tidw...@hp.com>> wrote: I was batting around some ideas regarding IPAM functionality, and it occurred to me that rate-limiting at an API level might come in handy and as an example might help provide one level of defense against DoS for an external IPAM provider that Neutron might make calls off to. I’m simply using IPAM as an example here, there are a number of other (ie better) reasons for rate-limiting at the API level. I may just be ignorant (please forgive me if I am ☺ ), but I’m not aware of any rate-limiting functionality at the API level in Neutron. Does anyone know if such a feature exists that could point me at some documentation? If it doesn’t exist, has the Neutron community broached this subject before? I have to imagine someone has brought this up before and I just was out of the loop. Anyone have thoughts they care to share? Thanks! -Ryan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Certainly you want to do some rate-limiting before a request even hits Neutron. I was asking the question since I believe Nova has a rate-limiting feature that is built-in, although it seems to serve a different purpose than just keeping generic DoS attacks at bay (which is why you want to put something in front of Neutron/Nova/etc.). I simply wondered if there was any utility to per-tenant throttling which is what Nova seems to have. I shared a very poor example and wasn't very clear, my apologies. -Ryan __________________________________________________________________________ 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
