Open Stack

Hi Nachi,

In the last quantum team meeting, you said you have a point to be
discussed about the spec.
If I remember correctly, it is related to source_ip_prefix for egress rule.
Aaron and I are in the same page that source_ip_prefix for egress rule
is interprested as destination.
Could you share your questions or thoughts?

Thanks,
Akihiro Motoki

2012/12/2 Akihiro MOTOKI <amotoki at gmail.com>:
> 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>



-- 
Akihiro MOTOKI <amotoki at gmail.com>