[RFE] Add attribute to the a port that lists the UUIDs of other ports that the port is allowed to impersonate

[Denes Nemeth]

==========================================================
Advanced policy for address pair
==========================================================

The allowed address pair extension extends the port attribute to enable you to
specify arbitrary mac_address/ip_address(cidr) pairs that are allowed to pass
through a port regardless of the subnet associated with the network.

The allowed address pairs is typically used for specify a moving or virtual
IP between a HA server pair.

Problem Description
===================

An end user can only create ports with allowed address pairs on non owned
networks (shared or provider) with elevated privileges. With elevated
privileges it is possible to use any IP or MAC address. This poses a
significant security risk, because the attacker may abuse this privilege
for DoS or man in middle attacks.

Proposed Change ===============

Extend the currently existing policy with a rule that allows an user to
create or update a port with allowed address pairs to already allocated
IP / MAC addresses.

[Armando Migliaccio (armando-migliaccio)]

You mean you want to limit the user to be able to add IP/MAC pairs only if they match MAC/IPs assigned to existing neutron ports that he/she owns?

[Kevin Benton (kevinbenton)]

@Armax, yeah, I interpreted it the same way.

[Kevin Benton (kevinbenton)]

Basically you want to be able to run HA services on a provider network, is that right?

[Kevin Benton (kevinbenton)]

Moving to triaged because we have enough to discuss with it already while waiting for the response.

[Denes Nemeth (denes-nemeth)]

Sorry for the late response, but probably we are in different time zones.

We would like to run HA pair (sometimes more that two) servers that are able to use the same IP address. The IP at a given time is only used by one server (active). In case of failure the passive server takes over the IP.

The allowed address pair makes it possible to use any IP address. I would like to limit the allowed IP addresses to the IPs that particular tenant already holds. In most environments the allowed address pairs is not allowed for normal users in policy.json, because of the security issue of being able to use any IP addesss.

So the introduction of this new policy would make it possible for normal tenant to use allowed address pairs without the security issue.

[Armando Migliaccio (armando-migliaccio)]

We talked about this request during today's meeting, however it's not clear the exact use case. Could you walk us through the steps involved to set up this HA port pair? Is the tenant executing this steps a 'service' like a PaaS on top of OpenStack? Why wouldn't that own the network?

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-07-13-22.05.log.html

[Armando Migliaccio (armando-migliaccio)]

Marking incomplete until more details are provided.

[Denes Nemeth (denes-nemeth)]

The use cases are the following:

1. In telco environments multiple vendors use the same cloud provided by the operator. These vendors should be treated as competing entities. Each vendor gets a separate tenant. The tenants are used to deploy products of the vendors. The products must communicate with each other with typical telco workloads (non NAT, high throughput, low latency, ...) so a shared network is created on which both vendors can create ports. Each vendor would like to create a virtual IP (that may be used by multiple servers) so that the servers operate in a HA setup with a single point of contact (IP). This requires currently allowed address pairs.

2. In the previous setup (1) the operator would not like to trust the vendor to specify any IP address in the allowed address pair section. Because this privilige could be abused to eavesdrop, execute man in. middle attacks or DoS by simple allocation of ANY address.

The steps to create the HA port pair is the following currently:
0. Create a port named port_vip
1. Create a port named port_left
2. Create a port named port_right with the IP address of port_vip specified as allowed address
3. Launch two servers with one port each (left and right)
The ports are created by deploying Heat templates. The servers receives the IP address of port_vip via user data. Each server configures the IP address of it's own port. Keepalived is used to configure the IP address of port_vip to only one of the servers at a given time. If the server that own the VIP dies the other server takes over the VIP and configures it.

The following scenario only describes the 2 HA pair setup, but typically more than two servers form a HA group (minimum 3).

[Armando Migliaccio (armando-migliaccio)]

The key element to the use case is that this happens on a shared network, but that needn't be. Why can't each vendor (tenant) have its own network?

Shared networks are not tenant isolated, and there's only minimal security protection. Even without allowed address pairs there's a chance to have tenant interference.

[Kevin Benton (kevinbenton)]

The use case here seems clear, allowing shared IPs within a tenant on provider networks.

This is probably not sane to implement the in policy engine alone. We could put in all of the logic to do lookups of a tenant's IP addresses on a shared network on an AAP update but then we would also need a really complex enforcement to make sure a port doesn't get deleted or have its address updated while another port is using its IP in allowed address pairs.

I think to do this we will probably need a separate attribute from allowed address pairs specifically for this use case that contains that validation logic within the Neutron code rather than trying to put it in the policy engine.

[Armando Migliaccio (armando-migliaccio)]

Now that we have the submitter's reply, let's mark this report triaged so that we can discuss it once more time during a future drivers meeting.

[Armando Migliaccio (armando-migliaccio)]

@Kevin: furthermore, the consumer of this new attribute need explicitly disable the 'untrusted' allowed address pair capability.

[Denes Nemeth (denes-nemeth)]

An each application is deployed on a separate tenant. Each application has it's own tenant network (non-shared) for internal communication. The applications communicate with each other using ports on shared network, because in this case no router (internal/external) is required to be deployed between them. The router is not an option because it does not provide the required performance.

The purpose of the shared network is to allow "interference" between application. By interference I mean communication. On a shared network the applications may also use any dynamically allocated IP address without any special privilege. Besides this I know no other way to interfere. If you know any other means of interference please elaborate.

[Armando Migliaccio (armando-migliaccio)]

If you are unable to use any type of routing capability (hardware or software) to provide internetworking between applications, then a shared medium sounds like it is your only option. I think your use case is clear now, thanks for providing these extra details.

[Kevin Benton (kevinbenton)]

@Armando, they won't need to disable the current one because regular tenants already cannot set allowed address pairs on ports on shared networks.

[Kevin Benton (kevinbenton)]

@Denes,

If we add a new attribute to a port that takes a list of port UUIDs that the port is allowed to impersonate, would that solve your use case?

The validation for the new attribute would confirm that the tenant owns the port they are trying to impersonate and that it is on the same network.

This would permit the port to source traffic from the fixed IP addresses of the ports in the UUID list.

[Denes Nemeth (denes-nemeth)]

@Kevin

This sounds really good. It would solve all out use cases.

[Brian Haley (brian-haley)]

Closing as this bug is very old and there was never a spec or patch proposed for this. Please re-open if anyone wishes to work on it. Thanks.