HomeIncident library
Incident library

INCIDENT REPLAY · 2025-03-18

North Korea knocked offline by its own ROA

At 09:30 UTC a ROA was published with a maximum length of /22 while the country's four routes are announced as /24s, making them RPKI-invalid. Carriers doing origin validation rejected them within minutes and reachability fell for over 16 hours until corrected ROAs appeared.

RPKI and driftPolicy error otherCatalog confidence: high

A reconstruction, not the operator's network. Hammerhead's authors rebuilt the change from the public record as a small network of their own. No configuration here is the operator's. What follows is what the tool reported on that reconstruction; it is not a claim that the tool would have prevented the outage.

What happened

Who: Star JV (AS131279) self-inflicted; upstreams China Unicom (AS4837) and TransTeleCom (AS20485); Arelion, GTT, Verizon and others dropped the routes

The summary at the top is paraphrased from the sources below. Hammerhead's catalog rates its confidence in this account high.

Sources

What the public record says

  • At 09:30 UTC a ROA was published with a maximum length of /22 while the country's four routes are announced as /24s, making them RPKI-invalid. Carriers doing origin validation rejected them within minutes and reachability fell for over 16 hours until corrected ROAs appeared.
  • Who: Star JV (AS131279) self-inflicted; upstreams China Unicom (AS4837) and TransTeleCom (AS20485); Arelion, GTT, Verizon and others dropped the routes

What the reconstruction assumed

Decided by Hammerhead's authors to build a network that runs. None of it describes the operator's network.

Everything below is ours.

  • Star JV (AS 131279) is modelled as one router, STAR-1, announcing four /24s (198.18.176.0/24 to 198.18.179.0/24, stand-ins for the country's four routes) to two upstreams outside the snapshot, China Unicom (AS 4837) and TransTeleCom (AS 20485).
  • The ROAs in force before are an empty set (roas-current.json): the record says the space had never had a ROA. The published ROA is roas-published.json, 198.18.176.0/22 maxLength /22 AS 131279; the corrected one is roas-corrected.json, maxLength /24. The record does not give the corrected ROAs' exact contents, only that the four routes became Valid; one /22 with maxLength /24 is the smallest set that does that.
  • The configs do not change. The same directory is passed as before and after, which is the point: the change was to RPKI data.
  • Cisco IOS syntax and stand-in address space throughout. A reconstruction, not any operator's configuration.
  • Nothing here claims the outage would have been prevented. The replay says what the tool reports on the reconstruction.

What Hammerhead said

Each run below is pinned by Hammerhead's replay tests at commit 0ee9732: the verdict and the quoted text are checked against the tool's output, and a run that disagrees fails the test. Reason lines are copied verbatim; a pinned line can be part of a longer reason. Every preflight run uses --max-blast-radius 100, so a change is never counted as caught merely because it touched many devices of a small network.

same configs on both sides, the published ROA (/22, maxLength /22)

now: fail

On the reconstruction, hammerhead preflight on a before and an after snapshot with --roas @north_korea_roa_2025/roas-current.json --proposed-roas @north_korea_roa_2025/roas-published.json returned fail, for the reasons below.

Reason text pinned (some reason contains each line)

  • the proposed ROAs would make 198.18.176.0/24 announced by STAR-1 as AS 131279 Invalid, where it is NotFound today
  • the proposed ROAs would make 198.18.177.0/24 announced by STAR-1 as AS 131279 Invalid, where it is NotFound today
  • the proposed ROAs would make 198.18.178.0/24 announced by STAR-1 as AS 131279 Invalid, where it is NotFound today
  • the proposed ROAs would make 198.18.179.0/24 announced by STAR-1 as AS 131279 Invalid, where it is NotFound today
  • The proposed ROA 198.18.176.0/22 maxLength /22 AS 131279 covers it and authorises AS 131279 only up to /22

Pinned in tests/gauntlet/replays-rpki-drift.yaml.

same configs on both sides, the corrected ROA (maxLength /24): the control

now: pass

On the reconstruction, hammerhead preflight on a before and an after snapshot with --roas @north_korea_roa_2025/roas-current.json --proposed-roas @north_korea_roa_2025/roas-corrected.json returned pass.

Text no reason may contain

  • RPKI (proposed ROAs)

Pinned in tests/gauntlet/replays-rpki-drift.yaml.

Limits

  • The configurations are a reconstruction. Where the record is silent, the assumptions above fill the gap; if one is wrong, the replay is wrong in that respect.
  • A verdict describes the reconstructed network's converged state. Timing, traffic load, and anything a device does that no configuration states, such as software reacting to a health check or a firmware bug, are outside it.
  • A pass is reported as a pass. A fail says a gate fired on the reconstruction, nothing more.
  • Why the catalog counts this outage as partly in scope: The change was to RPKI data, not router config, but a tool that knows the announced prefixes from router config can check a proposed ROA against them; that cross-check is simple and currently outside a config-only gate.

Imported from docs/replays/north-korea-roa-2025/FACTS.md and the replay manifests in the Hammerhead repository at commit 0ee9732.