BGP Route Leak Prevention: A Practical Guide to RPKI and IRR

In March 2025, a Tier-2 ISP in South-East Asia accidentally leaked 13,000 prefixes from a transit customer, causing a 40-minute routing blackhole for traffic destined to three European IXPs. The root cause? A missing max-prefix limit and no RPKI validation.

Understanding Route Origin Validation (ROV)

RPKI allows prefix holders to cryptographically sign Route Origin Authorisations (ROAs) that bind a prefix to an authorised origin ASN. Validators fetch these ROAs and feed the results to your routers via RTR protocol.

Deployment Checklist

1. Deploy a local RPKI validator (Routinator, Fort, or rpki-client)
2. Configure RTR sessions from your route servers and edge routers
3. Set policy: Invalid → Reject, Valid → Prefer, Unknown → Accept (initially)
4. Create ROAs for all your announced prefixes in your RIR's RPKI portal
5. Register route objects in RIPE IRR / RADB for legacy filtering compatibility

Junos Configuration Example

routing-options {
    validation {
        group rpki-validators {
            session 10.0.0.100 {
                port 8323;
            }
        }
    }
}
policy-options {
    policy-statement reject-rpki-invalid {
        term invalid {
            from validation-database invalid;
            then reject;
        }
    }
}

Deploying RPKI ROV is no longer optional — it's a baseline hygiene requirement for any network that peers at an IXP or provides transit.