Safe Host's 2019 Route Leak Made Peer Filtering a Cross-Border

Summary

Frozen event boundary: This article covers the Safe Host AS21217 route leak to China Telecom AS4134 observed on 6 June 2019 and the immediate propagation and recovery evidence. It does not merge the event with the separate 24 June 2019 Verizon, DQE, and Cloudflare leak or with other China Telecom routing controversies.
Counts require attribution: Public accounts describe more than 70,000 routes in some measurements and more than 40,000 IPv4 routes in another reconstruction. The figures depend on collector, interval, route-family, duplicate handling, and what an analyst calls part of the event. No one public count should be presented as a universal global table.
A control-plane path is not a surveillance finding: Route collectors and path measurements can show that AS4134 entered observed paths and that some traffic followed unexpected routes from specific vantage points. They do not by themselves prove the physical location of every packet, packet inspection, data access, or malicious intent.
Responsibility follows operational control: Safe Host controlled what AS21217 exported. China Telecom controlled what AS4134 accepted and propagated. Other transit and access networks controlled their own import, preference, onward export, monitoring, and escalation decisions. End users had no practical means to correct the route state.
Relationship uncertainty must remain visible: Public operator discussion did not establish one uncontested commercial label for the Safe Host-China Telecom connection. The observable accountability failure is propagation beyond intended scope, not a retrospective claim that every private contractual term is known.
Registry evidence is necessary but not self-enforcing: ASN, address, IRR, and RPKI records can identify resources and expected origins. They cannot encode every relationship or force a router to reject an unintended path. Running policy determined which announcements became reachable paths.
RPKI addresses only part of the problem: Route-origin validation can reject a conflicting origin when a valid ROA exists. A route leak can retain an authorized origin while traversing an unintended provider, peer, or customer relationship. Relationship-aware filters, customer-cone validation, maximum-prefix controls, explicit defaults, monitoring, and coordination remain necessary.
Recovery needs independent proof: A local configuration correction is not a complete recovery record. Accountable remediation shows withdrawals, replacement paths, convergence from multiple vantage points, residual exceptions, updated filters, tested alarms, and a replay demonstrating that the same announcement class is now rejected or contained.

Freeze the event before assigning responsibility

Infrastructure accountability begins by fixing the event boundary. On 6 June 2019, public routing observers reported that Safe Host, autonomous system 21217, announced a very large set of routes to China Telecom, autonomous system 4134, through an interconnection in Frankfurt. China Telecom accepted the announcements and propagated them. For some observed destinations and vantage points, AS4134 consequently appeared in paths that ordinarily would not have included it. Contemporary and later reports associated the event with disrupted or degraded reachability affecting parts of European mobile and service infrastructure. [1][2][3][4][5][6][7]

Those propositions are strong enough to support a routing-accountability analysis. They do not support every claim that circulated around the incident.

The public record does not disclose the complete Safe Host export configuration, the complete China Telecom import configuration, every route policy entity, all bilateral terms, every local-preference decision, all alert histories, or the identity of each person who approved or changed policy. It does not establish malicious intent. It does not show that all European traffic was affected. It does not prove that every packet whose control-plane path included AS4134 was physically forwarded through the same geography, inspected, retained, or altered.

The date is important because June 2019 contained other routing incidents. The later Verizon, DQE, and Cloudflare leak involved different networks, mechanisms, and service effects. Combining those events would make a dramatic story but a weak accountability record. A remediation owner cannot fix an incident whose route set, time interval, relationship boundary, and responsible controls have been blurred with another event.

The bounded question is therefore precise: how did an extraordinary set of routes leave AS21217, why did AS4134 accept and propagate those routes, how did other networks respond, what evidence shows the resulting path changes, and what evidence would prove that the route state was withdrawn and constrained against recurrence?

This framing also prevents geopolitical inference from replacing engineering evidence. Cross-border routing can have security implications, and operators should treat unexpected international paths seriously. But an unexpected path is first an observable routing event. Intent, access, and legal consequence require additional evidence. The accountability analysis should become more careful, not less careful, when the route crosses a politically sensitive boundary.

The route-count disagreement is an evidence problem, not a reason to dismiss the event

Public descriptions commonly say that AS21217 leaked more than 70,000 routes and that the event lasted for more than two hours. Another incident reconstruction describes more than 40,000 IPv4 routes. [1][2][4][5] These figures are not necessarily mutually exclusive. They can reflect different collectors, address families, time windows, update-versus-prefix counting, path deduplication, and definitions of which announcements belong to the event.

