Open Stack

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