[openstack-dev] [Quantum] Spec of Security Group implementation

Dan Wendlandt dan at nicira.com
Wed Nov 28 00:44:37 UTC 2012


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.


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



>
> IMO, if we take this limitation, these limitation should be done in
> securitygroups_db class.
>

seems reasonable.


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


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

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


More information about the OpenStack-dev mailing list