A BGP collector records what its participating peers export to it. One collector may receive an abnormal path that another never sees. A peer may export only its selected best path. An analyst may count unique prefixes, route updates, path variants, or origin combinations. The first observed update at one collector is not necessarily the first bad announcement anywhere, and the last withdrawal at one collector is not necessarily the end of stale state across every network.

Accountable reporting therefore needs a counting protocol. A defensible incident report would state:

which RouteViews, RIPE RIS, operator, or measurement vantage points were used;
the exact start and end timestamps and time standard;
whether IPv4 and IPv6 were both included;
whether the metric counts unique prefixes, updates, path variants, or origins;
how duplicate announcements and route replacements were handled;
which AS-path pattern defined an affected route;
how withdrawals and later normal paths were matched to the abnormal set; and
which parts of the network remained outside observation.

Without that protocol, a route count can become an authority signal rather than evidence. A larger number may attract attention, while a smaller number may appear more conservative. Neither is reliable unless another analyst can reproduce the method.

The uncertainty does not make the event small. Tens of thousands of routes were extraordinary relative to any plausible bounded announcement set for one interconnection. A maximum-prefix or route-volume control should not need a perfectly agreed final incident count before detecting that the received set is radically outside expectation.

This distinction matters operationally. Thresholds should be based on the authorized and expected route set for a relationship, with documented growth margins and explicit exceptions. They should not be based on an assumption that the next failure will resemble the final number in a historical report. The control should react when reality departs from the relationship contract, not only when a famous incident count is exceeded.

A route leak is an executable relationship-policy failure

BGP distributes reachability among independently operated autonomous systems. The base protocol carries prefixes, paths, attributes, and withdrawals. It does not contain a universal commercial truth for every session. Operators express customer, provider, peer, route-server, backup, and special-purpose relationships through configuration, policy generation, communities, filters, and operational process.

A route learned in one relationship is not automatically eligible for export into every other relationship. A customer generally announces its own prefixes and routes for which it is authorized to provide service. A provider may advertise broad reachability to a customer. Peers generally exchange their own and customer reachability rather than providing free transit between unrelated providers. Real agreements can be more complicated, but the existence of exceptions makes explicit policy more important, not less.

RFC 7908 later supplied a taxonomy for routes propagated beyond intended scope. [14] The value of that taxonomy is that it focuses on observable propagation and relationship policy rather than assuming malicious intent. Operator discussion around the 2019 event did not settle every relationship label or one uncontested leak type. [8][9] That uncertainty should remain in the record.

The core external behavior is still visible. AS21217 advertised a route set whose scale and scope were inconsistent with a narrow interconnection expectation. AS4134 accepted and exported enough of that set for the paths to spread. Other networks then applied their own policy: some accepted the path, some may have preferred it, some propagated it, some filtered it, and some retained unaffected alternatives.

Calling this a distributed failure must not make it ownerless. Safe Host controlled the export boundary at AS21217. China Telecom controlled the first visible import and onward-export boundary at AS4134. Each subsequent autonomous system controlled whether the path entered its routing information base, became a selected path, entered the forwarding table, or was announced to another neighbor. Route collectors controlled the quality and retention of independent evidence. Service and access operators controlled resilience and user communication.

The duties are not identical. The exporter has the most direct obligation to constrain what leaves its network. A direct importer has a powerful containment opportunity because it knows the bilateral relationship and can reject announcements that do not fit it. Further networks may have less specific knowledge, but they still control maximum-prefix limits, origin validation, relationship-aware policy, anomaly monitoring, and escalation.

The phrase "BGP accepted the routes" is therefore incomplete. Software running a configured policy accepted the routes. The protocol transported the announcement; operators determined the constraints.

Export accountability begins with an authorized route contract

An exporter should be able to define the route set that a session is permitted to advertise. That contract may be built from customer inventory, routing registry entities, RPKI data, internal service records, delegated authority, and explicit exceptions. Whatever the sources, the resulting policy needs an owner, a generation time, a version, a review path, and a method for proving what reached the router.

For AS21217, a post-event accountability record would distinguish at least four sets:

