Allow connection tracking to be disabled per-port

[Calum Loudon]

This RFE is being raised in the context of this use case https://review.openstack.org/#/c/176301/ from the TelcoWG.

OpenStack implements levels of per-VM security protection (security groups, anti-spoofing rules). If you want to deploy a trusted VM which itself is providing network security functions, as with the above use case, then it is often necessary to disable some of the native OpenStack protection so as not to interfere with the protection offered by the VM or use excessive host resources.

Neutron already allows you to disable security groups on a per-port basis. However, the Linux kernel will still perform connection tracking on those ports. With default Linux config, VMs will be severely scale limited without specific host configuration of connection tracking limits - for example, a Session Border Controller VM may be capable of handling millions of concurrent TCP connections, but a default host won't support anything like that. This bug is therefore a RFE to request that disabling security group function for a port further disables kernel connection tracking for IP addresses associated with that port.

[Armando Migliaccio (armando-migliaccio)]

I am not sure I understand the use case here. Neutron allows you to disable port security and remove security groups on the port. If the linux kernel gets in the way, it doesn't seem like it's Neutron's job to fiddle with the kernel. Shouldn't the the system management tool be in better position to disable connection tracking? What exactly are you looking for? Unloading conntrack modules?

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]

[György Szombathelyi (gyurco)]

Just an update: I think it would be wise to disable connection tracking (e.g. adding iptables -t raw -j NOTRACK ....) when port security is disabled for a port. It can make a huge difference on the used conntrack entries in the kernel.

[György Szombathelyi (gyurco)]

Experimented with this a bit, and seems the tricky part is that you have to disable conntrack on the incoming bridge, too, not just the tap interface of the VM. And on that bridge, there can be security enabled and disabled ports, too. Filtering for the IP of the port works, but I don't know if it is wise to use the IP for a port-security disabled port.

E.g. for a port on VLAN.913 with IP 192.168.168.11, two rules can be used to disable connection tracking:
iptables -I neutron-linuxbri-PREROUTING -t raw -m physdev --physdev-in br-vlan.913 --dest 192.168.168.11 -j NOTRACK
iptables -A neutron-linuxbri-PREROUTING -t raw -m physdev --physdev-in tap918bb4f3-23 -j NOTRACK

The second one is straightforward, just the first need a better matching than the IP, I think.

[Miguel Angel Ajo (mangelajo)]

Adding jakub to the thread. In the OVS firewall it's (or it's very easy to get too), because it's just a matter of skipping the CT lookup action AFAIK.

[György Szombathelyi (gyurco)]

Just another comment: if the whole network has disabled port security, then it is easy with the linuxbridge agent:

iptables -I neutron-linuxbri-PREROUTING -t raw -i brqfa4477a2-bf -j NOTRACK

So just add a NOTRACK for the bridge.

[György Szombathelyi (gyurco)]

...but seems the port_security_enabled flag on a network is just a default for new ports, so disabling port security on an existing network preserves port security on existing ports.

[György Szombathelyi (gyurco)]

Further experimenting, and with an idea of a co-worker, it is possible to use MAC address matching on the main bridge interface. And this seems to be good, since a port is always defined with a MAC (it is a not null field). So the final rules:

Mark packets arriving to the main bridge with the destination of the neutron port:

  ebtables -t nat -I PREROUTING -i br-vlan.913 -d fa:16:3e:50:9f:73 -j mark --mark-set 0x505050

Disable conntrack of the marked packets:

  iptables -I neutron-linuxbri-PREROUTING -t raw -m mark --mark 0x505050 -j NOTRACK

Disable conntrack on the tap interface belongs to the port:

  iptables -A neutron-linuxbri-PREROUTING -t raw -m physdev --physdev-in tap918bb4f3-23 -j NOTRACK

[György Szombathelyi (gyurco)]

And even further thinking about the rules needed, there can be some simplifications:

- The -m mark rule can be global, so just set it once when the agent starts

- Using -i {{ bridge_name }} must be omitted, since there can be incoming traffic from the same compute host.

So finally:

Need a global rule (the mark value is arbitrary):

 iptables -I 1 neutron-linuxbri-PREROUTING -t raw -m mark --mark 0x505050 -j NOTRACK
(another one can stop evaluating other rules)
 iptables -I 2 neutron-linuxbri-PREROUTING -t raw -m mark --mark 0x505050 -j RETURN

And two rules per port:

  ebtables -t nat -I PREROUTING -d fa:16:3e:50:9f:73 -j mark --mark-set 0x505050
  iptables -A neutron-linuxbri-PREROUTING -t raw -m physdev --physdev-in {{ tap_if }} -j NOTRACK

[Armando Migliaccio (armando-migliaccio)]

This sounds to me like a minor performance enhancement that can be dealt as a bug fix. From what I can see there's no API/RPC changes involved are there?

[Kevin Benton (kevinbenton)]

Yep, we can treat as a regular bug.

[Lajos Katona (lajos-katona)]

As I see the history we can close this with won't fix if you think please reopen this bug report