Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

Is Crunching Public Data the Right Approach to Detect BGP Hijacks?

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read An attacker who controls one AS can poison the public BGP data that ML hijack detectors depend on, letting forged-origin hijacks pass unnoticed.

desk verdict Plausible poisoning attacks on ML-based BGP hijack detectors, but the DFOH evaluation lacks a no-poisoning baseline, so the marginal effect is unproven. read the letter →

arxiv 2507.20434 v1 pith:J7L5YQ66 submitted 2025-07-27 cs.CR cs.NI

Alessandro Giaconia , Muoi Tran , Laurent Vanbever , Stefano Vissicchio This is my paper
classification cs.CRcs.NI
keywords BGPhijackingforged-originhijackdatapoisoningmachinelearningdetectionmonitorsRouteOriginValidationadversarialsecurity
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

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.

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 (4)
  1. [Section IV-C, Figure 4] 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.
  2. [Section IV-B and IV-C] 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.
  3. [Section V-C, Figure 5] 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.
  4. [Section III-C] 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.
minor comments (4)
  1. [Abstract and Introduction] 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.
  2. [Table I] 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.
  3. [Section IV-C] 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.
  4. [Section VI] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: white-box use of DFOH and BEAM to craft attacks is standard adversarial modeling, not a fitted input renamed as prediction.

full rationale

The paper's derivation chain does not reduce to its inputs. For DFOH, the attacker selects poison links that are false negatives of the classifier, but the reported success metric is the subsequent classification of the hijack link (attacker, victim), not the classification of the poison links; there is no identity between the two, and the text explicitly separates the 15% of attackers needing zero links (pre-existing false negatives) from the 85% requiring crafted links. Selecting poison links by querying a white-box copy of the target is a standard adversarial ML methodology, not a statistical fit that forces the outcome. For BEAM, the evaluation includes a baseline comparison ('an additional 10% of prefixes ... compared to the baseline scenario without pollution'), and the threshold increase is a computed consequence of the injected scores, not an assumed conclusion. The only overlapping-author citation ([44], by Vanbever and Vissicchio) appears in related work as background and is not load-bearing for the poisoning attacks. The absence of a no-poisoning control arm in Figure 4 is a legitimate internal-validity concern about attribution of the observed success rates, but it is a correctness/evidence gap, not a circularity as defined here; the attack's inputs (crafted announcements) are not equivalent to its outputs (hijack evasion) by construction.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The central claims rest on several taken-for-granted premises about BGP propagation, RPKI behavior, and attacker knowledge. The paper's simulations depend on these premises; none are verified with independent experiments in the paper.

free parameters (4)
  • Mean BGP announcement repetition rate = 6.43 per hour
    Measured from RouteViews update data for March 2024 and used to amplify the number of BEAM-polluting announcements seen by monitors. It is an empirical input, not a derived result.
  • DFOH historical topology window = 300 days
    Assumed from the DFOH architecture description (Section IV-A) as the length of history used to build the knowledge base. The poisoning attack must occur before the hijack and be retained in this window.
  • DFOH quarantine period for new legitimate links = 30 days
    Assumed in Section IV-C to model how DFOH treats a newly acquired legitimate transit connection before it is trusted; this widens the attacker's pool of poisonous ASes.
  • Number of attacker ASes in BEAM simulation = 5
    The paper selected 5 random ASes for the BEAM threshold pollution experiment, a small sample that limits statistical confidence in the reported percentages.