routes Safe Host was authorized to originate;
customer routes Safe Host was authorized to transit;
broad routes learned from another provider or peer;
routes that the AS21217-to-AS4134 policy actually exported during the event.

The difference between the intended and actual sets is the core technical finding. It is more useful than a generic statement that a configuration error occurred.

Export policy should default to no advertisement until an intended policy is attached. RFC 8212 formalizes the operational value of explicit eBGP import and export policy. [15] A default-reject posture does not solve every generation or attachment error, but it eliminates the dangerous assumption that a new or misclassified session should exchange everything until someone adds filters.

The route contract also needs negative tests. A policy pipeline should prove that it rejects:

a full routing table received from a source that is expected to announce a bounded set;
a prefix not present in the authorized customer inventory;
a path containing an impossible or unauthorized relationship sequence;
an unexpected default route;
a sudden route-count increase outside a documented growth window;
stale routes that remain after authority is removed; and
an exception whose approval has expired.

Configuration review alone is weak evidence because the reviewed source may differ from the generated configuration, deployed candidate, or running state. A credible process records the source data, generated filter, device diff, commit result, observed advertised-route set, and independent collector result.

Change control should be staged. A policy update can be tested against recorded BGP data, applied to a canary session, monitored for unexpected route delta, and rolled back without broad propagation. A route-leak replay should be part of resilience testing, not reserved for an incident.

Export accountability also includes withdrawal readiness. An operator must know how to stop an abnormal announcement quickly without replacing a routing event with a wider outage. That requires named authority, tested commands or automation, peer contacts, route-refresh and session-reset criteria, and external monitors that show whether the change propagated.

Import accountability is the first external containment opportunity

An importer's responsibility is sometimes described as secondary because it did not create the bad announcement. That is too weak for interdomain infrastructure. A direct neighbor controls the first external boundary and often possesses information that distant networks do not: the bilateral relationship, expected route volume, authorized prefixes, known AS paths, exception history, and published contact points.

AS4134 therefore matters independently of AS21217. The public evidence supports that China Telecom accepted and propagated the extraordinary route set. The record does not disclose every filter or internal decision, but the observed result shows that the import and onward-export controls did not contain the event at that boundary.

A relationship-aware importer can combine several controls.

First, prefix filters can be generated from authorized customer and resource records. The data must be current, versioned, and reconciled with the actual service contract. A stale allowlist can reject legitimate growth; an overbroad allowlist can turn the filter into theater.

Second, AS-path constraints can test whether an announcement is plausible for the relationship. A customer should not generally advertise a path implying transit between unrelated providers. Customer-cone data is imperfect, so exceptions and uncertainty need operational treatment, but imperfect relationship evidence can still support detection and review.

Third, maximum-prefix and route-volume controls can detect a radical departure from expectation. The warning threshold should alert an owned channel before the hard limit. The hard response should be documented: reject new routes, shut the session, quarantine the set, or invoke another bounded action. Fail-open behavior must be explicit rather than accidental.

Fourth, explicit import policy prevents a session from becoming permissive because a route map is absent, misnamed, or attached in the wrong direction.

Fifth, origin validation can reject an invalid origin when a valid ROA covers the prefix. It adds strong evidence but does not prove that the path is appropriate.

Sixth, anomaly monitoring can compare received and accepted routes with the relationship baseline, global collectors, and known changes. An alert should include the offending path, route count, expected set, policy version, affected peers, and a safe containment action.

The importer also controls onward export. Even if a route is retained for diagnosis, it need not be propagated to customers, peers, and providers. Separating acceptance, selection, forwarding, and advertisement controls can keep one failure from becoming a distributed event.

These controls impose operational costs. Filters need maintenance. Maximum-prefix limits can create outages if set carelessly. Relationship data can be incomplete. Emergency exceptions can be necessary. Accountability does not deny those tradeoffs. It requires operators to document them, test them, and show why the resulting exposure is acceptable.

AS-path evidence must not be confused with proof about every packet

The cross-border nature of the event attracted understandable concern. Public analyses showed AS4134 appearing in paths for destinations associated with European mobile operators and services. Measurement reports also described traffic following unexpected paths from specific vantage points. [1][2][3][4][5][7]

Four evidence layers must remain distinct.

The first is control-plane propagation. A BGP update observed by RouteViews, RIPE RIS, or another collector shows that a path was announced to that collector's peer. It supports statements about route visibility at a time and vantage point.

