A regional ISP signs its routes with RPKI ROAs and starts dropping invalid routes with route-origin validation, without breaking a customer
A regional fiber and fixed-wireless internet provider in the Southeast with about 18,000 subscribers and a small network operations team, a leader in its segment.
- Scale
- 1 autonomous system, 6 IPv4 prefixes and 1 IPv6 /32, 23 ROAs, 2 transit providers, 1 internet exchange, 2 edge routers, 2 validators
- Engagement
- A 3-week inventory and ROA design, a 4-week monitoring period, then a staged rollout of validation over 6 weeks
The challenge
A customer's prefix was briefly originated by an unrelated network, and a transit provider's customer announced one of the ISP's own /24s for about twenty minutes. Nobody at the ISP knew until subscribers called. The ISP's address blocks had no signed routing authorizations, so no one on the internet could prove which network was allowed to originate them, and the ISP accepted every route its neighbors sent. The team wanted both sides done: sign its own routes, and stop accepting routes that fail validation.
What our team delivered
- An address inventory that matched the registry records, the routes the ISP really announces and the customers who use its space. It found two /24s leased to business customers who announce them from their own autonomous system, and one old /22 announced by the ISP but registered to a company the ISP had acquired
- ROAs created in the registry's hosted RPKI portal after the account and legal agreement were in order: 23 ROAs covering every prefix and every authorized origin, including the customer-originated /24s with the customers' autonomous system numbers. Each ROA's maximum length equals the longest prefix actually announced, following the maxLength guidance in RFC 9319, so an attacker cannot announce a more specific route that looks valid. A /24 reserved for DDoS diversion got its own ROA for the scrubbing provider's origin
- A check of every ROA against the live routing table and a public validator before anything was enforced; two typos in the origin AS were caught in this stage, not after. Alerts now fire on a ROA that is about to expire, a prefix whose state turns invalid, and a new announcement of an ISP prefix from an unexpected origin
- Two redundant validators (Routinator and rpki-client) running on separate hosts, each feeding both edge routers over the RPKI-to-Router protocol (RFC 8210), so one validator failing does not leave the routers without data. The routers keep stale validation data for a defined time and alert when the feed is lost
- Route-origin validation (RFC 6811) in stages. First, a 4-week observation period tagged invalid routes with a BGP community and counted them: a few thousand invalid prefixes appeared in the full tables from transit, and a handful from peers, including routes for a customer of the ISP whose ROA was out of date, which the customer fixed. Then the import policy rejected invalid routes from transit and the exchange, one neighbor at a time, with a rollback ready and a customer notice before each change. Routes with no covering ROA (not-found) are still accepted, because most of the internet is not yet signed
- Customer sessions: the ISP now rejects invalid routes from BGP customers too, and filters customer announcements by prefix list built from the registry's route objects, adds a maximum-prefix limit and strips private AS numbers
- A written runbook for ROA changes when a customer changes provider or a prefix moves, an alert owner and a quarterly review. The work was also mapped to the routing security practices in the MANRS program as the ISP's own checklist, without implying participation
Result
The ISP's routes are now cryptographically authorized, and it no longer accepts routes that contradict a ROA from its transit providers, its exchange or its customers. A staged test announcement of an ISP prefix from a lab autonomous system was rejected at the first upstream that validated, and the monitoring alert fired in under two minutes. Subscriber traffic and customer routes were unaffected during the rollout. RPKI protects against mistaken and unauthorized origins, not against every path hijack, and this is an illustrative engagement and a modeled outcome.
Get this for your company
Related services with fixed prices and a written scope.
Managed IT and security (MSP)
One monthly price per team member: help desk, device management, patching, backup monitoring and security basics.
Onboarding starts within 10 business days
$100 per team member, per month
Emergency package: security engineer in 1 hour
Is your company in a cybersecurity crisis? Purchase this package and a security engineer will call you within 1 hour.
Callback within 1 hour, 24 hours a day, 365 days a year
$1,950 per incident
Initial assessment of public endpoints
What an attacker can see and reach from the internet: your domains, mail, websites, remote access and cloud exposure.
Report within 5 business days of kickoff
$1,000 per assessment
Show 3 more
Managed security monitoring
Endpoint detection and response watched by our analysts, priced per device.
Agents deployed within 7 business days
$18 per endpoint, per month
Datacenter build discovery
A fixed-price study of your server room or datacenter plans: power, cooling, network, security and a costed build plan.
Written plan within 15 business days of the site visit
$8,500 per site
Cabling site survey
A technician visits your site, measures runs, checks pathways and risers, and writes a fixed scope and quote for the cabling.
Visit within 10 business days; written scope 3 days after
$950 per site
After you purchase, we contact you within 1 hour, any time of day or night, to start onboarding.
No payment is taken online. When we call you within the hour we confirm the scope and send an invoice (ACH, card or crypto).
A hijacked prefix rejected by RPKI
A rogue network announces a more-specific slice of someone else's prefix, which normally wins because longer prefixes are preferred. A transit router doing route origin validation checks the announcement against signed ROAs, marks it RPKI-invalid and never installs it, so traffic keeps flowing to the real origin.
A BGP edge that survives a lost carrier
Two edge routers run BIRD 2, peer with two transit carriers and an internet exchange, validate every route with RPKI and detect a dead link in under a second with BFD, so traffic moves to the other carrier before users notice.
Detecting a dead neighbour
How long a BGP router waits before it declares a silent neighbour dead, on a log scale. Hold 180 s with keepalive 60 s is the Cisco IOS default and a common default on other vendors (RFC 4271 suggests 90 s and 30 s; some stacks use other values, so check the platform). Tuned timers of 9 s and 3 s are aggressive but valid. BFD (RFC 5880) at 3 missed packets of 50 ms detects loss in 150 ms and tells BGP to tear the session down. Detection time only: route withdrawal and FIB update come after.
The shortest path is the one you peer for
Without peering, traffic crosses paid transit through several networks. Once the enterprise joins an internet exchange and peers with the content network through the route server, the same traffic takes one AS hop, at lower latency and with no transit bill.
Facing something similar?
Tell us about your environment. We will tell you plainly what we would do and what it would take.