RIPE Is Teaching Route Leak Prevention Now. Here Is Why It Matters.
RIPE Is Teaching Route Leak Prevention Now. Here Is Why It Matters.
The RIPE NCC's BGP Routing Security course now carries theory on Route Leak Prevention and Detection based on RFC 9234, along with a hands-on lab on setting up BGP Roles and exploring Only-To-Customer. 1
When the RIR puts something in its standard curriculum, it has moved from an experimental proposal toward recommended operational practice.
The gap RPKI leaves
We wrote last week about where RPKI stops. The headline limit bears repeating: RPKI doesn't eliminate route leaks.
A route leak isn't a forged origin. The origin is legitimate and the ROA validates perfectly. The problem is propagation. A network receives a route from one peer or upstream and re-announces it to another, where it had no business going. Suddenly a small regional network is advertising itself as a path to large parts of the internet, and traffic follows, because BGP believes what it's told.
Historically, route leaks have caused some of the largest global routing incidents on record, and they're almost always accidents: a missing filter, a policy applied to the wrong session, a template copied between neighbours.
RPKI can't see any of this, because every announcement in the chain has a valid origin.
Roles and OTC, briefly
RFC 9234 takes the thing everyone already knows informally, that this session is with a customer, that one is with an upstream, that one is a peer, and makes it explicit in the protocol. 2
You configure a Role on each eBGP session: provider, customer, route server, route server client, or peer. The Role capability is exchanged in the OPEN message, allowing both sides to confirm the relationship and reject incompatible configurations. Once the roles are known, the Only-To-Customer attribute, an optional transitive path attribute, lets routers mark and detect announcements that have travelled somewhere the business relationship doesn't permit. 2
The elegance is that it adds a protocol-level check to what has always been a filtering problem. Traditional leak prevention means maintaining accurate prefix filters for every neighbour, which is enormous, error-prone and permanently out of date. Roles and OTC let compliant routers detect many leaks structurally, from the relationship itself, reducing dependence on neighbour-specific prefix filters.
Reducing, not replacing. RFC 9234 sits alongside your existing controls rather than retiring them, so you still want IRR-based filtering, RPKI origin validation, max-prefix limits and bogon filtering. What it removes is the assumption that those filters are the only thing standing between a mistyped policy and a leak.
It's also relatively easy to deploy: a few lines per session in BIRD, FRR or JunOS, and it degrades gracefully when the other end doesn't support it.
Control we hand to customers
We operate AS210464, and our position is that a customer should be able to control their own routing without opening a ticket.
That starts with RPKI validation on the routes we accept, which is origin validation as the floor. It extends to a full BGP community set that gives you leak-shaped controls directly in your own announcements: do not announce to a specific AS, to customers, to direct peers, to IXP peers, to route servers, or to upstreams, plus regional controls, prepending from one to three times, local-preference for backup routes, and remote-triggered blackholing when you need a prefix dropped at our edge instead of at your server.
That community set exists because scope control should be your decision, expressed in the announcement itself, rather than a filter someone at our end maintains by hand and eventually gets wrong.
BGP sessions start at €5/mo. Every VM comes with a routed /48 of IPv6; if you need space to announce rather than simply to use, you bring your own or lease it from us. Sessions peer against local gateway addresses, 10.0.0.1 and fd10::1, with multihop enabled on your side at TTL 255, and you can verify what our routers actually see through the looking glass from Tirana, Skopje, Amsterdam or Dublin, with no account and no sales call.
Three things worth an afternoon
If you run BGP, start by setting roles on your eBGP sessions, beginning with your upstreams, where a leak does the most damage.
Audit your ROAs while you're in there. Operational mistakes such as stale ROAs and over-generous maxLength values remain among the most common causes of RPKI-invalid announcements, so the most likely routing incident in your future is still one you cause.
And take the RIPE course if you're in the region. The labs are the fastest way to get comfortable with roles and OTC.
Route leaks remain one of the few internet failure modes where a single misconfigured session can degrade service for networks that have never heard of you. The fix is now standardised, taught, and cheap. There isn't much of an excuse left.