Routing on trust: how the internet’s paths are decided

1989 and 2006The protocol that decides where traffic goes

Networks tell their neighbours which ranges of addresses they can reach. Neighbours pass those announcements on, adding themselves to the path, and every network chooses among the routes it hears.

Nothing verifies that an announcing network has any right to the addresses it is announcing. The protocol was designed by people who knew each other, for organisations that knew each other, and the assumption is not written down anywhere because at the time it did not need to be.

What that permits

Any participant can announce any range. If the announcement is more specific than the legitimate one, it is preferred by the ordinary rules of route selection, and traffic for those addresses arrives at the announcer instead of the owner.

The traffic can then be discarded, which takes the service off the network, or examined and forwarded, which does not.

2008The canonical accident

An operator attempting to block a video service inside its own country announced a more specific route for that service's addresses. The announcement escaped to a neighbour and propagated, and the service became unreachable from much of the world for a couple of hours.

Nobody was attacking anything. A local policy became a global outage because the mechanism for expressing local policy is the same mechanism that expresses global reachability, and no participant can distinguish them.

Why it has not been fixed

There is no authority that can require anything. Each network is independently operated, and any verification scheme is deployed one network at a time by organisations that gain little from deploying it.

That is the shape of the difficulty: the benefit of checking accrues mainly to whoever is being impersonated, and the cost falls on whoever does the checking. A partially deployed scheme protects partially, which weakens the case for being early.

2010s onwardsWhat has been deployed

A system of signed statements, published by address holders, saying which network is authorised to announce each range. Networks that check them can discard announcements that contradict.

Adoption has become substantial among large operators, and it addresses the commonest failure, which is a wrong origin. It says nothing about the rest of the path, so an announcement with a correct origin and a fabricated route through it still passes.

The part that is specified and unused

A scheme for signing the whole path exists and is essentially undeployed. The reasons given are the cost of signature verification at line rate, the difficulty of incremental deployment, and the fact that it only helps where both ends and everyone between have adopted it.

Which is the same objection that appears in the part of this document about designs that require coordinated adoption, arriving here in the form of an operational cost rather than a philosophical one.

present dayWhat operators do instead

Filtering by what a customer is known to hold, monitoring for unexpected announcements about one's own addresses, and a set of voluntary norms with public commitments attached.

These are social and procedural remedies for a protocol problem, they work reasonably well, and they work because the community of operators is still small enough to have norms, which is the original assumption reappearing as a mitigation.

Why route selection prefers the specific

The preference that makes the failure work is not a defect. A more specific announcement is preferred because that is how a network delegates part of its own space to somebody else, which is an essential and constant operation.

So the mechanism cannot be removed. It is the same instrument used for ordinary delegation and for accidental hijack, and only context distinguishes them.

present dayHow wrong announcements are noticed

Mostly by watching. Several projects collect announcements from many vantage points continuously and alert address holders when something unexpected appears, which is detection rather than prevention and usually takes minutes.

Minutes is enough time to intercept a great deal of traffic, and it is also the difference between an incident that is noticed and one that is not.

present dayThe layer above inherits all of it

Certificates bind a name to a key, and the check that the name belongs to whoever asked for the certificate is frequently performed by contacting the name over the network, which is the layer this entry is about.

Which means a sufficiently well-placed announcement can obtain a genuine certificate for somebody else's name. That path has been demonstrated, and the mitigations are, once again, watching and publishing what was issued rather than preventing it.

Why it is worth understanding even if you never touch it

Because it is the clearest large example of a system that runs on assumed trust and cannot be repaired centrally, and because everything above it inherits the property.

Certificate validation, name resolution and every protocol that assumes traffic reaches the machine it was addressed to are resting on a layer where that is a convention rather than a guarantee.

What we cannot verify

The protocol specifications and the deployment measurements are public. Accounts of individual incidents come from operator reports and from analyses by monitoring projects, and the intent behind any particular announcement is usually inferred rather than established. Deployment figures move continuously and any number quoted here would be stale.