Open Stack

In line

On Mon, Jan 14, 2013 at 5:28 PM, Akihiro MOTOKI <motoki at da.jp.nec.com>wrote:

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