INCIDENT REPLAY · 2013-02 (almost daily through February; again briefly in May 2013)
Belarus GlobalOneBel traffic redirection
Renesys documented repeated events, minutes to hours long, in which victim prefixes were re-originated so traffic flowed through Belarus and was then forwarded on to the real destination, a working man-in-the-middle. The victim list changed daily.
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: GlobalOneBel and another Beltelecom customer (Belarus) caused; financial institutions, governments and network providers in several countries targeted
The summary at the top is paraphrased from the sources below. Hammerhead's catalog rates its confidence in this account medium.
Sources
What the public record says
- Renesys documented repeated events, minutes to hours long, in which victim prefixes were re-originated so traffic flowed through Belarus and was then forwarded on to the real destination, a working man-in-the-middle. The victim list changed daily.
- Who: GlobalOneBel and another Beltelecom customer (Belarus) caused; financial institutions, governments and network providers in several countries targeted
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.
- The family template (
tools/replays/gen_family_misorigination.py): GLOBALONEBEL-1 (AS 28849), an upstream BELTELECOM-1 (AS 6697) that prefers its customer's routes and filters nothing on that session, the victim, and a third party behind the upstream. GLOBALONEBEL-1 forwards the traffic it draws on to the victim over a second link. - Cisco IOS syntax. No operator here has published configuration, and which vendors they ran is not on the record.
- The upstream's other sessions are filtered and limited, so that the audit's finding is about this session and not the template.
- GLOBALONEBEL-1 exports with the ordinary customer policy, an AS-path filter that passes only what it originates (
^$). A mis-originated prefix is locally originated, so it passes. - Deliberate, by Renesys' account: nobody ran a change review. What is replayed is the provider's side, which believed the routes. The AS numbers are from memory of the Renesys report and are not confirmed.
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.
every network in one snapshot
now: failOn the reconstruction, hammerhead preflight on a before and an after snapshot returned fail, for the reasons below.
Reason text pinned (some reason contains each line)
- GLOBALONEBEL-1 would start originating 198.18.0.0/20, which is inside 198.18.0.0/20 that it learns from
- path change:
First run, before the fixes this batch prompted
first: fail- external advertisements: GLOBALONEBEL-1 would start originating 198.18.0.0/20, which is inside 198.18.0.0/20 that it learns from AS 64510. A more-specific of address space you receive from a peer is not yours to announce
Pinned in tests/gauntlet/replays-misorigination.yaml.
GLOBALONEBEL-1's own router, nothing declared: a new origination is reported, and only a caveat
now: passOn the reconstruction, hammerhead preflight on a before and an after snapshot returned pass.
Caveats pinned (some caveat contains each line; a caveat never moves the verdict)
- GLOBALONEBEL-1 would start announcing 1 prefix(es) to
First run, before the fixes this batch prompted
first: unknownPinned in tests/gauntlet/replays-misorigination.yaml.
GLOBALONEBEL-1's own router, with what the upstream sends declared
now: failOn the reconstruction, hammerhead preflight on a before and an after snapshot with --boundary @belarus_2013/boundary.yaml returned fail, for the reasons below.
Reason text pinned (some reason contains each line)
- GLOBALONEBEL-1 would start announcing 198.18.0.0/20 to
- which is inside 198.18.0.0/20 that
- (AS 6697) advertises to this network (declared by
First run, before the fixes this batch prompted
first: fail- external advertisements: GLOBALONEBEL-1 would start announcing 198.18.0.0/20 to 172.16.1.1 (AS 6697), which is inside 198.18.0.0/20 that 172.16.1.1 (AS 6697) advertises to this network (declared by noc@example.net). A more-specific of address space you receive from a peer is not yours to announce
- external advertisements: GLOBALONEBEL-1 would start announcing 198.18.0.0/20 to 172.16.3.2 (AS 64510), which is inside 198.18.0.0/20 that 172.16.1.1 (AS 6697) advertises to this network (declared by noc@example.net). A more-specific of address space you receive from a peer is not yours to announce
Pinned in tests/gauntlet/replays-misorigination.yaml.
BELTELECOM-1's own router, no change: the audit
now: fail (finding)An audit of one snapshot, no change: hammerhead nqe-library --mode run, check nqe.bgp.ebgp_peer_unfiltered_and_unlimited. Pinned status: fail, a finding whose evidence contains the text below.
Evidence pinned (the evidence contains each line)
- BELTELECOM-1
- 28849
First run, before the fixes this batch prompted
first: pass (no finding)Pinned in tests/gauntlet/replays-misorigination.yaml.
What changed in Hammerhead because of it
From the “What was fixed” table in Hammerhead's replay notes, where each fix landed after a failing test. “Found by” is copied as written; a family name means the batch this incident belongs to.
ROA maximum length
Roa::covers_prefix refused to cover a more-specific beyond maxLength, so such a prefix came back NotFound instead of Invalid (RFC 6811).
Found by: Mis-origination family
--roas <FILE> origin-validates new originations
From the originator's own seat a block that escapes is one new prefix, and only a caveat. With a validator's export it is decidable: "the ROA for 104.244.42.0/24 authorises AS 13414".
Found by: Mis-origination family
An announcement that multiplies
The announcement to an external peer goes from a few prefixes to many in one change.
Found by: Mis-origination family, Level 3
Outbound policy runs before the local AS is prepended
The simulator prepended first, so an outbound filter-list with ^$ matched nothing the router originated.
Found by: Mis-origination family
Many foreign originations are one reason
A mass mis-origination of hundreds of prefixes was hundreds of reasons.
Found by: Mis-origination family
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: Transit providers accepted customer-originated foreign prefixes without filters, which an audit flags; the act itself was not a reviewed change.
Not fixed: A single-prefix hijack from the hijacker's own seat, with no ROA and nothing declared
One new origination is what a legitimate new prefix looks like. pass with the caveat naming it; --roas or --boundary decides it.
Recorded against: Mis-origination family (17 of 28)
Not fixed: A forged-origin hijack
Origin validation passes it by construction. ASPA is not modelled.
Recorded against: Mis-origination family
Imported from docs/replays/belarus-2013/FACTS.md and the replay manifests in the Hammerhead repository at commit 0ee9732.