ARP poisoning, end to end
The protocol detail: ARP requests and replies are unauthenticated UDP-style broadcasts on the local segment. The kernel updates its ARP cache from any reply it sees, even one it did not solicit (gratuitous ARP).
An attacker on the LAN runs something like Ettercap or arpspoof. The tool:
- Sends gratuitous ARP replies to every host on the segment, claiming the attacker's MAC for the gateway's IP.
- Sends another gratuitous ARP to the gateway, claiming the attacker's MAC for each victim host's IP.
- Enables IP forwarding on the attacker's host so the bidirectional flow continues uninterrupted.
- Now the attacker sees every byte of every flow that crossed the gateway, and can inject or rewrite at will.
End-to-end TLS limits what the attacker reads to metadata, but does not prevent the position itself. From there, the attacker can do downgrade attacks on plaintext protocols, inject into unauthenticated DNS, and replay anything that lacks freshness.
Kaminsky's DNS poisoning
Before 2008, DNS resolvers used a fixed source port and a 16-bit transaction ID. To poison a cache, an attacker had to win a race: respond to a recursive resolver's query before the legitimate authoritative server, with the right TXID guessed out of 65,536 possibilities.
Kaminsky's insight: query for nonexistent subdomains. Each new query (aaaa.example.com, aaab.example.com, ...) generates a fresh outstanding lookup. The attacker can guess and resend at line rate; each attempt is independent. With this technique, full cache poisoning takes seconds, not days.
Emergency patches in 2008 added randomized source ports, giving an extra ~16 bits of entropy. Full long-term defense is DNSSEC (signed records), which adoption is patchy but improving. DoH/DoT encrypts the query, partially mitigates by hiding the in-flight query, but does not authenticate the records themselves.
TCP sequence-number injection
If an attacker is off-path (cannot see the actual TCP stream) but can guess the four-tuple (src IP, src port, dst IP, dst port) plus the current sequence number, they can inject packets that appear legitimate. The injected packet's sequence number must fall within the receive window.
Modern TCP implementations use cryptographically random initial sequence numbers, which makes prediction infeasible. But other side channels still exist: leaking the sequence number through ICMP errors, or exploiting bugs that reveal it. Watch for the OS bulletin if your kernel's TCP stack gets patched.
BGP hijacks: the global version
An attacker who runs an AS (or compromises one) can announce a prefix they do not own. Neighbours that lack RPKI validation propagate it. The hijacker is then on-path for some or all of the traffic to that prefix.
Variants:
- Prefix hijack: announce a more-specific (e.g., /24) of someone's /22. Longest-prefix match wins; their traffic flows to you.
- Path manipulation: announce the prefix with a shorter AS path than the legitimate origin, drawing traffic to your AS.
- Route leak: an AS that should not propagate a route (e.g., a customer leaking provider routes back upward) inadvertently becomes the preferred path for a region.
The defense in production today: publish ROAs for every prefix you originate, monitor with BGP route monitoring services, and have an emergency contact list of upstream providers ready when something goes wrong. RPKI Origin Validation rejects unsigned or mismatched announcements at participating networks but leaves a long tail unprotected.
The defense pattern is the same
Across all four attacks (ARP, DNS, TCP, BGP), the defense pattern is identical: do not trust the network layer; authenticate end-to-end. TLS makes the ARP or BGP attacker mostly useless. DNSSEC makes the DNS poisoner mostly useless. End-to-end encryption with strong identity is what closes the gap that the network layer leaves open.