test_port_security_macspoofing_port doesn't work when l2pop and arpresponding are enabled

Bug #1728886 reported by Miguel Angel Ajo on 2017-10-31
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
tempest
Undecided
Unassigned

Bug Description

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers