BGP Security: Prefix Filtering, RPKI and Route Origin Validation

BGP was designed among a small number of cooperating operators who knew each other, and it kept that trust model as the internet grew to a hundred thousand autonomous systems. A network announcing a prefix is generally believed, and everything below is the retrofitted machinery for deciding when not to believe it. The protocol itself is covered under autonomous systems and BGP.

The two failure modes

Prefix hijacking is announcing address space you do not hold. Traffic destined for that space arrives at you instead, which allows interception, redirection or simply a blackhole. Announcing a more specific prefix wins over a less specific one regardless of path length or policy, which is what makes the attack reliable — a /24 beats the legitimate holder's /16 everywhere.

Route leaks are a policy failure rather than a forgery. A network advertises routes it should not — typically announcing one peer's routes to a provider — and briefly becomes transit for traffic far exceeding what it can carry. Nothing is forged; the announcements are genuine and sent to the wrong parties.

Both happen accidentally far more often than deliberately, usually through a filter that was removed for troubleshooting or a summarization typo. The accidental and malicious versions look identical for the first few minutes, which is a large part of the difficulty.

Prefix filtering

The oldest control and still the most important. A provider accepts from each customer only the prefixes that customer is registered to announce, and rejects everything else.

The registration data comes from internet routing registries, where operators publish which prefixes and which origin autonomous systems are legitimate. A provider builds filters from that data, usually automatically and regularly.

The weaknesses are data quality — registry entries go stale and some registries have historically accepted entries without verification — and coverage, since filtering is effective at the customer edge and impractical at a large peering boundary where the prefix count is enormous.

Maximum prefix limits are the blunt companion: if a peer suddenly announces far more prefixes than expected, tear the session down rather than accepting them. It converts a catastrophic leak into a localized outage, which is the right trade.

RPKI and route origin validation

The cryptographic layer, and the current answer.

Resource Public Key Infrastructure lets an address holder publish a signed statement — a Route Origin Authorization — declaring which autonomous system may originate their prefix and up to what length. The signature chains to the regional registry that allocated the space, so it is verifiable.

A router performing route origin validation checks each announcement against these and classifies it as valid (an ROA exists and matches), invalid (an ROA exists and the origin or length does not match), or not found (no ROA covers it). Policy then drops invalid routes and accepts the rest.

Adoption has grown substantially and is not universal, so "not found" remains common and cannot be treated as invalid without losing reachability to a large part of the internet.

The critical limitation, and the exam point: RPKI validates the origin, not the path. It proves that the announced autonomous system is authorized to originate that prefix. It does not prove that the AS path is genuine, so an attacker who prepends the legitimate origin to a forged path still passes validation. Path validation is a separate and much harder problem with limited deployment.

Session-level protection

Distinct from route validation and worth knowing. BGP sessions run over TCP, so they can be attacked directly: a reset tears down the session and withdraws every route learned over it. Forging that reset requires spoofing the peer’s source address, which packet crafting makes straightforward for anyone on a network without egress filtering.

Protections: authenticate the session, restrict which addresses may connect, and use a mechanism that checks the packet's time-to-live so only a directly connected peer can reach the port — a spoofed packet from further away arrives with a lower value and is discarded.

Detecting problems

Monitor your own prefixes from outside. Public route collectors and monitoring services show what the internet believes about your address space, and an announcement of your prefixes by an autonomous system that is not yours is immediately visible — frequently before anyone internal notices anything wrong.

Alert on it, because response is a phone call to upstream providers and to the offending network, and minutes matter. Have those contacts recorded somewhere reachable, which is the same preparedness argument as under DDoS mitigation — and BGP is the mechanism both problems are resolved through.

Note also that a hijack of the right prefix can intercept certificate validation traffic, which is one reason certificate authorities perform domain validation from multiple network vantage points.

Exam angles

Know that BGP accepts announcements on trust, making prefix hijacking and route leaks possible, and that a more specific prefix always wins. Name prefix filtering from routing registry data and maximum prefix limits as the traditional controls. Know RPKI as publishing signed Route Origin Authorizations and route origin validation as classifying routes valid, invalid or not found — and that it validates the origin only, not the AS path.