The Routing Registries: IRRs and Their Limitations

The Routing Registries: IRRs and Their Limitations

Long before cryptographic validation through RPKI was deployed, the network operations community created the Internet Routing Registry (IRR) system to record routing policies, prefix ownership, and transit relationships. While IRRs remain widely used to generate automated prefix-lists, their fundamental design weaknesses highlight why cryptographic authentication became necessary.

What Routing Registries Are and How They Store Route Objects

An Internet Routing Registry is a distributed database storing text-based policy statements formatted in Routing Policy Specification Language (RPSL, RFC 2622).

The IRR system is not a single database; it is a confederation of more than 30 independent registries worldwide: - Authoritative RIR Registries: Run by Regional Internet Registries (RIPE, APNIC, AFRINIC, LACNIC, and ARIN-RR), containing records tied to actual resource allocations. - Third-Party / Commercial Registries: Including RADB (Merit), NTT, Level3/Lumen, and ALTDB, established historically to allow multi-region operators to register policy objects without cross-RIR coordination.

Registries mirror each other’s databases via daily or hourly bulk dumps, but synchronization is loose, partial, and frequently inconsistent.

Creating Route Objects: Route, Route6, AS-SET and Related Classes

RPSL defines several core object classes:

1. route (IPv4) and route6 (IPv6) Objects

A route object binds an IP prefix to an authoritative origin Autonomous System:

route:         198.51.100.0/24
descr:         Example Production Web Backbone
origin:        AS65001
mnt-by:        EXAMPLE-MNT
source:        RADB

2. aut-num Objects

An aut-num object specifies the routing policy of an Autonomous System, detailing its import, export, and peering rules:

aut-num:       AS65001
as-name:       EXAMPLE-NET
import:        from AS65002 action pref=100; accept ANY;
export:        to AS65002 announce AS-EXAMPLE;
mnt-by:        EXAMPLE-MNT
source:        RADB

3. as-set Objects

An as-set is a hierarchical grouping of Autonomous Systems representing an entire customer cone. Upstream transit providers use as-set objects to recursively build prefix-lists for an entire downstream customer hierarchy:

as-set:        AS-EXAMPLE-CUSTOMERS
descr:         Downstream customers of AS65001
members:       AS65010, AS65020, AS-SUB-CLIENTS
mnt-by:        EXAMPLE-MNT
source:        RADB

Policy-Based Filtering: Using IRR Data to Build Filters

Modern Tier-1 and Tier-2 transit providers use open-source tools such as bgpq4 or irrpt to query IRR databases and automatically generate vendor-specific prefix filters:

# Query RADB and generate a Cisco IOS XR prefix-list for AS-EXAMPLE-CUSTOMERS
bgpq4 -X -l CUSTOMER-IN AS-EXAMPLE-CUSTOMERS

Output:

prefix-set CUSTOMER-IN
  198.51.100.0/24,
  203.0.113.0/24 le 24
end-set

These generated prefix-lists are applied to customer-facing eBGP sessions, preventing customers from advertising arbitrary unauthorized prefixes.

Weaknesses: No Authorization Checking, No Cryptographic Binding

Despite its widespread operational use, the legacy IRR system suffers from critical security flaws:

1. No Authorization Checking in Third-Party IRRs: In non-authoritative registries (such as RADB or legacy ALTDB), anyone with a paid account could register a route object for any IP address on Earth. An attacker could create a fake route object claiming that 1.1.1.1/32 originates from AS666. If an upstream transit provider built its filters using an unvetted query (-S radb), the attacker’s route would be automatically permitted through the provider’s border filters!
2. Stale and Ghost Objects: When organizations renumber, merge, or return IP blocks to an RIR, they rarely delete their old IRR objects. Millions of obsolete route objects remain active in mirrored registries decades after the addresses were reassigned.
3. No Cryptographic Signatures: IRR objects are plaintext text files. They contain no digital signatures, no public-key certificates, and no cryptographic binding to the resource holder’s cryptographic keys.

The Transition from IRR Filtering to RPKI-Based Validation

Because the legacy IRR system could not guarantee origin authenticity or prevent rogue registrations, the IETF developed the Resource Public Key Infrastructure (RPKI).

While RPKI provides cryptographic truth for origin validation, IRRs remain operationally necessary for expanding as-set customer cones and generating strict inbound prefix-lists at transit borders. In modern network operations, IRR and RPKI are deployed as complementary controls: IRR validates the path and customer cone, while RPKI cryptographically verifies the origin.