In line <br><br><div class="gmail_quote">On Mon, Jan 14, 2013 at 5:28 PM, Akihiro MOTOKI <span dir="ltr"><<a href="mailto:motoki@da.jp.nec.com" target="_blank">motoki@da.jp.nec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Aaron,<br>
<br>
# Re-Added openstack-dev<br>
<br>
>>>>> Date: Mon, 14 Jan 2013 17:05:30 -0800<br>
>>>>> From: Aaron Rosen <<a href="mailto:arosen@nicira.com">arosen@nicira.com</a>><br>
>>>>> Subject: Re: [Quantum-core] [openstack-dev] Proposed Quantum Port SecurityAPI/Blueprint<br>
<div class="im">><br>
> Hi Bob,<br>
><br>
> You're right I take back what I proposed before.<br>
><br>
> How about having a configuration flag to enforce port_security on shared networks?<br>
<br>
</div>This flag looks unnecessary. If only a owner of a shared network (not a<br>
owner of a port) is allowed to change port security for the port on the shared<br>
network, a proper access policy can be achieved.<br>
<div class="im"><br></div></blockquote><div>I agree but they wouldn't really be able to do this pro-actively right? Would you mind explaining? <br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> > - Why can we disable port security when a port is associated with a<br>
> > security group?<br>
> > The limitation section in the spec document says "if a port is<br>
> > associated with a security group<br>
> > one cannot remove the port security setting as port security is<br>
> > required for security groups to work."<br>
> ><br>
> ><br>
> > The reason for this is if we allow the vm to change it's source ip then<br>
> > it would be possible for them to get around the security group applied<br>
> > to the port.<br>
<br>
</div>Agreed. If we allow a VM to change it's source ip, source_group does not work.<br>
When I wrote the mail I did not take care of this case.<br>
<div class="im"><br>
> > A usual case is a case where a VM wants to another IP address in<br>
> > addition to its IP address assigned,<br>
> > but it is likely a user still wants to use security group (to drop<br>
> > incoming packets to undesired L4 ports).<br>
> ><br>
> ><br>
> > In this use case you are talking about, are you meaning on the same vif<br>
> > using ip aliases? If so then the user should update the port to include<br>
> > this ipaddress and then add the desired security group settings for the<br>
> > communication they want.<br>
<br>
</div>Yes. Adding an IP address is a right solution. I missed it.<br>
<div class="im"><br>
> > It's not possible to support port security on a<br>
> > port for only one ipaddress and not the other because of the reason i<br>
> > mentioned previously. The user could create another port with out port<br>
> > security though.<br>
<br>
</div>Thanks,<br>
Akihiro<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Aaron<br>
><br>
> On Mon, Jan 14, 2013 at 4:45 PM, Robert Kukura <<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a>> wrote:<br>
><br>
> On 01/14/2013 03:39 PM, Aaron Rosen wrote:<br>
> > Hi Akihiro,<br>
> ><br>
> > Thanks for your feedback. Responses inline.<br>
> ><br>
> > On Sat, Jan 12, 2013 at 2:44 AM, Akihiro MOTOKI <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a><br>
> > <mailto:<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>>> wrote:<br>
> ><br>
> > Hi Aaron,<br>
> ><br>
> > Sorry for the late feedback.<br>
> ><br>
> > I have some comments on the spec.<br>
> ><br>
> > - Who can change the port security? If the network physical<br>
> > infrastructure provides an address<br>
> > space isolation among logical network, a tenant (a regular use) may<br>
> > change port security freely.<br>
> > On the other hand, if the network physical infrastructure requires MAC<br>
> > uniqueness (for example,<br>
> > network_type == flat), only admin should change port security.<br>
> ><br>
> > Correct, I was thinking about building a flag<br>
> > (require_port_security_on_shared_networks and<br>
> > require_port_security_on_provider_networks) in which it would force all<br>
> > ports created on that network to use port security (and would require<br>
> > the admin to remove that setting). Do you think this is something we<br>
> > should build in?<br>
><br>
> I'd recommend not trying to base any behavior on whether a network was<br>
> created using the provider attributes or not. Once they are created,<br>
> provider networks are indistinguishable from those created from a pool<br>
> for a tenant.<br>
><br>
> -Bob<br>
><br>
> ><br>
> ><br>
> ><br>
> > - Why can we disable port security when a port is associated with a<br>
> > security group?<br>
> > The limitation section in the spec document says "if a port is<br>
> > associated with a security group<br>
> > one cannot remove the port security setting as port security is<br>
> > required for security groups to work."<br>
> ><br>
> ><br>
> > The reason for this is if we allow the vm to change it's source ip then<br>
> > it would be possible for them to get around the security group applied<br>
> > to the port.<br>
> ><br>
> ><br>
> > A usual case is a case where a VM wants to another IP address in<br>
> > addition to its IP address assigned,<br>
> > but it is likely a user still wants to use security group (to drop<br>
> > incoming packets to undesired L4 ports).<br>
> ><br>
> ><br>
> > In this use case you are talking about, are you meaning on the same vif<br>
> > using ip aliases? If so then the user should update the port to include<br>
> > this ipaddress and then add the desired security group settings for the<br>
> > communication they want. It's not possible to support port security on a<br>
> > port for only one ipaddress and not the other because of the reason i<br>
> > mentioned previously. The user could create another port with out port<br>
> > security though.<br>
> ><br>
> ><br>
> > The current secgroup implementation honors the original security group<br>
> > implementation in nova<br>
> > and IP/MAC spoofing rules are added automatically as provider rules.<br>
> > We can change the provider rules according to port security state<br>
> > for the port.<br>
> ><br>
> > I hope my understanding it correct.<br>
> ><br>
> > Thanks,<br>
> > Akihiro<br>
> ><br>
> > 2013/1/5 Aaron Rosen <<a href="mailto:arosen@nicira.com">arosen@nicira.com</a> <mailto:<a href="mailto:arosen@nicira.com">arosen@nicira.com</a>>>:<br>
> > > Hi,<br>
> > ><br>
> > > I'm starting to work on the following blueprint<br>
> > ><br>
> > (<a href="https://blueprints.launchpad.net/quantum/+spec/port-security-api-base-class" target="_blank">https://blueprints.launchpad.net/quantum/+spec/port-security-api-base-class</a>)<br>
> > > and would like to run this spec by the community for feedback.<br>
> > ><br>
> > ><br>
> > <a href="https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit" target="_blank">https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit</a><br>
> > ><br>
> > > Thanks,<br>
> > ><br>
> > > Aaron<br>
> > ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Akihiro MOTOKI <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a> <mailto:<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>>><br>
> ><br>
> > --<br>
> > Mailing list: <a href="https://launchpad.net/~quantum-core" target="_blank">https://launchpad.net/~quantum-core</a><br>
> > Post to : <a href="mailto:quantum-core@lists.launchpad.net">quantum-core@lists.launchpad.net</a><br>
> > <mailto:<a href="mailto:quantum-core@lists.launchpad.net">quantum-core@lists.launchpad.net</a>><br>
> > Unsubscribe : <a href="https://launchpad.net/~quantum-core" target="_blank">https://launchpad.net/~quantum-core</a><br>
> > More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
><br>
> --<br>
> Mailing list: <a href="https://launchpad.net/~quantum-core" target="_blank">https://launchpad.net/~quantum-core</a><br>
> Post to : <a href="mailto:quantum-core@lists.launchpad.net">quantum-core@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~quantum-core" target="_blank">https://launchpad.net/~quantum-core</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
><br>
<br>
--<br>
Mailing list: <a href="https://launchpad.net/~quantum-core" target="_blank">https://launchpad.net/~quantum-core</a><br>
Post to : <a href="mailto:quantum-core@lists.launchpad.net">quantum-core@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~quantum-core" target="_blank">https://launchpad.net/~quantum-core</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br>