Open Stack

On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici <SamuelB at radware.com>wrote:

>  Hi,****
>
> ** **
>
> This might be apparent but not to me.****
>
> Can you point to how broadcast can be turned on a network/port?
>

There  is currently no way to prevent it so it's on by default.

> ****
>
> ** **
>
> As for the
> https://github.com/openstack/neutron/blob/master/neutron/extensions/portsecurity.py,
> in NVP, does this totally disable port security on a port/network or it
> just disable the MAC/IP checks and still allows the “user defined” port
> security to take effect?
>

Port security is currently obtained from the fixed_ips and mac_address
field on the port. This removes the filtering done on fixed_ips and
mac_address fields when disabled.


> ****
>
> This looks like an extension only implemented by NVP, do you know if there
> are similar implementations for other plugins?****
>
> **
>

No, the other plugins do not currently have a way to disable spoofing
dynamically (only globally disabled).


>  **
>
> Regards,****
>
>             -Sam.****
>
> ** **
>
> ** **
>
> *From:* Aaron Rosen [mailto:arosen at nicira.com]
> *Sent:* Tuesday, July 23, 2013 10:52 PM
> *To:* Samuel Bercovici
> *Cc:* OpenStack Development Mailing List; sorlando at nicira.com; Avishay
> Balderman; gary.kotton at gmail.com
>
> *Subject:* Re: [openstack-dev] [Neutron] Chalenges with highly available
> service VMs - port adn security group options.****
>
> ** **
>
> 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/20130724/5971bb5e/attachment.html>