Goblin Eaters Cyber Cavern

This week’s article concerns a traveller who reaches a walled city near midday. He crosses the open ground and walks to the merchant who keeps door eighty. He doesn’t need to knock because the door is open. He doesn’t give his name either, as no one asks for it. He says what he wants, a copy of a particular record, and the merchant hands it over across the threshold. The traveller turns and leaves. By the time he has reached the road again, the merchant has moved on to the next task and keeps busy with fulfillment. If the original traveller returns an hour later, he would return as a stranger. This isn’t rudeness; it’s because the merchant never needed to remember anyone. After all, in the days this door was cut, everyone who came to it was a neighbor, and a neighbor does not need to be remembered to be trusted. ...

In the earlier posts, we looked at how communities grew into towns and kingdoms, opening their gates to trade while trying to keep out spies, thieves, and those seeking to seize power. The gatehouse guard became our way of thinking about who a network lets in. But some information was available without passing through the gate at all. Imagine a notice board outside the walls. Residents could leave messages saying where they were, when they expected to return, or who could help in their absence. Anyone passing could read it. For someone trying to reach a friend or arrange a delivery, that was useful. ...

Imagine a small town where nobody locks their doors. Not because the locks don’t exist, but because nobody in living memory has needed one. That’s not a metaphor for carelessness. It’s a description of a community that has never included a thief. That was the early internet. ARPANET connected a small number of academic and government institutions who mostly knew each other, mostly trusted each other, and had no realistic expectation of an adversary showing up uninvited. Encryption existed, but it was computationally expensive and, for a long stretch, export-controlled. Building a cleartext protocol in 1978 wasn’t a mistake. It was a reasonable design choice for the network that actually existed at the time. The assumption of a trusted network was correct in 1983. It is catastrophic in 2026. This section is about three protocols that were built for that trusted network, and about why “the cleartext era” never fully ended, it just moved into the corners of infrastructure nobody looks at closely. ...

The kingdom’s roads do not concern us this week. We are not concerned with the portcullis guard, the distance between gate and gate, or the checkpoint captain squinting at addresses on a passing cart. All of that machinery exists to get a sealed letter from one place to another. This week the letter has already arrived, and it is on the desk of the person who receives it. The question is no longer how it traveled. The question is whether it can be trusted, and whether anyone read it, or altered it, along the way. ...

Floods, Amplification, and What Firewalls Actually Do Last week’s post closed with a thesis worth restating: TCP’s flags tell the truth about what a packet claims to be. They say nothing about whether the claim is legitimate. Let’s wander back to our medieval landscape to frame this discussion. In the kingdom’s early days, the gap between a message’s claim and its legitimacy rarely mattered. There was one castle (host), one gate (network connection), and a guard (TCP/IP Stack) who knew most travelers by sight and could respond to their requests. When a visitor requested to enter, the guard reserved a room for him on the spot, not because he’d earned it, but because there was little reason to withhold it. Bad faith was rare and was not seen as an operational risk. ...

The City, the Duke, and the Portcullis Picture a walled city. A Duke — the operating system — presides over it, though he governs less than it sounds like he might. Behind the city walls, tradespeople work their own shops: a baker, a blacksmith, an armourer, a stableman. Each is a service running on the host, reachable through its own door — a port. Visitors arrive from other cities looking to trade, and each has to pass the portcullis first, where a guard decides who gets through and who doesn’t. ...

In medieval Europe, if you wanted to make shoes, you joined the cobblers’ guild. Not because the guild made better shoes than you could make alone — though it might have. You joined because the guild controlled the knowledge of shoemaking, the supply of leather, the right to sell in the market square. The guild wasn’t just a craft association. It was an economic enclosure - you couldn’t compete with what you couldn’t learn. ...

They say that if you don’t learn from history, then you are destined to repeat it. This week I have a companion post to The Switch, the Spring, and the Spy. This is a tour through layer 2 history, and a look at how history has shaped today. In that post, we covered ARP, the trust model, and the Gateway Mechanism. This post will cover how Ethernet was conceived and how competitive technologies offered more robust mechanisms for data transfer but lost. I also want to look at how the technology was adjusted and augmented by new protocols that overcame the limitations once Ethernet was pushed to and past its limits. ...

Most subnetting tutorials hand you a mask and march you through the arithmetic. That teaches the mechanics but hides the thing people actually get stuck on — which isn’t the math at all. It’s a category error about what kind of question subnetting actually is. Here is the reframe this whole piece rests on: An address block has no subnetting until you give it one. 172.16.0.0/16 is not secretly eight /19s waiting to be uncovered. Before you commit a mask, the question “what are its subnets?” has no determinate answer. In subnetting terms, the block is under-determined, not undecidable. It’s like a loaf of bread. Whole, one unit. It needs exactly one more constraint to resolve to a subnet scheme — and that constraint does not live in the address math. It doesn’t live in how big the loaf or the slices are. The constraint comes from outside the address space: the network’s requirements. How many segments? How many sandwiches to make. How many hosts in the largest one? Those are the measurement. Bring them, and the block snaps into one determinate layout. The classic hang-up is treating an underdetermined problem as an intractable one — staring harder at the range of possible subnet masks, when the resolution was never going to come from the possibles. It comes from asking what the network needs. Keep that in mind and the arithmetic stops being intimidating, because you’re no longer searching a space — you’re applying a requirement. Everything below is a tool for applying it cleanly. ...

Architecture, security implications, and the competency gap the industry hasn’t closed. IPv6 is the second part of Layer 3. Last week we discussed IPv4, and the design assumptions that were made, and have led to many types of attacks due to the way the protocols work. This week, we’ll investigate IPv6 — the current version of the Internet Protocol, operating at Layer 3 of the OSI model. Back in the days of the early 1990’s it began to dawn on the industry that IPv4 was running out of steam. The two biggest challenges were the inefficient use of the class A, B, C (and D and E!!) address space, and the exploding capacity of router tables. They realized something needed to be done quickly, while deeper work began on a complete rework of IP. ...