Dynamic ARP Inspection

fonque

I have a question that might have a lenghty setup.

I am confused by the following command
ip arp inspection validate {[src-mac] [dst-mac] [ip]} - used to configure additional checks on an arp packet.

However, for src-mac option, I cannot think of a scenario where you would need to compare the ethernet header source mad and the arp source hardware address, and make sure they match?
note: the closest to an answer I have come to, is I could not think of a situation where these 2 fields should ever not match.

Same for dst-mac, what would be a scenario where you would need to compare the ethernet header destination mac address with the arp destination hardware address?
Since, in a malicious or valid gratuitous arp, the destination hardware address is ignored.

for the ip option, why would a check for unusal ip addresses be needed?

The more I think about this (I even compared the ARP field with the Ethernet header fields and played a fill in the blank game) the more I dont understand why the additional checks would be needed. I cant help but come to the conclusion that comparing packets against the dhcp snooping binding table would be enough.

any insight would be greatly appreciated.

_maurice

bump...

I am also curious about this. I can not see an attack strategy that the 'validate' option defeats, as the source MAC address in the Ethernet header can be spoofed, to match the spoofed MAC address in the ARP request/reply. It seems to me that just having 'ip arp inspection' without 'validate' is enough.

-maurice

fonque

Thanks for the bump. I am going to run this question by some of our core engineers at work tomorrow if its not too busy.

dtlokee

Validation of the src-mac can cause issues with some server load balancing solutions as the arp reply for the virtual ip address is sourced from a different MAC address (the physical address) than the one in the payload (the virtual MAC) so there are cases where the MAC in the L2 header is different than the MAC in the arp reply. Validation will help protect a host that does not verify the origin of the arp reply and trusts the contents of the ARP reply. This can lead to a man in the middle attack where an attacker is redirecting the traffic to themself through arp posioning.

I can't really think of an instance where I would use dst-mac except where the ARP reply has been sent as a broadcast (FFFF.FFFF.FFFF) instead of unicast back to the host that sent the initial request.

I am sure there are other uses but I haven't run into them.