When two ASNs announce the same prefix: hijack, anycast, or handover

A shape, not a verdict

The closest thing to a rule against this is a 1996 guideline: RFC 1930's section seven is literally titled One prefix, one origin AS, and says a prefix should generally belong to only one AS. It is a best practice, not a protocol constraint, and the routing system has always carried exceptions. The 2023 measurement study of persistent cases found long lived MOAS, defined there as a conflict visible for at least 30 days, on roughly one to two percent of visible IPv4 prefixes across 2017 to 2023, about 24,000 prefixes in its January 2023 snapshot. More than 80 percent of MOAS conflicts never last that long, and among the persistent ones the overwhelming case is exactly two origins, about 95 percent for IPv4. Three or more concurrent origins is uncommon, and mostly not anycast either, which we will come back to, because the anycast folklore is the most common misreading in this area.

The benign mechanics, case by case

The founding study of MOAS conflicts, from 2001, already catalogued the ordinary causes: exchange point prefixes announced by every AS at the exchange, and the classic multihoming without BGP, where a customer prefix reached over a static or internal route looks, from BGP's view, like it belongs to the upstream, so the upstream's AS originates it while the customer's AS originates it elsewhere. The 2023 study adds the modern texture: among persistent two origin pairs, almost half sit in a customer and provider relationship with each other, a considerable number trace to mergers and acquisitions, and sibling networks of one organisation are a small slice. The same study detected no relationship at all between the two origins for around half of the pairs, so these categories account for part of the persistent population rather than all of it, and the relationship check narrows the question without closing it. Handover overlap is a benign cause with a clock on it: during a transfer or migration the old and new announcer can legitimately overlap, and APNIC even keeps a seller's ROAs alive for two weeks after a live transfer so exactly this overlap does not break validation.

DDoS scrubbing deserves its own paragraph because it manufactures this shape on purpose, and whether you see it depends on the contract. Cloudflare's Magic Transit documentation describes both branches: a customer who brings their own ASN keeps it as the BGP origin, with Cloudflare's AS13335 merely prepended on the path, so no second origin ever appears; a customer without an ASN originates from AS13335 itself, or from Cloudflare's AS209242 on older onboardings, so their prefix shows a Cloudflare origin. That reading is available only if your organisation actually onboarded with the provider: the origin AS in an announcement is unsigned, so a scrubbing vendor's ASN on space you have no record of contracting to protect is unexplained rather than confirmed, and unexplained is where the temperature rises rather than falls. Check whether a parent organisation or an upstream arranged the protection before you treat it as forged, because vendor onboarding errors and upstream originated customer space both produce this shape. On demand protection advertises the prefixes only around attacks, so in the provider origin branch the second origin flickers into view for hours or days and goes quiet again. Akamai's Prolexic page documents the same always on versus on demand split, with a /24 or larger requirement. And anycast, precisely: classic anycast is one origin AS announced from many sites, which produces no MOAS at all. A second origin appears only in the per node ASN model that RFC 6382 recommends for globally anycasted critical infrastructure, where possible and appropriate, even instructing reporting systems not to treat the resulting inconsistent origins as undesirable. In the 2023 data, anycast explains under one percent of persistent IPv4 MOAS, so treat "every second origin has an anycast explanation" as the folklore it is, and ask which anycast deployment, run by whom, before you accept it.

The hijack profile, with its caveats

The hostile version of this shape has been measured too. The IMC 2019 serial hijacker study found the hijackers in its ground truth produced almost exclusively short term MOAS announcements, while legitimate networks showed a mix of short and long conflicts, and flagged networks originated MOAS prefixes at roughly triple the median rate of everyone else. But every duration heuristic in this literature comes with its own warning label. The 2001 authors expected multihoming to produce months long conflicts and were surprised by how many short lived ones they found, most of which they attributed to faults rather than attacks, concluding duration alone is not accurate enough to validate a conflict. The 2019 study's own data flagged 18 of the 29 DDoS protection networks its authors could identify, because scrubbing services legitimately rack up short MOAS conflicts by design, and a 2024 reproduction confirmed the methodology while warning that legitimate MOAS use has grown since, naming a DDoS protection network as its example of a false positive. So the profile reads one way only: sudden, short lived, unauthorised overlap is the shape hijacks take, but the shape alone convicts nobody. Run the direction the other way too: an overlap that is months old is not thereby authorised, it may simply be an overlap nobody looked for, and an inferred relationship between two networks is evidence of a relationship rather than of permission to originate. Duration tells you what kind of story to expect, not which one is true.

The settled example is worth keeping in mind because of how fast it moved. In the 2008 YouTube incident, per the RIPE NCC's case study, Pakistan Telecom's AS17557 began announcing 208.65.153.0/24 at 18:47 UTC; YouTube's AS36561 answered with the same /24 at 20:07, creating a two origin conflict that lasted under an hour before an upstream withdrew the hijacked routes at 21:01. Note the timescale, because it is the one an origin history cannot preserve: an overlap of under an hour, seen by a subset of collector peers, is the kind of event a bucketed timeline rounds away. Incidents on that scale are reconstructed from raw collector updates or caught on a live feed; the origin history is where you read the overlaps that lasted.

Reading it in the origin history

