An event-driven simulation of BGPsec on 200 real ASes from the CAIDA AS graph, running in your browser. Every AS signs each route it passes on, so signatures pile up hop by hop. Pick a signature scheme and an event, then watch the signed updates spread, or fail to.
Topology. The 60 ASes with the largest customer cones, 60 mid-tier transit ASes and 80 stub ASes, with every link between them from CAIDA's AS-relationship dataset (2026-01-01). Routing follows the Gao-Rexford rules: prefer customer over peer over provider routes, then the shorter path, and export peer and provider routes only to customers. Each AS is modelled as a single router.
Costs. Sign and verify times are measured per operation (liboqs / OpenSSL, Apple M4) and charged to a per-router CPU queue. A router verifies every signature on a received path, and signs once per prefix and per neighbor, because a BGPsec signature covers the AS it is sent to. An UPDATE carries 110 B plus (signature + 28 B) per hop, as in the paper's Eval 3. In a session reset, each of the 200 simulated prefixes stands for 1/200 of a 1.1M-prefix table, so its CPU and byte costs are scaled up to full-table size.
Not modelled. Route-flap damping, iBGP inside an AS, partial BGPsec deployment and signature caching across sessions. All numbers are model outputs for discussion, not measurements of a real router.