CYBER-03-002-P · Primer — Core Protocols and Their Built-In Weaknesses

The idea in one sentence

The protocols that move every packet on the internet were designed in an era of trusted networks, so most of them will believe whatever they're told — and an attacker's whole job is to find the field where that trust was never checked.

Why it exists

The core protocols — IP, TCP, UDP, ARP, ICMP — were written in the late 1970s and early 1980s for a small research network where every machine was run by someone you knew. The problem being solved back then was reliability, not security: how do you get a packet across an unreliable link, reassemble it in order, and recover when a router drops it? The designers spent their ingenuity making the network survive hardware failure, not making it survive a lying participant. There was no threat model, because on ARPANET there was barely a threat.

So the trust got baked in. IP will route a packet to whatever destination address it carries, and it will believe whatever source address the sender wrote — the field is never verified. TCP identifies a connection by a sequence number that, if you can guess it, lets you inject data as if you were the other endpoint. ARP hands out "who owns this IP?" answers with no proof of ownership. ICMP lets any host tell any other host "the network changed, please redirect." Every one of these was a reasonable convenience among trusted peers and a permanent liability the moment the network went global.

This matters because you can't patch away a design assumption. These protocols are the foundation the entire internet runs on; they can't simply be replaced. Instead, security got layered on top — TLS, IPsec, DNSSEC, 802.1X — precisely to compensate for trust the base layer never enforced. Understanding the built-in weaknesses is how you understand why all that extra machinery exists, and where it's still missing.

How it works

Walk up the stack and watch what each protocol checks — and what it just believes.

IP (RFC 791) — best-effort, unauthenticated delivery. IP's job is to carry a packet from a source address to a destination address across many hops. It makes no guarantee of delivery, order, or integrity, and — critically — it never verifies the source address. A host writes its own return address into the header, and routers forward based only on the destination. That's the root of IP spoofing: forge the source field and the reply (if there is one) goes somewhere else entirely. IP also fragments large packets and reassembles them at the destination, a mechanism that has historically been abused to slip past filters.

TCP (RFC 793) — a reliable stream built on top of unreliable IP. TCP adds what IP lacks: ordered, reliable, connection-oriented delivery. It opens with the three-way handshake — SYN, SYN-ACK, ACK — during which each side picks an Initial Sequence Number (ISN) used to order bytes and match acknowledgements. Two design consequences: first, the server allocates state on the first SYN, before the handshake completes, which is what a SYN flood exhausts. Second, if an attacker can predict the ISN, they can forge packets that TCP accepts as part of a legitimate connection (sequence-number prediction / injection) — which is why modern stacks randomize the ISN.

UDP (RFC 768) — connectionless, no handshake, no state. UDP is IP with just ports bolted on: send a datagram and hope. There's no handshake, so there's nothing proving the source address is real. That makes UDP the favorite carrier for reflection and amplification attacks: spoof the victim's address as the source, send a small query to a service (DNS, NTP) that answers with a much larger response, and the whole flood lands on the victim who never asked.

ARP (RFC 826) — mapping IP to hardware, on the honor system. Inside a local network, a host that knows a peer's IP still needs its MAC (hardware) address to actually send a frame. It broadcasts "who has 10.0.0.5?" and waits for a reply. ARP has no authentication: any host can answer, and receivers cache the reply. Send an unsolicited or forged reply — ARP spoofing / cache poisoning — and you convince the victim that your MAC owns the gateway's IP, quietly routing their traffic through you (a classic man-in-the-middle foothold).

ICMP (RFC 792) — the network's control channel. ICMP carries error and diagnostic messages: ping (echo request/reply), "destination unreachable," "time exceeded." One message type, ICMP Redirect, lets a router tell a host "use a better next hop for this destination." Since hosts historically accepted redirects with no authentication, a forged redirect could reroute a victim's traffic — another path to man-in-the-middle.

Cleartext vs authenticated protocols. Sitting above all this are the application protocols, and many of the originals sent everything — usernames, passwords, content — in cleartext: HTTP, FTP, Telnet, plain SMTP. Anyone positioned to read the traffic (via ARP spoofing, a shared Wi-Fi link, a tapped router) reads it all. The fix is an authenticated, encrypted layer — TLS (RFC 8446) is the modern one — which both encrypts the bytes and proves the server's identity via certificates, so an attacker can neither read the stream nor impersonate the far end. HTTPS, SFTP, and SSH are the trusted replacements for their cleartext ancestors.

The one gotcha

The whole stack trusts source and identity fields it never verifies — so "the packet says it's from X" is never proof it's from X. Beginners read a source IP in a log, an ARP reply, or an ICMP redirect and treat it as ground truth. It isn't. IP source addresses are attacker-writable, ARP replies are unauthenticated, ICMP control messages can be forged, and any cleartext protocol can be read and rewritten by whoever sits in the path. The single mental habit that protects you: for every field a protocol acts on, ask "who verified this, and how?" If the answer is "nobody" — which it usually is at the base layers — then a security control above that layer (TLS, IPsec, DNSSEC, 802.1X, dynamic ARP inspection) has to supply the verification the protocol never did. Attackers live exactly in the gap where you assumed a field was checked and it never was.

See it — where the built-in trust breaks

flowchart TD
    A["Sender writes the<br/>packet header"] --> B{"Which field does the<br/>attacker control?"}
    B -->|Source IP address| C["IP spoofing<br/>(RFC 791 never<br/>verifies source)"]
    B -->|ARP reply| D["Cache poisoning<br/>(RFC 826 has no<br/>authentication)"]
    B -->|ICMP redirect| E["Traffic rerouted<br/>(RFC 792 control<br/>msg is trusted)"]
    B -->|Cleartext payload| F["Read and rewritten<br/>(HTTP / FTP / Telnet<br/>have no crypto)"]
    C --> G["Fix above the layer:<br/>TLS, IPsec, DNSSEC,<br/>802.1X, filtering"]
    D --> G
    E --> G
    F --> G

The one-line takeaway

The core protocols believe whatever a packet claims about its source and identity — so real security lives in the authenticated layers you add on top to check what the base layer never did.

Where you'll meet it

You'll meet this the first time you open a packet capture in Wireshark and realize you can see a plaintext password fly by on an HTTP or Telnet login — and then realize anyone on that network could see it too. You'll meet it running arpspoof or ettercap in a lab and watching a victim's traffic silently route through your machine. You'll meet it when a service gets knocked over by a UDP reflection flood and the "source" addresses in the logs turn out to be forged. In interviews, this is the bedrock: "why is HTTPS safer than HTTP?", "what is ARP spoofing and how do you defend against it?", "how does a SYN flood work?", "why can't you trust a source IP address?" The strong answer always names the specific trust the base protocol failed to enforce, and the authenticated layer — TLS, IPsec, DNSSEC, dynamic ARP inspection, ingress filtering — that was invented to enforce it.

Named concepts: IP/TCP/UDP behavior, ARP and ICMP, cleartext vs authenticated protocols, protocol design flaws