How can a router not recognize a gratuitous ARP MITM attack?

Question

I'm reading the chapter for DHCP Snooping/DAI in the OCG for the CCNA and I have a question regarding how gratuitous ARP message attacks work.

I'm sure there is a piece I am missing, but I've searched and haven't been able to find the answer to my question.

Refer to the diagram below: PC-A sends a gratuitous ARP to R2 to update R2's ARP table such that R2 believes 172.16.2.101 has a L2 address of MAC A.

In the steps listed in the diagram, the first is that PC 1 sends traffic to a server through R2. My question is, wouldn't R2 see in the ethernet header that the source MAC from source IP 172.16.2.101 was MAC 1 and not MAC A as it should be according to its ARP table? In other words, if R2 knows that the address 172.16.2.101 is connected to MAC A, and it receives a packet that has MAC 1 as the source and 172.16.2.101 as the source IP, wouldn't it know something is up? I'm probably missing something super simple. Anyways, this is my first question and I hope to get some responses. Thank you...

Answer 1

Only ARP packets can update ARP tables. If the target sends its own ARP request, the router will see that and can update its ARP table, but that is an ARP packet, not an IP packet.

Also, remember that a host seeing an ARP packet not destined for itself should only update its ARP table if its ARP table already has an entry for that address.

See RFC 826, An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses that has the pseudo code for reception of an ARP packet:

When an address resolution packet is received, the receiving
Ethernet module gives the packet to the Address Resolution module
which goes through an algorithm similar to the following.
Negative conditionals indicate an end of processing and a
discarding of the packet.

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
  [optionally check the hardware length ar$hln]
  ?Do I speak the protocol in ar$pro?
  Yes:
    [optionally check the protocol length ar$pln]
    Merge_flag := false
    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.
    ?Am I the target protocol address?
    Yes:
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

Answer 2

Theoretically you could implement this security mechanism in a router, but it would make traffic forwarding slower. Why slower? Normally when a router forwards a packet it checks its routing table, 1 lookup, and then the packet is sent out the resulting interface. Sometimes RPF check is configured to verify the source of the packet - so a total of 2 lookups.

If you wanted to check each packet, and cross-reference the source mac with the ARP table entry it would result in an additional lookup in the ARP table.

So, yes this is possible, but it would make traffic forwarding a bit slower.