An address-keyed allow rule in a fleet that recycles IPs hourly: what can an attacker inherit, and what does label-keying cost?

## Why an address is not an identity In a cloud virtual network, instances are replaced rather than repaired. Addresses are drawn from a pool and returned to it, and a re-addressing exercise — a new CIDR plan, a migration, a subnet split — is a routine Tuesday. Against that background, a segmentation rule that names addresses is making a claim it cannot check. A rule of the form `allow 10.0.3.17 -> 10.0.9.4:5432` asserts two things: that `10.0.3.17` is the reporting service, and that `10.0.9.4` is the ledger database. The fabric verifies neither. It verifies that a packet arrived carrying that source address; it has no idea what is behind the address today. ## The inheritance Destroy the reporting service and `10.0.3.17` goes back to the allocation pool. The next workload to receive that address inherits every rule that named it — database reachability on 5432, granted by nobody, crossing no boundary in a way that looks unusual to any sensor. Flow records will show a permitted conversation between two addresses that are allowed to converse. The adversary in this story does not have to be sophisticated. They need to *be*, or to control, whatever lands on a recycled address: a low-trust batch workload, a build runner, a service someone else already compromised. In an estate with autoscaling and short-lived instances, that allocation lottery runs several times an hour, and the attacker's cost is patience rather than skill. Note the direction of the claim carefully: the packet proves the *address* matched, never that the *workload* is the one the rule intended. ## The second failure, which people actually notice The first failure is silent; the second is loud, and it is what erodes the rule base. A replacement instance comes up on a different address, the flow breaks, someone under time pressure widens the rule from a /32 to the subnet — and then to a larger prefix when that also breaks. Address-keyed rule bases do not stay tight under churn; they drift toward the flat network the segmentation was built to prevent. That is why "nobody dares delete a rule" and "there are four thousand rules" are the same story told twice. ## What label-keying actually changes Attribute-keyed policy expresses the rule over what a workload *is*: `tier=web may reach tier=db on 5432`. Enforcement lives in the platform dataplane, which resolves the attribute to whatever set of workloads carries it right now. Re-addressing then changes nothing in the rule set, because no rule in it mentions a number. That is the whole point of the design: what survives renumbering is a rule that never named an address. Two things do **not** change, and a strong candidate says both: | Still address-based | Now label-based | |---|---| | Delivery: routing, forwarding, anti-spoofing at the edge, source filtering (BCP38-style), uRPF checks | Admission: which workload may talk to which, on what port | Labels decide who is allowed; addresses still decide where the packet goes. Dropping address-based anti-spoofing because "we use labels now" is a real mistake — the two controls answer different questions. ## The price: issuance becomes a control you operate A label is an assertion, and an assertion has a writer. Permission to set `tier=web` is permission to be reachable as a web tier, which makes it a firewall change wearing different clothes. Holding that honestly costs you: - a *restricted set* of security-significant labels, separated from the free-form tags teams use for cost reporting; - a write path that is the deployment pipeline rather than the workload's own runtime credential; - an audit record for every write, naming the principal that made it; - a reconciliation that compares the labels workloads claim against what the deployment record says was launched, because drift is normal rather than exceptional; - an owner, a queue of exceptions, and someone who answers when the issuance path is down at 3am. You have not deleted the problem. You have exchanged a stale-address problem, which nobody owns and which degrades quietly, for an identity-issuance problem, which has an owner and a bill. That exchange is usually worth making in an estate with hourly churn, and saying so — with the cost named — is the answer an interviewer is listening for. ## Answering it in an interview Say both halves. Churn makes address-keyed rules dangerous (a recycled address inherits a grant) *and* loose (widening is the fastest fix when a replacement breaks). Labels remove both effects and hand you an issuance service to run. A candidate who describes only the renumbering convenience has described a maintenance win; a candidate who names the inherited grant and the new control has described a security decision.