[security] Add allowed-address-pair 0.0.0.0/0 to one port will open all others' protocol under same security group

[LIU Yulong]

[security] Add allowed-address-pair 0.0.0.0/0 to one port will open all others' protocol under same security group

When add allowed-address-pair 0.0.0.0/0 to one port, it will unexpectedly open all others' protocol under same security group. First found in stable/queens, but also confirmed in master branch.
IPv6 has the same problem!

Devstack test config:
[DEFAULT]
[l2pop]
[ml2]
type_drivers = flat,gre,vlan,vxlan
tenant_network_types = vxlan
extension_drivers = port_security,qos
mechanism_drivers = openvswitch,l2population

[ml2_type_vxlan]
vni_ranges = 10000:19999

[securitygroup]
firewall_driver = openvswitch
[ovs]
local_ip = 10.0.5.10

[agent]
tunnel_types = vxlan
l2_population = True
arp_responder = True
enable_distributed_routing = True
extensions = qos

Step to reproduce:
1. Assuming you have following VMs
| 24231705-ee79-4643-ae5a-9f0f7ff8f8ba | dvr-ha-vm-2 | ACTIVE | dvr-ha=192.168.30.44, 172.16.12.220 | cirros | nano |
| 4865d216-9f95-40bf-a6b4-221e3af06798 | dvr-ha-vm-1 | ACTIVE | dvr-ha=192.168.30.64, 172.16.13.52 | cirros | nano |

$ nova interface-list 4865d216-9f95-40bf-a6b4-221e3af06798
+------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+
| Port State | Port ID | Net ID | IP addresses | MAC Addr | Tag |
+------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+
| ACTIVE | b333b1ca-bb9a-41fd-a878-b524ffbc6d7a | a9e82560-f1ac-4909-9afa-686b57df62fa | 192.168.30.64 | fa:16:3e:12:66:05 | - |
+------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+
$ nova interface-list 24231705-ee79-4643-ae5a-9f0f7ff8f8ba
+------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+
| Port State | Port ID | Net ID | IP addresses | MAC Addr | Tag |
+------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+
| ACTIVE | 93197f48-3fe4-47f4-9d15-ba8728c00409 | a9e82560-f1ac-4909-9afa-686b57df62fa | 192.168.30.44 | fa:16:3e:14:ff:f1 | - |
+------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+

2. Security group rules
$ openstack security group rule list 535018b5-7038-46f2-8f0e-2a6e193788aa --long|grep ingress
| 01015261-0ca3-49ad-b033-bc2036a58e26 | tcp | IPv4 | 0.0.0.0/0 | 22:22 | ingress | None |
| 36441851-7bd2-4680-be43-2f8119b65040 | icmp | IPv4 | 0.0.0.0/0 | | ingress | None |
| 8326f59e-cf26-4372-9913-30c71c036a2e | None | IPv6 | ::/0 | | ingress | 535018b5-7038-46f2-8f0e-2a6e193788aa |
| e47c6731-a0f7-42aa-8125-a9810e7b5a17 | None | IPv4 | 0.0.0.0/0 | | ingress | 535018b5-7038-46f2-8f0e-2a6e193788aa |

3. Start a nc test server in dvr-ha-vm-2
# nc -l -p 8000

4. Try to curl that dvr-ha-vm-2 port 8000 in the outside world
$ curl http://172.16.12.220:8000/index.html
curl: (7) Failed connect to 172.16.12.220:8000; Connection timed out

5. Add allowed address pair 0.0.0.0/0 to dvr-ha-vm-1
openstack port set --allowed-address ip-address=0.0.0.0/0 b333b1ca-bb9a-41fd-a878-b524ffbc6d7a

6. Try to curl that dvr-ha-vm-2 port 8000 again
It is connected!!!

