[openstack-dev] [Quantum] Spec of Security Group implementation
Nachi Ueno
nachi at nttmcl.com
Wed Dec 5 17:59:27 UTC 2012
Hi Akihiro
sorry remote_prefix is the typo
I'm also +1 for remote_ip_prefix and remote_group_id.
2012/12/5 Akihiro MOTOKI <motoki at da.jp.nec.com>
> Hi,
>
> > > Should I work on the change on this patch? or do this on separate
> patch ?
>
> > > > direction='egress' source_ip_prefix='1.1.1.1/32' then this port
> would be
> > > > able to send traffic to 1.1.1.1/32 from this port.
>
> I think you don't need to do so in your patch.
> What should be implemented is to follow the above behavior.
>
> I feel we agreed how source_ip_prefix and source_group_id should be
> interpreted, and there is no blocking issue to land Nachi's secgroup
> linuxbridge implentation.
>
> The remaining item is naming of source_ip_prefix and source_group_id.
>
> > > I'm +1 for remote_prefix
>
> > My vote would be for ip_prefix and the direction of it is controlled by
> direction=ingress/egress
> > (same for group_id). In my opinion remote_prefix seems just as confusing
> as others found
> > source_ip_prefix.
>
> My vote is 'remote_ip_prefix'. 'ip_prefix' is also acceptable to me.
> I agree remote_prefix is confusing.
>
> Similarily 'remote_group_id' is my vote for source_group_id.
> In my opinion 'group_id' has too broader meaning and
> during the review of aaron's secgroup db patch group_id is renamed to
> source_group_id if I remember correctly.
>
> I am looking for xxx_ which can be applied to xxx_ip_prefix and
> xxx_group_id.
> 'remote_*' is an option which satifies it.
>
>
> Amazon VPC security group uses no-prefix naming like ip_prefix and
> group_id,
> but ip_prefix or group_id are a subresource of permissions (IpPermision in
> VPC)
> Thus there is no confuing point in naming of group_id.
> On the other hand, Quantum security group has no hierarchical attribute,
> so 'group_id' is a little confusing.
>
> When the discussion has landed, I will work on it.
>
> Thanks,
> Akihiro
>
> >>>>> Date: Tue, 4 Dec 2012 11:25:12 -0800
> >>>>> From: Aaron Rosen <arosen at nicira.com>
> >>>>> Subject: Re: [openstack-dev] [Quantum] Spec of Security Group
> implementation
> >
> > My vote would be for ip_prefix and the direction of it is controlled by
> direction=ingress/egress
> > (same for group_id). In my opinion remote_prefix seems just as confusing
> as others found
> > source_ip_prefix.
> >
> > Aaron
> >
> > On Tue, Dec 4, 2012 at 10:45 AM, Nachi Ueno <nachi at nttmcl.com> wrote:
> >
> > Hi Aaron, Akihiro
> >
> > I'm +1 for remote_prefix
> >
> > Should I work on the change on this patch? or do this on separate
> patch ?
> >
> > Thanks
> > Nachi
> >
> > 2012/12/2 Akihiro MOTOKI <amotoki at gmail.com>
> >
> > Hi Aaron,
> >
> > Thanks for clarifying. We are in the same page I believe.
> >
> > 2012/12/2 Aaron Rosen <arosen at nicira.com>:
> > > Hi Akihiro,
> > >
> > > On Sat, Dec 1, 2012 at 11:21 AM, Akihiro MOTOKI <
> motoki at da.jp.nec.com>
> > > wrote:
> > >>
> > >> Hi Quantum folks (particulary who involve secgroup
> implementation),
> > >>
> > >> During reviewing and tesitng Nachi's secgroup implementation,
> > >> quesitons are raised about secgroup spec I would like to
> confirm.
> > >>
> > >> (1) How should a rule without both source_ip_prefix (source
> IP cidr) and
> > >> source_group_id should handled?
> > >> There are two possible options: (a) If both source_ip_prefix
> and
> > >> source_group_id are not specified, .A N reject such a rule.
> > >> (b) (a) If both source_ip_prefix and source_group_id are not
> specified,
> > >> assume source_ip_prefix is 0.0.0.0/0.
> > >> Note that in the current implementation, the secgroup db
> layyer accepts
> > >> such rule but lb implmentation ignores it.
> > >> It is confusing and it needs to be improved.
> > >>
> > > Good point, in security groups if you don't specify
> source_ip_prefix it is
> > > actually set to null in the security_group_rules table.
> Perhaps we should
> > > have it more explicitly set it to 0.0.0.0/0. My opinion here
> is that if you
> > > don't specify something in a security group rule it's
> basically wild carded
> > > (allow all). For example, if you say ip_source=1.1.1.1/32,
> > > direction='ingress', ethertype='IPv4', protocol='tcp' but do
> not specify the
> > > min/max range you can then receive .A N on any port (they
> become wild carded).
> >
> > I totally agree with your opinion.
> > It has a compatibility with nova's security group behavior.
> >
> > >> (2) How should source_ip_prefix or source_group_id be
> translated into the
> > >> implementation for egress rule?
> > >> IMO they should be interpreted as "destination" in egress
> rule. How do you
> > >> think?
> > >> Naming of "source_*" comes from the traditional secgroup
> context (i.e.,
> > >> "ingress") and it would be better to rename attribute names.
> > >>
> > >
> > > If you have a rule that says:
> > >
> > > direction='ingress' source_ip_prefix='1.1.1.1/32' then this
> port would be
> > > able to receive traffic from 1.1.1.1/32 on this port.
> > >
> > > Alternatively,
> > >
> > > direction='egress' source_ip_prefix='1.1.1.1/32' then this
> port would be
> > > able to send traffic to 1.1.1.1/32 from this port.
> > >
> > > Does that make it more clear? I'm against to remove source_
> though.
> >
> > That's exactly same as what I think.
> > For naming, just removing source_ is not good for me too.
> > I think remote_ is one of alternatives.
> >
> > Thanks,
> > Akihiro
> >
> > >
> > >
> > >>
> > >> Thanks,
> > >> Akihiro
> > >>
> > >>
> > >> (2012/11/29 10:38), Nachi Ueno wrote:
> > >>
> > >> Thanks
> > >>
> > >> .A N Ok I got the spec.
> > >>
> > >> Let's discuss underlaying filtering rule layer in next patch.
> > >>
> > >> 2012 $BG/ (B11 $B7n (B28 $BF|?eMKF| (B Dan Wendlandt
> dan at nicira.com:
> > >>>
> > >>>
> > >>>
> > >>> On Wed, Nov 28, 2012 at 4:06 AM, Akihiro MOTOKI <
> motoki at da.jp.nec.com>
> > >>> wrote:
> > >>>
> > >>> Hi Nachi,
> > >>>
> > >>> I will check and test your new patch.
> > >>> As I raised these issues, I commented inline. There is no
> confliciton
> > >>> with Dan's comment.
> > >>>
> > >>>
> > >>> (2012/11/28 10:39), Nachi Ueno wrote:
> > >>>
> > >>> Hi Dan
> > >>>
> > >>> Thank you for your reply
> > >>>
> > >>>
> > >>> 2012/11/27 Dan Wendlandt <dan at nicira.com>
> > >>>
> > >>>
> > >>>
> > >>> On Tue, Nov 27, 2012 at 2:34 PM, Nachi Ueno <
> nachi at nttmcl.com> wrote:
> > >>>
> > >>> Hi Aaron, Akihiro, Gary
> > >>>
> > >>> I would like to ask your opinion about the security group
> specs.
> > >>>
> > >>> [Discussion 1] .A N security group rule applied for port
> for network:* ports?
> > >>>
> > >>> - Dhcp port (looks not needed)
> > >>>
> > >>>
> > >>> I don't see obvious use cases here, and a tenant could
> definitely shoot
> > >>> themselves in the foot by configuring security groups here.
> .A N Not supporting
> > >>> them here would make sense.
> > >>>
> > >>> I totally with Dan. .A N I don't see any useful usecases
> either.
> > >>>
> > >>>
> > >>> - Router port ( I could see many usecases, but this may be
> implemented as
> > >>> a service extension such as VPM)
> > >>>
> > >>>
> > >>> This is tricky. .A N It make sense to do packet filtering
> at router ports,
> > >>> but I would argue that security groups are the wrong
> abstraction here.
> > >>> Security groups are very directional, as their original
> intent was to
> > >>> project an "inside" VM from the "outside" world. .A N That
> directionality
> > >>> doesn't really make sense on router port in my experience.
> > >>>
> > >>> My understanding is similar to Dan.
> > >>> I see security groups are basically applied to network
> endpoints such as
> > >>> VIF of VM.
> > >>> Router is not an network endpoint and the meaning of
> 'direction' is
> > >>> turned for a router port.
> > >>> It is better packet filtering at router is supported by
> other scheme than
> > >>> security groups.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> IMO, if we take this limitation, these limitation should be
> done in
> > >>> securitygroups_db class.
> > >>>
> > >>>
> > >>> seems reasonable.
> > >>>
> > >>> yes, I think we all agree there.
> > >>>
> > >>> dan
> > >>>
> > >>>>
> > >>>>
> > >>>> Ideally some underlying layer of security group seems a
> better place to
> > >>>> implement such logic
> > >>>> and securitygroups_db class should dedicate itself to
> manage security
> > >>>> group and its rule.
> > >>>> It makes it easier to manage provider specific rules I
> think.
> > >>>>
> > >>>>
> > >>>>
> > >>>> Thanks,
> > >>>> Akihiro
> > >>>>
> > >>>>
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> Dan
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>> Thanks
> > >>>>>> Nachi
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> 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
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> 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
> > >>
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > --
> > Akihiro MOTOKI <amotoki at gmail.com>
> >
> > _______________________________________________
> > 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
> >
> >
>
>
> _______________________________________________
> 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/20121205/0d831c30/attachment.html>
More information about the OpenStack-dev
mailing list