assumptions (5)
  • domain assumption The Internet's ASes propagate BGP announcements toward monitors without dropping crafted routes containing fake links.
    Section III-C assumes that a sub-prefix announcement with forged origin reaches monitors because upstreams cannot verify the link and ROV accepts NotFound routes. Any significant filtering would stop the poisoning before it reaches the knowledge base.
  • domain assumption ROV-enabled ASes follow RFC 7115 and do not drop routes with NotFound RPKI status.
    The poisoning methodology in Section III-C relies on NotFound status being accepted by ROV filters, despite real-world variation in operator policy.
  • domain assumption Attackers can compute which fake links DFOH will misclassify as legitimate and what BEAM's current threshold is.
    Section IV-B assumes the attacker selects poisonous links based on DFOH's false-negative set; Section V-B assumes the attacker can estimate BEAM's dynamic threshold from public data. The paper does not demonstrate this capability for DFOH.
  • domain assumption DFOH's classifier mistakes selected fake links as legitimate and adds them to its historical topology graph.
    The knowledge-base poisoning attack in Section IV-B requires that crafted links be accepted into the graph used for later comparisons; this is assumed rather than shown with an actual system.
  • domain assumption The attacker can create a ROA for a sub-prefix they own authorizing a fake origin AS.
    In Section III-C, the attacker can optionally create a ROA that includes the fake origin AS B, making the announcement RPKI-valid and avoiding NotFound filters. This assumes the attacker controls the ROA for their own prefix.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Is Crunching Public Data the Right Approach to Detect BGP Hijacks?." pith.science (2026). https://pith.science/paper/J7L5YQ66

@misc{pith2026250720434,
  author       = {Pith},
  title        = {Pith review of: Is Crunching Public Data the Right Approach to Detect BGP Hijacks?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/J7L5YQ66}},
  note         = {Machine review of arXiv:2507.20434}
}
read the original abstract

The Border Gateway Protocol (BGP) remains a fragile pillar of Internet routing. BGP hijacks still occurr daily. While full deployment of Route Origin Validation (ROV) is ongoing, attackers have already adapted, launching post-ROV attacks such as forged-origin hijacks. To detect these, recent approaches like DFOH [Holterbach et al., USENIX NSDI '24] and BEAM [Chen et al., USENIX Security '24] apply machine learning (ML) to analyze data from globally distributed BGP monitors, assuming anomalies will stand out against historical patterns. However, this assumption overlooks a key threat: BGP monitors themselves can be misled by adversaries injecting bogus routes. This paper shows that state-of-the-art hijack detection systems like DFOH and BEAM are vulnerable to data poisoning. Using large-scale BGP simulations, we show that attackers can evade detection with just a handful of crafted announcements beyond the actual hijack. These announcements are indeed sufficient to corrupt the knowledge base used by ML-based defenses and distort the metrics they rely on. Our results highlight a worrying weakness of relying solely on public BGP data.

Figures

Figures reproduced from arXiv: 2507.20434 by the authors.

