[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