test_port_security_macspoofing_port doesn't work when l2pop and arpresponding are enabled

[Miguel Angel Ajo]

While we manually verified that port security disable is working, the test will fail when the remote host receiving the ping will respond, but the mac address it learned for the IP address to respond is not the spoofed one "00:00:00:00:00:01" but instead the address arp responder provided.

If we force the mac address via arp -s on the host being pinged, it won't work either (l2pop) because the remote address for "00:00:00:00:00:01" is not learned, hence the remote destination (tunnel) is not know.

EXTRA CONTEXT:

   Port security feature is intended to be used on provider networks (where no arp responders or l2pops would exist), while allowed address pairs can be used for provider or private networks -the SDN is informed about the possible mac addresses and can configure the dataplane to properly function-.

PROPOSAL:

   Rewriting the test so VM A (non spoofed mac) will listen via netcat on an UDP port, and wait for a message from VM B (spoofed mac). When the message is received on VM A, the test has passed.

   An important detail is that on VM A we need to disable the RP filter on VM A (listening side) because otherwise it will drop the UDP packet as non matching the mac address anounced by the ARP responder.

 echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

on VM A:

      $ nohup nc -l -p 1111 -u &

on VM B:
      $ echo TESTPASSED | nc $VM_A 1111 -u -w 1

then we check VM A: "nohup.log" output for "TESTPASSED" with:

  $ grep TESTPASSED nohup.log

[wes hayutin (weshayutin)]

http://logs.rdoproject.org/openstack-periodic-master/opendev.org/openstack/tripleo-ci/master/periodic-tripleo-ci-centos-7-ovb-1ctlr_2comp-featureset021-master/438fdbb/logs/stestr_results.html

http://logs.rdoproject.org/openstack-periodic-latest-released/opendev.org/openstack/tripleo-ci/master/periodic-tripleo-ci-centos-7-ovb-1ctlr_2comp-featureset021-train/fc94407/logs/stestr_results.html

[Marios Andreou (marios-b)]

not sure what the story on this one is. @weshay the logs you point to in comment #1 are from featureset021.

Which is our special 'always fail' featureset. Why are we marking this promotion-blocker and alerting on it?

I think we should mark invalid or there is some more information missing does it happen in other promotion criteria jobs I have not come across that as marios|rover this sprint.

[chandan kumar (chkumar246)]

http://logs.rdoproject.org/openstack-periodic-master/opendev.org/openstack/tripleo-ci/master/periodic-tripleo-ci-centos-7-ovb-1ctlr_2comp-featureset021-master/438fdbb/logs/undercloud/var/log/tempest/tempest_run.log.txt.gz

{0} tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_port_security_macspoofing_port [340.840035s] ... FAILED

It is in skip list, https://opendev.org/openstack/tripleo-quickstart-extras/src/branch/master/roles/validate-tempest/vars/tempest_skip_master.yml#L17 here.

The bug should be open always for tracking the skip list. We may remove promotion blocker from it unless above mentioned issue is fixed.

[Daniel Alvarez (dalvarezs)]

I wrote this patch [0] and it fixes the issue. I think that the analysis on the bug description is not really accurate. Just by setting the OVN addresses field to 'unknown' when port security is disabled is allowing traffic on a spoofed MAC.

[0] https://review.opendev.org/#/c/700005/

[wes hayutin (weshayutin)]

https://review.opendev.org/#/c/702249/

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 16.0.0.0b1 development milestone.

[Martin Kopec (mkopec)]

I see this got fixed in neutron and the test has been passing over the last 3 months:

http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_port_security_macspoofing_port?duration=P3M

Is anything required on tempest side here or shall we considered this fixed entirely?

[Maciej Jozefczyk (maciejjozefczyk)]

Hey Martin,

from tempest side there is nothing that needs to be done.

The root cause has been fixed in Core OVN. With this fix the ARP responder flows are not installed on LS pipeline, when LSP has port security disabled, and
an 'unknown' address is set in addresses column. This makes MAC spoofing possible.

Because of it now we can revert [2]. I already proposed it here [3].

[1] https://patchwork.ozlabs.org/patch/1258152/
[2] https://review.opendev.org/#/c/702249/
[3] https://review.opendev.org/#/c/708852/

[Martin Kopec (mkopec)]

Hi Maciej,

I'm glad to hear that, thank you for the info. I'm gonna close this for Tempest then.

[Martin Kopec (mkopec)]

Based on the comments above, mainly #8, I'm closing this for Tempest as the issue got fixed in OVN in neutron project.