Open Stack

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.
>
>
>> - 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.
>
>
OK I'll add check code for this.


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


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


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