IRR route object missing or naming a different origin

A valid ROA does not finish prefix-origin hygiene. Route origin validation asks one question: does the RPKI say this origin AS may announce this prefix? Many networks still build their BGP filters from Internet Routing Registry (IRR) data, and those filters ask a different one: does a registered route object say this origin may announce this prefix? When the two sources disagree, or the IRR has no entry, the prefix is only partly protected. This article covers the finding that flags that gap, why it matters, and how to clear it.

What the finding means

SetEnforce looks at the prefixes that serve your domain's addresses and compares three views of each one:

1. The live announcement: which origin AS or ASes currently announce the prefix in the global routing table.
2. The RPKI: the ROAs covering the prefix, as defined in RFC 6482, including their origin AS and maxLength.
3. The IRR: the route or route6 objects registered for the prefix, and the origin: attribute each one carries.

The finding fires when the IRR has no route object for the announced prefix, or when the only objects name an origin AS other than the one announcing it. The wider check asks whether origin authorization is precise, uncontested and consistently registered, and this finding covers the "consistently registered" part. Two related problems sit next to it: a ROA whose maxLength is looser than the announcement needs, and a prefix seen from more than one origin AS without the operator confirming that this is intentional.

Why stale registry data is a real problem

Origin validation under RFC 6811 classifies a route as valid, invalid or not-found against the ROA set. Enforcement is still uneven. Plenty of transit providers and exchange points build prefix lists from IRR objects, usually with tools such as bgpq4, and apply them to customer sessions. For those networks, the route object is the authorization.

That leaves two failure modes.

A missing object is the first. Your upstream generates its customer filter from your AS-SET, and if the prefix has no route object, the filter omits it. A legitimate announcement may be dropped, or the provider falls back to manual exceptions that nobody reviews.

A stale object naming another origin is worse. Suppose you moved the prefix from a previous provider's AS64500 to your own AS64501 but never removed the old object. The IRR now authorizes AS64500, an AS you no longer control. If that AS is a former hosting provider, a reseller that changed hands, or simply an organization with weak controls, anyone operating it can announce your prefix and pass every filter built from IRR data. Other networks may also reject your real announcement because the registry says it comes from the wrong place.

Stale data can also mask a hijack in monitoring. Alerting that compares announcements against the IRR sees a registered origin and stays quiet.

The cost is not a guaranteed outage. It is weakened defence in depth. Filters that should protect you authorize the wrong party, and troubleshooting a rejected announcement can take hours because the cause sits in a registry rather than your router.

How the scanner detects and rates it

For each prefix tied to the domain's resolved addresses, the scanner:

• Reads the announced prefix and origin AS from public routing data.
• Queries IRR databases for route and route6 objects that exactly match the prefix.
• Compares each object's origin: to the announcing AS.
• Records the ROA set seen for the same prefix, so the report shows all three views side by side.

The result is a failure when no object exists or when no object names the announcing origin. The evidence attached to the finding lists the prefix, the live origin AS, the IRR objects found (with source database and origin), and the ROA data. From that you can tell at a glance whether you have an omission, a stale entry, or a conflict.

The severity is low. An IRR mismatch does not by itself allow a hijack: RPKI-based validation still protects networks that enforce it, and the data is quick to correct. The rating reflects a hygiene and resilience gap, not an active exploit path. In practice it matters more if your upstreams rely on IRR-only filtering, or if the evidence also shows multiple origin AS values for the prefix.

Fixing it

1. Confirm the intended origin

Decide which AS should announce each prefix. If more than one is legitimate, for example during a provider migration or with anycast across two ASNs, record that decision, because each intended origin needs its own object.

2. Inspect what is registered

whois -h whois.radb.net -- '-i origin AS64501'
whois -h whois.radb.net '203.0.113.0/24'

Check every database that holds objects for the prefix. Note which source each object lives in, since you can only change objects in registries where you hold authorization.

3. Create or correct the route object

A correct object looks like this:

route:      203.0.113.0/24
descr:      Example Corp edge network
origin:     AS64501
mnt-by:     MAINT-EXAMPLE
source:     RIPE

For IPv6, use route6: with the prefix in that form. Submit the object through your registry's web portal, email interface or API. Authorization usually requires the maintainer of both the address block and the origin AS.

4. Remove stale objects

Delete route objects that name ASes you no longer use. Leaving them "just in case" keeps the hijack window open. If another party's maintainer protects the stale object, ask the registry or that party to remove it.

5. Keep the ROA consistent

Create or review the ROA at the same time. Per RFC 9319, set maxLength equal to the announced prefix length unless you genuinely announce more-specifics. A generous maxLength lets an attacker announce a sub-prefix from your origin AS and still validate. Every origin you register in the IRR should appear in a matching ROA, and the other way round.

6. Update the AS-SET

If upstreams build filters from your AS-SET, make sure it contains the AS that now announces the prefix, then ask them to refresh their filters.

Confirming the fix on re-scan

IRR changes usually propagate to mirrors within minutes to a few hours. Before re-scanning, verify directly:

whois -h whois.radb.net '203.0.113.0/24'
bgpq4 -4 -l allow AS64501

The first command should return a single object with the expected origin. The second should list your prefix. Then trigger a re-scan from the domain page. The finding clears when every announced prefix has an IRR route object naming its live origin, and the evidence view will show the matching IRR source with the ROA beside it. If the finding persists, compare the evidence's origin AS with what you registered. A typo in the ASN or a registry mirror that has not synced yet are the usual causes.

Key takeaways

• A valid ROA does not make the IRR irrelevant. Many networks still filter on route objects.
• The finding triggers when a prefix has no route object, or none naming the AS that announces it.
• A stale object naming a former origin is the dangerous variant, since it can authorize a party you no longer control.
• The severity is low because RPKI still protects enforcing networks and the fix is quick, but the gap undermines filter-based defences.
• Fix it by registering one correct object per intended origin, deleting stale ones, and keeping ROA maxLength tight per RFC 9319.
• Verify with whois and bgpq4 first, then re-scan to confirm.