yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #73784
[Bug 1757482] Re: IP address for a router interface allowed outside the allocation range of subnet
Reviewed: https://review.openstack.org/575444
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=54aa6e81cb17b33ce4d5d469cc11dec2869c762d
Submitter: Zuul
Branch: master
commit 54aa6e81cb17b33ce4d5d469cc11dec2869c762d
Author: Miguel Lavalle <miguel.lavalle@xxxxxxxxxx>
Date: Thu Jun 14 09:21:09 2018 -0500
Disallow router interface out of subnet IP range
Currently, a non privileged tenant can add a router interface to a
shared / external network's subnet with an IP address outside the
subnet's allocation pool, creating a security risk. This patch prevents
tenants who are not the subnet's owner or admin from assigning a router
interface an IP address outside the subnet's allocation pool.
Change-Id: I32e76a83443dd8e7d79b396499747f29b4762e92
Closes-Bug: #1757482
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1757482
Title:
IP address for a router interface allowed outside the allocation range
of subnet
Status in neutron:
Fix Released
Status in OpenStack Security Advisory:
Incomplete
Bug description:
Currently running Queens on Ubuntu 16.04 with the linuxbridge ml2
plugin with vxlan overlays. We have a single, large provider network
that we have set to 'shared' and 'external', so people who need to do
things that don't work well with NAT can connect their instances
directly to the provider network. Our 'allocation range' as defined
in our provider subnet is dedicated to tenants, so there should be no
conflicts.
One of our users connected a neutron router to the provider network
(not via the 'external network' option, but rather via the normal 'add
interface' option) and neglected to specify an IP address. The
neutron router decided that it was now the gateway for the entire
provider network and began arp'ing.
This seems like it should be disallowed inside of neutron (you
shouldn't be able to specify an IP address for a router interface that
isn't explicitly part of your allocation range on said subnet).
Unless neutron just expect issues like this to be handled by the
physical provider infrastructure (spoofing prevention, etc.)?
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1757482/+subscriptions
References