Summary

  • The 3 January 2024 incident followed a precise authority chain: compromised registry access enabled hostile ROA changes, validators refreshed at different times, and networks applying local Route Origin Validation policy progressively withdrew reachability.
  • The defensible response is not weaker RPKI. It is stronger control over high-impact writes: transaction-specific authentication, independent approval, bounded delay for exceptional changes, out-of-band notice, signed receipts and rehearsed recovery.

The route did not disappear everywhere at once

At about 14:11 UTC on 3 January 2024, an affected Orange España route began disappearing from networks observed by bgp.tools. The descent was stepped rather than vertical. Different relying parties refreshed signed routing data at different times, and different networks applied different routing policies. The Internet did not receive one central command to disconnect Orange España.

Cloudflare's traffic view records a later customer-facing window. It observed a decline between 16:45 and 19:45 local time, alongside a notable reduction in IPv4 address space announced by AS12479. Kentik's aggregate traffic data placed a large inbound decline between roughly 14:20 and 18:00 UTC. These windows are not mutually exclusive; they measure different vantage points and different consequences.

That distinction matters. A universal outage timestamp would be tidier, but it would conceal the mechanism. The signed state changed first. Validators absorbed it on their own schedules. Operators then decided locally what to do with routes that no longer matched the validated authorisation. Reachability deteriorated as those independent decisions accumulated.

The event is therefore best understood as a signed outage. Its destructive force came from a record that looked cryptographically authoritative, not from a false BGP announcement that every network blindly accepted. The attacker did not need to control the world's routers. Access to one privileged account was enough to influence the evidence those routers' operators had chosen to trust.

What the attacker reached

The public record does not provide a complete forensic chain from the first stolen credential to every action inside the Orange España account. Independent reconstructions say credentials available on the public Internet were used and that the account lacked two-factor authentication. Orange España has not published an account-specific forensic report that settles every step before the unauthorised access.

What is established is narrower. Someone obtained unauthorised access to Orange España's RIPE NCC account and changed its RPKI configuration. Kentik traced ROA activity from 09:28 UTC and identified three materially relevant ROAs published at 09:42. Later changes made large parts of AS12479's announced space evaluate as RPKI-invalid.

That capability is more consequential than an ordinary profile edit. A Route Origin Authorisation binds address space to an autonomous system permitted to originate it. The resulting validated payload is consumed by relying-party software and delivered to routing systems. A hostile write can therefore alter how legitimate, unchanged BGP announcements are classified.

RFC 6811 defines the decisive state. A route is Invalid when at least one validated payload covers the prefix but none matches it. The same standard makes an equally important point: a router must not discard the route merely because of that state unless it is explicitly configured to do so. Validation produces information. Operator policy turns that information into acceptance, lower preference or rejection.

RPKI behaved correctly at the wrong boundary

It is tempting to say that RPKI caused the outage. That diagnosis is too crude. The legitimate routes were rejected because the signed authorisation data said they were illegitimate. Validators processed the data, and networks enforcing rejection of Invalid routes followed their chosen security policy. At that layer, the system behaved predictably.

Kentik's Doug Madory compared the episode to an intruder obtaining router credentials and disabling interfaces. One would not blame the router for executing an authorised command. The relevant failure is how the command became authorised. For Orange España, the high-impact surface sat above route validation: who could create, broaden, replace or revoke the signed records on which validation depended.

The standard anticipated this category of danger. RFC 6811 warns that blocking Invalid routes can create a denial-of-service vector if an attacker can inject or remove records in the validation database. The Orange España event supplied an operational example. It converted a security control from protection against false origin into a means of making true origin look false.

This does not make Route Origin Validation irrational. A network that accepts every Invalid route to avoid this failure would reopen exposure to the hijacks RPKI is meant to constrain. The choice is not between perfect safety and avoidable fragility. It is between different failure paths, each of which must be controlled at the layer where it begins.

Three authorities, not one

The incident separates three kinds of authority that are often compressed into the word “RPKI.”

The first is write authority. Orange España's hosted service account could cause signed routing objects to be published for its resources. This is where identity, privilege, reauthentication, approval and recovery belong.

The second is validation authority. Relying-party software fetched and processed published objects, then provided validated prefix-to-origin data to networks. Refresh intervals, cache behaviour, software resilience and observability shaped when the changed state became usable.

The third is routing authority. Each network decided how to treat Invalid routes. Some rejected them. Some still had paths through networks that did not enforce rejection or through direct relationships. bgp.tools could still observe a minority of paths during the disruption, although its feed set was not a global census.

These authorities are dependent without being identical. The registry service did not command routers. Operators did not create the hostile ROAs. Validators did not choose the business consequence of rejection. Yet the combination converted one compromised account into a distributed loss of reachability.

That is the design lesson. Decentralised enforcement does not cure centralised or weakly guarded input authority. It can amplify a bad signed input precisely because independent operators trust the same cryptographic statement and apply it faithfully.

The recovery was also distributed

Orange España regained control shortly before 18:00 UTC and began publishing corrective ROAs. Kentik observed broad traffic returning around that period. bgp.tools placed the beginning of route-visibility recovery near 17:47 UTC, followed by roughly another hour before most observed feeds again saw the affected prefix.

