Open Stack

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).


> (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.



> 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 listOpenStack-dev at lists.openstack.orghttp://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 listOpenStack-dev at lists.openstack.orghttp://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/20121201/191afc13/attachment.html>