Open Stack

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>