The second is route selection. A network may receive multiple paths and select one under local preference, path length, communities, origin validation, and other policy. A collector often sees only the path its peer exports, not every path considered.

The third is forwarding behavior. A selected route may enter the forwarding table and carry traffic, but traceroute or active measurement is needed to test the path from a specific source. Even then, IP-to-location mapping, hidden hops, MPLS, asymmetric routing, load balancing, and response-path differences limit inference.

The fourth is packet handling and security consequence. A forwarding path through an autonomous system does not by itself prove packet inspection, content access, retention, alteration, or intent. Encryption, application protocols, endpoint behavior, and internal network operations matter.

A strong incident account aligns these layers by timestamp. It can say that a route with a particular AS path became visible, that active measurements from specified locations then observed a changed forwarding path or degraded service, and that the behavior normalized after withdrawals. It should not collapse those observations into a universal statement about all traffic.

This discipline is especially important when the path is politically sensitive. The evidence may justify a security investigation and more stringent controls. It does not justify substituting geopolitical suspicion for packet-level proof.

Operators should preserve the data needed for that distinction: raw updates, routing information bases, looking-glass results, traceroutes, flow summaries, packet-loss measurements, application health, time synchronization records, and the method used to map network hops. Retention should be sufficient to reconstruct the period before, during, and after the event.

Route collectors are accountability infrastructure with known blind spots

RouteViews and RIPE RIS provide indispensable independent evidence for interdomain incidents. Their June 2019 archives and measurement documentation make later reconstruction possible. [12][13] RIPEstat also provides an evidence surface for AS21217 and AS4134, though present-day records must not be projected backward without qualification. [10][11]

Collectors are not omniscient. They receive routes from selected peers under those peers' export policies. They may not see a path that is confined to another part of the topology. They may see a best path but not alternatives. Their timestamps record arrival at the collector, not the first global cause. Session resets, duplicate updates, route flap damping, and collector availability can affect the record.

An accountable reconstruction should use more than one collector and document their differences. It should preserve raw files or precise archive references, parsing code or commands, normalization rules, and derived datasets. It should record the collector peer used to make each claim.

Operator telemetry can close some gaps. Received-route and advertised-route snapshots at the direct session show what crossed the relationship boundary. Local routing information bases show selection. Forwarding tables and sampled flows show use. Change logs and policy repositories connect the observed state to deployed configuration. Peer reports add independent confirmation.

The evidence should also preserve negative results. If one collector did not see the path, that does not prove the path was absent globally, but it can constrain propagation. If a service remained reachable from one location, that does not disprove impact elsewhere, but it can reveal path diversity.

Public incident reports often cite a collector graph without explaining these limits. That creates false precision and makes disputes over numbers look like disputes over whether the event occurred. A better report treats the collector as a bounded witness: valuable, reproducible, and incomplete.

Registry records are ledgers, not router enforcement

The Safe Host event sits directly on the control surface of BGP routing, ASN and IP registry evidence, and peering or transit relationships.

An ASN record can identify AS21217 and AS4134. Address registries can identify allocations and assignments. Internet Routing Registry entities can publish intended origins and policy. RPKI can provide signed origin authorization. These records improve uniqueness, accuracy, transfer history, security metadata, and operational coordination.

They do not determine the running path.

A registry entry does not know every private commercial relationship. An IRR object does not force a router to load a generated filter. A ROA says which origin is authorized for a prefix and maximum length; it does not say which providers or peers may carry that route. An abuse or NOC contact does not guarantee that an alert reaches a person with authority to withdraw routes.

This is why registry legitimacy should be understood through the quality of the ledger rather than imagined sovereignty over routing. The recordkeeper provides evidence that operators can use. The running systems, policies, and interconnections determine reachability.

Running-code primacy makes governance testable. A board can require route authorization records, but it should also require evidence that those records are fetched, validated, transformed into policy, deployed, and monitored. An auditor can inspect an IRR route object, but it should trace the entity through the policy generator to a device and inject a conflicting test announcement.

The ledger itself needs controls. Resource records must be unique, current, authenticated, transferable through documented process, and recoverable during organizational or infrastructure disruption. Stale or ambiguous records can make strict filtering operationally risky. Operators may then create broad exceptions, which must have owners, expiration dates, and monitoring.

