Open Stack

On Sat, Dec 1, 2012 at 8:16 PM, Aaron Rosen <arosen at nicira.com> wrote:

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

I think this is the issue Nachi was referring to during the team meeting.

I don't think "source_ip_prefix" makes sense in the context of an egress
(i.e., "outbound from the VM") security group.

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:
http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-query-AuthorizeSecurityGroupEgress.html,
though in the GUI they still call them "source" or "destination", based on
the direction of the rule.

I think the same would apply for the "source_group_id" field, potentially
renaming it to "group_id"

Dan



>
>
>
>>  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
>>
>>
>
> _______________________________________________
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121204/8a7efc64/attachment-0001.html>