BGP Hijacking After IPv4 Transfers: ROA Protection Guide

BGP hijacking risk doesn’t stay flat after an IPv4 transfer. It spikes. In the days and weeks right after a block changes hands, routing records lag behind the registry databases, old announcements keep floating around the internet, and for anyone running networks this transition window is arguably the most dangerous stretch in an address block’s life. Unscrupulous actors watch RIR transfer logs precisely to catch blocks in limbo, then announce them as their own before proper Route Origin Authorization (ROA) protection is in place. If you buy or sell IPv4 space, closing that window is not optional.

Why IPv4 Transfers Create a BGP Hijacking Window

Here’s the uncomfortable part: when an IPv4 block changes hands, the RIR updates its registry database to reflect the new owner, but the global routing system doesn’t update on its own. The previous holder’s ASN may still announce the prefix. Cached routes can persist across autonomous systems. And the new owner, meanwhile, may not have configured their own announcements yet. During that gap, the block sits in a state of ambiguous ownership as far as routing is concerned.

Slow operational processes make it worse. Many organizations take days, sometimes weeks, to update their IRR objects, and RPKI ROA creation is often treated as an afterthought rather than a priority. Industry incident reports — the kind tracked by the Global Routing Intelligence Platform (GRIP) and Cloudflare Radar — suggest a significant share of suspected hijacks involve prefixes that were recently transferred, reassigned, or otherwise touched in registry databases.

Hijackers actively scan RIR data feeds for these signals. A /22 that shows up in a transfer log with no corresponding ROA is a soft target: neighbors are less likely to reject the bogus announcement, and the legitimate owner may not even be announcing the prefix yet, so they’d never notice. Until RPKI-based Route Origin Validation (ROV) adoption becomes universal, attackers will keep exploiting the gap between registry truth and routing reality.

Common Post-Transfer Hijacking Scenarios and Attack Vectors

Several recurring attack patterns target recently transferred address space:

• Sub-prefix announcements: An attacker announces a /24 carved out of your newly acquired /20. Because more-specific routes win in BGP, traffic destined for that /24 gets diverted to the attacker’s network — even if your ROA covers the /20. This is exactly why ROAs must authorize maximum prefix length carefully, ideally setting maxLength equal to the exact prefix you’re announcing.
• Legacy announcement persistence: The seller’s ASN keeps announcing the block after the transfer completes, whether through oversight or malice. The result is routing conflicts, blackholing, and potential RPKI invalid status if a ROA now exists for your ASN.
• Squatting during escrow: More sophisticated bad actors watch transfer queues and announce blocks between registry approval and the buyer’s first announcement, monetizing the traffic or launching phishing campaigns from “clean” hijacked space.
• IRR object spoofing: Attackers create or modify IRR route objects claiming their ASN originates your prefix, giving their illegitimate announcement a veneer of legitimacy for networks still filtering on IRR data alone.

Any of these vectors can mean intercepted traffic, email spoofing from your prefixes, reputation damage to your ASN, and remediation time you didn’t budget for.

Route Origin Validation: Setting Up RPKI ROAs the Right Way

RPKI ROAs are your strongest defense — but only when configured correctly. Sequence matters, too. Follow this order immediately after any IPv4 transfer:

1. Create the ROA before announcing. In your RIR-hosted or third-party RPKI CA (ARIN’s Hosted RPKI, RIPE NCC RPKI, or a provider in the Cloudflare go-rpkirtr ecosystem), authorize your ASN for the exact prefix with maxLength set to the same prefix length. That prevents authorized sub-prefix hijacks.
2. Revoke stale ROAs from the seller. Confirm the previous holder’s ROAs are deleted. Overlapping valid ROAs for a different ASN can invalidate your own announcements.
3. Update IRR objects in parallel. Keep route objects current in authoritative IRRs (RADB, RIR-maintained databases) to satisfy operators still using IRR-based filtering.
4. Monitor validation status. Use tools like RIPEstat and Routinator to verify your ROAs are propagating correctly before go-live.

A disciplined ROA-first workflow shrinks the hijacking window from weeks to hours. Combine it with vigilant monitoring, and most post-transfer attack opportunities disappear entirely.

Cleaning Up Legacy ROAs and Stale IRR Objects

Acquired address space almost always arrives with baggage. Legacy ROAs created by the previous holder, outdated route objects in IRR databases, and stale registry entries can all conflict with your new configuration. A conflicting ROA is particularly dangerous: if the seller left a ROA authorizing their old ASN with a shorter max-length, your own announcements may be flagged as RPKI-invalid by validating networks, effectively causing a self-inflicted routing outage that mirrors hijack symptoms.

Audit every ROA under the transferred prefix within the first week of ownership. Remove or replace objects referencing the seller’s ASN, and make sure your new ROA specifies your origin ASN with a max-length that matches your announcement plan exactly. The same applies to IRR route objects in RADB, RIPE, and ARIN databases, since many large transit providers still filter based on IRR data. Submit route objects for your ASN and coordinate with the registry to retire obsolete entries tied to the transfer.

• Document the cleanup: keep a dated record of every ROA and IRR change for audit and dispute purposes.
• Verify propagation: use RPKI validators and IRR query tools to confirm stale objects are fully purged before cutting over traffic.

Continuous Monitoring: Detecting BGP Hijacking in Real Time

Prevention is not a substitute for detection. Even with flawless ROAs, your prefixes should be monitored continuously for unexpected origin ASNs, sudden route leaks, or announcements from geographies where you hold no presence. Public monitoring services such as RIPE RIS, RouteViews, BGPMon-style alerting platforms, and Cloudflare Radar allow you to set automated alerts triggered by any new origin ASN appearing on your prefixes.

Configure alerts with meaningful thresholds to avoid alarm fatigue: a single missed update is noise, but a new origin ASN or a sudden visibility drop across multiple route collectors demands immediate investigation. For critical prefixes, maintain a rehearsed incident response playbook that includes contacting upstream providers to withdraw hijacked routes, filing reports with the relevant RIR, and communicating with customers. Networks that can revoke a hijack within minutes routinely limit customer impact to negligible levels, while unprepared operators can lose traffic for hours or days.

Conclusion: Building a Hijack-Resilient Prefix Management Workflow

BGP hijacking risks do not end when an IPv4 transfer completes; in many cases, that is precisely when exposure peaks. The resilient workflow is straightforward to describe and requires discipline to execute: validate chain of custody before purchase, deploy ROAs and IRR objects before the first announcement, purge every legacy artifact from the previous holder, and monitor continuously with automated alerts and a tested response plan.

Buying from a marketplace with verified sellers and clean, pre-audited holdings, such as IP4 Market, removes most of the upstream uncertainty, letting your team focus on protecting the prefix going forward rather than untangling someone else’s history. Combine that foundation with RPKI validation on your own edge, peer coordination, and quarterly audits of your routing objects, and your transferred prefixes become dramatically harder to hijack than the average announced block on the internet today. In a market where address scarcity keeps values rising, protecting the routing integrity of your assets is not optional overhead; it is fundamental asset management.