The reality layer rejects two easy stories. One says decentralized routing means no one is accountable. The other says a central registry can command routes into correctness. The actual system is a network of autonomous operators using shared evidence, bilateral policy, running code, and coordination. Accountability follows the points where those elements can be changed and verified.

Removing AS21217, AS4134, BGP announcements, relationship policy, route collectors, and withdrawal evidence from this article destroys the thesis. The network-control surface is not a metaphor added to a generic corporate incident. It is the incident.

RPKI is valuable, but origin validity is not path authorization

RPKI and route-origin validation are often proposed after routing incidents. They deserve precise treatment.

RFC 6811 describes how a router can classify a route against validated ROA data. [16] A route may be valid, invalid, or not found depending on the announced origin, prefix, maximum length, and available validated records. Rejecting or de-preferring invalid routes can prevent some misoriginations and hijacks.

A route leak can preserve the legitimate origin. The problem may be that an authorized route was exported through an unintended relationship and then propagated further. The origin remains valid while the path policy is wrong. Origin validation alone does not encode who is a customer, provider, or peer, or whether a route learned from one relationship may be exported into another.

That limitation is not an argument against RPKI. It is an argument for layered controls.

An operator should deploy origin validation with documented policy, monitor invalid and not-found routes, maintain its own ROAs, and coordinate exceptions. It should also maintain prefix and path filters, explicit import and export policy, customer-cone evidence, maximum-prefix controls, route-leak detection, peer coordination, and independent monitoring.

RPKI can also strengthen accountability after an incident. It helps distinguish an origin conflict from a relationship leak and supplies signed evidence about authorization at a point in time. Historical validation requires archived validated state; using today's ROAs to judge a 2019 route without qualification can be misleading.

The same caution applies to later standards and practices. RFC 8212, MANRS actions, and NIST guidance provide useful control frameworks. [15][17][18] They should be used to design present remediation, not to invent proof about what every operator had deployed or contractually owed during the event.

Maximum-prefix limits are necessary and easy to misuse

The extraordinary route volume makes maximum-prefix control an obvious question. A direct neighbor that normally announces a bounded set should not be able to send tens of thousands of unexpected routes without warning or containment.

Yet a maximum-prefix limit is not a single number copied from an industry checklist. It must be derived from the relationship's expected route set, legitimate growth, maintenance patterns, address families, and failure impact. A limit set too high does not contain the event. A limit set too low can shut down a healthy session and cause an outage.

A mature design separates warning and action thresholds. The warning should reach an owned operational channel with context before the hard response. The hard response may reject excess routes, preserve the last known authorized set, quarantine the session, or shut it down. The chosen behavior should be tested.

Threshold changes need governance. An emergency increase should identify the requester, evidence, approver, expiration, and monitoring. Otherwise a temporary exception can become permanent exposure.

Volume is also only one dimension. A small number of strategically important prefixes can cause severe impact. Controls should combine volume with authorization, origin validity, path plausibility, relationship scope, destination criticality, and rate of change.

The Safe Host event illustrates why importers should know the expected route count before an incident. If the baseline is assembled only after a leak begins, containment becomes a negotiation under pressure. A frozen authorized set and tested threshold turn the abnormal volume into an immediate, actionable signal.

Other networks still control their own acceptance and propagation

The direct exporter and importer are central, but the route travelled through a wider ecosystem. Cogent and other networks appeared in contemporaneous discussions and reports, sometimes in ways later corrected or clarified. [3][5][6] The lesson is not to assign one undifferentiated blame score. It is to map each observed path segment to the control available at that network.

A further transit network may not know the private details of the original Safe Host-China Telecom relationship. It can still ask whether the path is plausible, whether the route origin is authorized, whether the volume is anomalous, whether the path conflicts with customer-cone data, and whether independent feeds report a leak.

Access and mobile operators control route diversity and service resilience. If critical services rely on paths that share upstream dependencies, one leak can affect multiple brands or regions despite apparent contractual diversity. Topology evidence should therefore complement provider counts.

Content and cloud operators can monitor their prefixes from external vantage points, maintain route-alert contacts, and coordinate with upstreams. They cannot directly configure every transit network, but they can detect unexpected paths and supply evidence that speeds containment.

Internet exchange operators and route-server operators have different roles depending on topology. Their controls may include entity policy, route-server filtering, maximum-prefix settings, and incident coordination. The evidence must establish that they were actually on the relevant path before assigning duties.

