RPKI Validation: Validators, VRPs and Relying Parties

Author

K19G

Updated

October 31, 2026

RPKI Validation: Validators, VRPs and Relying Parties

Routers cannot directly walk the planetary RPKI certificate tree. Public-key signature verification, recursive repository crawling, and cryptographic certificate chain parsing require substantial computational power, memory, and disk I/O that router control-plane processors do not possess.

This structural reality necessitates an architectural split: an external server software package—the RPKI Relying Party (RP) or Validator—performs the heavy cryptographic heavy lifting and delivers a simple, flattened table to routers.

What an RPKI Validator Does: Download, Verify, Extract

An RPKI Validator performs four primary tasks in a continuous operational loop (typically every 10 to 20 minutes):

+-----------------------------------------------------------+
|                  RPKI Repository Tree                     |
|  (ARIN, RIPE, APNIC, LACNIC, AFRINIC Publication Points)  |
+-----------------------------+-----------------------------+
                              |
                              | 1. Sync via RRDP (HTTPS) / rsync
                              v
+-----------------------------------------------------------+
|                  RPKI Relying Party (Validator)          |
|                  (Routinator, rpki-client, FORT)          |
|                                                           |
|  2. Cryptographic Verification:                           |
|     - Walk TAL root anchors -> EE certificates            |
|     - Check cryptographic signatures (RSA/ECDSA)          |
|     - Verify RFC 3779 resource inclusions                 |
|     - Check CRLs and Manifest hashes                      |
|                                                           |
|  3. Extraction: Flatten valid ROAs into VRP table         |
+-----------------------------+-----------------------------+
                              |
                              | 4. RTR Protocol (Port 3323)
                              v
+-----------------------------------------------------------+
|                     Edge & Core Routers                   |
|                   (Cisco, Juniper, Nokia, FRR)            |
+-----------------------------------------------------------+
  1. Repository Synchronization: Synchronizes local cache with all global RPKI publication repositories.
  2. Cryptographic Validation: Validates the entire certificate chain from the 5 Trust Anchor Locators (TALs) down through intermediate CAs to End-Entity certificates and ROAs.
  3. Revocation and Integrity Checking: Confirms that certificates have not been revoked on Certificate Revocation Lists (CRLs) and that all files match the hashes recorded on signed manifests.
  4. VRP Extraction: Extracts valid authorizations into a flattened list of Validated ROA Payloads (VRPs) and serves them to routers over the RPKI-to-Router (RTR) protocol.

Validator Architecture and Repository Sync: RRDP vs. rsync

Historically, RPKI repositories synchronized using rsync. In production, rsync proved disastrously fragile: - Scaling bottlenecks: Thousands of validators executing concurrent rsync crawls overwhelmed RIR server CPU and memory. - Partial updates: Network dropouts during rsync transfers left directories with missing or inconsistent certificate sets.

The IETF resolved this by introducing RPKI Repository Delta Protocol (RRDP, RFC 8182): - Operates over standard HTTPS. - Uses an XML-based Notification File (notification.xml), Snapshot Files, and Delta Files. - Enables caching through commercial Content Delivery Networks (CDNs), allowing millions of queries per second without placing load on RIR origin servers. - Validators only fall back to rsync if an RRDP publication endpoint fails.

Validated ROA Payloads (VRPs): The Validator’s Output

The final output of an RPKI validation cycle is a flat table of Validated ROA Payloads (VRPs). A VRP is a simplified 4-tuple:

VRP = (Prefix, PrefixLength, MaxLength, OriginASN)

Example VRP table dump:

IP Prefix Prefix Length Maximum Length (maxLength) Authorized Origin ASN
198.51.100.0 24 24 AS65001
203.0.113.0 24 24 AS65002
2001:db8:: 32 48 AS65001
192.0.2.0 24 24 AS65100

This compact table is all a router needs to make real-time forwarding decisions.

CRL and SKI/IAI: Revocation and Validation Accuracy

  • Certificate Revocation Lists (CRLs): Each CA periodically signs a CRL listing the serial numbers of revoked certificates. Validators must download the CRL before evaluating any certificate issued by that CA.
  • Subject Key Identifier (SKI) & Authority Key Identifier (AKI): Ensure exact cryptographic matching between the public key in a parent CA certificate and the issuer signature on a child certificate, preventing key substitution attacks.

Validator Outages, Stale Data and Recovery Behavior

What happens when an RPKI validator server crashes, loses Internet connectivity, or is partitioned from the RIR repositories?

  • Local Cache Persistence: Validators do not purge their databases when an upstream sync fails. They continue serving the last known valid VRP set to routers until certificates and manifests reach their cryptographic expiration dates.
  • Router Cache Timer: Routers maintain an RTR expiry timer (default typically 60 to 120 minutes). If all RTR sessions to all local validators drop, the router preserves its VRP table in memory until the timer expires.
  • Redundant Validator Architecture: Best operational practice dictates deploying at least two independent validator instances running different software implementations (e.g., Routinator by NLnet Labs and rpki-client by the OpenBSD project) in separate physical data centers to prevent single-vendor software bugs from taking down the routing policy.