Practical Notes on semicolony.dev

When a cloud provider, internet exchange, or transit carrier misconfigures their Border Gateway Protocol (BGP) filters, the entire internet can route traffic through a network never intended to handle it. A route leak occurs when an autonomous system accepts a route advertisement from one peer and incorrectly re-advertises it to another peer or transit provider. If your hosting environment or edge network handles its own Autonomous System Number (ASN) and public prefixes, deciding how to defend against these leaks comes down to three operational models: trusting your upstream transit providers, running local Resource Public Key Infrastructure (RPKI) Route Origin Validation, or maintaining strict automated prefix-list and AS-path filtering. At a hosting support desk, this problem shows up as sudden global packet loss where internal monitoring shows healthy hypervisors and idle gateway links, but external users hit timeouts. The traffic intended for your servers or outbound to your dependencies gets diverted to an unintended transit provider whose interfaces immediately saturate.

The Three Defenses

Handling BGP route leak risks involves choosing where validation logic runs and how much routing policy you manage in-house.

Option 1: Upstream-Managed Hygiene

You announce prefixes to upstream transit providers and rely entirely on the transit providers to filter bad routes, drop unauthenticated announcements, and prevent route leaks. You run basic BGP sessions without RPKI validators or custom route-maps.

Workload: Low-complexity single-homed or simple dual-homed networks without dedicated network engineers.
Budget: Zero added hardware, software, or monitoring overhead.
Skill Level: Beginner to junior support.
Risk: High. If your upstream provider accepts a leaked more-specific prefix from a third party, your outbound traffic heads into a black hole. If you accidentally leak a route yourself, your upstream might carry it globally if their ingress filters lag behind.

Option 2: Local RPKI Route Origin Validation (ROV)

You deploy a local RPKI validator (such as Routinator, StayRTR, or OctoRPKI) and connect edge routers (running BIRD, FRRouting, or hardware vendor NOS) to validate whether the origin AS on received prefixes matches cryptographic Route Origin Authorizations (ROAs).

Workload: Multi-homed networks operating edge border gateways that process full global tables or partial transit tables.
Budget: Minimal. A small virtual machine running a validator cache daemon alongside border routers.
Skill Level: Intermediate. Requires understanding BGP communities, RPKI states (Valid, Invalid, NotFound), and route-map evaluation.
Risk: Medium. Protects against origin hijacks and unauthorized origin leaks. Does not protect against path-shortening leaks where an unauthorized AS appears in the middle of the AS-path while the origin AS remains legitimate.

Option 3: Comprehensive Policy-Driven Filtering

You combine RPKI ROV with automated prefix filtering derived from Internet Routing Registry (IRR) data (using tools like bgpq4), strict maximum prefix limits (max-prefix), and AS-path filtering that enforces valley-free routing.

Workload: Autonomous systems hosting multi-tenant infrastructure, content networks, or hybrid cloud interconnects with both peering and transit links.
Budget: Moderate. Requires automated deployment pipelines to refresh route filters against PeeringDB and IRR databases daily.
Skill Level: Advanced. Requires scripting, continuous route health monitoring, and proactive alert triage.
Risk: Lowest. Drops both invalid origins and transit-to-transit announcement violations before routes reach the main routing table.

Comparing the Approaches

Criteria	Upstream-Managed	Local RPKI ROV	Comprehensive Policy Filtering
Hardware Overhead	None	Minimal (Validator cache)	Minimal to Moderate (Automation tools)
Configuration Complexity	Low	Moderate	High
Origin Leak Protection	Depends on carrier	Deterministic and local	Deterministic and local
Mid-Path Leak Protection	None	None	High (Via AS-path and valley-free rules)
Maintenance Overhead	Low	Low (Validator maintenance)	Ongoing (Filter updates, IRR tracking)

Choosing by Network Profile

If you run a small hosting setup with a single transit provider and a rented portable prefix, Option 1 is standard. Your primary responsibility is signing your own ROAs in your Regional Internet Registry (RIR) portal (such as APNIC, ARIN, or RIPE NCC) so the rest of the world can drop unauthorized announcements of your prefixes. Enforcing policies on incoming routes offers little benefit if you take only a default route from your provider. If you multi-home across two or more transit providers to achieve high availability, Option 2 is the operational baseline. Without local RPKI ROV, one upstream provider can accept a poisoned route for a popular external service (such as an object storage provider or payment gateway) and pass it to your router. Your edge router will gladly send your outbound application traffic through that degraded upstream path. Setting up local validation gives your routers the authority to discard RPKI Invalid states directly. For networks participating in internet exchanges (IXPs) or direct private network interconnects (PNIs), Option 3 is necessary. When you peer directly with other networks, you risk becoming an involuntary transit network if your edge router leaks routes learned from one peer to another transit provider. This violation of valley-free routing floods your border interfaces with global traffic. You can inspect how these policy mistakes occur in our look at accidental transit and valley-free routing.

Implementing RPKI ROV in Practice

For edge setups running Linux software routers, implementing Option 2 requires connecting the routing daemon to a local RTR (RPKI-to-Router) cache server. In BIRD 2, this involves configuring an RPKI protocol block and checking the route status within an import filter before accepting an announcement into the routing table.

TEXT

# Illustrative BIRD 2 configuration for RPKI validation
router id 192.0.2.1;

protocol rpki rtr_validator {
    rtr server 127.0.0.1 port 8282;
    refresh 600;
    retry 60;
    expire 7200;
}

filter bgp_in_filter {
    # Reject RPKI invalid prefixes immediately
    if roa_check(rtr_validator, net, bgp_path.last) = ROA_INVALID then {
        reject "RPKI check failed: invalid origin AS ", bgp_path.last, " for prefix ", net;
    }
    
    # Accept valid and unknown/not-found prefixes
    accept;
}

Rejecting ROA_INVALID ensures that routes carrying an origin AS not authorized by the prefix owner are dropped at the edge. However, prefixes marked ROA_UNKNOWN (NotFound) must typically be accepted unless you want to discard routes for the large portion of the internet that has not yet published ROAs. For deeper implementation steps on Linux gateways, review our guide on hardening Linux border routers with RPKI in BIRD. Defending against BGP route leaks does not require rewriting your entire infrastructure overnight. Start by signing ROAs for all assigned IP space at your registry. Next, if you receive full tables from upstreams, deploy a local validator and drop ROA_INVALID announcements. Add automated prefix lists and explicit peer filters only when operating an open peering policy or multi-homed BGP mesh.