Regulators and customers should avoid treating all these parties as interchangeable. The most effective questions follow the route:

What did this network receive?
What did it accept?
What did it select?
What did it forward?
What did it announce onward?
Which policy and evidence governed each decision?
Which alert fired, who owned it, and what action followed?
How did the network prove that abnormal state was withdrawn?

This route-by-route method makes distributed responsibility concrete without pretending that every operator had identical visibility or authority.

Cross-border resilience should be designed, not inferred from provider names

The event also exposed a planning weakness. Organizations often count providers, data centres, or contracts and assume that each name represents an independent network path. BGP policy can make nominally separate services converge on a shared transit, exchange, cable, or autonomous system.

Resilience assessment should inspect actual paths from relevant user regions to critical prefixes. It should test normal and failure conditions, include IPv4 and IPv6, and identify common autonomous systems and facilities. A route leak can change those paths dynamically, so continuous or sampled external monitoring is more useful than a one-time diagram.

Cross-border constraints need explicit treatment. A service may have requirements about latency, jurisdiction, operational access, or exposure. Those requirements cannot be enforced by a contract clause alone if routing changes are invisible. Monitoring should alert when a path enters an unexpected AS or geography, but the alert must preserve uncertainty in geolocation and distinguish control-plane evidence from packet forwarding.

Encryption remains essential because path control is imperfect. It reduces the consequence of unexpected transit, but it does not eliminate availability, metadata, traffic-analysis, or endpoint risks. Routing controls and cryptographic controls solve different problems.

Incident exercises should include a path leak that sends routes through an unexpected international network. The exercise should test technical detection, NOC escalation, provider contacts, customer communication, legal assessment, and evidence preservation. The objective is not to dramatize geopolitical risk. It is to make response responsibilities executable before an ambiguous event occurs.

A credible recovery record proves withdrawal and normalization

Public reporting indicates that the abnormal routing persisted for more than two hours in some observations before paths normalized. [1][2][4][5][7] As with route counts, the exact duration depends on vantage point and definition. One observer's last abnormal route may not represent global convergence.

An accountable recovery record should distinguish:

when the triggering export began;
when the first external observer detected it;
when an alert reached an owned team;
when Safe Host changed or disabled the export;
when AS4134 stopped accepting or propagating the routes;
when direct neighbors observed withdrawals;
when major collectors returned to expected paths;
when forwarding and service health normalized; and
when residual stale or exceptional routes were cleared.

The record should identify the source for each timestamp. Router logs, collector updates, ticket systems, chat records, active measurements, and application health may use different clocks. Time synchronization and normalization are part of the evidence.

Withdrawal proof should operate at multiple layers. A local router can show that it no longer advertises the route. A direct neighbor can show receipt of a withdrawal or replacement. Route collectors can show the abnormal AS path disappearing from their peers. Active measurements can show forwarding normalization. Service telemetry can show recovery.

None of these observations alone proves universal convergence. Together they form a bounded, auditable record.

The report should also identify what changed permanently. Examples include:

a corrected session role or route-map attachment;
a generated authorized-prefix filter;
a customer-cone or path constraint;
lower warning and hard maximum-prefix thresholds;
an explicit default-reject policy;
RPKI validation and ROA maintenance;
an owned anomaly alert;
improved contact and escalation data;
a canary or staged deployment process; and
a replay test using the historical route pattern.

Saying "filters were added" is not enough. The evidence should show the filter input, generated output, deployment result, running state, negative test, and monitoring result.

Residual risk must remain visible. Relationship data can be incomplete. A valid-origin leak can evade origin validation. Exceptions can widen scope. Collectors have blind spots. A hard session shutdown can itself affect availability. The remediation record should explain how those tradeoffs are managed.

The recurrence test is more important than a policy statement

The strongest evidence that remediation works is a controlled replay of the failure class.

The test environment should reproduce a session with the relevant relationship role and a frozen expected route set. It should then introduce:

a route outside the authorized prefix set;
a full-table or high-volume announcement;
an unexpected AS path;
a valid-origin route propagated through an unintended relationship;
an expired exception;
a stale route after authority removal; and
a failure of one policy data source.

The operator should show what each layer does. The exporter should reject or suppress the invalid set. The importer should contain what escapes. Maximum-prefix and anomaly controls should alert. Onward export should remain bounded. The response owner should receive context sufficient to act. The rollback should restore the last known authorized state.

