Hi Tomoe,<div><br></div><div>Yes, my understanding of what Amazon does is that each VPC security group is automatically configured with an explicit "allow all outbound" rule. I assume Amazon did this so that that VPC groups were implicitly backward compatible with non-VCP security groups, which perform no egress filtering. However, if you remove this rule and have a truly empty egress group, all packets will be dropped, which makes the default-deny semantics symmetric across both ingress + egress rules. </div>
<div><br></div><div>I personally like the trade-off amazon made here and I think it makes sense to do something similar in Quantum.</div><div><br></div><div>dan<br><br><div class="gmail_quote">On Tue, Feb 26, 2013 at 3:29 AM, Tomoe Sugihara <span dir="ltr"><<a href="mailto:tomoe@midokura.com" target="_blank">tomoe@midokura.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi quantum devs, <div><br></div><div>I was looking into Quantum Security Groups feature and I have some questions regarding default behavior for egress processing.</div>
<div><br></div><div>
>From the slide[1] linked form the BP and the document[2], it sounds like the following:</div><div><br></div><div> - by default, all the egress traffic would be allowed</div><div> - once you have a egress rule, the rule processing becomes white list, meaning traffic that doesn't match on the rules would be dropped.</div>
<div><br></div><div>This actually sounds similar to what Amazon VPS SG document[3], although their implementation doesn't match on the statement in the doc, which I'll get to it shortly.</div><div>
<br></div><div>If I understand the spec correctly, when I remove the last egress rule from all the SGs bound to a port, the default behavior should change from DROP to ALLOW. Symmetrically, when I add a first egress rule in any of the SGs to which a VM is bound, the default behavior should change from ALLOW to DROP. Am I interpreting this right?</div>
<div>However, I couldn't find a part to implement this. In fact, this processing would be annoying if you have thousands of ports referring to multiple SGs because, for each port, you would have to count numbers of egress rules for all the SGs, and depending on the count, you would have to change the default behavior.<br>
</div><div><br></div><div>Then, I took a look at Amazon VPC security groups in the console. Contrary to their online doc, their implementation seems more intuitive or explicit like this:</div><div><br></div>
<div>- When you create a SG, you get a (default) visible outbound rule that allows everything</div><div>- When you add/delete egress rules to the SG, the default rule is not affected.</div><div><br></div>
<div>Basically, in VPC SG outbound behavior, just as same as the inbound, the default is DROP. There's no implicit default behavior. <br></div><div>You merely get the default rule to allow everything for default SG, as well as when you create another SG.</div>
<div><br></div><div>So, I'm wondering what the right behavior for Quantum SG. To me, amazon style seems easy to understand for user's perspective and easy to implement. And, I now slightly remember that there was a discussion about having amazon compatibility flag in OS summit.</div>
<div><br></div><div>I'd appreciate any comments. </div><div><br></div><div>Thanks,</div><div>Tomoe</div><div><br></div><div><br></div><div>[1] <a href="http://docs.openstack.org/trunk/openstack-network/admin/content/securitygroups.html" target="_blank">http://docs.openstack.org/trunk/openstack-network/admin/content/securitygroups.html</a><br>
</div><div>[2]: <a href="http://www.slideshare.net/delapsley1/20120417-osdesignsummitsecuritygroupsdlapsleyfinal" target="_blank">http://www.slideshare.net/delapsley1/20120417-osdesignsummitsecuritygroupsdlapsleyfinal</a> , slide, 13. </div>
<div>[3]: <a href="http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html" target="_blank">http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html</a><br></div><div><br></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>
</div>