On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici <samu...@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:aro...@nicira.com] > *Sent:* Tuesday, July 23, 2013 10:52 PM > *To:* Samuel Bercovici > *Cc:* OpenStack Development Mailing List; sorla...@nicira.com; Avishay > Balderman; gary.kot...@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 <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