Hi Aaron, Akihiro<div><br></div><div>I'm +1 for remote_prefix</div><div><br></div><div>Should I work on the change on this patch? or do this on separate patch ?</div><div><br></div><div>Thanks</div><div>Nachi</div><div class="gmail_extra">
<br><br><div class="gmail_quote">2012/12/2 Akihiro MOTOKI <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<div class="im">> 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>
>> source_group_id are not specified,  reject such a rule.<br>
>> (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>
> min/max range you can then receive  on any port (they become wild carded).<br>
<br>
</div>I totally agree with your opinion.<br>
It has a compatibility with nova's security group behavior.<br>
<div class="im"><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>
</div>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>
<div><div class="h5"><br>
><br>
><br>
>><br>
>> Thanks,<br>
>> Akihiro<br>
>><br>
>><br>
>> (2012/11/29 10:38), Nachi Ueno wrote:<br>
>><br>
>> Thanks<br>
>><br>
>>  Ok I got the spec.<br>
>><br>
>> Let's discuss underlaying filtering rule layer in next patch.<br>
>><br>
>> 2012年11月28日水曜日 Dan Wendlandt <a href="mailto:dan@nicira.com">dan@nicira.com</a>:<br>
>>><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>
>>> [Discussion 1]  security group rule applied for port for network:* ports?<br>
>>><br>
>>> - Dhcp port (looks not needed)<br>
>>><br>
>>><br>
>>> I don't see obvious use cases here, and a tenant could definitely shoot<br>
>>> themselves in the foot by configuring security groups here.  Not supporting<br>
>>> them here would make sense.<br>
>>><br>
>>> I totally with Dan.  I don't see any useful usecases either.<br>
>>><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>
>>> This is tricky.  It make sense to do packet filtering at router ports,<br>
>>> 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>
>>> project an "inside" VM from the "outside" world.   That directionality<br>
>>> 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>
<br>
--<br>
</div></div>Akihiro MOTOKI <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>><br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>