Simulator scenario 2: ROA scope expansion and validation environment mapping

What this phase is about

After establishing baseline and legitimate RPKI presence (Playbook 1), Phase 2 prepares the control plane for an eventual hijack by:

  1. Creating a fraudulent ROA — authorising your AS for a victim’s prefix and a more‑specific subprefix.

  2. Testing where RPKI validation is actually enforced in the wider internet, so you know where your forthcoming attack will succeed.

  3. Setting up monitoring for ROA changes — so you know if defenders revoke or override your fraudulent ROA.

Important real‑world nuance:

  • Many RPKI validators do incorporate conflicting ROAs, and deployment varies by region.

  • Phase 2 is mostly about observing the validation environment so you know if later hijacks will be accepted or dropped.

Simulator implementation

scenario.yaml and telemetry.py model the core playbook 2 actions:

  • Create fraudulent ROA for victim’s prefix with expanded maxLength

  • Send BGP test announcements to detect RPKI validation behavior

  • Produce periodic validation telemetry

It does not try to simulate RIR portal behaviour or real API polling, but produces telemetry you can use to exercise SIEM logic around phase 2. You can add more probes or regions easily by expanding this timeline.

This mirrors Phase 2 actions without making anything malicious and gives visibility into Phase 2 behaviour before an actual hijack.