Open Stack

Hi Aaron,

# Re-Added openstack-dev

>>>>> Date: Mon, 14 Jan 2013 17:05:30 -0800
>>>>> From: Aaron Rosen <arosen at nicira.com>
>>>>> Subject: Re: [Quantum-core] [openstack-dev] Proposed Quantum Port SecurityAPI/Blueprint
> 
> Hi Bob,
> 
> You're right I take back what I proposed before.
> 
> How about having a configuration flag to enforce port_security on shared networks?

This flag looks unnecessary. If only a owner of a shared network (not a
owner of a port) is allowed to change port security for the port on the shared
network, a proper access policy can be achieved.

>     >     - Why can we disable port security when a port is associated with a
>     >     security group?
>     >     The limitation section in the spec document says "if a port is
>     >     associated with a security group
>     >     one cannot remove the port security setting as port security is
>     >     required for security groups to work."
>     >
>     >
>     > The reason for this is if we allow the vm to change it's source ip then
>     > it would be possible for them to get around the security group applied
>     > to the port.

Agreed. If we allow a VM to change it's source ip, source_group does not work. 
When I wrote the mail I did not take care of this case.

>     >     A usual case is a case where a VM wants to another IP address in
>     >     addition to its IP address assigned,
>     >     but it is likely a user still wants to use security group (to drop
>     >     incoming packets to undesired L4 ports).
>     >
>     >
>     > In this use case you are talking about, are you meaning on the same vif
>     > using ip aliases? If so then the user should update the port to include
>     > this ipaddress and then add the desired security group settings for the
>     > communication they want.

Yes. Adding an IP address is a right solution. I missed it.

>     > It's not possible to support port security on a
>     > port for only one ipaddress and not the other because of the reason i
>     > mentioned previously. The user could create another port with out port
>     > security though.

Thanks,
Akihiro

> 
> Aaron
> 
> On Mon, Jan 14, 2013 at 4:45 PM, Robert Kukura <rkukura at redhat.com> wrote:
> 
>     On 01/14/2013 03:39 PM, Aaron Rosen wrote:
>     > Hi Akihiro,
>     >
>     > Thanks for your feedback. Responses inline.
>     >
>     > On Sat, Jan 12, 2013 at 2:44 AM, Akihiro MOTOKI <amotoki at gmail.com
>     > <mailto:amotoki at gmail.com>> wrote:
>     >
>     >     Hi Aaron,
>     >
>     >     Sorry for the late feedback.
>     >
>     >     I have some comments on the spec.
>     >
>     >     - Who can change the port security? If the network physical
>     >     infrastructure provides an address
>     >     space isolation among logical network, a tenant (a regular use) may
>     >     change port security freely.
>     >     On the other hand, if the network physical infrastructure requires MAC
>     >     uniqueness (for example,
>     >     network_type == flat), only admin should change port security.
>     >
>     > Correct, I was thinking about building a flag
>     > (require_port_security_on_shared_networks and
>     > require_port_security_on_provider_networks) in which it would force all
>     > ports created on that network to use port security (and would require
>     > the admin to remove that setting). Do you think this is something we
>     > should build in?
>    
>     I'd recommend not trying to base any behavior on whether a network was
>     created using the provider attributes or not. Once they are created,
>     provider networks are indistinguishable from those created from a pool
>     for a tenant.
>    
>     -Bob
>    
>     >
>     >
>     >
>     >     - Why can we disable port security when a port is associated with a
>     >     security group?
>     >     The limitation section in the spec document says "if a port is
>     >     associated with a security group
>     >     one cannot remove the port security setting as port security is
>     >     required for security groups to work."
>     >
>     >
>     > The reason for this is if we allow the vm to change it's source ip then
>     > it would be possible for them to get around the security group applied
>     > to the port.
>     >
>     >
>     >     A usual case is a case where a VM wants to another IP address in
>     >     addition to its IP address assigned,
>     >     but it is likely a user still wants to use security group (to drop
>     >     incoming packets to undesired L4 ports).
>     >
>     >
>     > In this use case you are talking about, are you meaning on the same vif
>     > using ip aliases? If so then the user should update the port to include
>     > this ipaddress and then add the desired security group settings for the
>     > communication they want. It's not possible to support port security on a
>     > port for only one ipaddress and not the other because of the reason i
>     > mentioned previously. The user could create another port with out port
>     > security though.
>     >
>     >
>     >     The current secgroup implementation honors the original security group
>     >     implementation in nova
>     >     and IP/MAC spoofing rules are added automatically as provider rules.
>     >     We can change the provider rules according to port security state
>     >     for the port.
>     >
>     >     I hope my understanding it correct.
>     >
>     >     Thanks,
>     >     Akihiro
>     >
>     >     2013/1/5 Aaron Rosen <arosen at nicira.com <mailto:arosen at nicira.com>>:
>     >     > Hi,
>     >     >
>     >     > I'm starting to work on the following blueprint
>     >     >
>     >     (https://blueprints.launchpad.net/quantum/+spec/port-security-api-base-class)
>     >     > and would like to run this spec by the community for feedback.
>     >     >
>     >     >
>     >     https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit
>     >     >
>     >     > Thanks,
>     >     >
>     >     > Aaron
>     >     >
>     >     > _______________________________________________
>     >     > 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
>     >
>     >
>     >
>     >     --
>     >     Akihiro MOTOKI <amotoki at gmail.com <mailto:amotoki at gmail.com>>
>     >
>     >     --
>     >     Mailing list: https://launchpad.net/~quantum-core
>     >     Post to     : quantum-core at lists.launchpad.net
>     >     <mailto:quantum-core at lists.launchpad.net>
>     >     Unsubscribe : https://launchpad.net/~quantum-core
>     >     More help   : https://help.launchpad.net/ListHelp
>     >
>     >
>     >
>     >
> 
>     --
>     Mailing list: https://launchpad.net/~quantum-core
>     Post to     : quantum-core at lists.launchpad.net
>     Unsubscribe : https://launchpad.net/~quantum-core
>     More help   : https://help.launchpad.net/ListHelp
> 
>