Open Stack

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 <mailto:dan at nicira.com>>
>
>
>
>     On Tue, Nov 27, 2012 at 2:34 PM, Nachi Ueno <nachi at nttmcl.com <mailto: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.

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 <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>     -- 
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     Dan Wendlandt
>     Nicira, Inc: www.nicira.com <http://www.nicira.com>
>     twitter: danwendlandt
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121128/1604dd86/attachment.html>