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