{"id":"9c15cb44-5c17-4653-87f3-7f5a6a95e727","arxiv_id":"2507.20434","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"BGP hijackers can make ML-based detectors DFOH and BEAM miss forged-origin hijacks by injecting a few crafted announcements that poison the public monitoring data.","lead":"This paper shows that attackers can poison the public BGP routing data used by two recent machine-learning defenses, DFOH and BEAM, enabling forged-origin hijacks to evade detection. It simulates injecting only a handful of crafted route announcements that corrupt the systems' knowledge bases and inflate their alarm thresholds.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"DFOH attack evaluation lacks a no-poisoning baseline; reported success rates may largely reflect DFOH's inherent false negatives rather than the effect of the crafted poison links.","rationale":"The reader's verdict is CONDITIONAL, and I agree that the paper's quantitative claims are not yet fully supported. The reader's stated weakest assumption is about real-world propagation of poison routes through monitors and filters (Section III-C); that is a plausible concern, but the paper does give an argument for propagation via sub-prefixes of attacker-owned space and RFC 7115's NotFound handling, so it is not the most decisive gap. The more load-bearing issue is the missing control arm in the DFOH evaluation: the paper's own data shows that a nontrivial fraction of attacks succeed with zero poison links, yet Figure 4 presents only post-poisoning results. This directly undermines the causal claim that the poison announcements cause evasion. A baseline would settle it. The BEAM evaluation, in contrast, does compare against a no-pollution baseline, and the countermeasure section includes quantitative simulations, so the concern is specifically targeted at the DFOH half of the central claim. Because the reader already conditioned acceptance on stronger evidence, my concern does not change the verdict; it sharpens what evidence is needed.","tokens_in":13588,"tokens_out":3600,"duration_ms":49150,"concrete_test":"Add a no-poisoning control arm to the DFOH experiment in Section IV-C: for each of the 1,000 attacker ASes, run the same forged-origin hijack evaluation with zero injected poison links, using the identical classifier, feature computation, and knowledge-base timing, and record the per-attacker hijack success rate. Then compute the per-attacker delta = (success rate with poisoning) - (baseline success rate) and plot the distribution of deltas, reporting the median and quartiles as well as the fraction of attackers with delta above 5 percentage points. If the median delta is near zero or negative, the claim that a few crafted announcements materially enable evasion is unsupported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central quantitative claim in Section IV is that a handful of poison links lets attackers evade DFOH. However, Figure 4 reports only post-poisoning hijack success rates, with no control arm in which the same 1,000 attackers attempt the same forged-origin hijacks without injecting any poison links. This matters because the paper's own text notes that roughly 15% of attackers needed zero additional links—the hijack link was already a false negative—and the poisoning procedure begins by selecting links DFOH already classifies as legitimate. Without a baseline distribution of success rates, we cannot attribute the observed high success rates to poisoning: they could pre-exist as classifier blind spots. The conclusion that 'even minimal additional effort allows typical hijacks to evade detection' depends on the marginal effect of the poison announcements being substantial. If the baseline evasion rate is already high for the attackers shown, the crafted links add little; if the baseline is low, the figure overstates the attack's benefit. This is an internal-evidence gap, not a disagreement with consensus, and it is load-bearing for the paper's headline claim.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper argues that ML-based BGP hijack detectors that rely on public monitor data are vulnerable to data poisoning. The authors describe two attacks: a knowledge-base poisoning attack against DFOH, where an attacker injects crafted BGP announcements so that new, fake AS links are misclassified as legitimate, and a threshold-pollution attack against BEAM, where the attacker inflates the dynamic threshold by injecting slightly-anomalous announcements. The evaluation uses BGP simulations with 1,000 attacker ASes for DFOH and 5 attacker ASes for BEAM. The authors conclude that a handful of crafted announcements beyond the hijack itself allows typical forged-origin hijacks to evade detection, and they discuss naive defenses and private-monitor countermeasures.","tokens_in":13770,"tokens_out":3078,"duration_ms":40527,"significance":"If the central claim holds, the paper identifies a real and under-explored attack surface: public BGP monitor data can be manipulated by adversaries to corrupt the knowledge bases and thresholds of ML-based detectors. The choice of DFOH and BEAM as case studies is apt, and the DFOH simulation is large in scale. The paper also takes seriously the question of how poisoned announcements could propagate, discussing RPKI NotFound handling and upstream filtering. However, the current evidence does not yet quantify the marginal effect of poisoning, because the evaluations lack no-poisoning baselines and the attack procedures assume access to the target model's own classifications. The significance of the work depends on closing these gaps.","major_comments":[{"comment":"The DFOH evaluation reports only post-poisoning hijack success rates. The text notes that roughly 15% of attackers needed zero additional links, meaning those attacks succeeded even without poisoning. Without a control arm that measures hijack success for the same 1,000 attackers when no poison links are injected, the marginal benefit of the poisoning is unquantified. This matters because the headline conclusion—that 'minimal additional effort allows typical hijacks to evade detection'—depends on poisoning substantially increasing success above the classifier's existing false-negative rate. Please add a baseline distribution and report the incremental success attributable to poisoning.","section":"Section IV-C, Figure 4"},{"comment":"The poisoning procedure selects poisonous links by 'identifying potential false negatives in DFOH's classification' and querying the classifier itself. This makes the evaluation partly self-referential: the attacker is given access to the exact model they are trying to evade, and the success metric is influenced by the model's pre-existing blind spots. The threat model in Section III-A does not state that the attacker has white-box access to DFOH. Please either evaluate a black-box variant in which the attacker only uses public BGP data and observable features, or explicitly justify why white-box access is the appropriate threat model for the deployed system.","section":"Section IV-B and IV-C"},{"comment":"The BEAM experiment uses only five randomly selected attacker ASes, and the reported result—that 10 distinct polluting announcements raise the threshold by about 5% and allow an additional 10% of prefixes to be hijacked—is presented without per-attacker variance or confidence intervals. With n=5, the finding may not be representative. In addition, the injected announcements are calibrated to fall just below BEAM's current threshold, which is the very threshold being attacked; this assumes the attacker can compute BEAM's dynamic threshold exactly. Please report per-attacker results, confidence intervals, and a sensitivity analysis for error in the attacker's threshold estimate.","section":"Section V-C, Figure 5"},{"comment":"The feasibility of both attacks rests on the claim that a crafted route with a forged origin AS, announced on a sub-prefix of the attacker's own address space, will propagate through the Internet and be ingested by public monitors. This is asserted rather than demonstrated. The paper argues that upstream providers cannot exclude a business relationship and that ROV-enabled ASes accept NotFound states per RFC 7115, but it does not account for other real-world filtering, route flap damping, or monitor-side collection policies. Please provide empirical evidence that such announcements are actually collected by RouteViews/RIS, or a realistic propagation simulation including common inbound filters, to support the assumption that poisoning reaches the targeted systems.","section":"Section III-C"}],"minor_comments":[{"comment":"There are several typos: 'occurr' in the abstract, 'byreaking' in reference [7], 'direction of the money' in Figure 1, and 'security,y' in Section VII. These should be corrected before publication.","section":"Abstract and Introduction"},{"comment":"Table I reports feature importance scores derived from training on 2024-03-01 data, but the paper does not state how much the scores vary across training days. Given that the attack targets the most important features, a stability analysis would strengthen the claim that PeeringDB is a persistent attack surface.","section":"Table I"},{"comment":"The description of the enhanced attacker model—acquiring additional connectivity through commercial BGP transit services—is important, but the waiting time of 30 days for DFOH's quarantine period is mentioned only in passing. Please state explicitly how this waiting time is incorporated into the attack cost and whether it affects the claimed practicality.","section":"Section IV-C"},{"comment":"The private-monitor simulation reports detection rates for random and best-case monitor selection, but it does not model false positives or the cost of private monitoring. A sentence clarifying that these results are upper bounds on detection capability would help the reader interpret Figure 6.","section":"Section VI"}],"recommendation":"major_revision","confidential_remarks":"The paper addresses a timely and important question, and the attack direction is novel enough for a security venue. My main concern is evaluation rigor: the absence of no-poisoning baselines for DFOH, the white-box selection of poison links, and the very small BEAM experiment currently prevent the paper from supporting its strong conclusions. I would be willing to accept after a major revision that addresses these points. I would also encourage the authors to release code and data for reproducibility."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The core idea is real and worth taking seriously: ML-based BGP hijack detectors that ingest public monitor data can be poisoned by an attacker announcing sub-prefix routes with forged origins. Prior work focused on hiding hijacks from collectors, not on corrupting the models themselves. That is a genuine gap, and the two attacks—knowledge-base poisoning for DFOH and threshold pollution for BEAM—are specific and mechanistically sound.\n\nThe paper is clearly written, the threat model is sensible, and the authors are honest about several limitations, including the 30-day quarantine for new legitimate links and the use of commercial transit to expand attacker connectivity. The countermeasure discussion is even-handed, and the related work is appropriately scoped.\n\nThe evaluation is where it gets shaky. The DFOH experiment in Figure 4 reports only post-poisoning success rates. There is no control arm showing how many of the same 1,000 attackers would succeed without any poison links. The paper even says ~15% of attackers needed zero links, which means those hijacks were already false negatives. Since the poison link selection queries the very DFOH classifier whose evasion is the success metric, the high success rates could be largely pre-existing classifier blind spots rather than the effect of poisoning. That gap is load-bearing: the headline claim that 'even minimal additional effort allows typical hijacks to evade detection' requires the marginal effect to be large. The BEAM evaluation uses only five attacker ASes, so the apparent 10% improvement is thin, and there is no code or data release to check the simulation pipeline. The propagation assumption—that forged-origin sub-prefix announcements will survive to public collectors—is argued from RFC 7115 but not empirically demonstrated. That is a softer concern, but still worth flagging.\n\nThe paper deserves a serious referee because the idea is novel and the attacks are plausible, but it is not ready in this form. Who gets value? Researchers in BGP security and ML-based monitoring, who will find a useful attack catalog and a reminder that public data is manipulable. I would send it to peer review with a request for a baseline control, a larger BEAM sample, and ideally code/data release. I would not cite the quantitative results in my own work until those are addressed.","headline":"Plausible poisoning attacks on ML-based BGP hijack detectors, but the DFOH evaluation lacks a no-poisoning baseline, so the marginal effect is unproven.","tokens_in":14325,"tokens_out":2409,"would_cite":false,"duration_ms":28328,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"An attacker who controls one AS can poison the public BGP data that ML hijack detectors depend on, letting forged-origin hijacks pass unnoticed.","keywords":["BGP hijacking","forged-origin hijack","data poisoning","machine learning detection","BGP monitors","Route Origin Validation","adversarial machine learning","BGP security"],"falsifier":"Deploy a test AS that announces such crafted sub-prefix routes with forged origins while observing public BGP feeds: if the announcements are filtered by upstreams or never reach collectors, or if a running DFOH and BEAM instance does not incorporate the fake links and shifted thresholds as predicted, the attack would not work as described.","tokens_in":13356,"feed_emoji":"🌐","tokens_out":4588,"duration_ms":48583,"temperature":0.7,"pith_summary":"This paper argues that state-of-the-art machine-learning defenses against BGP hijacks are vulnerable to data poisoning by the very attackers they are meant to catch. An adversary who controls an Autonomous System can announce a handful of crafted routes, using a sub-prefix of their own address space with a forged origin, so that public BGP monitors ingest the fake data. Once ingested, that data corrupts the historical knowledge base or statistical thresholds that DFOH and BEAM rely on, letting a subsequent forged-origin hijack evade detection. If the simulations are right, monitor-based defenses give a false sense of security because the public data they crunch is actively manipulable.","feed_headline":"A handful of crafted BGP routes blinds hijack detectors","feed_subtitle":"Simulations show ML defenses can be poisoned with few fake announcements, letting forged-origin hijacks pass unnoticed.","key_machinery":"The load-bearing mechanism is a crafted BGP announcement of a sub-prefix the attacker legitimately controls, with a forged origin AS: the attacker's upstream cannot filter it because the forged AS could in principle be a new customer, and ROV-enabled ASes accept it as RPKI 'NotFound' per RFC 7115, so the route propagates to public monitors and enters the detector's knowledge base. The attacker exploits the detector's inherent false-negative rate to choose which fake links will be swallowed, and uses BGP's natural oscillation, roughly 6.43 repeated observations per announcement per hour in March 2024 data, as an amplification factor for threshold pollution.","core_discovery":"The paper's central claim is that a small number of extra BGP announcements, on top of the hijack itself, can make two recent ML-based detectors miss forged-origin hijacks. Against DFOH, the attacker selects 'poisonous' ASes whose fake links DFOH would misclassify as legitimate, announces sub-prefix routes claiming those ASes as origin, and thereby corrupts the historical topology graph so that the later attacker-victim link looks less anomalous. Against BEAM, the attacker injects route changes whose path-difference scores fall just below the current dynamic threshold; these scores are counted as normal, inflating the threshold until the real hijack falls beneath it. In large-scale BGP simulations, over 100 of 1,000 simulated attackers could hijack more than 80% of all other ASes after poisoning DFOH, and around ten crafted announcements sufficed to raise BEAM's threshold by roughly 5%, adding about 10% more hijackable prefixes.","pith_inferences":["If the poisoning route is as easy to propagate as the paper assumes, the same logic extends to any monitor-based detector that learns normalcy from public BGP feeds, not just DFOH and BEAM; detectors that train on such data inherit the vulnerability.","The paper leaves open whether real-world hijackers already use such poisoning; a natural test is to replay known forged-origin hijack events against the detectors while scanning historical update streams for the signature 'sub-prefix with forged origin' pattern.","A concrete hardening direction the paper only gestures at is for detectors to weight or discard observations that arrive via short-lived commercial transit sessions, though this could also create new false positives."],"forward_implications":["Poisoning DFOH requires very few links: about 15% of simulated attackers needed zero additional links, 14% needed one, and 28% needed two.","The attack succeeds at scale: more than 100 of 1,000 simulated attacker ASes could hijack over 80% of all other ASes after poisoning.","BEAM's dynamic threshold is a soft target: roughly ten distinct polluting announcements raised the threshold by about 5% and let attackers hijack an additional 10% of prefixes.","Naive fixes fail: removing a feature category like PeeringDB degrades DFOH's detection, and per-prefix thresholds are impractical for BEAM due to scale and data sparsity.","Private monitoring helps only marginally: even 1,000 randomly selected private monitors detected fewer than 3% of poisoned links in simulation."],"supporting_citations":[{"why":"Describes DFOH, the forged-origin hijack detector that the knowledge-base poisoning attack targets.","marker":"[1]"},{"why":"Describes BEAM, the semantics-aware anomaly detector whose dynamic threshold is polluted in the attack.","marker":"[2]"},{"why":"Provides the Type-0/Type-1 hijack taxonomy and the ARTEMIS hybrid-monitoring approach used as baseline and context.","marker":"[11]"},{"why":"Supplies the general adversarial-example result that crafted inputs can mislead machine-learning classifiers.","marker":"[16]"},{"why":"Surveys adversarial machine learning and grounds the claim that ML systems are vulnerable to deliberately altered inputs.","marker":"[17]"},{"why":"RFC 7115 is cited to argue that ROV-enabled ASes accept routes with RPKI 'NotFound' status, letting poisoning announcements propagate.","marker":"[24]"},{"why":"PeeringDB is the feature source the attacker manipulates by choosing poisonous ASes geographically close to the victim.","marker":"[25]"},{"why":"Defines the Gao-Rexford valley-free routing model that DFOH uses to score AS-path patterns, which the crafted links must satisfy.","marker":"[26]"},{"why":"Provides the March 2024 BGP update measurements used to model oscillation amplification in the BEAM threshold pollution evaluation.","marker":"[29]"}],"fun_headline_variants":["Few crafted BGP routes blind hijack detectors","Data poisoning fools ML-based BGP hijack detectors","A handful of routes can evade BGP hijack detection","BGP hijack detectors vulnerable to tiny route poisoning","ML defenses for BGP hijacks fall to few fake routes"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The attack depends on crafted routes with a forged origin AS, announced on a sub-prefix of the attacker's own address space, actually propagating through the Internet to public monitors and being ingested by the detectors.","fun_headline_variants_meta":{"raw":{"variants":["Few crafted BGP routes blind hijack detectors","Data poisoning fools ML-based BGP hijack detectors","A handful of routes can evade BGP hijack detection","BGP hijack detectors vulnerable to tiny route poisoning","ML defenses for BGP hijacks fall to few fake routes"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000227,"raw_usage":{"total_tokens":1477,"prompt_tokens":954,"completion_tokens":523,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":570,"completion_tokens_details":{"reasoning_tokens":455}},"tokens_in":570,"tokens_out":523,"duration_ms":6238,"temperature":1.0,"reasoning_tokens":455,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T13:34:23.138429+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deploy a test AS that announces such crafted sub-prefix routes with forged origins while observing public BGP feeds: if the announcements are filtered by upstreams or never reach collectors, or if a running DFOH and BEAM instance does not incorporate the fake links and shifted thresholds as predicted, the attack would not work as described.","supporting_citations":[{"cited_title":"A System to Detect Forged-Origin Hijacks,","cited_arxiv_id":null,"evidence_quote":"Describes DFOH, the forged-origin hijack detector that the knowledge-base poisoning attack targets."},{"cited_title":"Learning with Semantics: Towards a Semantics-Aware Routing Anomaly Detection System,","cited_arxiv_id":null,"evidence_quote":"Describes BEAM, the semantics-aware anomaly detector whose dynamic threshold is polluted in the attack."},{"cited_title":"ARTEMIS: Neutralizing BGP Hijacking Within a Minute,","cited_arxiv_id":null,"evidence_quote":"Provides the Type-0/Type-1 hijack taxonomy and the ARTEMIS hybrid-monitoring approach used as baseline and context."},{"cited_title":"Wild patterns: Ten years after the rise of adversarial machine learning,","cited_arxiv_id":null,"evidence_quote":"Surveys adversarial machine learning and grounds the claim that ML systems are vulnerable to deliberately altered inputs."},{"cited_title":"Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI),","cited_arxiv_id":null,"evidence_quote":"RFC 7115 is cited to argue that ROV-enabled ASes accept routes with RPKI 'NotFound' status, letting poisoning announcements propagate."},{"cited_title":"The Interconnection Database,","cited_arxiv_id":null,"evidence_quote":"PeeringDB is the feature source the attacker manipulates by choosing poisonous ASes geographically close to the victim."},{"cited_title":"Stable internet routing without global coor- dination,","cited_arxiv_id":null,"evidence_quote":"Defines the Gao-Rexford valley-free routing model that DFOH uses to score AS-path patterns, which the crafted links must satisfy."},{"cited_title":"Route views bgp update archive - march 2024,","cited_arxiv_id":null,"evidence_quote":"Provides the March 2024 BGP update measurements used to model oscillation amplification in the BEAM threshold pollution evaluation."}],"review_version":1}