Figure 1
Figure 1. Example of hijack for prefix 1.0.0.0/8 owned by AS [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. General architecture of a monitor-based hijack detection system. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Monitor Poisoning Attack: Attacker H announces a prefix with forged [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Evaluation of the DFOH poisoning attack. Left: Distribution of hijack success rates across 1,000 simulated attackers targeting all other ASes. Each [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Effectiveness of the BEAM threshold pollution attack. The plot shows the percentage of prefixes an attacker can successfully hijack (evading detection) [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Hijack detection rate improvement when using an increasing number [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Path Dynamics in a Deployed Path-Aware Network: A Measurement Study of SCIONLab

    cs.NI 2025-09 conditional novelty 5.0 of 10

    A four-week SCIONLab measurement finds path churn with average lifetimes as short as 8.6 hours, asymmetric path availability, and a throughput-versus-latency trade-off when using multiple paths at once.

Reference graph

Works this paper leans on

44 extracted references · 41 canonical work pages · cited by 1 Pith paper

  1. [1]

    A System to Detect Forged-Origin Hijacks,

    T. Holterbach, T. Alfroy, A. D. Phokeer, A. Dainotti, and C. Pelsser, “A System to Detect Forged-Origin Hijacks,” in Proc. USENIX NSDI , 2024

    work page 2024

  2. [2]

    Learning with Semantics: Towards a Semantics-Aware Routing Anomaly Detection System,

    Y . Chen, Q. Yin, Q. Li, Z. Liu, K. Xu, Y . Xu, M. Xu, Z. Liu, and J. Wu, “Learning with Semantics: Towards a Semantics-Aware Routing Anomaly Detection System,” in Proc. USENIX Security , 2024

    work page 2024

  3. [3]

    A survey of bgp security issues and solutions,

    K. Butler, T. R. Farley, P. McDaniel, and J. Rexford, “A survey of bgp security issues and solutions,” Proceedings of the IEEE , vol. 98, no. 1, pp. 100–122, 2010

    work page 2010

  4. [4]

    Not just another BGP Hijack,

    A. Siddiqui, “Not just another BGP Hijack,” https://manrs.org/2020/04/ not-just-another-bgp-hijack/, 2020

    work page 2020

  5. [5]

    YouTube Hijacking: A RIPE NCC RIS case study,

    R. NCC, “YouTube Hijacking: A RIPE NCC RIS case study,” https://www.ripe.net/about-us/news/ youtube-hijacking-a-ripe-ncc-ris-case-study/, 2008

    work page 2008

  6. [6]

    KlaySwap – Another BGP Hijack Tar- geting Crypto Wallets,

    A. Siddiqui, “KlaySwap – Another BGP Hijack Tar- geting Crypto Wallets,” https://www.manrs.org/2022/02/ klayswap-another-bgp-hijack-targeting-crypto-wallets, 2022

    work page 2022

  7. [7]

    Hackers emptied Ethereum wallets byreaking the basic infrastructure of the internet,

    R. B. bm, “Hackers emptied Ethereum wallets byreaking the basic infrastructure of the internet,” 2018

    work page 2018

  8. [8]

    The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1,

    R. Bush and R. Austein, “The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1,” RFC 8210, Sep. 2017. [Online]. Available: https://www.rfc-editor.org/info/rfc8210

    work page 2017

Show all 44 references
  1. [9]

    The resource public key infrastructure (rpki): A survey on measurements and future prospects,

    N. Rodday, ´I. Cunha, R. Bush, E. Katz-Bassett, G. D. Rodosek, T. C. Schmidt, and M. W ¨ahlisch, “The resource public key infrastructure (rpki): A survey on measurements and future prospects,” IEEE TNSM, 2023

    2023

  2. [10]

    RPKI ROV Deployment Reaches Major Milestone,

    D. Madory, “RPKI ROV Deployment Reaches Major Milestone,” https: //manrs.org/2024/05/rpki-rov-deployment-reaches-major-milestone/, 2024

    2024

  3. [11]

    ARTEMIS: Neutralizing BGP Hijacking Within a Minute,

    P. Sermpezis, V . Kotronis, P. Gigis, X. Dimitropoulos, D. Cicalese, A. King, and A. Dainotti, “ARTEMIS: Neutralizing BGP Hijacking Within a Minute,” IEEE/ACM ToN, 2018

    2018

  4. [12]

    BGPsec Protocol Specification,

    M. Lepinski and K. Sriram, “BGPsec Protocol Specification,” RFC 8205, Sep. 2017. [Online]. Available: https://www.rfc-editor.org/info/rfc8205

    2017

  5. [13]

    RouteViews Project,

    U. of Oregon, “RouteViews Project,” www.routeviews.org/routeviews/, 2024

    2024

  6. [14]

    Routing Information Service (RIS),

    R. NCC, “Routing Information Service (RIS),” www.ripe.net/data- tools/stats/ris/, 2024

    2024

  7. [15]

    Thousandeyes,

    Cisco Systems, “Thousandeyes,” n.d. [Online]. Available: https: //www.thousandeyes.com/

  8. [16]

    Explaining and harnessing adversarial examples,

    I. J. Goodfellow, J. Shlens, and C. Szegedy, “Explaining and harnessing adversarial examples,” 2015. [Online]. Available: https: //arxiv.org/abs/1412.6572

    2015 arXiv

  9. [17]

    Wild patterns: Ten years after the rise of adversarial machine learning,

    B. Biggio and F. Roli, “Wild patterns: Ten years after the rise of adversarial machine learning,” Pattern Recognition, vol. 84, p. 317–331, Dec. 2018. [Online]. Available: http://dx.doi.org/10.1016/j.patcog.2018. 07.023

    2018 doi

  10. [18]

    Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format,

    L. Blunk, C. Labovitz, and M. Karir, “Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format,” RFC 6396, Oct. 2011. [Online]. Available: https://www.rfc-editor.org/info/rfc6396

    2011

  11. [19]

    BGP Monitoring Protocol (BMP),

    J. Scudder, R. Fernando, and S. Stuart, “BGP Monitoring Protocol (BMP),” RFC 7854, Jun. 2016. [Online]. Available: https://www. rfc-editor.org/info/rfc7854

    2016

  12. [20]

    A deep learning approach for ip hijack detection based on asn embedding,

    T. Shapira and Y . Shavitt, “A deep learning approach for ip hijack detection based on asn embedding,” in Proceedings of the Workshop on Network Meets AI & ML , ser. NetAI ’20. New York, NY , USA: Association for Computing Machinery, 2020, p. 35–41. [Online]. Available: https:...

    2020

  13. [21]

    Isp self-operated bgp anomaly detection based on weakly supervised learning,

    Y . Dong, Q. Li, R. O. Sinnott, Y . Jiang, and S. Xia, “Isp self-operated bgp anomaly detection based on weakly supervised learning,” in 2021 IEEE 29th International Conference on Network Protocols (ICNP) , 2021, pp. 1–11

    2021

  14. [22]

    Servperso systems – bgp and lir services for small network operators,

    “Servperso systems – bgp and lir services for small network operators,” https://www.servperso.net/, 2025

    2025

  15. [23]

    ifog gmbh – web hosting, vps, ip transit, and lir services,

    “ifog gmbh – web hosting, vps, ip transit, and lir services,” https://ifog. ch/en, 2025

    2025

  16. [24]

    Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI),

    R. Bush, “Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI),” RFC 7115, Jan. 2014. [Online]. Available: https://www.rfc-editor.org/info/rfc7115

    2014

  17. [25]

    The Interconnection Database,

    “The Interconnection Database,” https://www.peeringdb.com/

  18. [26]

    Stable internet routing without global coor- dination,

    L. Gao and J. Rexford, “Stable internet routing without global coor- dination,” IEEE/ACM Transactions on Networking , vol. 9, no. 6, pp. 681–692, 2001

    2001

  19. [27]

    Caida as relationships dataset,

    “Caida as relationships dataset,” https://www.caida.org/catalog/datasets/ as-relationships/, 2025

    2025

  20. [28]

    Using dynamic time warping to find pat- terns in time series,

    D. J. Berndt and J. Clifford, “Using dynamic time warping to find pat- terns in time series,” in Proceedings of the 3rd International Conference on Knowledge Discovery and Data Mining , ser. AAAIWS’94. AAAI Press, 1994, p. 359–370

    1994

  21. [29]

    Route views bgp update archive - march 2024,

    U. of Oregon Route Views Project, “Route views bgp update archive - march 2024,” https://archive.routeviews.org/route-views.wide/bgpdata/ 2024.03/UPDATES/, 2024

    2024

  22. [30]

    Cidr report,

    T. Bates, P. Smith, and G. Huston, “Cidr report,” https://www.cidr-report. org/, 2025, accessed: 2025-04-29

    2025

  23. [31]

    SCION Overview,

    C. de Kater, N. Rustignoli, and A. Perrig, “SCION Overview,” Internet Engineering Task Force, Tech. Rep., 2024

    2024

  24. [32]

    Let the market drive deployment: a strategy for transitioning to BGP security,

    P. Gill, M. Schapira, and S. Goldberg, “Let the market drive deployment: a strategy for transitioning to BGP security,” in Proc. ACM SIGCOMM, 2011

    2011

  25. [33]

    Disco: Sidestepping rpki’s deployment barriers,

    T. Hlavacek, I. Cunha, Y . Gilad, A. Herzberg, E. Katz-Bassett, M. Schapira, and H. Shulman, “Disco: Sidestepping rpki’s deployment barriers,” in Proc. NDSS, 2020

    2020

  26. [34]

    Are we there yet? on rpki’s deployment and security,

    Y . Gilad, A. Cohen, A. Herzberg, M. Schapira, and H. Shulman, “Are we there yet? on rpki’s deployment and security,” in Proceedings of the Network and Distributed System Security Symposium (NDSS) , 02 2017

    2017

  27. [35]

    Bgpmon: A real-time, scalable, extensible monitoring system,

    H. Yan, R. Oliveira, K. Burnett, D. Matthews, L. Zhang, and D. Massey, “Bgpmon: A real-time, scalable, extensible monitoring system,” in Proceedings of the 2009 Cybersecurity Applications & Technology Conference for Homeland Security , ser. CATCH ’09. USA: IEEE Computer Societ...

    2009 doi

  28. [36]

    Bgpalerter,

    N. G. I. Network, “Bgpalerter,” https://github.com/nttgin/BGPalerter, 2019

    2019

  29. [37]

    Cloudflare Radar’s new BGP origin hijack detection system,

    M. Zhang and C. Martinho, “Cloudflare Radar’s new BGP origin hijack detection system,” https://blog.cloudflare.com/bgp-hijack-detection/, 2023

    2023

  30. [38]

    Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration,

    D. R. McPherson, S. Amante, E. Osterweil, L. Blunk, and D. Mitchell, “Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration,” RFC 7682, Dec. 2015. [Online]. Available: https://www.rfc-editor.org/info/rfc7682

    2015

  31. [39]

    Irr hygiene in the rpki era,

    B. Du, G. Akiwate, T. Krenc, C. Testart, A. Marder, B. Huffaker, A. C. Snoeren, and K. Claffy, “Irr hygiene in the rpki era,” in Passive and Active Measurement , O. Hohlfeld, G. Moura, and C. Pelsser, Eds. Cham: Springer International Publishing, 2022, pp. 321–337

    2022

  32. [40]

    Pitfalls in machine learning for computer security,

    D. Arp, E. Quiring, F. Pendlebury, A. Warnecke, F. Pierazzi, C. Wressnegger, L. Cavallaro, and K. Rieck, “Pitfalls in machine learning for computer security,” Commun. ACM , vol. 67, no. 11, p. 104–112, Oct. 2024. [Online]. Available: https://doi.org/10.1145/ 3643456

    2024

  33. [41]

    On evaluating adversarial robustness,

    N. Carlini, A. Athalye, N. Papernot, W. Brendel, J. Rauber, D. Tsipras, I. Goodfellow, A. Madry, and A. Kurakin, “On evaluating adversarial robustness,” 2019. [Online]. Available: https://arxiv.org/abs/1902.06705

    2019 arXiv

  34. [42]

    The threat of adversarial attacks on machine learning in network security – a survey,

    O. Ibitoye, R. Abou-Khamis, M. el Shehaby, A. Matrawy, and M. O. Shafiq, “The threat of adversarial attacks on machine learning in network security – a survey,” 2023. [Online]. Available: https://arxiv.org/abs/1911.02621

    2023 arXiv

  35. [43]

    Global bgp attacks that evade route monitoring,

    H. Birge-Lee, M. Apostolaki, and J. Rexford, “Global bgp attacks that evade route monitoring,” 2024. [Online]. Available: https: //arxiv.org/abs/2408.09622

    2024 arXiv

  36. [44]

    On the effectiveness of bgp hijackers that evade public route collectors,

    A. Milolidakis, T. B ¨uhler, K. Wang, M. Chiesa, L. Vanbever, and S. Vissicchio, “On the effectiveness of bgp hijackers that evade public route collectors,” IEEE Access, vol. 11, pp. 31 092–31 124, 2023

    2023

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.