[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