Security · 12 Aug 2026 · 6 min read
RPKI and BGP security on a national backbone
Prefix-lists and MD5 are table stakes. Here is how we enforce RPKI-based origin validation across upstream peering without breaking legitimate traffic.
A misconfigured BGP policy is a security event. That is not a slogan — it is how I run a national IIG/ISP backbone.
When you carry downstream ISP traffic to the global internet, every peering session is a trust boundary. Prefix-lists, max-prefix limits, and MD5 authentication stop the obvious accidents. They do not stop origin hijacks.
What we actually enforce
Across upstream sessions we treat RPKI as part of the routing standard, not an optional lab feature:
- Origin validation on accepted prefixes
- Explicit reject policy for invalids, with a documented exception process
- Prefix-lists and max-prefix as a second fence, never the only fence
- Session authentication and logging so a policy change is auditable
Why operators skip this
RPKI looks expensive until the first incident. Invalids are noisy. A legitimate customer prefix can fail ROA hygiene. Teams delay enforcement because they fear a false drop more than a hijack they have not yet seen.
The fix is operational, not philosophical: start in monitor mode, publish a weekly invalids report, and only then flip to drop. Mentoring the team on how to read a ROA is as important as the knob on the MX.
What I would tell another backbone team
Do not split "routing" and "security" across two groups if they never sit in the same change window. The engineer who writes the BGP policy should also own the RPKI outcome. That is how you keep a national backbone both reachable and honest.
