RPKI & routing security

A verified DNSSEC chain and a pinned TLSA key are worthless if someone can just steal the route.

BGP has no built-in authentication — any network can announce "I originate 2a04:2a01::/32," and if enough peers believe it, traffic to every Whisper agent is vacuumed into the hijacker's network before it reaches us. It has happened to real prefixes: YouTube's 2008 hijack by Pakistan Telecom, the 2018 Amazon Route 53 hijack that redirected myetherwallet.com traffic to a phishing site. DNSSEC and DANE prove the answer is authentic; RPKI proves the path to the server wasn't stolen. Skip it and you've locked the front door while leaving the delivery route unguarded.

Whisper's whole address block (2a04:2a01::/32, announced by AS219419) is RPKI-signed, and the resolver can enforce that every destination it hands an agent is running on a route nobody hijacked. This page covers the actual mechanism — ROAs, origin validation, the RFCs behind it — and how to check it yourself with nothing but stock tools.

The mechanism: Route Origin Authorizations (RFC 6482)

RPKI (Resource Public Key Infrastructure, RFC 6480) is a PKI overlaid on the number resources themselves. A Regional Internet Registry (RIPE NCC, ARIN, APNIC…) holds the root certificate for the address space it allocated. It issues a certificate to the resource holder — Whisper Security / viaGraph B.V. holds the certificate for 2a04:2a01::/32 — and that holder signs a Route Origin Authorization (ROA, RFC 6482), a small signed object asserting three fields:

The max length caps how specific a sub-announcement is allowed to be, and Whisper's ROA sets it to 32 — exactly the prefix length itself. That means only the exact /32 is authorized: any more-specific announcement — a /33, a /48, a /64 — from anywhere on earth, including AS219419 itself, is RPKI-invalid. It's the tightest ROA there is. There's no authorized more-specific for a hijacker to hide a bogus route behind and win longest-prefix-match, and no room for our own kit to leak one either. (A holder can permit more-specifics by setting maxLength longer than the prefix; Whisper deliberately doesn't — the per-agent /128 identities all live inside that single /32 announcement, so there's never a reason to announce anything narrower.)

ROAs are published in the RIR's RPKI repository as signed CMS objects and fetched by relying-party software (Routinator, rpki-client, OctoRPKI) that any network operator runs. That software builds a VRP set (Validated ROA Payload: prefix + max-length + ASN tuples) and hands it to the router.

Route Origin Validation (RFC 6811)

RFC 6811 defines how a BGP speaker uses that VRP set against every route it receives. For each announced (prefix, origin-ASN) pair, RPKI-to-router (RFC 8210) delivers the VRPs to the router in real time, and the outcome is one of three states:

• Valid — a VRP exists that covers this exact prefix (or a less-specific covering it, within max-length) with a matching origin ASN.
• Invalid — a covering VRP exists, but either the origin ASN doesn't match (hijack) or the announced prefix is more specific than the max-length allows (leak/overclaim).
• NotFound (Unknown) — no ROA covers this prefix at all — most of the internet's legacy space, still unsigned.

RFC 6811 recommends: prefer valid, never propagate invalid to customers, and deprioritize (or drop, per local policy) invalid routes in best-path selection. Whisper's edge routers apply origin validation on every eBGP session — invalid routes are marked and stripped from the RIB, so a hijacked more-specific of our own /32, or a bogus origin ASN claiming it, never wins a path even transiently.

Dual-homed, not single-homed

AS219419 peers with more than one upstream and exchanges routes at public internet exchanges rather than depending on a single transit provider — the MANRS baseline for resilience. If one upstream flaps, has an outage, or itself propagates a bad route, the other path keeps 2a04:2a01::/32 reachable. Combined with RPKI-invalid dropping, this is what "an address on land we own" (see Verifiable identity) actually cashes out to operationally: a route that's both cryptographically authorized and not a single point of failure.

MANRS: the operational commitment, not just the crypto

