[openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities

Miguel Angel Ajo mangelajo at redhat.com
Fri Jun 19 16:30:03 UTC 2015

Hi John, I guess it totally makes sense as a new type of rule for QoS, 
once the framework
is ready, it could make sense to add a "connection per second limit" or 
"max connection limit"
type of rule.

John Joyce (joycej) wrote:
> Gal:
> I had seen the brute force blueprint and noticed how close the use 
> case was. Can you tell me the current status of the work? Do you feel 
> confident it can get into Liberty? Ideally, we think this fits better 
> with QoS. Also I don’t think of it as providing FWaaS as we see that 
> all VMs would be protected by this when enabled, but maybe that is 
> just terminology. We think these protections are critical so we are 
> more concerned with having the ability to protect against these cases 
> than the specific API or service it falls under. Yes we would be 
> interested in working together to get this pushed through.
> John
> From: Gal Sagie [mailto:gal.sagie at gmail.com]
> Sent: Wednesday, June 17, 2015 12:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: lionel.zerbib at huawei.com; Derek Chamorro (dechamor); Eran Gampel
> Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional 
> QoS capabilities
> Hi John,
> We were trying to push a very similar spec to enhance the security 
> group API, we covered both DDoS case
> and another use case for brute force prevention (We did a research to 
> identify common protocols login behaviour
> in order to identify brute force attacks using iptables) and even some 
> UI work
> You can view the specs and implementations here:
> 1) https://review.openstack.org/#/c/184243/
> 2) https://review.openstack.org/#/c/154535/
> 3) https://review.openstack.org/#/c/151247/
> 4) https://review.openstack.org/#/c/161207/
> The spec didn't got approved as there is a strong opinion to keep the 
> security group API compatible with Amazon.
> I think this and your request fits much more into the FWaaS and if 
> this is something you would like to work together on and push
> i can help and align the above code to use FWaaS.
> Feel free to contact me if you have any question
> Thanks
> Gal.
> On Wed, Jun 17, 2015 at 6:58 PM, John Joyce 
> (joycej)<joycej at cisco.com<mailto:joycej at cisco.com>> wrote:
> Hello everyone:
> I would like to test the waters on some new functionality we think is 
> needed to protect OpenStack deployments from some overload situations 
> due to an excessive user or DDOS scenario. We wrote this up in the 
> style of an RFE. Please let us know your thoughts and we can proceed 
> with a formal RFE with more detail if there are no concerns raised.
> *What is being requested*
> This request is to extend the QOS APIs to include the ability to 
> provide connection rate limiting
> *Why is it being requested*
> There are many scenarios where a VM may be intentionally malicious or 
> become harmful to the network due to its rate of initializing TCP 
> connections. The reverse direction of a VM being attacked with an 
> excessive amount of TCP connection requests either intentionally or 
> due to overload is also problematic.
> *Implementation Choices
> There might be a number of ways to implement this, but one of the 
> easiest would appear to be to extend the APIs being developed under: 
> https://review.openstack.org/#/c/187513/. An additional rule type 
> “connections per-second” could be added.
> The dataplane implementation itself may be realized with netfilter and 
> conntrack.
> *Alternatives
> It would be possible to extend the security groups in a similar 
> fashion, but due to the addition of rate limiting, QoS seems a more 
> nature fit.
> *Who needs it*
> Cloud operators have experienced this issue in real deployments in a 
> number of cases.
> __________________________________________________________________________
> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150619/256c4202/attachment.html>

More information about the OpenStack-dev mailing list