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:sorla...@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
<aro...@nicira.com<mailto:aro...@nicira.com>> wrote:
On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici
<samu...@radware.com<mailto:samu...@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:aro...@nicira.com<mailto:aro...@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.ubu...@cack.org.uk<mailto:ijw.ubu...@cack.org.uk>> wrote:
On 18 July 2013 19:48, Aaron Rosen
<aro...@nicira.com<mailto:aro...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
