Summary
- On March 18, 2025, public network-analysis sources reported that North Korea-linked BGP routes became RPKI-invalid after a faulty Route Origin Authorization was published, apparently authorizing a /22 while the network announced four /24s.
- The incident is a useful accountability case because the route-security mechanism worked as designed from the validator perspective: networks rejecting invalid routes reduced reachability for routes that were operationally legitimate but inconsistent with the new ROA.
- The failure was therefore not an argument against RPKI. It was evidence that RPKI data has become shared infrastructure and must be governed with change review, staging, maxLength discipline, monitoring, rollback and alerting.
- Common-mode dependency is the key risk. As more networks adopt route-origin validation and reject invalids, a single resource-holder or RIR-side publication mistake can have wider operational consequences because many networks consume the same cryptographic statement.
- The repair standard should be verifiable: identify the invalid prefixes, correct the ROA, measure route propagation recovery, preserve the timeline, and publish enough evidence that other operators can audit their own maxLength and alerting controls.
Evidence record and how it is used
This article treats the public record as layered evidence. Incident reports, standards, browser or routing measurements, regulator or policy materials, and current operator guidance are used for different claims. Company-authored sources are attributed as company positions. Standards and later guidance are used to explain controls and present accountability expectations, not to invent private facts or retroactively impose later obligations where the public record does not support that claim.
| # | Public record | Use in this analysis |
|---|---|---|
| 1 | Kentik North Korea faulty ROA | Primary public network-analysis source for March 18, 2025 North Korea routes becoming RPKI-invalid due to a faulty ROA. |
| 2 | Internet Society Pulse report | Independent public summary noting APNIC signed a new ROA and describing the faulty ROA impact. |
| 3 | North Korea Internet report | Specialist monitoring report for AS131279 connectivity drop and ROA/SOA change timing. |
| 4 | lazarus.day mirror/report | Additional public incident report explaining /22 maxLength against four /24 announcements. |
| 5 | RIPE Labs real-time routing analysis | RIPE Labs article revisiting the North Korea faulty ROA incident with BGP monitor context. |
| 6 | APNIC cleaning invalid routes | Regional internet registry guidance on incorrect maxLength values and ROA updates. |
| 7 | RIPE NCC BGP origin validation | Operational explanation of ROA validity states and route-origin validation policy. |
| 8 | bgp.tools invalid alert help | Operational alerting context for a prefix that turns RPKI invalid. |
| 9 | MANRS hunting invalid routes | Industry article on monitoring discrepancies among IRR, ROA and BGP state. |
| 10 | RFC 6480 | RPKI architecture standard for certifying number resources. |
| 11 | RFC 6482 | ROA profile standard for Route Origin Authorization entities. |
| 12 | RFC 6811 | BGP prefix origin validation standard defining validity outcomes. |
| 13 | RFC 7115 | Origin validation operation guidance for BGP speakers. |
| 14 | NIST SP 800-189 | Government guidance for RPKI, BGP origin validation and route-security operations. |
| 15 | Cloudflare RPKI explainer | Operator explanation of route authorization and RPKI purpose. |
| 16 | Cloudflare RPKI deployment details | Operator deployment context for ROA maxLength and routing-security practice. |
| 17 | NRO RPKI program | Number Resource Organization context for global RPKI across RIRs. |
| 18 | LACNIC incorrect ROA guidance | RIR guidance explaining incorrect ROAs and verification. |
| 19 | Learning to Identify Conflicts in RPKI | Research context for benign RPKI conflicts, misconfigurations and operator filtering incentives. |
| 20 | Kentik BGP explainer | Plain-language explanation of BGP, RPKI and ROAs for reader context. |
RPKI made the mistake visible and consequential
RPKI exists because ordinary BGP gives networks too much room to believe false reachability claims. Route Origin Authorizations let resource holders say which autonomous system may originate which prefix and, through maxLength, how specific the announcement may be. Networks performing Route Origin Validation can then treat routes as valid, invalid or not found and apply policy. That is a major security improvement. The North Korea faulty ROA incident shows that the improvement creates a new operational dependency on the accuracy of the published authorization data.
Kentik reported that on March 18, 2025 North Korea’s BGP routes became RPKI-invalid due to publication of a faulty ROA. Other public reports describe a /22 authorization with maxLength /22 while the network was announcing four /24 prefixes. Under ROV logic, a route can be invalid even if the origin AS matches when the announced prefix is more specific than the ROA permits. If operators reject invalids, reachability drops. In other words, the system did not fail by ignoring the ROA. It failed because the ROA described production routing incorrectly.
That is the common-mode point. Before RPKI, each network’s route filters and judgment could fail in different ways. With RPKI, many networks can consume the same signed entity. This is good when the entity is correct: a wrong-origin hijack can be rejected widely. It is dangerous when the entity is wrong: legitimate routes can be rejected widely. The shared source of truth becomes a shared failure mode.
The answer is not to avoid RPKI. Refusing to validate because authorizations can be wrong leaves the old BGP trust problem intact. The answer is to treat ROA data as production change control. Creating the first ROA for a resource holder, changing maxLength, moving origins, or deaggregating prefixes should be handled like a high-impact routing change. It needs review, simulation, monitoring, rollback and alerting.
This is especially important for small or concentrated networks. North Korea’s public internet footprint is limited compared with a hyperscale provider, which made the incident easier to analyze. But the same pattern can affect universities, governments, banks, CDNs, regional carriers or emergency-service networks. A small number of prefixes can still carry critical services. A wrong ROA can turn a security control into an availability incident.
maxLength is a policy decision, not a form field
The optional maxLength field is where many ROA mistakes become outages. A ROA for a covering prefix can authorize only that prefix length or can allow more-specific announcements up to a stated maximum. If the network normally announces /24s under a /22 but the ROA authorizes only the /22, validators see the /24s as invalid. That appears to be the public explanation of the North Korea incident. The field was not a cosmetic detail; it encoded whether production routes were allowed to exist.
Operators sometimes prefer narrow maxLength values because overly broad authorizations can weaken protection. If a /22 ROA allows /24s, then unauthorized more-specifics using the same origin may be easier to treat as valid. If it does not allow /24s, legitimate traffic engineering or deaggregation may fail. The right value depends on actual routing intent, emergency plans and monitoring. There is no universally safe autopilot setting.
This makes maxLength a governance question. Who knows the production route set? Who approves deaggregation? Who maintains ROAs when prefixes move, announcements change or providers are added? Who receives alerts when a route turns invalid? Who can correct the entity outside business hours? Who verifies that a newly published ROA matches BGP before relying networks begin rejecting invalids? These questions sound procedural, but they determine whether a security deployment protects or breaks reachability.
APNIC guidance on cleaning up invalid routes and RIR materials on incorrect ROAs point to the practical repair path: find the invalid route, inspect the ROA, correct the maxLength or origin, and wait for relying-party caches and BGP propagation to converge. That sequence should be rehearsed. A first-ever ROA for a country, agency or enterprise should not be published as if it were a low-risk paperwork update.
The problem also belongs in contract language. Managed network providers, RIR account holders and outsourced routing teams may share responsibility for ROA creation. A customer may not know that a provider changed a ROA until users report failure from validating networks. Contracts should specify who owns ROA data, who approves maxLength, what monitoring exists, and what evidence is provided after a validity-state change.
Fail-open and fail-closed incentives are uneasy
RPKI creates an incentive tension. If networks reject invalid routes, they help stop hijacks and misoriginations. If they accept invalid routes, they avoid breaking reachability when a legitimate network publishes a faulty ROA. The North Korea incident sits at that tension. The routes became invalid. Networks that enforced rejection reduced reachability. Networks that were permissive may have kept paths available but also preserved a route-security weakness.
This tension is sometimes used as an argument against strict validation. That is too simple. A security control that never blocks anything cannot protect against the attack it was built to stop. But a security control that blocks production traffic because of stale or wrong data will create pressure to disable it. The sustainable answer is to improve data hygiene and alerting so that invalid legitimate routes become rare, quickly detected and quickly corrected.
Research on benign RPKI conflicts and operator incentives makes this point at scale. Misconfigurations persist, and networks that reject invalids can lose traffic when the invalid state is benign. That creates economic pressure against adoption. The fix is not to normalize bad data. It is to make bad data visible, provide pre-publication checks, warn resource holders before route state changes, and create emergency correction paths.
Route-origin validation also changes who pays for mistakes. A resource holder or account administrator may publish a faulty ROA. The immediate connectivity loss may be experienced by users and downstream services. Transit providers enforcing ROV may be blamed for dropping traffic even though their policy is doing what the security model says it should do. The party that created the bad entity may not receive all of the support calls. That cost split can undermine trust unless evidence identifies the true source of invalidity.
A mature accountability record should therefore avoid the lazy phrase “RPKI caused the outage.” More precisely, an inaccurate authorization made legitimate production routes invalid, and validating networks that reject invalids enforced that statement. The root problem was data-governance failure in a shared security system.
Monitoring must watch the control plane and the authorization plane
Traditional routing monitoring watches BGP announcements: origins, paths, prefix lengths, withdrawals and propagation. RPKI requires a second monitoring layer: the authorization plane. A route can change validity without the BGP speaker changing its announcement. A newly published ROA, expired certificate, repository failure or maxLength change can convert yesterday’s valid route into today’s invalid route. Monitoring only BGP is no longer enough.
This is why services such as bgp.tools invalid-route alerts matter. A prefix that turns RPKI invalid is an urgent production signal. It may indicate a hijack, a wrong origin, a maxLength mismatch, a stale ROA, a repository problem or a planned change gone wrong. The operator needs to know quickly which case applies. For a critical network, that alert should page someone with authority to change the ROA or routing announcement.
RIPE Labs’ later discussion of real-time routing analysis and incident visualization points toward a useful future: combine BGP views, RPKI validity, route propagation and reachability evidence in one workflow. During the North Korea incident, external observers could see the validity change and propagation drop. A resource holder should have at least that level of visibility for its own prefixes before the public notices.
Monitoring should also be pre-change. Before publishing a ROA, a tool should compare intended ROAs against current BGP announcements and flag every route that would become invalid. If the result is intentional, the operator should schedule the routing change and ROA change together. If it is not intentional, the tool should stop the publication. This is ordinary change-management logic applied to cryptographic route data.
Public-sector networks need special attention. Agencies often rely on contractors, shared services or upstreams for routing. If ROA administration sits with one team and service continuity sits with another, a maxLength mistake can land between ownership boundaries. A continuity plan should name the RPKI account holder, the route-set owner, the emergency contact and the evidence needed to prove recovery.
Verifiable repair is better than reassurance
A faulty ROA incident should not end with “fixed.” It should end with evidence. Which ROA was wrong? Which prefixes became invalid? Which origin was authorized? What maxLength was set? When was the entity published? Which route collectors saw propagation drop? When was the ROA corrected? How long did relying-party caches take to converge? Which networks still rejected the route after correction? These details let other operators learn and let affected users trust the repair.
The North Korea incident is externally documented, but it is not accompanied by the kind of full operator postmortem that a large enterprise or public agency should provide after an equivalent outage. External analysis can reconstruct much of the event, but internal evidence would answer why the ROA was created that way, whether checks existed, who approved it, and what changed afterward. Those facts matter because the same mistake class can recur anywhere.
For RIRs and tooling providers, the lesson is to make dangerous ROA changes hard to do silently. Interfaces should show current BGP announcements, simulate validity outcomes, warn about maxLength conflicts, provide rollback guidance and encourage alerts. The goal is not to remove operator agency. It is to make the consequence of a signed entity visible before it affects global reachability.
For networks validating RPKI, the lesson is to keep enforcing while improving exception handling. Operators need visibility into invalid routes they reject, contacts for resource holders, and policy for emergency assessment. Rejecting invalids should not mean ignoring customer pain; it should mean using evidence to identify whether the route is malicious, mistaken or stale and then pushing correction to the right owner.
The bottom line is that RPKI turns routing trust into data. That is progress. But data becomes infrastructure when enough networks rely on it. A faulty ROA can therefore be an infrastructure incident, not a clerical error. Governance has to catch up with the power of the signed entity.
The security control became an availability dependency
Route-origin validation is designed to make networks safer by rejecting routes that conflict with signed authorization. That design is exactly why a faulty ROA can cause an outage. The control is not decorative; validating networks actually use it. When a legitimate route becomes invalid because of a bad maxLength or origin statement, the networks that reject invalids are enforcing the resource holder’s published data. The outage is therefore a sign that RPKI has become operationally meaningful, not a sign that it is useless.
This matters for how organizations describe the risk. If leaders say “RPKI broke us,” they may disable the validator and return to an older, weaker trust model. If they say “our route authorization data did not match our routing,” they can fix the true problem. The North Korea incident is best understood as a mismatch between the authorization plane and the routing plane. The BGP announcements continued to exist. The signed authorization changed their global validity state.
An availability dependency created by a security control should be governed with the same seriousness as any other production dependency. DNSSEC trust anchors, certificate transparency logs, OCSP responders, RPKI repositories and validator feeds all sit in this category. They are security systems, but they affect whether production traffic flows. Treating them as compliance artifacts rather than live infrastructure invites operational surprise.
The common-mode risk grows with adoption. When only a few networks reject RPKI-invalid routes, a faulty ROA has limited reach. When many major networks reject invalids, the same faulty ROA can have broad effect. That is not an argument against adoption. It is an argument for rigorous publication controls. A shared security mechanism has to become more disciplined as it becomes more successful.
The incident also suggests a more careful metric for RPKI programs. Coverage percentage is not enough. A network can have high ROA coverage and still create risk if maxLength values are wrong, stale or too broad. A better metric combines coverage, validity alignment, stale-entity review, maxLength policy, alerting, repository health and correction time. The goal is not just “we have ROAs.” The goal is “our ROAs accurately describe the routes we intend the internet to accept.”
RIR and account workflows are part of the control surface
ROAs are often created through RIR portals or delegated tools. That means the user interface, account permissions, approval workflow and warning system are part of the security control. A well-designed validator cannot compensate for a publication workflow that lets a high-impact maxLength mistake pass without warning. The North Korea incident shows why ROA creation should include simulation against current BGP announcements before publication.
A portal can tell an operator: if you publish this ROA, these currently visible routes will become invalid. That warning is not speculative. It follows directly from route-origin validation logic. If the operator intends to withdraw those routes, the warning helps coordinate timing. If the operator did not intend the invalidity, the warning prevents an outage. RIRs and tooling vendors should treat that simulation as a safety guard, not an optional convenience.
Account ownership also matters. In many organizations, the person who can publish ROAs is not the same person who manages routers or service continuity. A registry administrator may be acting from an address-management view, while the NOC sees BGP announcements and the application team sees outages. If those teams are not connected, the authorization plane can change without the routing plane adapting. The fix is ownership mapping: every ROA should have a routing owner, service owner, emergency contact and review cadence.
Permissions should be scoped. Not every registry account user should be able to make high-impact ROA changes without review. Changes that would invalidate currently observed routes should require confirmation, perhaps a second approver for critical resources. Emergency correction paths should exist, but emergency creation of dangerous entities should be visible and logged. Again, the point is not bureaucracy. It is to respect the operational power of a signed route authorization.
RIR guidance on incorrect ROAs and cleanup is valuable because it normalizes the idea that invalid states often come from ordinary mistakes. That is constructive. Shame does not improve route-security data. Clear warnings, better tooling, shared examples and fast correction paths do. The incident should motivate RIRs, managed-service providers and resource holders to improve the workflow around ROA data, not to retreat from publishing it.
Validators need evidence for exception handling
Networks that reject invalid routes also need an exception-handling discipline. If a customer or public service complains that a route is unreachable because it is RPKI-invalid, the validating operator needs to know what evidence would justify any temporary override. Blindly accepting invalid routes undermines security. Refusing to help diagnose a benign invalid route undermines trust in deployment. The middle path is evidence-based triage.
The first question is whether the invalidity is caused by origin mismatch, prefix-length mismatch, expired or missing publication, repository failure or validator state. Each cause points to a different owner. An origin mismatch may be hijack or stale migration. A prefix-length mismatch may be a maxLength mistake. A repository failure may affect many prefixes. A validator cache issue may be local. Good tooling should classify the invalidity quickly.
The second question is whether reachability loss is broad. Route collectors, looking glasses, RIS/RouteViews, commercial monitoring and customer reports can show whether many networks dropped the route or only a few. That evidence helps decide urgency and communication. A single invalid route with limited impact may be handled through ordinary ticketing. A critical public-service prefix invalidated across many validating networks requires immediate escalation.
The third question is who can repair the source of truth. If the resource holder published the wrong ROA, the clean fix is to update the ROA, not to ask every validating network to override policy. If the BGP announcement is wrong, the clean fix may be to change the route. If both are changing as part of a migration, the fix is coordinated sequencing. Exception handling should push repair to the correct owner rather than normalizing local bypasses.
This is where public incident records help. When a known incident such as the North Korea faulty ROA is documented, operators can use it as training material. They can ask whether their NOC would have recognized the invalidity, whether alerts would have fired, whether registry contacts were current and whether a rollback could happen outside business hours. A good incident becomes a rehearsal for the next one.
Common-mode dependency requires independent checks
Common-mode failure means many parties fail in the same way because they depend on the same component or assumption. In RPKI, the signed authorization entity can become that shared component. If it is right, many networks improve together. If it is wrong, many networks can reject together. Independent checks are therefore essential before publication and after change.
One independent check is BGP comparison. Compare intended ROAs against current global announcements. Another is staged monitoring. Publish in a way that allows rapid observation of validity changes and rollback. Another is external alerting from services not operated by the resource holder. A local dashboard may say the entity exists; an external monitor may show that a route is now invalid across the public internet. Both are useful, and neither should be the only signal.
A second independent check is human review of policy intent. Does the network ever announce /24s under this /22? Does it have DDoS mitigation that deaggregates? Does it use multiple origin ASNs during failover? Does a provider announce on its behalf? Does a migration require temporary dual origin? A ROA can be syntactically correct and operationally wrong if it ignores these realities. The reviewer needs to understand routing intent, not only registry syntax.
A third check is expiration and repository health. A ROA can become invalid or unavailable through certificate or repository issues, not only through maxLength mistakes. Validators have cache behavior and failure modes. Resource holders should monitor whether their RPKI repository is reachable and whether relying-party views match expected entities. A signed entity that nobody can retrieve is not a dependable control.
Common-mode thinking also affects communication. If a faulty ROA invalidates a critical route, many validating networks may independently reject it. The resource holder needs a public status channel or contact that explains the correction. Otherwise each provider may open separate tickets and spend time diagnosing the same cause. A concise public note can reduce duplicated work and accelerate convergence.
The incentive problem is solvable if evidence improves
RPKI adoption faces an incentive problem because the benefits of rejecting invalid routes are distributed, while the pain from a benign invalid route can be immediate and local. A provider that rejects invalids may get blamed by customers when someone else publishes a bad ROA. A provider that accepts invalids may avoid the support call but contribute to an unsafe global routing system. Better evidence can reduce that tension.
If invalid alerts clearly identify the responsible ROA, affected prefix, origin, maxLength and likely owner, the validating provider can explain the issue and point to the fix. If RIR tools warn before publication, fewer benign invalids occur. If resource holders receive alerts immediately, they can correct before many users notice. If public incident reports normalize cleanup, organizations are less tempted to hide mistakes. Each evidence improvement lowers the cost of strict validation.
Procurement can help. Large buyers should ask transit and cloud providers whether they reject invalid routes and how they handle benign invalid events. They should also ask who manages the buyer’s own ROAs if the buyer has address space. A buyer that pressures providers to accept invalid routes during every mistake undermines routing security. A buyer that maintains clean ROAs and expects strict validation improves the ecosystem.
Regulators and government networks should take the same stance. Public-sector address resources should have ROA ownership, maxLength policy, route monitoring and emergency correction. Government procurement can ask providers for RPKI validation while also requiring support workflows for invalid-route diagnosis. Security and availability should be managed together rather than traded off under stress.
The North Korea faulty ROA incident is a compact reminder that route security is no longer only about keeping attackers out. It is also about keeping authority data accurate. The signed statement has power. That power deserves change control, monitoring and accountability.
The reader decision for ROA governance
A reader should not treat the faulty ROA case as a reason to distrust RPKI. The better decision is to treat ROA governance as production governance. If an organization has address space, it needs an owner for ROA data, a map of normal and emergency announcements, a maxLength policy, pre-publication simulation, alerts for invalidity, a rollback path and a contact who can correct entities quickly. Without those controls, the organization has a signed route policy but not a managed route policy.
For resource holders, the immediate question is whether every visible route is covered by an intentional and accurate ROA. That includes origin AS, prefix length and maxLength. It also includes exceptional cases: DDoS providers, backup transit, anycast, traffic engineering, migration windows and emergency deaggregation. If the route plan and the ROA plan live in different tools with different owners, the risk is already present.
For validating networks, the decision is to reject invalids while building humane diagnosis. Strict validation improves the internet, but customers need clear evidence when an invalid route is benign. Operators should be able to explain the invalidity, point to the responsible entity and help the resource holder fix the source of truth. That protects security without turning every mistake into pressure to disable validation.
For RIRs and tooling providers, the decision is to make dangerous ROA changes hard to publish silently. Show current announcements. Simulate validity. Warn before invalidating live routes. Keep audit trails. Encourage alerts. Provide emergency correction guidance. A good interface can prevent a routing outage before the cryptographic entity leaves the portal.
The North Korea incident is compact because the public footprint was small enough to analyze. The lesson is large because the dependency is global. As RPKI adoption grows, the quality of the signed data becomes as important as the decision to validate. The internet should keep moving toward rejection of invalid routes, but that future requires better care for the authority data that makes routes valid.
The failure class is larger than one country
The North Korea example is useful because it is visible, but the failure class is not country-specific. Any resource holder that announces more-specific routes under a covering allocation can create the same problem with a narrow maxLength. Any organization that moves prefixes between origin ASNs can create origin mismatch. Any managed network provider that changes ROAs without coordinating with the NOC can invalidate production traffic. The common pattern is a signed statement that no longer matches operational reality.
That means every RPKI program should include a periodic reconciliation job. Take the routes visible in global BGP. Take the ROAs currently published. Compare origin and maxLength. Flag every invalid and every not-found route that should be covered. Review every overly broad authorization that permits more-specifics the network does not intend to announce. This reconciliation is not a one-time onboarding task. Routing changes. Providers change. DDoS mitigation changes. Mergers, divestitures and cloud migrations change origin plans. The authorization plane must follow the routing plane.
The best long-term outcome is cultural. Operators should become as uncomfortable with stale ROAs as they are with stale DNS records for critical services or expired certificates on public endpoints. The signed entity is small, but the dependency can be large. Treating it as living infrastructure is the difference between route security that earns trust and route security that is disabled after the first painful mistake.
That culture also needs a change-review habit. A ROA edit should not be treated as a clerical registry update when it can change reachability under strict validation. The reviewer should ask what route is live now, what route will be live after a provider change, whether more-specifics are intentionally authorized, whether any DDoS or backup origin needs temporary authority, and how the organization will know if the published entity made traffic invalid. The rollback plan should be just as explicit as the change plan. If the answer is “wait for someone to complain,” the signed data is not under production control.
Cloud providers, registries, route-server operators and large enterprises all have a stake in making that habit normal, because strict validation works best when the authority data is boringly accurate.
The same habit should cover ownership transfer. Address resources move through acquisitions, registry updates, provider changes, cloud migrations and disaster-recovery designs. A ROA that was correct under one operating model can become harmful under the next. Governance therefore needs a handover checklist: who owns the entities, who receives alerts, who approves maxLength, who can revoke stale authorization, and who verifies global route visibility after the change. The North Korea record is useful because it makes the failure small enough to understand.
The next failure may involve a bank, public agency, CDN customer, or emergency service whose routing plan changes during stress. Signed route authority should be ready for that stress before validation enforces it.
Typography
Typography
Typography is the art and technique of arranging type to make written language legible, readable, and visually appealing. It involves selecting typefaces, point sizes, line lengths, line-spacing, and letter-spacing.
- Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
- Key elements include font selection, kerning, tracking, and leading.
- Good typography enhances readability and conveys mood or tone in design.
The bottom line
The accountability standard is practical control joined to public evidence. The strongest record does not pretend that every actor controlled every outcome. It identifies who could prevent the failure, who could detect it, who could limit blast radius, who could notify affected parties, who could repair the trust relationship, and what evidence proves that the repair reached the systems and people that depended on it.