Open Stack

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.
>>
>>
>  OK I'll add check code for this.
>
>
> Good approach at the current.
> 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.
>
>
>
>>
>>>  [Discussion 2] Security groups for external networks
>>> I could see use cases here. ( limit outbound or inbound connections)
>>> However may be different default setting needed.
>>>  Allow all traffic here ?
>>>
>>
>>  Can you be more precise about what you mean here?  In Quantum, external
>> networks are a concept that is currently only relevant for L3 + Floating
>> IPs.  Similar to the logic above, I don't think it makes sense to apply
>> security groups on router gateway ports.  But if a VM is connected directly
>> to a "shared=True" public network that also happens to be "external=True",
>> then applying security groups there would make sense.
>>
>>
>
>  Yes. In addition to the your example, cloud provider (admin tenant) may
> create vm which serves some services for vms on the cloud.
>
>
> That's exactly what I think.
> We can simply achieve it by excluding ports with 'network:*'.
>
>
>
>
>>
>>>  [Discussion 3] Default filtering rule
>>> IMO, we should update definition of wiki considering some
>>> provider specified rules.
>>>
>>>
>>> Egress
>>>  -p udp --sport 68 --dport 67 -d 255.255.255.0 -j RETRUN
>>>  -p udp --sport 68 --dport 67 -d $DHCP_IP -j RETRUN
>>>  -m mac --mac-source !$PORT_MAC -j DROP (arp spoofing)
>>>  -s !$PORT_FIXED_IPS -j DROP (ip spoofing)
>>>  -p udp --sport 67 --dport 68 -J DROP (disallow dhcp)
>>>
>>>    - if no there are no egress rule, all egress traffic allowed except
>>>    above rules
>>>
>>>  Ingress
>>>  -p udp --sport 68 --dport 67 -s $DHCP_IP -j RETURN
>>>
>>>
>>>
>>  to summarize, you are saying "prevent L2/L3 spoofing" and "allow VMs to
>> get IPs via DHCP".  The former is commonly done in conjunction with
>> security groups, since a VM spoofing a source IP could evade filters.  The
>> latter also makes sense, as it goes along with the default security group
>> policy that  "VM can send anything outbound, and can always receive a reply
>> to anything it sent".
>>
>
>  Yes. Established session is allowed by default. # we should note this
> also
>
>
> IMO such provider specified rules should not exposed to tenants
> even if such rules are registered to security group tables.
> At least such rules must not be changed by non-admin user.
>

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