Open Stack

Hi,

I failed to ask another question. In quantum's SG rule, there's
source_ip_prefix for both directions while Amazon VPC SG has source prefix
for inbound and destination for outbound respectively. Is that designed
model or oversight?

Thanks,
Tomoe


On Wed, Feb 27, 2013 at 12:02 PM, Tomoe Sugihara <tomoe at midokura.com> wrote:

> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130227/7bbed56e/attachment.html>