Open Stack

Hi,

It is worth discussed at this timing since it becomes difficult to change
security groups models and default rules once Grizzly Quantum is shipped.

Personally I prefer to symmetric models and semantics both for ingress and egress.
It helps users understand the behaivor of security groups easily.
(Honestly I was a little confused at first.)

It looks reasonable to me that all egress traffic is dropped if there is
truly no rules and the ALL ALLOW rule will be created automatically to
egress rule when any security group is created. From users view there is
no default behavior change.

@Nachi,
I don't see any bug so far except the one you found :-)

Thanks,
Akihiro

>>>>> Date: Wed, 27 Feb 2013 12:02:50 +0900
>>>>> From: Tomoe Sugihara <tomoe at midokura.com>
>>>>> Subject: Re: [openstack-dev] [quantum] Security groups egress defaultbehaviour
> 
> Hi Dan
> 
> 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. 
> 
> Hi Nachi,
> 
> >Here is the implementation for allow all egress if there are no egress rule.
> > https://github.com/openstack/quantum/blob/master/quantum/db/securitygroups_rpc_base.py#L227
> 
> 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? 
> 
> The problems I'm bringing up here are the following:
> 
>  o Model
> 
>     - this makes semantics asymmetric; given that now there are default explicit rules for ingress
>     - 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. 
> 
> o the implementation above
> 
>      - This is implemented in RPC layer. All the plugins that don't need RPC to implement SG would
> need to do the same thing
>     - 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.
> 
> What do you think?
> 
> Thanks,
> Tomoe
>  
> 
> On Wed, Feb 27, 2013 at 4:05 AM, Nachi Ueno <nachi at nttmcl.com> wrote:
> 
>     Hi Tomoe,
>    
>     Here is the implementation for allow all egress if there are no egress rule.
>     https://github.com/openstack/quantum/blob/master/quantum/db/securitygroups_rpc_base.py#L227
>    
>     Internally, the implementation is default deny. I'm adding all all
>     egress traffic iptables rule here.
>     If this is not working well, could you report a bug reprot on launchpad?
>    
>     Thanks
>     Nachi
> 
>     2013/2/26 Dan Wendlandt <dan at nicira.com>:
>     > Hi Tomoe,
>     >
>     > 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.
>     >
>     > I personally like the trade-off amazon made here and I think it makes sense
>     > to do something similar in Quantum.
>     >
>     > dan
>     >
>     > On Tue, Feb 26, 2013 at 3:29 AM, Tomoe Sugihara <tomoe at midokura.com> wrote:
>     >>
>     >> Hi quantum devs,
>     >>
>     >> I was looking into Quantum Security Groups feature and I have some
>     >> questions regarding default behavior for egress processing.
>     >>
>     >> From the slide[1] linked form the BP and the document[2], it sounds like
>     >> the following:
>     >>
>     >>  - by default, all the egress traffic would be allowed
>     >>  - once you have a egress rule, the rule processing becomes white list,
>     >> meaning traffic that doesn't match on the rules would be dropped.
>     >>
>     >> 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.
>     >>
>     >> 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?
>     >> 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.
>     >>
>     >> 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:
>     >>
>     >> - When you create a SG, you get a (default) visible outbound rule that
>     >> allows everything
>     >> - When you add/delete egress rules to the SG, the default rule is not
>     >> affected.
>     >>
>     >> Basically, in VPC SG outbound behavior, just as same as the inbound, the
>     >> default is DROP. There's no implicit default behavior.
>     >> You merely get the default rule to allow everything for default SG, as
>     >> well as when you create another SG.
>     >>
>     >> 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.
>     >>
>     >> I'd appreciate any comments.
>     >>
>     >> Thanks,
>     >> Tomoe
>     >>
>     >>
>     >> [1]
>     >> http://docs.openstack.org/trunk/openstack-network/admin/content/securitygroups.html
>     >> [2]:
>     >> http://www.slideshare.net/delapsley1/20120417-osdesignsummitsecuritygroupsdlapsleyfinal
>     >> , slide, 13.
>     >> [3]:
>     >> http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
>     >>
>     >>
>     >> _______________________________________________
>     >> OpenStack-dev mailing list
>     >> OpenStack-dev at lists.openstack.org
>     >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >>
>     >
>     >
>     >
>     > --
>     > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     > Dan Wendlandt
>     > Nicira, Inc: www.nicira.com
>     > twitter: danwendlandt
>     > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>    
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> [2  <text/plain; us-ascii (7bit)>]
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev