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 <samu...@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: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> wrote:**** > > ** ** > > ** ** > > On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici <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] > *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> wrote: > **** > > On 18 July 2013 19:48, Aaron Rosen <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 > 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**** > > ** ** > > > _______________________________________________ > OpenStack-dev mailing list > 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