In ARP cache poisoning for a man-in-the-middle position, why must the attacker poison both the victim's entry for the gateway and the gateway's entry for the victim?
answer
- frames flow in two directions
- each side keeps its own table
- one-way claim sees half the conversation
- relaying versus dropping
basics
~20 sEach host resolves MACs from its own cache. Forging only the victim's entry diverts outbound frames while the gateway's replies still go straight back, so the attacker sees half the conversation; both entries must name the attacker's MAC.
solid answer
~40 sA host sends frames to whatever MAC its own cache holds. If the attacker only convinces the victim that the gateway is at the attacker's MAC, the victim's outbound frames arrive there, but the gateway still has the victim's genuine MAC and its replies bypass the attacker. To intercept both directions, the attacker also claims the victim's IP in the gateway's cache. It then has to forward what it receives to the real destination's MAC. If it does not forward, both sides lose connectivity, which is a denial of service rather than interception. Because entries age or get corrected by genuine ARP traffic, the claims must be repeated.
go deeper
Know that ARP poisoning redirects a host's frames to the attacker and that the attacker must pass them on to avoid breaking the connection.
Explain that each side's cache is independent, so a full man-in-the-middle needs both entries forged plus forwarding, while no forwarding gives a black hole.
Describe the traffic effects you would see, such as an extra hop and refresh bursts, and what encryption still leaves exposed to a path attacker.
Weigh how much to invest against a same-segment attacker versus reducing what a path position yields, through end-to-end encryption and smaller broadcast domains.
## The setup, with documentation addresses A segment 192.0.2.0/24 has a victim host at 192.0.2.10, a default gateway at 192.0.2.1 and an attacker on the same VLAN. The MACs are drawn from the documentation block that RFC 9542 reserves, 00-00-5E-00-53-00 to 00-00-5E-00-53-FF. | Host | IP | MAC | |---|---|---| | Victim | 192.0.2.10 | 00-00-5E-00-53-0A | | Gateway | 192.0.2.1 | 00-00-5E-00-53-FE | | Attacker | 192.0.2.66 | 00-00-5E-00-53-66 | ## Why the two entries are independent Every host keeps its own cache and uses only that cache to choose a destination MAC. So there are two decisions to subvert: 1. **Victim to gateway.** Destination IP is off-subnet, so the victim frames the packet to the MAC it holds for 192.0.2.1. If that is 00-00-5E-00-53-66, the Ethernet frame is switched to the attacker's port. 2. **Gateway to victim.** The gateway frames replies to the MAC it holds for 192.0.2.10. If that is still the genuine MAC, replies go to the victim directly and the attacker never sees them. Poisoning one entry gives the attacker a one-way view: every request, none of the responses. Poisoning both gives a full view of the conversation. ## What the attacker must also do - **Forward.** The IP packets keep their real destination IP; only the Ethernet destination was wrong. The attacker has to pass each one on, addressed to the true next-hop MAC, or the flow dies. - **Re-assert the claims.** Entries age out and are corrected when the genuine host's own ARP traffic arrives, so the forged packets must be repeated. The interval depends on the target's cache lifetime, an implementation choice, not an RFC value. - **Accept a visible side effect.** An IPv4 router decrements TTL; a forwarding attacker is an extra Layer 3 hop in what should be a one-hop path. ## Interception versus denial of service | Attacker behaviour | Effect for victim and gateway | |---|---| | Poison both, forward everything | Traffic works, attacker reads or alters it | | Poison both, forward nothing | Black hole: both directions fail | | Poison one direction only | Half-view for the attacker, traffic still works | | Selectively drop or modify | Targeted disruption or injection | A switch does not rescue the victim. The attacker's MAC is a known, learned address, so the switch unicasts the frames to its port. Flooding applies only to unknown destination MACs. ## What encryption changes TLS above the TCP connection stops the attacker from reading or silently altering the payload, a subject covered by the transport-security topics. It does not stop the attacker from sitting in the path, seeing which hosts talk to which, dropping traffic, or reading anything unencrypted such as DNS queries sent in clear. ## Interview summary Say that **each host's cache decides its own frames**, so a man in the middle needs both caches wrong and needs to forward; one cache gives half the traffic; no forwarding gives a black hole. Then name the defence at the right layer: validate ARP at the switch against known bindings, rather than trusting what arrives.
- What does the attacker's host have to do besides sending forged ARP packets?It must forward the redirected IP packets onward, addressed to the real next-hop MAC. Without forwarding, both sides see a black hole. With forwarding, it also appears as one extra router hop, because forwarding decrements the IPv4 TTL.
- Why does the attacker keep sending forged packets instead of one?Cache entries age and are corrected whenever the genuine host's own ARP traffic arrives. Lifetimes are an implementation choice, not set by RFC 826, so the attacker repeats its claims often enough to keep both entries wrong.
A forged mail-room clerk who tells the sender's office he is the recipient and the recipient's office he is the sender: only with both lies does every letter and every reply pass through his hands, and only if he re-posts them does anyone get their mail.
saying these in an interview costs you the question
- Thinks poisoning only the victim gives full interception
- Believes the switch will flood frames to the real gateway anyway
- Says the attacker does not need to forward packets to stay hidden
- Treats man-in-the-middle and denial of service as the same outcome
- Claims HTTPS makes the attacker's path position useless