Routing security: RPKI, IRR and BGP monitoring
An ISP, hosting provider or enterprise with its own address space and AS number is only as safe from hijacks and route leaks as its routing records and filters. Route Origin Authorizations (ROAs), accurate IRR objects, strict customer and peer filters and a watch on how the rest of the internet sees your prefixes all help. This group covers how our team sets those up and keeps them current.
What we do
- ROA planning and publishing
- Validator and RTR setup
- IRR object hygiene
- Prefix list generation
- Hijack and leak alerting
- Peer and customer filter design
- MANRS action checklist
- Hijack response runbook
Our team works with Krill to run a delegated RPKI certificate authority and publish ROAs, with Routinator, rpki-client and FORT as validators that feed routers over RTR (RFC 8210), with IRRd and bgpq4 to keep IRR objects accurate and build prefix lists, with BGPalerter, RIPEstat, RIPE RIS and RouteViews to watch announcements, and with PeeringDB records. We also work with the RIPE NCC and ARIN RPKI services and with the MANRS actions as a checklist.
This works alongside our routing and BGP, internet exchange and network detection groups, and links to our Managed IT and Cybersecurity services. Which registry services, contracts and filters apply depends on each network and its upstreams. These are tools our team has experience with, not partnerships, and not a statement that any tool prevents every hijack or leak.
Leading platforms we work with
- Krill
- Routinator
- rpki-client
- FORT validator
- IRRd
- bgpq4
- BGPalerter
- RIPEstat
- RIPE RIS
- RouteViews
- RIPE NCC RPKI
- ARIN RPKI
- MANRS
- bgp.tools
- Kentik
Platforms and practices
- ROA plan with max-length decisions
- Delegated RPKI CA for provider-independent space
- ROV policy: invalid, not-found and valid handling
- RTR session design and validator redundancy
- IRR route and route6 object clean-up
- as-set design and customer prefix filters
- Max-prefix and AS-path filter templates
- BGP role checks (RFC 9234) on supported software
- Hijack and leak alerting with a named contact
- Runbook for a suspected hijack
References
- Krill documentation (NLnet Labs)
- NLnet Labs: Routinator
- rpki-client
- FORT Project: RPKI validator
- IRRd documentation
- bgpq4 (GitHub)
- BGPalerter (GitHub)
- RIPEstat
- RIPE NCC: Routing Information Service (RIS)
- RouteViews
- RIPE NCC: RPKI
- ARIN: RPKI
- PeeringDB
- Internet Society: MANRS
- RFC 6480: An Infrastructure to Support Secure Internet Routing
- RFC 6811: BGP Prefix Origin Validation
- RFC 8210: The RPKI to Router Protocol, Version 1
- RFC 9582: A Profile for Route Origin Authorizations (ROAs)
- RFC 9234: Route Leak Prevention and Detection Using Roles
- RFC 7454: BGP Operations and Security
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
How we use Routing security: RPKI, IRR and BGP monitoring for clients
Managed IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreCloud Management
Cloud cost review and management, without compromising on quality or security.
Learn moreWhere this matters most
Frequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWho can publish ROAs for our address space?
The holder of the space in the registry. A ROA can only cover resources in your own resource certificate, so a network that received addresses from an upstream provider usually has to ask the provider to publish them. Check your registry's rules and your agreement. We help work out whose ROAs are needed and keep them current.
Should we use hosted RPKI or run our own Krill?
Hosted RPKI, where the registry runs the certificate authority and signs your ROAs, is the simplest and fits most regional networks. Running your own delegated authority with Krill gives more control, but you then operate it and keep it available and backed up. We compare the two against what your registry offers and how many prefixes you manage.
What do the validators and the RTR feed do?
A validator such as Routinator, rpki-client or FORT downloads and checks the signed objects, and your routers get the result from it over the RTR protocol. We run more than one validator, so validation keeps working if one fails, and set what the router does if the feed is lost.
How would we find out about a hijack or a route leak?
We set up monitoring of how the rest of the internet sees your prefixes, using tools such as BGPalerter with RIPEstat, RIPE RIS and RouteViews data, with alerts to a named contact and a written runbook for what to do. Monitoring shortens the time to notice, but no tool prevents every hijack or leak.