Claimed Names and Addresses

## What a host has to be told, and who tells it Nothing on a plain office VLAN is born knowing how to leave it. A machine that has just come up on a conference-room wall port knows only what it is handed. It asks the segment for configuration and takes, from the answer it gets, three things that matter: an address of its own, the address of a **default gateway** (where it sends anything not on the local segment), and the address of a **resolver** (what it asks to turn names into addresses). Having been told which address is the gateway, it still has to reach that address on the wire, so it asks the segment which hardware address owns it and uses whatever comes back. Two answers therefore decide where every packet the host sends actually goes. Neither is authenticated in any meaningful sense. There is no shared secret between a client and whatever answered its configuration request, no signature over the answer, no list of servers the client is willing to believe, and no verification that the machine replying on behalf of the gateway address is the gateway. The client applies a first-acceptable-answer rule and gets on with its work. That is not a bug anybody shipped; it is what makes plug-in-and-it-works possible. ## Why "we are fully patched" is not an answer The reflex when a network attack is described is to ask which version fixes it. Nothing does. There is no defect being triggered here - no memory corruption, no missing bounds check, no unauthenticated management endpoint. An attacker taking the first-hop position sends well-formed messages that every implementation on that segment is required to accept, and the hosts do exactly what their documentation says they will do. So there is no identifier to look up, no advisory to read and no patch level that changes the exposure. A fully current, hardened, signed-image fleet on a flat segment is exposed in precisely the same way as an unpatched one. This matters in interviews because it separates two categories a candidate must not conflate: **implementation vulnerabilities**, which are mistakes and get fixed, and **design trust**, which is a property of the environment and gets removed only by changing the environment - who is allowed to speak on the segment at all, and whether the hosts that matter share one. That structural answer is a separate subject; the point here is only that patching is not it. ## The adversary class this creates The interesting consequence is the kind of attacker it admits. Most intrusion stories start with a credential: somebody is phished, a password is reused, a token is stolen. This one starts with a cable. Consider a vendor engineer on site to service a badge controller. They have no directory account, cannot log in to anything, are not authorised to touch a server, and would fail every access check in the building - and they have a laptop and a live switch port in a room they were shown to. Physical standing, zero logical rights. That combination is enough, because the only prerequisite the position has is link-layer adjacency. The same is true of anyone else who gets a port: a contractor, a visitor left alone in a meeting room, a device plugged into a wall socket behind a plant. It is also true of a machine that was already compromised for other reasons, which now has adjacency for free. ## Why the flat mixed segment makes it worse Office VLANs are rarely just laptops. The same broadcast domain typically carries printers, badge readers, IP cameras and other fixed-function devices. Those endpoints have no ability to be sceptical: they take the configuration they are given, many of them never encrypt anything they send, and several authenticate nothing at either end. So the value of the position is not bounded by what the laptops are doing. The segment is only as trustworthy as its least controlled port, and a conference-room port is by definition available to people you did not vet. ## Two routes, priced differently There is more than one way to occupy the position - you can answer for the gateway's hardware address, or you can be the one who answers the configuration request in the first place. They are not equivalent: they hand over different things, cost different amounts to hold, and survive different events. Pricing them against each other is the real senior question here. But both start from the same place, and the thing to be able to say cleanly in an interview is that the starting cost is adjacency, and adjacency is not a vulnerability anyone can patch away.