CYBER-03-001-P · Primer — The Network Stack as an Attack Surface

The idea in one sentence

Every network message is wrapped in labeled layers of headers on the way out and unwrapped on the way in, and each layer's label is a place where an attacker can lie, listen, or overwhelm — so the stack is also a map of where defenses have to sit.

Why it exists

When two computers talk, an enormous amount has to go right: signals on a wire, addresses to find the right machine, a reliable stream so nothing arrives scrambled, and finally an application that understands what the bytes mean. Trying to solve all of that in one tangled program would be impossible to build or reason about.

So the industry agreed to split the job into layers. The OSI model (ISO/IEC 7498-1) is the seven-layer teaching model: Physical, Data Link, Network, Transport, Session, Presentation, Application. The TCP/IP model (described in RFC 1122) is the four-layer model the real internet actually runs on: Link, Internet, Transport, Application. They map onto each other loosely — OSI is the vocabulary people use to point at a problem, TCP/IP is the plumbing that ships the packet.

For a defender, layering is a gift. It means a threat lives at a specific layer, and a defense can attach at that same layer. "Where does this attack happen, and where do I stop it?" becomes a question with a concrete answer instead of a shrug.

How it works

Data moves down the stack through encapsulation. Your application produces a chunk of data; each layer below wraps it in its own header — a small block of fields that says who this is for and how to handle it — before handing it down. On the receiving machine the process runs in reverse: each layer reads its header, strips it off, and passes the payload up.

Picture sending a letter. The letter is your data. You put it in an envelope with a street address (Transport: which port/application). You hand it to a courier who routes it city-to-city by postal code (Internet/Network: the IP address). The courier's truck drives a specific road (Link/Physical: the actual wire or radio). Every layer added its own addressing label without opening the layer above it.

Now map the threats to those same labels:

• Physical / Link (Layer 1–2): the wire and the local segment. Threats: cable tapping, rogue Wi-Fi access points, MAC address spoofing, ARP spoofing to redirect local traffic. Trust here is "am I even talking to the right nearby device?"
• Internet / Network (Layer 3 — IP, RFC 791): finding hosts across networks. Threats: IP address spoofing, routing manipulation, and reachability. Firewalls and access control lists (ACLs) filter here — they decide which addresses may reach which addresses.
• Transport (Layer 4 — TCP, RFC 793 / UDP): ports, sessions, reliable delivery. Threats: port scanning to find open doors, SYN floods that exhaust a server's half-open connection table, session hijacking. This is where "which service is listening?" gets probed.
• Application (Layer 7): where the data finally means something — HTTP, DNS, email. Threats: injection, malformed requests, credential abuse, and the flood of business-logic attacks. Most breaches ultimately land here because this is where humans and money are.

Encryption also attaches at a layer. TLS wraps the application data at the transport/session boundary, so someone tapping Layer 1 sees ciphertext, not your password. Knowing the layer tells you exactly what a given protection does and does not cover.

The one gotcha

A header field is only a claim, not a fact. "This packet is from 10.0.0.5" is just bytes an attacker can write themselves — that is all IP spoofing is. Layers below the one you trust can be forged.

The practical consequence: do not build a trust boundary out of a lower layer's address alone. A source IP address is a hint, not an identity; the network being "internal" is not the same as the caller being trusted. Real trust boundaries have to be enforced with something that can't be cheaply forged — a cryptographic handshake, an authenticated session, a verified certificate — usually at Transport (TLS) or Application layer. The classic mistake is a service that "trusts anything on the corporate LAN," which quietly turns one foothold into the whole network.

See it — a packet gains a header at each layer, and each header is a target

flowchart TB
  App["Application data<br/>(e.g. HTTP request)"]
  T["+ Transport header<br/>(TCP port, RFC 793)<br/>threat: SYN flood,<br/>port scan"]
  N["+ Internet header<br/>(IP address, RFC 791)<br/>threat: IP spoofing"]
  L["+ Link header<br/>(MAC address)<br/>threat: ARP spoof, tap"]
  Wire["On the wire<br/>as bits"]
  App --> T --> N --> L --> Wire
  Trust["Trust boundary must<br/>live at TLS / app auth,<br/>not at the IP address"]
  N -.forged claim.-> Trust

The one-line takeaway

Each network layer adds a header that both routes your data and exposes a distinct class of attack — so read the stack as a map: name the layer, name the threat, and put the defense at the same layer, never trusting a lower layer's address as proof of identity.

Where you'll meet it

You'll meet this the first time you read a firewall rule (Layer 3–4), configure TLS (Transport), debug why a service "works from the office but not the VPN" (a trust boundary drawn at the wrong layer), or read a packet capture in Wireshark and watch the headers peel off one layer at a time. It's also the backbone for reading threat frameworks like MITRE ATT&CK, where techniques cluster by exactly where in the stack they operate.

Named concepts: OSI vs TCP/IP model, layer-by-layer attack surface, encapsulation and headers, where trust boundaries live