Conntrack zones support

https://blueprints.launchpad.net/neutron/+spec/conntrack-in-security-group

Problem Description

Network isolation could be broken since security groups created for one network can affect connectivity between ports of other network if they have same IP addresses as ports on the initial network.

Forcing connection close via conntrack by IP will break existing connections on networks which aren’t related to security group being enforced.

See [1] for the reference.

Proposed Change

The goal is to add support for conntrack zones which allow to handle multiple connections with equal identities in conntrack and NAT.

A zone is simply a numerical identifier associated with a network device that is incorporated into the various hashes and used to distinguish entries in addition to the connection tuples. Additionally it is used to separate conntrack defragmentation queues. An iptables target for the raw table could be used alternatively to the network device for assigning conntrack entries to zones. See [3] for more information.

In the case of security groups, each conntrack zone should correspond to a neutron network. Adding some sort of network identifier makes connection tuple unique.

In fact, that is already done in ovs agent, where there is a local vlan mapping. Exactly the same strategy could be applied to conntrack zones. Local vlan ids could be used as a conntrack zone id.

Changes are required in Firewall driver. It should keep current network-to-zone mapping and apply port firewall rules with this additional parameter. Upon ovs agent start/restart this mapping could be populated from local vlan mapping. Changing zone identifies is ok because iptables rules are updated after ovs agent restart.

This could also be utilized by other agents such as OFAgent.

Data Model Impact

None

REST API Impact

None

Security Impact

This feature should actually improve security by fixing tenant network isolation.

Notifications Impact

None

Other End User Impact

None

Performance Impact

None or insignificant.

IPv6 Impact

None

Other Deployer Impact

None

Developer Impact

None

Community Impact

None

Alternatives

None

Implementation

Assignee(s)

yangxurong

Work Items

  1. The implementation for ovs agent. See [2]
  2. Functional tests.
  3. Implementations for other affected agents.

Dependencies

None

Testing

Tempest Tests

None

Functional Tests

Functional test is required.

API Tests

None

Documentation Impact

User Documentation

None

Developer Documentation

None