<br><br><div class="gmail_quote">On Sat, Dec 1, 2012 at 8:16 PM, Aaron Rosen <span dir="ltr"><<a href="mailto:arosen@nicira.com" target="_blank">arosen@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Akihiro, <br><br><div class="gmail_quote"><div class="im">On Sat, Dec 1, 2012 at 11:21 AM, Akihiro MOTOKI <span dir="ltr"><<a href="mailto:motoki@da.jp.nec.com" target="_blank">motoki@da.jp.nec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
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 source_group_id should handled?<br>
There are two possible options: (a) If both source_ip_prefix and
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, 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 such rule but lb implmentation ignores it.<br>
It is confusing and it needs to be improved.<br>
<br></div></blockquote></div><div>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 <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>. 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=<a href="http://1.1.1.1/32" target="_blank">1.1.1.1/32</a>, 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). </div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
(2) How should source_ip_prefix or source_group_id be translated
into the implementation for egress rule?<br>
IMO they should be interpreted as "destination" in egress rule. How
do you think?<br>
Naming of "source_*" comes from the traditional secgroup context
(i.e., "ingress") and it would be better to rename attribute names.<br>
<br></div></blockquote><div><br></div></div><div>If you have a rule that says:</div><div><br></div><div>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 able to receive traffic from <a href="http://1.1.1.1/32" target="_blank">1.1.1.1/32</a> on this port.</div>
<div><br></div><div>Alternatively, </div><div><br></div><div><div>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 able to send traffic to <a href="http://1.1.1.1/32" target="_blank">1.1.1.1/32</a> from this port. </div>
</div><div><br></div><div>Does that make it more clear? I'm against to remove source_ though. </div></div></blockquote><div><br></div><div>I think this is the issue Nachi was referring to during the team meeting. </div>
<div><br></div><div>I don't think "source_ip_prefix" makes sense in the context of an egress (i.e., "outbound from the VM") security group. </div><div><br></div><div>I would suggest either having a source_ip_prefix field that is valid only if direction="ingress" and a destination_ip_prefix field that is valid only if direction="egress", or simply having an "ip_prefix" field, with source or destination being implicit based on the "direction" of the rule. It seems like the latter is what Amazon VPC does: <a href="http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-query-AuthorizeSecurityGroupEgress.html">http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-query-AuthorizeSecurityGroupEgress.html</a>, though in the GUI they still call them "source" or "destination", based on the direction of the rule. </div>
<div><br></div><div>I think the same would apply for the "source_group_id" field, potentially renaming it to "group_id"</div><div><br></div><div>Dan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><div class="h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Thanks,<br>
Akihiro<div><div><br>
<br>
<div>(2012/11/29 10:38), Nachi Ueno wrote:<br>
</div>
<blockquote type="cite">Thanks
<div><br>
</div>
<div> Ok I got the spec.</div>
<div><br>
</div>
<div>Let's discuss underlaying filtering rule layer in next patch.<span></span><br>
<br>
2012年11月28日水曜日 Dan Wendlandt <a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
<div class="gmail_quote">On Wed, Nov 28, 2012 at 4:06 AM,
Akihiro MOTOKI <span dir="ltr"><<a>motoki@da.jp.nec.com</a>></span>
wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> 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 with Dan's comment.
<div><br>
<br>
(2012/11/28 10:39), Nachi Ueno wrote:<br>
<blockquote type="cite">Hi Dan
<div><br>
</div>
<div>Thank you for your reply</div>
<div><br>
<br>
<div>2012/11/27 Dan Wendlandt <span dir="ltr"><<a>dan@nicira.com</a>></span><br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
<div>
<div>On Tue, Nov 27, 2012 at 2:34 PM, Nachi
Ueno <span dir="ltr"><<a>nachi@nttmcl.com</a>></span>
wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Aaron,
Akihiro, Gary
<div><br>
</div>
<div>I would like to ask your opinion
about the security group specs.</div>
<div><br>
</div>
<div>[Discussion 1] security group rule
applied for port for network:* ports?</div>
<div><br>
</div>
<div>- Dhcp port (looks not needed)</div>
</blockquote>
<div><br>
</div>
</div>
<div>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. <br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
I totally with Dan. I don't see any useful usecases
either.
<div><br>
<br>
<blockquote type="cite">
<div>
<div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>- Router port ( I could see many
usecases, but this may be implemented
as a service extension such as VPM)</div>
</blockquote>
<div><br>
</div>
</div>
<div>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. </div>
<div>
<div><br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
My understanding is similar to Dan.<br>
I see security groups are basically applied to network
endpoints such as VIF of VM.<br>
Router is not an network endpoint and the meaning of
'direction' is turned for a router port.<br>
It is better packet filtering at router is supported by
other scheme than security groups.
<div><br>
<br>
<blockquote type="cite">
<div>
<div>
<div> </div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
</div>
<div>IMO, if we take this limitation,
these limitation should be done in
securitygroups_db class.</div>
</blockquote>
<div><br>
</div>
</div>
<div>seems reasonable. </div>
<div>
<div><br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<div>yes, I think we all agree there.</div>
<div><br>
</div>
<div>dan</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> <br>
Ideally some underlying layer of security group seems a
better place to implement such logic<br>
and securitygroups_db class should dedicate itself to
manage security group and its rule.<br>
It makes it easier to manage provider specific rules I
think.<br>
<br>
<br>
<br>
Thanks,<br>
Akihiro
<div><br>
<br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div><br>
</div>
<div>Dan</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p> <span> </span></p>
</div>
<div>Thanks</div>
<span><font color="#888888">
<div>Nachi</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</font></span><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a>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>
<span><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt
<div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
<br>
</font></span><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a>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>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a>OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div> </div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a>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>
<br clear="all">
<div><br>
</div>
-- <br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt
<div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div></div><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></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>