On a subnethistory report the persistent version of this question renders in its native shape, within the limits of the underlying view. The origin history is built from route collector data, long range views arrive in multi day buckets and low visibility segments are filtered out, so an overlap that lasted hours may never produce a second row at all. Treat the report as the record of what persisted and as the place to date an arrangement, not as a live alarm; for a live second origin use the streaming monitors named at the end of this post and confirm in a looking glass. Origin history is stored per origin AS and prefix, so a MOAS overlap appears as two concurrent rows for the same prefix, each with first and last seen dates, ordered by the network currently announcing, which is not the same fact as who holds the block. The dates are the discriminators from the sections above made visible: when the overlap began, whether it persists, and whether the second origin has come and gone before. A prefix that flickers into view for hours or days and then goes quiet, repeatedly, is the shape of on demand scrubbing, and it looks very different from the years long steadiness of a multihoming arrangement or the sudden single burst of a hijack; a first activation and a hijack burst look alike in the rows, and the paperwork is what you ask for next. Covering aggregates announced by transit providers are separated out below the origin rows precisely so a carrier's larger block is not mistaken for a second origin. Where confirmed tags exist on an origin's network they supply a severity ladder, hijacked-space, frequent-origin-change, shell-asn or dormant-space-revived raising the temperature, cdn, cloud or hosting context fitting the scrubbing and anycast stories, but the caveats matter more here than anywhere: tags are sparse, they usually sit on the ASN rather than the prefix, a live hijack will typically carry no tag yet, and absence of a tag is never a finding of innocence. The report shows you the dated rows; reading the routing history is the general skill, and the interpretation is yours.

The checks that separate the cases

Three public checks turn the shape into a story. First, RPKI, which is built for exactly this: validity is assessed per prefix and origin pair, and since each ROA names a single origin AS, a prefix genuinely announced by two networks should have one for each, which RIPE's ROA documentation spells out. Where the prefix holder has published no ROAs at all, both origins show NotFound and this check is silent, which is still common and proves nothing either way. Run both pairs through a validation lookup: a second origin that validates against a ROA the prefix holder published is a strong sign of arrangement, and one that shows RPKI invalid the moment your own ROA exists is being rejected by the networks that validate, which is containment rather than a fix, since origin validation is not universally deployed and the same route still propagates through networks that do not check it. Second, the IRR: route objects for both origins, visible side by side in tools like IRRexplorer, tell you whether the second origin was papered in advance. Third, the humans: the announcing network's contacts in PeeringDB and the registry, which the MANRS coordination action exists to keep answerable. The logic of these checks is asymmetric in both directions, and honesty requires saying so. Matching paperwork makes the benign story likely rather than certain, because the origin AS in a BGP announcement is unsigned: validation checks the prefix and origin pair, not the announcer, so a hijacker who forges an origin the prefix holder has already authorised, or who announces a more specific that a loose maxLength still covers, can produce a route that validates. RFC 9319 documents that forged origin case and recommends minimal ROAs to shrink it. Missing paperwork is a question rather than a verdict: a transfer or migration routinely runs ahead of the records, so a new holder mid handover can show no ROA, no route object and no answering contact while being entirely legitimate. What separates the handover from the hijack is not the absence of paper but whether the paper arrives when you ask for it, and whether the registry shows a transfer in or recently completed. Ask first, escalate after.

What to do in each branch

If the second origin is contracted, a scrubbing vendor, an anycast partner, a migration in progress, the work is to make the paperwork match the routing before anyone else asks: a letter of authorization naming the prefixes and the announcing ASN, route objects for the vendor origin, and a ROA per origin so both announcements validate. Cloudflare's newer self serve flow even generates the LOA from your RPKI signed ROA, though the traditional customer supplied letter still rules elsewhere. If the second origin is not contracted, verify before escalating, then escalate where the leverage is: no RIR polices routing, the RIPE NCC's hijacking process, for instance, covers registry records rather than announcements, and the community proposal to make hijacking a policy violation was withdrawn in 2019, so the practical path is the announcing network's upstreams, read straight from the AS path of the offending routes in a looking glass, with contacts for each found through PeeringDB and the registry, and one formal carve out: if the announcer participates in MANRS, a report to the secretariat triggers a documented process that can end in suspension from the publicly listed membership. The emergency lever is deaggregation, announcing more specifics than the offending route, and it has a prerequisite: a more specific your existing ROA does not cover is RPKI invalid and will be dropped by validating networks, so the ROA has to be widened to permit the emergency prefixes as they are announced. That is the opposite of the minimal ROA practice RFC 9319 recommends for normal operation, which is why it belongs in the incident plan rather than the standing configuration. Apple did this in July 2022 when Rostelecom's AS12389 announced a /19 covering its space and Apple answered with 17.70.96.0/21; note the caveats, since even the MANRS write up framed that event as a possible hijack whose intent was never established, the /19 circulated for hours after the /21 appeared, and the lever vanishes entirely at /24, which common filters treat as the longest acceptable IPv4 announcement. And you should not be learning any of this from a customer ticket: RIS Live streams the routing table's changes in real time, and open source monitors like BGPalerter alert when any origin other than the one you declared announces your space. Hijacked or transferred is the forensic procedure when the history is the question. One last mirror: at least one IPv4 broker's due diligence checklist now tells buyers to review MOAS events and ask why a block ever appeared from unrelated ASNs, so an unexplained second origin can follow a block into its next sale, which makes cleaning up stale announcements part of preparing a block for sale, not just routing hygiene.