Open Stack

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