Open Stack

Hi Aaron,

The main motivation is simplicity. Consider the case where we want to allow
ip cidr 10.10.1.0/24 to be allowed on a port which has a fixed IP of
10.10.1.1. Now if we do not want to allow overlapping, then one needs to
add 8 cidrs to get around this - (10.10.1.128/25, 10.10.1.64/26,
10.10.1.32/27, ....10.10.1.0/32); which makes it cumbersome.

In any case, allowed-address-pairs is ADDING on to what is allowed because
of the fixed IPs. So, there is no possibility of conflict. The check will
probably make sense if we are maintaining denied addresses instead of
allowed addresses.

Cheers,
Praveen


On Tue, May 20, 2014 at 9:34 AM, Aaron Rosen <aaronorosen at gmail.com> wrote:

> Hi Praveen,
>
> I think we should fix the update_method instead to properly check for
> this. I don't see any advantage to allow the fixed_ips/mac to be in the
> allowed_address_pairs since they are explicitly allowed. What's your
> motivation for changing this?
>
> Aaron
>
>
> On Mon, May 19, 2014 at 4:05 PM, Praveen Yalagandula <
> ypraveen at avinetworks.com> wrote:
>
>> Hi Aaron,
>>
>> Thanks for the prompt response.
>>
>> If the overlap does not have any negative effect, can we please just
>> remove this check? It creates confusion as there are certain code paths
>> where we do not perform this check. For example, the current code does NOT
>> perform this check when we are updating the list of allowed-address-pairs
>> -- I can successfully assign an existing fixed IP address to the
>> allowed-address-pairs. The check is being performed on only one code path -
>> when assigning fixed IPs.
>>
>> If it sounds right to you, I can submit my patch removing this check.
>>
>> Thanks,
>> Praveen
>>
>>
>>
>> On Mon, May 19, 2014 at 12:32 PM, Aaron Rosen <aaronorosen at gmail.com>wrote:
>>
>>> Hi,
>>>
>>> Sure, if you look at this method:
>>>
>>>     def _check_fixed_ips_and_address_pairs_no_overlap(self, context,
>>> port):
>>>         address_pairs = self.get_allowed_address_pairs(context,
>>> port['id'])
>>>         for fixed_ip in port['fixed_ips']:
>>>
>>>             for address_pair in address_pairs:
>>>
>>>                 if (fixed_ip['ip_address'] == address_pair['ip_address']
>>>
>>>                     and port['mac_address'] ==
>>> address_pair['mac_address']):
>>>                     raise
>>> addr_pair.AddressPairMatchesPortFixedIPAndMac()
>>>
>>>
>>>
>>> it checks that the allowed_address_pairs don't overlap with fixed_ips
>>> and mac_address on the port. The only reason we do this additional check is
>>> that having the same fixed_ip and mac_address pair as an
>>> allowed_address_pair would have no effect since the fixed_ip/mac on the
>>> port inherently allows that traffic through.
>>>
>>> Best,
>>>
>>> Aaron
>>>
>>>
>>>
>>> On Mon, May 19, 2014 at 12:22 PM, Praveen Yalagandula <
>>> ypraveen at avinetworks.com> wrote:
>>>
>>>> Hi Aaron,
>>>>
>>>> In OVS and ML2 plugins, on port-update, there is a check to make sure
>>>> that allowed-address-pairs and fixed-ips don't overlap. Can you please
>>>> explain why that is needed?
>>>>
>>>> ------------- icehouse final: neutron/plugins/ml2/plugin.py ------------
>>>>
>>>> 677             elif changed_fixed_ips:
>>>>
>>>> 678                 self._check_fixed_ips_and_address_pairs_no_overlap(
>>>>
>>>> 679                     context, updated_port)
>>>> -----------------------
>>>>
>>>> Thanks,
>>>> Praveen
>>>>
>>>>
>>>> On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen <arosen at nicira.com> wrote:
>>>>
>>>>> Hi Ian,
>>>>>
>>>>> For shared networks if the network is set to
>>>>> port_security_enabled=True then the tenant will not be able to remove
>>>>> port_security_enabled from their port if they are not the owner of the
>>>>> network. I believe this is the correct behavior we want. In addition, only
>>>>> admin's are able to create shared networks by default.
>>>>>
>>>>> I've created the following blueprint
>>>>> https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairsand doc:
>>>>> https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich will provide us a way to do this. It would be awesome if you could
>>>>> check it out and let me know what you think.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>> On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells <ijw.ubuntu at cack.org.uk>wrote:
>>>>>
>>>>>> On 10 July 2013 21:14, Vishvananda Ishaya <vishvananda at gmail.com>
>>>>>> wrote:
>>>>>> >> It used to be essential back when we had nova-network and all
>>>>>> tenants
>>>>>> >> ended up on one network.  It became less useful when tenants could
>>>>>> >> create their own networks and could use them as they saw fit.
>>>>>> >>
>>>>>> >> It's still got its uses - for instance, it's nice that the metadata
>>>>>> >> server can be sure that a request is really coming from where it
>>>>>> >> claims - but I would very much like it to be possible to, as an
>>>>>> >> option, explicitly disable antispoof - perhaps on a per-network
>>>>>> basis
>>>>>> >> at network creation time - and I think we could do this without
>>>>>> >> breaking the security model beyond all hope of usefulness.
>>>>>> >
>>>>>> > Per network and per port makes sense.
>>>>>> >
>>>>>> > After all, this is conceptually the same as enabling or disabling
>>>>>> > port security on your switch.
>>>>>>
>>>>>> Bit late on the reply to this, but I think we should be specific on
>>>>>> the network, at least at creation time, on what disabling is allowed
>>>>>> at port level (default off, may be off, must be on as now).  Yes, it's
>>>>>> exactly like disabling port security, and you're not always the
>>>>>> administrator of your own switch; if we extend the analogy you
>>>>>> probably wouldn't necessarily want people turning antispoof off on an
>>>>>> explicitly shared-tenant network.
>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20140520/37d82446/attachment.html>