In IPv4 ARP, why can any host on the same Ethernet segment overwrite another host's IP-to-MAC entry, and what does that let it do?
answer
- trust model of a shared wire
- no sender check at all
- update happens before opcode is read
- claim an IP, receive its frames
basics
~20 sARP carries no authentication, and RFC 826's receive algorithm overwrites an existing entry from any packet's sender fields before reading the opcode. Any host on the segment can therefore claim another's IP and draw its traffic.
solid answer
~40 sARP was designed in 1982 for a segment where every station is trusted: a packet carries sender and target hardware and protocol addresses and nothing that proves them. Under RFC 826's receive algorithm, if the receiver already holds an entry for the sender's IP, it replaces the stored MAC with the one in the packet, and only afterwards checks whether it is the target and which opcode arrived. A forged reply or request therefore rewrites a victim's entry for, say, the default gateway. Frames meant for that IP now go to the forger's MAC. RFC 5227 §5 says plainly that ARP-based mechanisms inherit this weakness.
go deeper
Recall that ARP maps IP to MAC on one segment and that nothing authenticates it, so any local host can claim another host's IP.
Explain RFC 826's receive order: merge sender fields into an existing entry first, check target and opcode afterwards, and why that makes forged packets effective.
Place the weakness in the threat model: it needs same-segment access, so segmentation and switch-side inspection, not host hardening, are the realistic controls.
Weigh retrofitting authentication to ARP against moving enforcement into the switch fabric, and who owns the binding data that enforcement depends on.
## What ARP actually trusts ARP maps an IPv4 address to a link-layer address on one segment. An ARP packet is carried directly in an Ethernet frame (EtherType 0x0806, decimal 2054 in RFC 1042) with hardware type 1 for Ethernet, opcode 1 for a request or 2 for a reply, and four address fields: sender hardware address, sender protocol address, target hardware address and target protocol address. Nothing in the packet is signed, keyed or tied to who is entitled to an IP address. A receiver believes the sender fields because the protocol was written for a LAN of cooperating machines. ## What RFC 826 tells a receiver to do The receive algorithm, simplified: 1. Check that the hardware type and protocol type are ones the host speaks. 2. If an entry for the pair (protocol type, sender protocol address) already exists, **overwrite its hardware address** with the packet's sender hardware address, and remember that a merge happened. 3. Only now ask whether the receiver is the target protocol address. If yes and no merge happened, **add** a new entry. 4. Only now look at the opcode. If it is a request and the receiver is the target, send a reply. The RFC even stresses that the sender's mapping is merged before the opcode is examined, on the assumption that communication is bidirectional, and that a new hardware address supersedes the old one. The two consequences that matter for security: - **Overwriting is unconditional.** The packet does not have to be a reply, and it does not have to answer anything the host asked. - **It can be unicast or broadcast.** A forged packet aimed at one victim is invisible to everyone else on the segment. ``` on ARP packet P arriving: if P.hardware_type or P.protocol_type not supported: drop merged = false if table has entry for P.sender_protocol_addr: entry.hardware_addr = P.sender_hardware_addr # no check merged = true if P.target_protocol_addr is one of my addresses: if not merged: table.add(P.sender_protocol_addr, P.sender_hardware_addr) if P.opcode == REQUEST: send REPLY unicast to P.sender_hardware_addr ``` Real implementations differ at the edges, for example in whether they accept an unsolicited reply for an address they hold no entry for, so treat the pseudocode as the RFC's baseline rather than any one operating system's behaviour. ## What a forged claim buys An attacker on the segment sends packets whose sender protocol address is the gateway's IP and whose sender hardware address is its own MAC. Hosts that process them now send frames for the gateway to the attacker. The attacker can then: - **Drop** the frames: a denial of service for that host's off-subnet traffic. - **Forward** them to the real gateway: a man-in-the-middle position, with the attacker reading or altering whatever is not protected end to end. - **Answer for a server's IP** itself, if the attacker would rather impersonate than relay. Encryption above IP changes what the attacker can read, not whether it can sit in the path. ## Why it is a local-segment problem ARP is not routed. A packet lives within one broadcast domain, so only hosts on the same VLAN or subnet can poison one another. That is why the attack is described as needing an internal foothold, and why segmentation limits how far it reaches. It is also IPv4-specific: IPv6 uses Neighbor Discovery, which has its own, separate, spoofing issues. ## Why the protocol stayed this way Adding authentication to ARP would need keys on every host and a distribution scheme, and the weakness was acceptable on 1980s shared Ethernet. Instead, defences moved into the network: a switch that checks ARP against known bindings, covered in other questions of this topic, and source-address validation as in RFC 7513. RFC 5227's security section notes that its address-conflict detection is based on ARP and so inherits the same weakness: a malicious host can answer every ARP Request with its own hardware address, claiming every address on the network. ## Interview summary State the mechanism in one line: *ARP is unauthenticated and updates caches from any packet, so a host on the segment can claim another's IP.* Then add the consequence: redirect, black-hole or relay that traffic. Do not claim it works across routers, and do not call it a bug in one vendor's stack: it is how the protocol is specified.
- Does the attacker need to answer a request, or can it send an ARP packet nobody asked for?It does not need a request. RFC 826 merges the sender fields into an existing entry before it looks at the opcode, so an unsolicited packet can rewrite an entry. Implementations differ on whether they accept unsolicited packets for addresses they hold no entry for, which is why attackers target addresses the host is actively using.
- Why does the attack not work from another subnet?An ARP packet is carried straight in an Ethernet frame with no IP header, and routers do not forward it. A packet therefore only ever reaches hosts on the same broadcast domain, so the attacker must be attached to the victim's own VLAN or subnet.
- Which security property is missing: confidentiality, integrity or authentication?Authentication, and with it integrity of the mapping. Nothing proves the sender owns the IP it claims, and nothing protects the packet from modification. Confidentiality is not the issue because ARP carries no secrets.
saying these in an interview costs you the question
- Says ARP spoofing works across routers from the internet
- Believes only ARP replies can change a cache entry
- Thinks a host must have sent a request before accepting a reply
- Calls it a flaw in one operating system rather than in ARP
- Says TLS stops the attacker from being in the traffic path