BGP hijacks remain one of the most impactful routing security threats on the internet. A misconfigured or malicious BGP announcement can redirect your traffic through an attacker's network, intercept data, or make your services unreachable. While the largest networks have invested in routing security for years, small operators — single-AS hosting providers, regional ISPs, enterprises with their own address space — often lack clear guidance on what they can do with limited resources.

This guide covers the practical steps small operators can take to protect their address space from BGP hijacks, using RPKI, ROAs, Route Origin Validation, and monitoring — with realistic expectations about what each measure actually defends against.

Why small operators are vulnerable

Small operators face specific BGP security challenges:

  • Single upstream or limited peering — fewer vantage points to detect hijacks
  • No dedicated routing security team — BGP configuration is one of many responsibilities
  • Limited influence over transit providers — cannot easily force peers to filter
  • Smaller address blocks — more specific announcements are harder to hijack but also harder to protect if the covering aggregate is hijacked

The good news: RPKI tooling has matured significantly, and creating ROAs is now straightforward through RIR portals.

RPKI and ROAs explained

Resource Public Key Infrastructure (RPKI)

RPKI is a cryptographic framework that associates IP address blocks with their authorised origin ASNs. It is managed by the Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC).

Route Origin Authorisation (ROA)

A ROA is a signed cryptographic statement that says: "IP prefix X is authorised to be originated by ASN Y, with a maximum prefix length of Z."

Example: A ROA for 203.0.113.0/24 originated by AS64496 with max-length /24 means:

  • AS64496 is authorised to announce 203.0.113.0/24
  • No one else should be originating this prefix
  • The prefix cannot be announced as more-specific than /24 (e.g., /25 would be invalid)

Route Origin Validation (ROV)

ROV is the process by which routers check incoming BGP announcements against the RPKI database:

  • Valid: The announcement matches a ROA (correct origin AS and prefix length)
  • Invalid: The announcement contradicts a ROA (wrong origin AS or prefix too specific)
  • Not Found: No ROA exists for this prefix (no opinion)

Networks performing ROV can filter or deprioritise invalid announcements, preventing hijacked routes from propagating.

Implementation checklist for small operators

Step 1: Create ROAs for your address space

  1. Log into your RIR portal (RIPE NCC portal, ARIN OT&E, APNIC MyAPNIC, etc.)
  2. Navigate to the RPKI/ROA section
  3. Create ROAs for each prefix you announce:
    • Origin AS: your ASN
    • Prefix: your announced prefix
    • Max length: set to the most specific prefix you actually announce (usually the prefix length itself)
  4. Verify ROA publication: check at rpki-validator.ripe.net or routinator.nlnetlabs.nl

Critical: max-length configuration. Setting max-length too permissive (e.g., /24 with max-length /32) allows anyone who hijacks a more-specific prefix to have a "valid" announcement. Set max-length to exactly the most specific prefix you announce.

Step 2: Enable ROV on your routers (if you peer with BGP)

If you run BGP routers:

  1. Deploy an RPKI validator: Routinator, Fort, or OctoRPKI
  2. Connect your router to the validator via RTR protocol (RFC 8210)
  3. Configure ROV policy:
    • Mark routes as valid/invalid/not-found based on RPKI data
    • Prefer valid routes over not-found
    • Reject or deprioritise invalid routes

For small operators with a single upstream, you may not run BGP at all — your transit provider announces your prefix on your behalf. In that case, ROAs are your primary tool, and you should request that your transit provider performs ROV.

Step 3: Request ROV from your transit providers

Contact your upstream transit providers and ask:

  • Do you perform ROV on customer routes?
  • Do you filter RPKI-invalid routes?
  • What is your timeline for enabling ROV if not yet active?

Many large transit providers now filter RPKI-invalid routes by default. If yours doesn't, this is a meaningful factor for choosing providers.

Step 4: Set up monitoring

You need to know when your prefix is announced by someone else. Monitoring options:

  • RIPE RIS / RIPEstat: Free, shows BGP announcements for your prefix from RIPE's route collectors
  • BGPStream (CAIDA): Real-time BGP data stream, free for research and monitoring
  • Cloudflare Radar Route Leak Detection: Alerts for detected route leaks
  • BGPalerter (open source): Self-hosted tool that monitors BGP announcements and alerts on anomalies
  • Commercial options: ThousandEyes, Kentik, BGPmon

Set up alerts for:

  • Your prefix being announced by an unexpected AS
  • Your prefix being announced as a more-specific prefix
  • Your prefix disappearing from the global routing table
  • New or changed upstream paths for your prefix

What RPKI/ROV does and doesn't protect against

Protects against

  • Accidental misconfiguration: A fat-finger BGP announcement from another network will be marked RPKI-invalid and filtered by ROV-enabled networks
  • Opportunistic hijacks: Attackers who originate your prefix without a valid ROA will be filtered
  • Route leaks (partial): ROV helps limit the propagation of leaked routes

Does not protect against

  • Path manipulation: An attacker who has a valid AS in the path can prepend or insert ASes without violating RPKI
  • Sub-prefix hijacks within your ROA's max-length: If your ROA allows /24 to /28, an attacker announcing /28 from your AS would appear valid
  • Non-ROV networks: Networks that don't perform ROV will still accept invalid announcements. Global ROV adoption in 2026 is ~40% of routes but far from universal.
  • Compromised RPKI certificates: Theoretical but not yet observed at scale

Common mistakes

Not creating ROAs at all. Your prefix is "Not Found" by default, which means ROV provides no protection. Creating ROAs is free and takes minutes.

Setting max-length too broadly. A ROA for 192.0.2.0/24 with max-length /32 authorises any sub-prefix. Set max-length to the exact prefixes you announce.

Forgetting to update ROAs when changing providers. If you move to a new transit provider with a different AS, update your ROAs to authorise the new AS. Stale ROAs can make your own announcements RPKI-invalid.

Creating overlapping or conflicting ROAs. If you have ROAs for both 192.0.2.0/23 and 192.0.2.0/24 from different ASes, the validity logic becomes complex. Keep ROAs clean and minimal.

Ignoring monitoring. ROAs and ROV are preventive measures. You still need detection — monitoring tells you when something unexpected happens, whether RPKI caught it or not.

Verification

  1. Check your ROA status: visit rpki-validator.ripe.net and search for your prefix
  2. Verify ROA matches your current announcements: compare origin AS in the ROA with your actual BGP origin
  3. Check ROV filtering from outside: use looking-glass tools from major transit providers to see how your prefix is received
  4. Test monitoring alerts: if you set up BGPalerter or similar, verify alerts trigger correctly by checking historical data for known events

Related reading on wplus.net