[openstack-dev] [neutron] Neutron API rate limiting

Tidwell, Ryan ryan.tidwell at hp.com
Fri May 15 18:34:07 UTC 2015


________________________________________
From: Carl Baldwin [carl at 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.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

On Fri, May 15, 2015 at 2:21 AM, Tidwell, Ryan <ryan.tidwell at hp.com<mailto:ryan.tidwell at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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


More information about the OpenStack-dev mailing list