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¶
The implementation for ovs agent. See [2]
Functional tests.
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
References¶
[1] https://bugs.launchpad.net/neutron/+bug/1359523 [2] https://review.openstack.org/#/c/118274/ [3] http://lwn.net/Articles/370152/