RPKI signs what should be true; MANRS (Mutually Agreed Norms for Routing Security, manrs.org) is the community's checklist that operators actually do something with it. AS219419 is MANRS-compliant against all four network-operator actions:

1. Filtering — reject announcements (from customers/peers) that fail origin validation or don't match agreed prefixes.
2. Anti-spoofing — enforce source-address validation so packets can't leave the network with a forged source.
3. Coordination — publish current contact info (peeringdb, IRR/RPKI metadata) so abuse and routing incidents get resolved fast.
4. Global validation — publish accurate route-object/ROA information so other networks can validate against AS219419's own routes.

That last one is the point where RPKI and MANRS meet: it's not enough for Whisper to validate what it receives — the ROA for 2a04:2a01::/32 has to be correct and current so the rest of the internet's routers validate Whisper's own announcements as valid, not invalid or unknown.

Checking it yourself — stock tools

No Whisper software required — RPKI state is public data, published for exactly this purpose.

# 1. Ask a public RPKI validator (RIPEstat) for the ROA and origin-validation verdict
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS219419&prefix=2a04:2a01::/32" | jq '.data'
# → { "status": "valid", "validator": "routinator", "validating_roas": [
#       { "origin": "219419", "prefix": "2a04:2a01::/32", "max_length": 32, "validity": "valid" } ] }

# 2. Cross-check the ASN's name, peers and announced prefixes with bgpview.io (or bgp.tools)
curl -s "https://api.bgpview.io/asn/219419" | jq '.data | {name, description_short, rir_allocation}'
curl -s "https://api.bgpview.io/asn/219419/prefixes" | jq '.data.ipv6_prefixes[].prefix'
whois -h whois.radb.net '!6as219419'           # IPv6 IRR route objects for the origin AS

# 3. Grep the ROA out of a public, current VRP export (Cloudflare's rpki-client feed)
curl -s "https://rpki.cloudflare.com/rpki.json" \
  | jq '.roas[] | select(.asn=="AS219419")'
#   → { "prefix": "2a04:2a01::/32", "maxLength": 32, "asn": "AS219419", "ta": "ripe" }

stat.ripe.net's rpki-validation endpoint runs the exact RFC 6811 algorithm against the live VRP set and gives you the same valid/invalid/unknown verdict a router would compute — no BGP session of your own required.

With Whisper: enforcing it on the resolver, not just the wire

Checking the route to Whisper is public and stock-tools-only, as above. But Whisper's control plane goes one step further: it can make the resolver itself refuse to hand an agent a destination whose own route is RPKI-invalid — protecting the agent from resolving straight into a hijack of somebody else's prefix.

# Turn on hijack-aware routing policy for one agent — the resolver refuses to
# hand it any destination currently announced via an RPKI-invalid route.
whisper policy shipping-bot --routing drop-hijacked

Under the hood this is one call to the control verb — the same whisper.agents verb that provisions identity, sets geo/category policy, and streams logs (see Control plane):

CALL whisper.agents({op:'policy', args:{
  agent:   'shipping-bot',
  routing: 'drop-hijacked'
}})

With this set, any candidate answer the resolver would otherwise return is checked against current route-origin validation state before it's handed to the agent; an RPKI-invalid destination is treated the same as a graph-flagged malicious one — it doesn't resolve. Every policy field is additive and revocable: re-run whisper policy shipping-bot … with a different set of levers at any time and the next query the agent makes is evaluated under it — nothing to redeploy.

whisper policy shipping-bot --routing drop-hijacked --geo-allow EU --block tor-exit
# routing + geofence + category block, one call, evaluated fresh per query

This is opt-in, not a hidden filter — Postel's Law cuts both ways: liberal in what the resolver accepts as a query, conservative (and honest about it) in what it's willing to hand back as an answer once you've asked it to be.

Next: Verifiable identity — how the address itself, not just the route to it, is provable · Trustless verification — chain-of-custody checks (DANE, DNSSEC, transparency) that compose with RPKI for an end-to-end trust story.