In line On Mon, Jan 14, 2013 at 5:28 PM, Akihiro MOTOKI <[email protected]>wrote:
> Hi Aaron, > > # Re-Added openstack-dev > > >>>>> Date: Mon, 14 Jan 2013 17:05:30 -0800 > >>>>> From: Aaron Rosen <[email protected]> > >>>>> 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. > > I agree but they wouldn't really be able to do this pro-actively right? Would you mind explaining? > > > - 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 <[email protected]> > 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 <[email protected] > > > <mailto:[email protected]>> 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 <[email protected] <mailto: > [email protected]>>: > > > > 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 > > > > [email protected] > > > <mailto:[email protected]> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > -- > > > Akihiro MOTOKI <[email protected] <mailto:[email protected]>> > > > > > > -- > > > Mailing list: https://launchpad.net/~quantum-core > > > Post to : [email protected] > > > <mailto:[email protected]> > > > Unsubscribe : https://launchpad.net/~quantum-core > > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > > > > > > > > -- > > Mailing list: https://launchpad.net/~quantum-core > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~quantum-core > > More help : https://help.launchpad.net/ListHelp > > > > > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
