On an IPv4 Ethernet segment, which ARP-level observations point to cache poisoning, and why is each one only a hint rather than proof?

## What a defender can see Detection works by comparing ARP traffic and caches against what should be stable. The sources are host ARP caches, a passive monitor on a mirrored port or the switch itself, and log lines from hosts that notice a conflict. ## The signals 1. **A stable address changes owner.** The default gateway is the best canary. If a monitor keeps an IP-to-MAC pairing table and the gateway's IP shows a second MAC, or alternates between two, someone is contesting it. The alternation is the tell: the attacker repeats its claim and the genuine host's traffic keeps restoring the truth. 2. **One MAC claiming many IPs.** A forged-reply campaign, or an attacker answering broadly, makes a single MAC appear as the sender for several addresses. 3. **Unsolicited replies.** ARP replies that do not follow a request the target sent, especially unicast to one host, at a steady rate. 4. **Conflict reports from the genuine host.** RFC 5227 §2.4 says that when a host receives an ARP packet, request or reply, whose sender IP is its own address and whose sender hardware address is not its own, that is a *conflicting ARP packet*. A host wishing to provide reliable operation MUST respond in one of three defined ways, and hosts that defend or give up usually log it. This only fires when the forged claim is seen by the real owner, so it appears for broadcast claims, not for a packet aimed solely at another victim. 5. **Path symptoms.** A forwarding attacker adds one Layer 3 hop, visible as a TTL one lower or an extra hop on a classic traceroute, and flows may show added latency or sudden resets. ## Why every signal is only a hint | Signal | Legitimate lookalike | |---|---| | Gateway IP changes MAC | Failover of a virtual IP to a standby, announced by an unsolicited ARP; a replaced router | | One MAC, many IPs | A router doing proxy ARP; a host or load balancer owning several addresses | | Unsolicited replies | Gratuitous announcements after a NIC swap or address change | | Conflict report | Genuine duplicate address after misconfiguration | The two lookalikes that bite most are failover announcements and proxy ARP, each owned by its own topic, so a detector must be told which addresses are expected to move or to be shared. A well-tuned monitor alerts on **a change to a stable binding it was told to expect not to change**, not on any single packet. ## Detection is late by construction When you see the flip, the poisoned entry already exists. Detection therefore supports response, such as locating the port by MAC and isolating it, but prevention comes from validating ARP before it reaches hosts, as with the switch-side checks in the next question. RFC 5227 also notes that its conflict machinery turns a silent failure into a visible one: the same visibility is what helps here. ## Operating it sensibly - Record expected bindings for gateways and critical servers and alert only on deviation. - Keep change records so a failover or NIC replacement explains itself. - Rate-limit and aggregate alerts; a loop of conflicting hosts is noisy by nature. - Act on the port, not the IP: the attacker's MAC and switch port are what you can contain. ## Interview summary Lead with the gateway-MAC flip and unsolicited replies, name the legitimate twins (failover, proxy ARP, NIC change), and say that detection confirms an attack that has already happened.