Tests must use the actual policy generation and deployment path. A laboratory filter that differs from production proves little. Results should include software and policy versions, configuration hashes, expected and actual routes, timing, alert delivery, human decisions, and independent observation.

The test should also include failure of the control itself. What happens if the IRR feed is stale, the RPKI validator is unavailable, the policy compiler errors, or the monitoring collector loses a session? Fail-open and fail-closed choices should be deliberate and tied to service criticality.

Executives do not need to inspect every route. They should require evidence that the test occurred, exceptions were explained, failures have owners, and the next test is scheduled. Auditors can sample the underlying artifacts.

This approach turns routing security from an aspiration into an operational claim that can be falsified.

Governance questions should follow control rather than headlines

Boards, regulators, customers, and auditors can ask effective questions without pretending to operate BGP sessions.

Boards should ask:

Which people and systems can change public route announcements?
How many external sessions lack an explicit relationship role?
What proportion of customer sessions use current authorized-prefix filters?
Which sessions have warning and hard maximum-prefix limits?
How many exceptions are open, who owns them, and when do they expire?
When was the last route-leak replay, and what failed?
How quickly can the organization prove withdrawal from independent vantage points?

Transit providers should ask whether customer and peer records match live configuration, whether filters are generated and tested, whether origin validation is applied consistently, and whether onward export is separately constrained.

Data-centre and hosting operators should ask whether routing responsibilities are clear between facility, network, tenant, reseller, and transit provider. A physical hosting contract does not automatically define who owns the AS21217 export policy.

Enterprise and mobile customers should ask for topology evidence, external route monitoring, incident contacts, and route-state proof in post-incident reports. They should avoid equating provider-brand diversity with path diversity.

Auditors should trace a sample resource from registry evidence through policy generation to running configuration and a negative route test. Screenshots of a portal or a written policy are not enforcement evidence.

Regulators should avoid mandating one control as a universal cure. ROAs improve origin evidence. They do not encode every relationship. Maximum-prefix limits contain volume but can cause outages if unmanaged. Effective requirements should focus on outcomes: authorized scope, layered containment, retained evidence, coordination, and tested recovery.

Incident reviewers should reject "human error" as a root cause. The phrase does not explain why one action could export an enormous route set, why a direct neighbor accepted it, why onward safeguards did not contain it, why alerts did or did not fire, or why recovery took the observed time.

Public reporting should distinguish fact, inference, and unknown. It should attribute route counts, duration, relationship descriptions, affected services, forwarding observations, and recovery timing. It should correct errors without erasing the evidence trail.

The accountability test is bounded propagation and verifiable recovery

The 6 June 2019 Safe Host event remains instructive because it joins technical routing policy with cross-border consequence.

AS21217 exported an extraordinary route set. AS4134 accepted and propagated enough of it to change observed paths and affect reachability for parts of European network infrastructure. Further networks made their own acceptance and propagation decisions. Public collectors and measurement systems preserved part of the record.

The evidence does not justify a malicious-intent finding, one universal route count, one uncontested commercial relationship label, or a claim that every packet was inspected or physically followed the same route. Those limits are part of the accountability record.

Responsibility remains concrete. The exporter controlled the route set. The direct importer controlled the first containment boundary. Other networks controlled onward propagation and resilience. Monitoring operators controlled evidence. Service operators controlled user impact response. End users bore consequences without authority over BGP state.

The durable control set is layered: explicit import and export policy, authorized-prefix and path filters, relationship evidence, maximum-prefix controls, origin validation, anomaly monitoring, staged changes, named coordination contacts, independent route observation, and verified withdrawal.

Registry and routing-policy records are indispensable ledgers. They identify resources, origins, and contacts. They do not enforce a path. Running code determines reachability.

A credible operator should therefore be able to prove four things:

it knows which routes a neighbor is authorized and expected to announce;
its running policy rejects or contains announcements beyond that scope;
its monitoring detects abnormal path and volume changes quickly enough for an owner to act; and
after containment, independent evidence shows that withdrawals propagated and expected forwarding returned.

That is the peer-filtering and cross-border accountability test exposed by the Safe Host leak. The standard is not perfect prevention. It is bounded propagation, assigned control, reproducible evidence, and recovery that can be verified outside the network making the claim.

Safe Host's 2019 Route Leak Made Peer Filtering a Cross-Border Accountability Test