Restoration could not be instantaneous for the same reason the outage was staggered. Corrected objects had to be published, fetched, validated and reflected in routing decisions. A central account action began the repair, but the operational result depended on many systems reaching the new state.

Residual damage outlived broad recovery. Kentik reported that more than a thousand AS12479 routes remained Invalid immediately after the main incident and that unique announced IPv4 addresses had fallen from about seven million to five million. Some of that state was linked to maximum-length choices in corrective ROAs. Recovery therefore required more than regaining a password; it required restoring an internally coherent authorisation set.

This is why incident closure needs a receipt, not a status message. The holder needs to know which objects were added, changed or revoked; when each repository version became visible; which prefixes remain Invalid; which operators still reject them; and whether a later corrective write unintentionally narrows legitimate more-specific announcements.

The control that followed

RIPE NCC made two-factor authentication mandatory after the incident. That materially reduces the chance that a stolen password alone reaches an account. It does not, by itself, answer every question raised by a high-impact signed write.

Two-factor authentication proves that a second factor participated in login. It does not necessarily prove that two independent people approved a new ROA covering millions of addresses. It does not distinguish a routine correction from a first-ever hosted ROA, an abrupt origin change or a maximum-length choice capable of invalidating many more-specific routes.

The relevant control should follow the blast radius of the proposed change. A narrow, expected ROA renewal and a first-time authorisation across large aggregates should not receive identical treatment. Risk can be estimated before publication from prefix breadth, address count, origin change, maximum length, prior state, current BGP observations and the number of announcements that would become Invalid.

A high-risk write must prove more

The first control is transaction-specific reauthentication. A session that is sufficient to view invoices or edit contacts should not remain sufficient hours later to issue a high-impact routing assertion. The user should present a fresh factor at the moment of the write, with the factor and device recorded in an auditable event.

The second is independent approval for exceptional changes. This need not mean two people for every small ROA. It can be triggered by objective conditions: first use of hosted RPKI, a new origin ASN, coverage of a large aggregate, a restrictive maximum length, a change that would turn many currently observed announcements Invalid, or simultaneous edits across unrelated prefixes.

The third is out-of-band notice before the change becomes widely relied upon. A message should reach designated routing-security contacts through a channel that the active account session cannot silently replace. The notice must show the proposed before-and-after state and the predicted invalid routes, not merely say that a setting changed.

The fourth is a bounded hold with an emergency escape. A short delay can interrupt an attacker who expects immediate propagation, but an inflexible delay could worsen a genuine hijack or block urgent repair. The escape should require stronger approval, a stated reason, narrower duration and an immutable receipt available to the holder and service operator.

The fifth is rapid revocation and rehearsed recovery. The account holder and hosted service need a known path to suspend newly issued objects, restore a last-known-good state, publish corrective material and monitor its propagation. A recovery plan that has never been exercised is an assertion, not continuity evidence.

Running-Code Primacy meets a signed record

Heng Lu's Running-Code Primacy argues that coordination should be limited to what independent networks require: uniqueness, interoperability, routing-adjacent continuity, security assertions and proof of control. It also insists that participants should validate state locally instead of treating institutional publication as reality by itself.

Orange España both supports and complicates that doctrine. Operators did make local decisions. Some rejected Invalid routes, while others preserved paths. The registry service did not possess a sovereign switch over the Internet. Yet a shared signed statement still changed the inputs to many local decisions and produced a broad common consequence.

The correct conclusion is not that publication lacks power. It is that publication gains operational force only through adoption, and that adopted signed state deserves custody proportional to that force. When many networks rely on one class of statement, the authority to create it becomes part of the Internet's effective control surface even if no institution can compel acceptance.

That distinction also prevents the opposite mistake. RIPE NCC's remediation should not be treated as proof that a registry ought to decide broader commercial or political questions. The Orange event justifies narrow security controls around identity and high-risk signed writes. It does not expand the registry's mandate over resource ownership, operator business models or routing policy.

What the event did not prove

No public evidence establishes that every Orange España customer lost service or that every route disappeared. Cloudflare, Kentik and bgp.tools observed different windows and different parts of the system. Their records support a major, multi-hour disruption, not a single universal experience.

The public record also does not prove the complete credential-theft path sometimes repeated in incident summaries. The pre-incident device, malware and credential-market sequence should remain attributed and uncertain unless Orange España or a forensic investigator publishes a verifiable report.

Nor does the event prove that mandatory two-factor authentication is ineffective. RIPE NCC's change materially raises the cost of password reuse and stolen-credential access. The unresolved question is whether the next layer—authorisation of exceptional routing-security writes—has controls proportionate to its potential reachability impact.

The incident left a clean test for future systems. A high-impact signed change should be able to answer who requested it, what fresh proof they presented, who else approved it, which live routes it would invalidate, when it became visible, how it can be reversed and how independent operators can verify the recovery.

That is not bureaucracy added to RPKI. It is the custody discipline required when one signed write can travel through thousands of independent decisions.

Sources