Open Stack

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/20130721/fc61ca50/attachment.html>