Open Stack

I agree too. I've posted a work in progress of this here if you want to
start looking at it: https://review.openstack.org/#/c/38230/

Thanks,

Aaron


On Tue, Jul 23, 2013 at 4:21 AM, Samuel Bercovici <SamuelB at radware.com>wrote:

>  Hi,****
>
> ** **
>
> I agree that the AutZ should be separated and the service provider should
> be able to control this based on their model.****
>
> ** **
>
> For Service VMs who might be serving ~100-~1000 IPs and might use multiple
> MACs per port, it would be better to turn this off altogether that to have
> an IPTABLE rules with thousands of entries. ****
>
> This why I prefer to be able to turn-off IP spoofing and turn-off MAC
> spoofing altogether.****
>
> ** **
>
> Still from a logical model / declarative reasons an IP that can migrate
> between different ports should be declared as such and maybe also from MAC
> perspective.****
>
> ** **
>
> Regards,****
>
>                 -Sam.****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Salvatore Orlando [mailto:sorlando at nicira.com]
> *Sent:* Sunday, July 21, 2013 9:56 PM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Neutron] Chalenges with highly available
> service VMs - port adn security group options.****
>
> ** **
>
> ** **
>
> ** **
>
> On 19 July 2013 13:14, Aaron Rosen <arosen at nicira.com> wrote:****
>
> ** **
>
> ** **
>
> On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici <SamuelB at radware.com>
> wrote:****
>
> Hi,****
>
>  ****
>
> I have completely missed this discussion as it does not have
> quantum/Neutron in the subject (modify it now)****
>
> I think that the security group is the right place to control this.****
>
> I think that this might be only allowed to admins.****
>
>  ****
>
> I think this shouldn't be admin only since tenant's have control of their
> own networks they should be allowed to do this. ****
>
> ** **
>
> I reiterate my point that the authZ model for a feature should always be
> completely separated by the business logic of the feature itself.****
>
> In my opinion there are grounds both for scoping it as admin only and for
> allowing tenants to use it; it might be better if we just let the policy
> engine deal with this.****
>
>  ****
>
>     Let me explain what we need which is more than just disable spoofing.*
> ***
>
> 1.       Be able to allow MACs which are not defined on the port level to
> transmit packets (for example VRRP MACs)== turn off MAC spoofing****
>
>  ** **
>
> For this it seems you would need to implement the port security extension
> which allows one to enable/disable port spoofing on a port. ****
>
>  ** **
>
> This would be one way of doing it. The other would probably be adding a
> list of allowed VRRP MACs, which should be possible with the blueprint
> pointed by Aaron. ****
>
>     2.       Be able to allow IPs which are not defined on the port level
> to transmit packets (for example, IP used for HA service that moves between
> an HA pair) == turn off IP spoofing****
>
>  ** **
>
> It seems like this would fit your use case perfectly:
> https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs****
>
>  3.       Be able to allow broadcast message on the port (for example for
> VRRP broadcast) == allow broadcast.****
>
>  ****
>
>  Quantum does have an abstraction for disabling this so we already allow
> this by default.  ****
>
>   ****
>
> Regards,****
>
>                 -Sam.****
>
>  ****
>
>  ****
>
> *From:* Aaron Rosen [mailto:arosen at nicira.com]
> *Sent:* Friday, July 19, 2013 3:26 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] Chalenges with highly available service VMs
> ****
>
>  ****
>
> Yup: ****
>
> I'm definitely happy to review and give hints. ****
>
> Blueprint:
> https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit
>
> https://review.openstack.org/#/c/19279/  < patch that merged the feature;
> ****
>
> Aaron****
>
>  ****
>
> On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
> ****
>
> On 18 July 2013 19:48, Aaron Rosen <arosen at nicira.com> wrote:
> > Is there something this is missing that could be added to cover your use
> > case? I'd be curious to hear where this doesn't work for your case.  One
> > would need to implement the port_security extension if they want to
> > completely allow all ips/macs to pass and they could state which ones are
> > explicitly allowed with the allowed-address-pair extension (at least
> that is
> > my current thought).****
>
> Yes - have you got docs on the port security extension?  All I've
> found so far are
>
> http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html
> and the fact that it's only the Nicira plugin that implements it.  I
> could implement it for something else, but not without a few hints...
> --
> Ian.****
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
>  ****
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
>   ** **
>
>
> _______________________________________________
> 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/20130723/284578ef/attachment.html>