<div dir="ltr">Hi Dan<div><br></div><div>Thanks for your comment. I think we are agreeing on having an explicit default egress rule for allowing everything that is created upon creation of security groups. In fact, now in Quantum SG, there are default explicit rules for ingress, so it makes sense to keep the semantics same for both directions. </div>
<div><br></div><div>Hi Nachi,</div><div><br></div><div>><span style="font-family:arial,sans-serif;font-size:13px">Here is the implementation for allow all egress if there are no egress rule.</span></div>
> <a href="https://github.com/openstack/quantum/blob/master/quantum/db/securitygroups_rpc_base.py#L227" style="font-family:arial,sans-serif;font-size:13px" target="_blank">https://github.com/openstack/quantum/blob/master/quantum/db/securitygroups_rpc_base.py#L227</a><div>
<br></div><div>Thanks for getting me the link. I took a closer look at it and if I understand correctly, you're right that it actually implements the default behavior but it does it implicitly, meaning users don't see allow-all rule when no egress rules found; is that correct? </div>
<div><br></div><div style>The problems I'm bringing up here are the following:</div><div style><br></div><div style> o Model</div><div style><br></div><div> - this makes <span style="font-size:13px;font-family:arial,sans-serif">semantics asymmetric; given that now there are default explicit rules for ingress</span><br>
</div><div style><span style="font-size:13px;font-family:arial,sans-serif"> - It'd be counter intuitive for users that default behavior changes implicitly depending on the numbers of egress SG rules especially the default DROP/ALLOW policy is invisible to users. </span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div style><span style="font-size:13px;font-family:arial,sans-serif">o the implementation above</span></div><div style><br></div><div style><span style="font-size:13px;font-family:arial,sans-serif"> - This is implemented in RPC layer. All the plugins that don't need RPC to implement SG would need to do the same thing</span></div>
<div style><span style="font-size:13px;font-family:arial,sans-serif"> - It can be expensive to calculate the number of egress rules for all the SGs for every port ever time SG and SG rule changes.</span></div><div style>
<span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div style>What do you think?</div><div style><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div style><font face="arial, sans-serif">Thanks,</font></div>
<div style><span style="font-size:13px;font-family:arial,sans-serif">Tomoe</span></div><div style><span style="font-size:13px;font-family:arial,sans-serif"> </span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Feb 27, 2013 at 4:05 AM, Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@nttmcl.com" target="_blank">nachi@nttmcl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Tomoe,<br>
<br>
Here is the implementation for allow all egress if there are no egress rule.<br>
<a href="https://github.com/openstack/quantum/blob/master/quantum/db/securitygroups_rpc_base.py#L227" target="_blank">https://github.com/openstack/quantum/blob/master/quantum/db/securitygroups_rpc_base.py#L227</a><br>
<br>
Internally, the implementation is default deny. I'm adding all all<br>
egress traffic iptables rule here.<br>
If this is not working well, could you report a bug reprot on launchpad?<br>
<br>
Thanks<br>
Nachi<br>
<br>
<br>
2013/2/26 Dan Wendlandt <<a href="mailto:dan@nicira.com">dan@nicira.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi Tomoe,<br>
><br>
> Yes, my understanding of what Amazon does is that each VPC security group is<br>
> automatically configured with an explicit "allow all outbound" rule. I<br>
> assume Amazon did this so that that VPC groups were implicitly backward<br>
> compatible with non-VCP security groups, which perform no egress filtering.<br>
> However, if you remove this rule and have a truly empty egress group, all<br>
> packets will be dropped, which makes the default-deny semantics symmetric<br>
> across both ingress + egress rules.<br>
><br>
> I personally like the trade-off amazon made here and I think it makes sense<br>
> to do something similar in Quantum.<br>
><br>
> dan<br>
><br>
> On Tue, Feb 26, 2013 at 3:29 AM, Tomoe Sugihara <<a href="mailto:tomoe@midokura.com">tomoe@midokura.com</a>> wrote:<br>
>><br>
>> Hi quantum devs,<br>
>><br>
>> I was looking into Quantum Security Groups feature and I have some<br>
>> questions regarding default behavior for egress processing.<br>
>><br>
>> From the slide[1] linked form the BP and the document[2], it sounds like<br>
>> the following:<br>
>><br>
>> - by default, all the egress traffic would be allowed<br>
>> - once you have a egress rule, the rule processing becomes white list,<br>
>> meaning traffic that doesn't match on the rules would be dropped.<br>
>><br>
>> This actually sounds similar to what Amazon VPS SG document[3], although<br>
>> their implementation doesn't match on the statement in the doc, which I'll<br>
>> get to it shortly.<br>
>><br>
>> If I understand the spec correctly, when I remove the last egress rule<br>
>> from all the SGs bound to a port, the default behavior should change from<br>
>> DROP to ALLOW. Symmetrically, when I add a first egress rule in any of the<br>
>> SGs to which a VM is bound, the default behavior should change from ALLOW to<br>
>> DROP. Am I interpreting this right?<br>
>> However, I couldn't find a part to implement this. In fact, this<br>
>> processing would be annoying if you have thousands of ports referring to<br>
>> multiple SGs because, for each port, you would have to count numbers of<br>
>> egress rules for all the SGs, and depending on the count, you would have to<br>
>> change the default behavior.<br>
>><br>
>> Then, I took a look at Amazon VPC security groups in the console. Contrary<br>
>> to their online doc, their implementation seems more intuitive or explicit<br>
>> like this:<br>
>><br>
>> - When you create a SG, you get a (default) visible outbound rule that<br>
>> allows everything<br>
>> - When you add/delete egress rules to the SG, the default rule is not<br>
>> affected.<br>
>><br>
>> Basically, in VPC SG outbound behavior, just as same as the inbound, the<br>
>> default is DROP. There's no implicit default behavior.<br>
>> You merely get the default rule to allow everything for default SG, as<br>
>> well as when you create another SG.<br>
>><br>
>> So, I'm wondering what the right behavior for Quantum SG. To me, amazon<br>
>> style seems easy to understand for user's perspective and easy to implement.<br>
>> And, I now slightly remember that there was a discussion about having amazon<br>
>> compatibility flag in OS summit.<br>
>><br>
>> I'd appreciate any comments.<br>
>><br>
>> Thanks,<br>
>> Tomoe<br>
>><br>
>><br>
>> [1]<br>
>> <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>
>> [2]:<br>
>> <a href="http://www.slideshare.net/delapsley1/20120417-osdesignsummitsecuritygroupsdlapsleyfinal" target="_blank">http://www.slideshare.net/delapsley1/20120417-osdesignsummitsecuritygroupsdlapsleyfinal</a><br>
>> , slide, 13.<br>
>> [3]:<br>
>> <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>
>><br>
>><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>
><br>
><br>
><br>
> --<br>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
> Dan Wendlandt<br>
> Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
> twitter: danwendlandt<br>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
><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>
<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>
</div></div></blockquote></div><br></div>