# nc -l -p 8000
GET /index.html HTTP/1.1
User-Agent: curl/7.29.0
Host: 172.16.12.220:8000
Accept: */*

asdfasdf
asdfasdf

[LIU Yulong (dragon889)]

The bug are mostly caused by the openflow security group. We compared the flows after added the 0.0.0.0/0 allowed-addres-pair. These two flows are added to table=82:
> table=82, priority=70,ct_state=+est-rel-rpl,ip,reg6=0x3 actions=conjunction(16,1/2)
> table=82, priority=70,ct_state=+new-est,ip,reg6=0x3 actions=conjunction(17,1/2)
Yes, this is the root cause, it will allow almost all ip traffic.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/712632

[Slawek Kaplonski (slaweq)]

@Liu: why You set this bug as not a duplicate of 1793029? It's exactly same problem in both. And 1793029 was marked as fixed because we did warning about such case in our documentation. Basically it is how allowed_address_pairs works together with remote security group ids. Please read especially comments #10 and #11 in the 1793029 - Akihiro explained exactly what is the problem with this and why it's not so easy to fix

[LIU Yulong (dragon889)]

I've seen those comments, and he said this is ideed a problem but without solutions. It was marked as fix released, so I'd like to use this one to trace the real solutions.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/712632
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=00298fe6e84cd7610b39af50e9517885a182f47c
Submitter: Zuul
Branch: master

commit 00298fe6e84cd7610b39af50e9517885a182f47c
Author: LIU Yulong <email address hidden>
Date: Fri Mar 13 18:18:04 2020 +0800

    [Security] fix allowed-address-pair 0.0.0.0/0 issue

    When add allowed-address-pair 0.0.0.0/0 to one port, it will
    unexpectedly open all others' protocol under same security
    group. IPv6 has the same problem.

    The root cause is the openflow rules calculation of the
    security group, it will unexpectedly allow all IP(4&6)
    traffic to get through.

    For openvswitch openflow firewall, this patch adds a source
    mac address match for the allowed-address-pair which has
    prefix lenght 0, that means all ethernet packets from this
    mac will be accepted. It exactly will meet the request of
    accepting any IP address from the configured VM.

    Test result shows that the remote security group and
    allowed address pair works:
    1. Port has 0.0.0.0/0 allowed-address-pair clould send any
       IP (src) packet out.
    2. Port has x.x.x.x/y allowed-address-pair could be accepted
       for those VMs under same security group.
    3. Ports under same network can reach each other (remote
       security group).
    4. Protocol port number could be accessed only when there
       has related rule.

    Closes-bug: #1867119
    Change-Id: I2e3aa7c400d7bb17cc117b65faaa160b41013dde

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/744133

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/744134

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/744135

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/744137

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/744134
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=18a171808ba8c5e4806feda43f571fb8cfc0b9a1
Submitter: Zuul
Branch: stable/stein

commit 18a171808ba8c5e4806feda43f571fb8cfc0b9a1
Author: LIU Yulong <email address hidden>
Date: Fri Mar 13 18:18:04 2020 +0800

    [Security] fix allowed-address-pair 0.0.0.0/0 issue

    When add allowed-address-pair 0.0.0.0/0 to one port, it will
    unexpectedly open all others' protocol under same security
    group. IPv6 has the same problem.

    The root cause is the openflow rules calculation of the
    security group, it will unexpectedly allow all IP(4&6)
    traffic to get through.

    For openvswitch openflow firewall, this patch adds a source
    mac address match for the allowed-address-pair which has
    prefix lenght 0, that means all ethernet packets from this
    mac will be accepted. It exactly will meet the request of
    accepting any IP address from the configured VM.

    Test result shows that the remote security group and
    allowed address pair works:
    1. Port has 0.0.0.0/0 allowed-address-pair clould send any
       IP (src) packet out.
    2. Port has x.x.x.x/y allowed-address-pair could be accepted
       for those VMs under same security group.
    3. Ports under same network can reach each other (remote
       security group).
    4. Protocol port number could be accessed only when there
       has related rule.

    Closes-bug: #1867119
    Change-Id: I2e3aa7c400d7bb17cc117b65faaa160b41013dde
    (cherry picked from commit 00298fe6e84cd7610b39af50e9517885a182f47c)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/744137
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bd6203b2c7e1e4af63813b307bc4ec1b49516bd5
Submitter: Zuul
Branch: stable/queens

commit bd6203b2c7e1e4af63813b307bc4ec1b49516bd5
Author: LIU Yulong <email address hidden>
Date: Fri Mar 13 18:18:04 2020 +0800

    [Security] fix allowed-address-pair 0.0.0.0/0 issue

    When add allowed-address-pair 0.0.0.0/0 to one port, it will
    unexpectedly open all others' protocol under same security
    group. IPv6 has the same problem.

    The root cause is the openflow rules calculation of the
    security group, it will unexpectedly allow all IP(4&6)
    traffic to get through.

    For openvswitch openflow firewall, this patch adds a source
    mac address match for the allowed-address-pair which has
    prefix lenght 0, that means all ethernet packets from this
    mac will be accepted. It exactly will meet the request of
    accepting any IP address from the configured VM.

    Test result shows that the remote security group and
    allowed address pair works:
    1. Port has 0.0.0.0/0 allowed-address-pair clould send any
       IP (src) packet out.
    2. Port has x.x.x.x/y allowed-address-pair could be accepted
       for those VMs under same security group.
    3. Ports under same network can reach each other (remote
       security group).
    4. Protocol port number could be accessed only when there
       has related rule.

    Conflicts:
        neutron/tests/unit/agent/linux/openvswitch_firewall/test_rules.py

    Closes-bug: #1867119
    Change-Id: I2e3aa7c400d7bb17cc117b65faaa160b41013dde
    (cherry picked from commit 00298fe6e84cd7610b39af50e9517885a182f47c)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/744135
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=64a0916d2b97700c8f0401ab284684569deebe78
Submitter: Zuul
Branch: stable/rocky

commit 64a0916d2b97700c8f0401ab284684569deebe78
Author: LIU Yulong <email address hidden>
Date: Fri Mar 13 18:18:04 2020 +0800

    [Security] fix allowed-address-pair 0.0.0.0/0 issue

    When add allowed-address-pair 0.0.0.0/0 to one port, it will
    unexpectedly open all others' protocol under same security
    group. IPv6 has the same problem.

    The root cause is the openflow rules calculation of the
    security group, it will unexpectedly allow all IP(4&6)
    traffic to get through.

    For openvswitch openflow firewall, this patch adds a source
    mac address match for the allowed-address-pair which has
    prefix lenght 0, that means all ethernet packets from this
    mac will be accepted. It exactly will meet the request of
    accepting any IP address from the configured VM.

    Test result shows that the remote security group and
    allowed address pair works:
    1. Port has 0.0.0.0/0 allowed-address-pair clould send any
       IP (src) packet out.
    2. Port has x.x.x.x/y allowed-address-pair could be accepted
       for those VMs under same security group.
    3. Ports under same network can reach each other (remote
       security group).
    4. Protocol port number could be accessed only when there
       has related rule.

    Closes-bug: #1867119
    Change-Id: I2e3aa7c400d7bb17cc117b65faaa160b41013dde
    (cherry picked from commit 00298fe6e84cd7610b39af50e9517885a182f47c)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/744133
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=551130e9f4e8c89821d73881ad8e90a0208adb3e
Submitter: Zuul
Branch: stable/train

commit 551130e9f4e8c89821d73881ad8e90a0208adb3e
Author: LIU Yulong <email address hidden>
Date: Fri Mar 13 18:18:04 2020 +0800

    [Security] fix allowed-address-pair 0.0.0.0/0 issue

    When add allowed-address-pair 0.0.0.0/0 to one port, it will
    unexpectedly open all others' protocol under same security
    group. IPv6 has the same problem.

    The root cause is the openflow rules calculation of the
    security group, it will unexpectedly allow all IP(4&6)
    traffic to get through.

    For openvswitch openflow firewall, this patch adds a source
    mac address match for the allowed-address-pair which has
    prefix lenght 0, that means all ethernet packets from this
    mac will be accepted. It exactly will meet the request of
    accepting any IP address from the configured VM.

    Test result shows that the remote security group and
    allowed address pair works:
    1. Port has 0.0.0.0/0 allowed-address-pair clould send any
       IP (src) packet out.
    2. Port has x.x.x.x/y allowed-address-pair could be accepted
       for those VMs under same security group.
    3. Ports under same network can reach each other (remote
       security group).
    4. Protocol port number could be accessed only when there
       has related rule.

    Closes-bug: #1867119
    Change-Id: I2e3aa7c400d7bb17cc117b65faaa160b41013dde
    (cherry picked from commit 00298fe6e84cd7610b39af50e9517885a182f47c)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron queens-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron rocky-eol release.