<div dir="ltr">Hello Rick,<div><br></div><div>First, we jumped into a different discussion as i was pointed out by Carl so lets continue this on another thread (Sorry everyone)</div><div>But to your question:</div><div><br></div><div>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).</div><div>There are two efforts trying to tackle this:</div><div><br></div><div>1. QoS API work that is being done [1]</div><div>2. New security rule classes spec i have written about in the previous email [2]</div><div><br></div><div>What you are describing is the implementation aspects of the QoS effort, and i agree with you</div><div>there are challenges (for example we are aware of HTB being problematic on high thoughtputs)</div><div><br></div><div>What i was describing in [2] is different, maybe the name "rate-limit" is wrong here and what we are doing is more of</div><div>a "brute force prevention" .</div><div>We are trying to solve common scenarios for east-west security attack vectors, for example a common vector is a compromised</div><div>VM trying to port scan the network.</div><div>By matching these port-scanning with "rate-limit" security rules we can detect this and either block</div><div>that traffic or alert the admin/user.</div><div>(An example of a "rate-limit" rule would be a VM pinging the same IP with different ports on a short period of time)</div><div><br></div><div>For that there is the security API extension that is needed and the reference implementation, and we should discuss</div><div>them both on the session [3] and how to support extending the API furthur for other user cases/vendors, hope to see you there!</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/88599/">https://review.openstack.org/#/c/88599/</a></div><div>[2] <span style="color:rgb(80,0,80);font-size:12.8000001907349px"> </span><a href="https://review.openstack.org/#/c/151247/" target="_blank" style="font-size:12.8000001907349px">https://review.openstack.org/#/c/151247/</a></div><div>[3] <a href="https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction" target="_blank" style="font-size:12.8000001907349px">https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 10:01 PM, Rick Jones <span dir="ltr"><<a href="mailto:rick.jones2@hp.com" target="_blank">rick.jones2@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On May 14, 2015 9:26 PM, "Gal Sagie" <<a href="mailto:gal.sagie@gmail.com" target="_blank">gal.sagie@gmail.com</a><mailto:<a href="mailto:gal.sagie@gmail.com" target="_blank">gal.sagie@gmail.com</a>>> wrote:<br>
Hello Ryan,<br>
<br>
We have proposed a spec to liberty to add rate limit functionality to security groups [1].<br>
We see two big use cases for it, one as you mentioned is DDoS for east-west and another<br>
is brute force prevention (for example port scanning).<br>
<br>
We are re-writing the spec as an extension to the current API, we also have a proposal<br>
to enhance the Security Group / FWaaS implementation in order to make it easily extendible by such<br>
new classes of security rules.<br>
<br>
We are planning to discuss all of that in the SG/FWaaS future directions session [2].<br>
I or Lionel will update you as soon as we have the fixed spec for review, and feel free to come to the discussion<br>
as we are more then welcoming everyone to help this effort.<br>
<br>
Gal.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/151247/" target="_blank">https://review.openstack.org/#/c/151247/</a><br>
[2] <a href="https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction" target="_blank">https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction</a><br>
</blockquote>
<br></span>
Isn't there already described a way to rate-limit instances (overall) by putting qdiscs onto their tap devices?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
rick jones</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best Regards ,<br><br>The G. </div>
</div>