Re: [openstack-dev] Chalenges with highly available service VMs
Hi Aaron,
I reported it as a bug with bit more details:
https://bugs.launchpad.net/neutron/+bug/1321864. The report has examples
showing the incompleteness in the overlap check due to cidr notation
allowed in the allowed address pairs API.
Cheers,
Praveen
On Tue, May 20, 2014 at 7:54 PM, Aaron Rosen aaronoro...@gmail.com wrote:
arosen@arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner | compute:None
|
| extra_dhcp_opts |
|
| fixed_ips | {subnet_id:
505eb39c-32dc-4fe7-a497-f801a0677c54, ip_address: 10.0.0.22} |
| id| f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address | fa:16:3e:77:4d:2d
|
| name |
|
| network_id| 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status| ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+---+--+
arosen@arosen-MacBookPro:~/devstack$ neutron port-update
f5117013-ac04-45af-a5d6-e9110213ad6f --allowed-address-pairs list=true
type=dict ip_address=10.0.0.0/24
Updated port: f5117013-ac04-45af-a5d6-e9110213ad6f
arosen@arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs | {ip_address: 10.0.0.0/24, mac_address:
fa:16:3e:77:4d:2d}|
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner | compute:None
|
| extra_dhcp_opts |
|
| fixed_ips | {subnet_id:
505eb39c-32dc-4fe7-a497-f801a0677c54, ip_address: 10.0.0.22} |
| id| f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address | fa:16:3e:77:4d:2d
|
| name |
|
| network_id| 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status| ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+---+--+
On Tue, May 20, 2014 at 7:52 PM, Aaron Rosen aaronoro...@gmail.comwrote:
Hi Praveen,
I think there is some confusion here. This function doesn't check if
there is any overlap that occurs within the cidr block. It only checks that
the fixed_ips+mac don't overlap with an allowed address pair. In your
example if the host has an ip_address of 10.10.1.1 and you want to allow
any ip in 10.10.1.0/24 to pass through the port you can just add a rule
for 10.10.1.0/24 directly without having to break it up.
Aaron
On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula
yprav...@avinetworks.com wrote:
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
Re: [openstack-dev] Chalenges with highly available service VMs
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 yprav...@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 aaronoro...@gmail.comwrote: 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 yprav...@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 aro...@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.ubu...@cack.org.ukwrote: On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@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@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 ___
Re: [openstack-dev] Chalenges with highly available service VMs
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 aaronoro...@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 yprav...@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 aaronoro...@gmail.comwrote: 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 yprav...@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 aro...@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.ubu...@cack.org.ukwrote: On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@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,
Re: [openstack-dev] Chalenges with highly available service VMs
arosen@arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner | compute:None
|
| extra_dhcp_opts |
|
| fixed_ips | {subnet_id:
505eb39c-32dc-4fe7-a497-f801a0677c54, ip_address: 10.0.0.22} |
| id| f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address | fa:16:3e:77:4d:2d
|
| name |
|
| network_id| 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status| ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+---+--+
arosen@arosen-MacBookPro:~/devstack$ neutron port-update
f5117013-ac04-45af-a5d6-e9110213ad6f --allowed-address-pairs list=true
type=dict ip_address=10.0.0.0/24
Updated port: f5117013-ac04-45af-a5d6-e9110213ad6f
arosen@arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs | {ip_address: 10.0.0.0/24, mac_address:
fa:16:3e:77:4d:2d}|
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner | compute:None
|
| extra_dhcp_opts |
|
| fixed_ips | {subnet_id:
505eb39c-32dc-4fe7-a497-f801a0677c54, ip_address: 10.0.0.22} |
| id| f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address | fa:16:3e:77:4d:2d
|
| name |
|
| network_id| 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status| ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+---+--+
On Tue, May 20, 2014 at 7:52 PM, Aaron Rosen aaronoro...@gmail.com wrote:
Hi Praveen,
I think there is some confusion here. This function doesn't check if there
is any overlap that occurs within the cidr block. It only checks that the
fixed_ips+mac don't overlap with an allowed address pair. In your example
if the host has an ip_address of 10.10.1.1 and you want to allow any ip in
10.10.1.0/24 to pass through the port you can just add a rule for
10.10.1.0/24 directly without having to break it up.
Aaron
On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula
yprav...@avinetworks.com wrote:
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 aaronoro...@gmail.comwrote:
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
Re: [openstack-dev] Chalenges with highly available service VMs
Hi Praveen, I think there is some confusion here. This function doesn't check if there is any overlap that occurs within the cidr block. It only checks that the fixed_ips+mac don't overlap with an allowed address pair. In your example if the host has an ip_address of 10.10.1.1 and you want to allow any ip in 10.10.1.0/24 to pass through the port you can just add a rule for 10.10.1.0/24 directly without having to break it up. Aaron On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula yprav...@avinetworks.com wrote: 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 aaronoro...@gmail.comwrote: 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 yprav...@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 aaronoro...@gmail.comwrote: 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 yprav...@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 aro...@nicira.comwrote: 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.ubu...@cack.org.ukwrote: On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@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,
Re: [openstack-dev] Chalenges with highly available service VMs
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 aro...@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-pairs and 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.ubu...@cack.org.ukwrote: On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@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@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
Re: [openstack-dev] Chalenges with highly available service VMs
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 yprav...@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 aro...@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-pairs and 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.ubu...@cack.org.ukwrote: On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@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@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
Re: [openstack-dev] Chalenges with highly available service VMs
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 aaronoro...@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 yprav...@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 aro...@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.ubu...@cack.org.ukwrote: On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@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@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 ___
Re: [openstack-dev] Chalenges with highly available service VMs
I'd still like the simpler and more general purpose 'disable spoofing' option as well. That doesn't allow MAC spoofing and it doesn't work for what I'm up to. Read the document properly, Ian. I take back the MAC spoofing comment, but it still won't work for what I'm up to ;) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Chalenges with highly available service VMs
On 18 July 2013 00:45, Aaron Rosen aro...@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. Can you point me to the documentation for port_security_enabled? I've created the following blueprint https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs and doc: https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharing which 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. I'd still like the simpler and more general purpose 'disable spoofing' option as well. That doesn't allow MAC spoofing and it doesn't work for what I'm up to. -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Chalenges with highly available service VMs
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
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
Re: [openstack-dev] Chalenges with highly available service VMs
On Jul 4, 2013, at 8:26 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 4 July 2013 23:42, Robert Collins robe...@robertcollins.net wrote: Seems like a tweak would be to identify virtual IPs as separate to the primary IP on a port: you don't need to permit spoofing of the actual host IP for each host in the HA cluster; you just need to permit spoofing of the virtual IP. This would be safer than disabling the spoofing rules, and avoid configuration errors such as setting the primary IP of one node in the cluster to be a virtual IP on another node - neutron would reject that as the primary IP would be known as that. With apologies for diverting the topic somewhat, but for the use cases I have, I would actually like to be able to disable the antispoofing in its entirety. 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. Vish -- 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
