[openstack-dev] [Quantum] Spec of Security Group implementation
Akihiro MOTOKI
motoki at da.jp.nec.com
Wed Dec 5 08:38:05 UTC 2012
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, 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 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
> >>
> >> Ok I got the spec.
> >>
> >> Let's discuss underlaying filtering rule layer in next patch.
> >>
> >> 2012年11月28日水曜日 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] 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. Not supporting
> >>> them here would make sense.
> >>>
> >>> I totally with Dan. 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. 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. 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
>
>
More information about the OpenStack-dev
mailing list