Pith. sign in

REVIEW 4 major objections 6 minor 60 references

Learning to Identify Conflicts in RPKI

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

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

Pith's one-line read The paper claims that a machine-learning system called LOV can tell benign RPKI routing conflicts from hijacks well enough to publish a whitelist of 52,846 safe routes.

desk verdict Substantial, honest RPKI whitelisting work whose central claim rests on a self-referential ground truth; worth refereeing, but the headline numbers stay conditional. read the letter →

arxiv 2502.03378 v1 pith:XVUP5UTT submitted 2025-02-05 cs.CR

Haya Schulmann , Shujie Zhao This is my paper · ORCID
classification cs.CR
keywords RPKIROVBGPhijackingbenignconflictswhitelistmachinelearningrouteoriginvalidationInternetroutingsecurity
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

The paper introduces Learning Origin Validation (LOV), a system for telling apart two kinds of routes that RPKI's Route Origin Validation (ROV) currently treats the same: genuine hijacks and 'benign conflicts' caused by misconfiguration, multi-homing, or routing policy. LOV learns a 'tightness' score between the AS announcing a prefix and the AS authorized by the route-origin certificate (ROA), and uses that score, plus post-hoc verification and a quarantine period, to build a daily whitelist of (AS, prefix) pairs. Over six months of live BGP data, LOV whitelisted 52,846 routes, and the paper estimates that roughly 79% of RPKI-invalid routes per day are benign conflicts rather than hijacks. If true, ROV-enforcing networks can install the whitelist and stop dropping legitimate traffic, removing one of the main economic disincentives to RPKI deployment while still blocking hijacks.

What carries the argument

The load-bearing machinery is a learned tightness relation between the two conflicting origins. For each RPKI-invalid route, LOV compares the origin AS in the BGP announcement with the AS authorized in the covering ROA and computes seven features capturing organizational, business, dependency, registry, and geographic connections; feature values default to 'no relation' so that an uncertain route leans toward being classified as a hijack. The Random Forest combines these into a classification, and the same features, weighted by their importance scores, form the tightness threshold that admits routes to the whitelist. This design lets LOV whitelist long-lived benign routes without weakening ROV's rejection of genuinely unauthorized origins.

What would settle it

Re-run LOV's pipeline on the same six-month BGP data but replace the duration-based ground truth with operator-confirmed outcomes: any (AS, prefix) pair in the published whitelist that an independent hijack report confirms as malicious would refute the claim. A complementary test would feed LOV a set of known short-lived legitimate announcements and count how many never enter the whitelist because they fail the 14-day persistence and activity criteria.

Watch

Extended reading notes

Core claim

The central claim is that benign conflicts and hijacks are separable by the relationship between the two origins involved, not by their behavior alone. The paper defines seven features—OriginMatch, PC, MOAS, Parent, Depen, AltSources, and ASdist—that capture whether the announced origin and the ROA-authorized origin are the same organization, provider and customer, parent and child, mutually dependent, cross-validated by Internet routing registries, or geographically close. A Random Forest trained on these features achieves about 95% accuracy on new benign conflicts and near-100% accuracy on new hijacks. The post-analyzer then checks suspected hijacks for anomalous surges in global AS visibility, and the quarantine stage admits only routes with a tightness score above 0.3, or routes that survive 14 days of behavior monitoring and activity checks. The paper asserts that this pipeline whitelisted 52,846 benign conflicts in a six-month live measurement, with about 79% of daily RPKI-invalid routes attributed to benign causes.

Load-bearing premise

The load-bearing premise is that any route that stayed unchanged and visible for the whole month of June 2022 is benign, and any route in a hijack-monitoring feed is malicious; if a hijack can persist for a month, or a legitimate conflict can last only hours, the training boundary is wrong.

Editorial extensions

If this is right

  • Networks that enforce ROV can install LOV's daily whitelist and stop dropping the roughly 79% of invalid routes that are benign, recovering legitimate traffic and the associated revenue.
  • Because the whitelist targets long-lived benign conflicts rather than short-lived hijacks, it avoids the synchronization and update problems that plague blacklist-based defenses.
  • The measurement identifies four non-human-error causes of benign conflicts—prefix deaggregation, AS-path dependencies, multi-origin ownership, and delayed ROA updates—giving operators concrete targets for fixing their ROA and routing configurations.
  • The finding that about 72% of benign conflicts are prefix-length mismatches with a matching origin raises a testable question about whether ROV should filter all invalid routes or only origin mismatches.
  • Broader ROV adoption becomes more attractive, since operators' main hesitation—loss of legitimate traffic—is addressed by a drop-in whitelist with negligible per-route overhead.

Reading between the lines

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

  • The paper leaves untested whether its duration-based ground truth undercounts short-lived benign conflicts, which would mean the 79% share is an upper bound on the traffic LOV can actually save.
  • A simple policy change suggested by the paper's own data—having ROV accept routes whose origin matches the ROA even when the prefix length exceeds MaxLength—might recover most of LOV's traffic without any machine learning; this is testable by replaying the measurement data through that rule.
  • Because the quarantine requires routes to appear on at least two days in a week and remain active for 14 days, LOV is biased toward stable, frequently-announced prefixes; rarely-used backup prefixes with benign conflicts would continue to be filtered.
  • The paper's confirmed hijack cases include perpetrators in the middle of the AS path, which origin-based validation cannot see; coupling LOV's whitelist with path-validation mechanisms would close a gap that the current design inherits from ROV.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper introduces LOV, a mechanism that uses a machine-learned classifier, a post-analyzer based on AS hegemony anomalies, and a quarantine/review process to whitelist RPKI-invalid BGP routes that are believed to be benign origin conflicts rather than hijacks. The authors train several classifiers on a ground-truth dataset of 2,000 benign conflicts and 2,000 hijacks, select a Random Forest model on cross-validation and on a held-out set, and then apply LOV to six months of live BGP data, reporting that about 79% of daily RPKI-invalid routes are benign and that 52,846 routes were whitelisted. The paper also categorizes root causes of benign conflicts and discusses deployment questions and limitations.

Significance. If the central claim is correct, LOV addresses a practical obstacle to ROV adoption by reducing collateral filtering of legitimate traffic while preserving hijack protection, and the six-month measurement is a useful data point on the prevalence and persistence of RPKI-invalid but benign routes. The paper's feature set is interpretable and largely grounded in public data sources, and the authors are explicit about several limitations, including the confidential nature of the code, data, and models and the acknowledged absence of short-lived benign conflicts from the ground truth. However, the significance of the headline numbers depends on an unvalidated labeling assumption, so the contribution is best assessed as a promising framework whose quantitative claims need stronger independent validation.

major comments (4)
  1. [Section 5.2.1 and Section 5.2.3] The benign ground truth is defined as RPKI-invalid routes that 'remained stable and persistent throughout the period' of May 30 to June 30, 2022, and the same one-month persistence assumption is reused in the holdout evaluation: the 7,223 'new' benign instances in Section 5.2.3 are simply the leftover instances from that same pool. The reported 94.6% accuracy on new benign instances therefore does not demonstrate generalization to independently labeled benign conflicts, and the classifier may simply be learning the persistent-route heuristic. The paper should either obtain benign labels from an independent source (e.g., operator confirmations, known ROA corrections, or IRR/registry cross-checks) or explicitly test how accuracy changes when short-lived RPKI-invalid routes are included in the evaluation.
  2. [Section 7 and Section 8.1.4] The quarantine whitelisting criteria inherit the same duration heuristic used to build the training labels. The 14-day quarantine period is justified by the observed recurrence of classifier-labeled benign conflicts (Section 8.1.1 reports that 80% of recurring conflicts have average frequency below 14 days), and the tightness threshold T_thr=0.3 is chosen from the CDF of classifier-labeled benign conflicts to whitelist 80% of them. Consequently, the whitelist of 52,846 routes is not independently validated against a ground truth that distinguishes benign origin errors from hijacks that persist for weeks. The paper should measure the false-positive rate of the whitelist, for example by checking whitelisted (AS, prefix) pairs against operator confirmations, known hijack databases, or subsequent ROA corrections, and should report how many whitelisted routes later became RPKI-valid or were confirmed as hijacks.
  3. [Section 5.2.1 and Section 9] The paper acknowledges in Section 5.2.1 and Appendix G.1 that short-lived benign conflicts are missing from the training data, and Section 9 states that 'all codes, data, and models are kept confidential and are not publicly available.' This combination is load-bearing for the central claim because the published whitelist cannot be audited and the classifier is not shown to generalize to the very class of transient conflicts that the one-month labeling rule excludes. At minimum, the authors should publish the feature values (which are derived from public data) and the full list of the 52,846 whitelisted (AS, prefix) pairs, or provide an independent audit mechanism, so that the whitelist's false-positive rate can be assessed by others.
  4. [Section 8.1.2 and Section 8.1.3] The measurement results are dominated by AS212483, which the authors suspect of feeding incorrect data to RouteViews collectors, and the post-analyzer is evaluated on only 8 hijacking events, for which it failed to verify 3 of 8 events due to missing hegemony data or threshold shifts (Section 6.3). The paper should quantify the sensitivity of the headline numbers (79% benign, 52,846 whitelisted) to the exclusion or inclusion of data from suspected faulty collectors, and should report the post-analyzer's false-positive rate on known benign routes, since the post-analyzer is tasked with reducing classifier errors but is only tested on incidents.
minor comments (6)
  1. [Abstract and Introduction] The abstract states that LOV 'whitelists 52,846 routes with benign origin errors,' but the whitelist is the output of the full pipeline including the quarantine stage; the phrasing could be clarified to distinguish classifier-identified benign conflicts from whitelisted ones.
  2. [Section 5.1, Table 1] The Depen feature is described as a 'new relationship' but is computed from the existing IHR local hegemony metric; the novelty of the feature definition should be stated more precisely, and the paper should report the coverage of local hegemony values in the training and measurement data, since Section 5.2.4 notes that about 35% of ground-truth routes lack this data.
  3. [Section 5.2.3, Table 3] The holdout hijack set is collected from only 8 radar incidents, and the table reports 'Acc' for the RF classifier per event; the paper should clarify whether these accuracy values are computed on deduplicated routes and whether the same incidents overlap with the BGPmon training period.
  4. [Section 6.2] The Z-test uses 50 historical hegemony values and a significance level of 0.05, but the paper does not describe how the historical window is selected when a route is first observed or when an AS has sparse hegemony data; this should be clarified, since the post-analyzer's failure on 3 of 8 events is attributed to missing data.
  5. [Section 7] The tightness formula T is defined as a weighted sum of the seven features, but the weights are only described as the feature importance scores from Section 5.2.4; providing the exact weight values and the chosen T_thr threshold would improve reproducibility.
  6. [General] Several references, such as [7] for RPKI-invalid announcement features and [36] for ROV deployment rates, are cited without page numbers or section numbers; adding those details would help readers verify the claims about prior work.

Circularity Check

2 steps flagged · score 6.0 of 10

Benign ground truth is defined by one-month persistence, and the same persistence heuristic is reused in the holdout 'new' data and quarantine whitelisting, so the 52,846-route whitelist claim is partially circular.

  1. self definitional [Section 5.2.1 (ground truth definition) and Section 7 (quarantine whitelisting criteria)]
    "According to previous studies [37, 53, 55], hijacked BGP announcements are usually short-lived (e.g., lasting only a few hours or days). In other words, long-lived announcements are generally considered benign. Using this basic concept, we collect BGP routes with ROA violations. We first utilized Routinator [44], a widely recognized and reliable open-source RPKI relying party validator (ROV), to validate BGP announcements that occurred between May 30, 2022, and June 30, 2022, collected from the RIB data of RouteViews."

    The paper defines benign conflicts by persistence: routes that remained stable and persistent for the one-month window May 30 - June 30, 2022 are labeled benign. The same longevity assumption is then reused as a whitelisting criterion in Section 7: 'A longer monitoring period increases confidence that whitelisted routes are indeed benign, given that benign routes typically persist longer... we set the quarantine period to 14 days'. Consequently, the final claim of whitelisting 52,846 'benign origin errors' is substantially an output of the persistence heuristic. A hijack that persists for a month would be labeled benign by construction, and short-lived genuine benign conflicts are excluded from training.

  2. fitted input called prediction [Section 5.2.3 (Evaluation on New Data)]
    "Recall that, we only selected 2000 instances as ground truth data. The remaining 7,223 benign conflicts are used subsequently as new data for the evaluation."

    The 'new' benign evaluation set is not an independently labeled holdout: it is the leftover portion of the same one-month persistent-invalid pool from which the 2,000 training benign instances were drawn, using the same duration-based labeling rule. Reporting approximately 95% accuracy on these 'new' benign instances therefore measures agreement with the persistence heuristic, not the correctness of the benign labels. The holdout evaluation cannot falsify the central assumption that persistent RPKI-invalid routes are benign, so the abstract's claim of whitelisting 52,846 routes with benign origin errors rests on a labeling rule that the paper never validates against independent ground truth for benign conflicts.

full rationale

The paper has substantial independent content: the ML features (PC, MOAS, Parent, Depen, AltSources, ASdist) are computed from external CAIDA, IHR, IRR, and GeoIP data; hijack labels come from BGPmon and Qrator; and the post-analyzer plus email surveys provide some external checks. There is no load-bearing self-citation chain or uniqueness theorem imported from the authors' prior work; citations to prior papers by the same group concern RPKI vulnerabilities and are not the basis for the central whitelist claim. The circularity is narrower but real: the benign ground truth in Section 5.2.1 is defined by stability and persistence over one month, and the same persistence/longevity assumption is reused in the quarantine whitelisting criteria in Section 7 and in the evaluation of the holdout 'new' benign set in Section 5.2.3. Thus the 52,846-route whitelist, and the 79% benign-conflict share, reduce in part to the paper's own operational definition of benign rather than to an independently verified property. The authors honestly acknowledge in Section 5.2.1 and Appendix G.1 that short-lived benign conflicts are missing, and Section 9 states that all code, data, and models are confidential, which prevents external audit. A persistent one-month hijack would be labeled benign by construction, and ephemeral legitimate conflicts would be invisible to the classifier. This is partial circularity in the central claim, not a fully independent derivation, so a score of 6 is appropriate.

Assumptions & free parameters 5 free parameters · 5 assumptions · 1 invented entities

The central claim rests on a small set of hand-chosen thresholds (T_thr, quarantine period, activity criteria) and on the domain assumption that long-lived invalid routes are benign. The ML model's hyperparameters are neither reported nor released, and the ASdist scaling transform is chosen empirically to improve separation on the authors' ground truth. The Depen metric is a new construct whose independent predictive value is not established.

free parameters (5)
  • Tightness threshold T_thr = 0.3
    Set in Section 8.1.4 to whitelist 80% of the 63,458 benign conflicts classified by the RF model; it is a hand-chosen operating point rather than a derived value.
  • Quarantine period = 14 days
    Chosen in Section 7 based on the observation that 80% of benign conflicts in the measurement recur within less than 14 days, tying the whitelist to the same duration heuristic used to build ground truth.
  • Activity criteria for behavior monitoring = >=2 days per week; last seen within 1 week of quarantine end
    Hand-chosen thresholds in Section 7 to ensure whitelisted routes are actively used; no independent validation is provided.
  • Random Forest hyperparameters = not disclosed
    Selected by grid search in Section 5.2.2, but Table 2 does not list the chosen values, so the exact model cannot be reproduced.
  • ASdist scaling function = ASdist = (2/pi)*arctan(d)
    Adopted in Appendix B because min-max scaling produced false negatives; the functional form is fit to the authors' ground truth to improve separation of hijacks and benign conflicts.
assumptions (5)
  • domain assumption Long-lived RPKI-invalid routes are benign
    Section 5.2.1 labels ground truth benign conflicts as routes that remained stable and persistent throughout May 30 to June 30, 2022; the classifier and whitelist inherit this assumption.
  • domain assumption BGPmon and Qrator Radar hijack labels are correct approximations
    Section 5.2.1 and 5.2.3 use BGPmon and Qrator Radar as ground truth for hijacks while acknowledging possible false positives and lack of transparency.
  • domain assumption AS hegemony from IHR reliably indicates AS visibility and hijack events
    Section 6.1 assumes a surge in global hegemony is a detection signature for hijacks; Section 6.3 reports several failures attributed to IHR computation issues.
  • domain assumption CAIDA, GeoIP, and IRR data are reliable and tamper-resistant
    Section 5.2.6 asserts these public sources are highly reliable, making it challenging for attackers to manipulate feature inputs; no independent validation is provided.
  • domain assumption Two origins with tighter known relationships are more likely to be benign
    Section 5.1 defines the feature set around this intuition; it is the basis for the ML classifier and the tightness formula in Section 7.
invented entities (1)
  • Depen relationship metric
    purpose: Captures interdependency between conflicting origin ASes using IHR local AS hegemony; used as a feature and in the tightness formula
    Introduced in Section 5.1 beyond provider-customer and MOAS relationships; its predictive value is only validated on the authors' self-labeled data.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Learning to Identify Conflicts in RPKI." pith.science (2026). https://pith.science/paper/XVUP5UTT

@misc{pith2026250203378,
  author       = {Pith},
  title        = {Pith review of: Learning to Identify Conflicts in RPKI},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XVUP5UTT}},
  note         = {Machine review of arXiv:2502.03378}
}
read the original abstract

The long history of misconfigurations and errors in RPKI indicates that they cannot be easily avoided and will most probably persist also in the future. These errors create conflicts between BGP announcements and their covering ROAs, causing the RPKI validation to result in status invalid. Networks that enforce RPKI filtering with Route Origin Validation (ROV) would block such conflicting BGP announcements and as a result lose traffic from the corresponding origins. Since the business incentives of networks are tightly coupled with the traffic they relay, filtering legitimate traffic leads to a loss of revenue, reducing the motivation to filter invalid announcements with ROV. In this work, we introduce a new mechanism, LOV, designed for whitelisting benign conflicts on an Internet scale. The resulting whitelist is made available to RPKI supporting ASes to avoid filtering RPKI-invalid but benign routes. Saving legitimate traffic resolves one main obstacle towards RPKI deployment. We measure live BGP updates using LOV during a period of half a year and whitelist 52,846 routes with benign origin errors.

Figures

Figures reproduced from arXiv: 2502.03378 by the authors.

Figure 1
Figure 1. illustrates an overview of LOV. The core goal of LOV is to provide network operators enforcing ROV with a high-quality 1The DFZ has a full global BGP routing table. BGP updates RouteViews RIS BGPStream Whitelist ROV ML-classifier Post￾analyzer Hijacks Verified Local cache ROAs Invalid routes Public data Benign conflicts Hijack events Unverified Tightness, behavior monitoring Human intervention Evidence Analysts User… view at source ↗
Figure 2
Figure 2. illustrates the cumulative distribution functions (CDFs) of distances (𝑑) we analyzed in 100 benign conflicts and 100 prefix hijacks randomly selected from our ground truth dataset (see details about the ground truth data in the following paragraphs). The plot shows that benign conflicts mostly (90%) exhibit a smaller distance value (less than 50km) compared to hijacks, which aligns with our previous assumption. Com… view at source ↗
Figure 3
Figure 3. Feature importance. 5.2.6 Robustness to Adversarial Attacks. As discussed above, ad￾versaries might design BGP hijacking attacks to evade detection by the ML-classifier, though such attacks have a low success rate. Recall that benign conflicts identified by the ML-classifier are not immediately added to the whitelist. Instead, they are quarantined for further review, which includes examining the tightness of the con… view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Changes in global visibility of malicious ASes before, during and after the BGP incidents and evaluation with the post￾analyzer. Red vertical lines indicate outlier detections. ownership, causing its global visibility on the Internet to signifi￾cantly increase. We leve…
Figure 5
Figure 5. Figure 5: The daily number of RPKI-invalid routes detected by ROV, benign conflicts, hijacks identified by the RF classifier, and hijacks unverified by the post-analyzer throughout the measurement period. 8.1 Results and Analysis 8.1.1 Identified Benign Conflicts By the ML-Class…
Figure 6
Figure 6. Figure 6: CDF of tightness values for benign conflicts identified by the ML-classifier. more specific prefixes would result in ROA conflicts due to max￾imum length mismatches (see OriginMatch). We discovered that 37,904 routes with benign conflicts had an inconsistent length com…
Figure 7
Figure 7. Figure 7: CDFs of occurrences and frequencies of benign conflicts. ACM Symposium on Applied Computing. 583–587. [57] Zheng Zhang, Ying Zhang, Y Charlie Hu, Z Morley Mao, and Randy Bush. 2008. iSPY: Detecting IP prefix hijacking on my own. In Proceedings of the ACM SIG￾COMM 2008 …
Figure 8
Figure 8. Figure 8: Transformation. 0.0 0.2 0.4 0.6 0.8 1.0 ASdist 0.0 0.2 0.4 0.6 0.8 1.0 Proportion Benign conflict BGP hijack [PITH_FULL_IMAGE:figures/full_fig_p014_8.png]
Figure 10
Figure 10. Figure 10: illustrates the distributions of event occurrences and frequencies for 513 ASes that frequently initiated events. F Root Causes of Hijacking Events We analyze the hijacking events identified through email surveys, with a focus on investigating their underlying causes.…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

60 extracted references · 57 canonical work pages

  1. [1]

    Azimov, E

    A. Azimov, E. Bogomazov, R. Bush, K. Patel, and J. Snijders. November, 2020. Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization. https://datatracker.ietf.org/d oc/html/draft-ietf-sidrops-aspa-verification-06

    work page 2020

  2. [2]

    Hitesh Ballani, Paul Francis, and Xinyang Zhang. 2007. A Study of Prefix Hijack- ing and Interception in the Internet. InACM SIGCOMM Computer Communication Review, Vol. 37. ACM, 265–276

    work page 2007

  3. [3]

    Alex Band. 2011. Certification in the real world. In RIPE NCC. https://ripe62.rip e.net/presentations/214-Cert-RIPE62-RoutingWG.pdf

    work page 2011

  4. [4]

    Randy Bush, Rob Austein, Steve Bellovin, and Michael Elkins. 2009. The RPKI & Origin Validation. https://ripe60.ripe.net/presentations/Bush\protect\discretio nary{\char\hyphenchar\font}{}{}The_RPKI_Origin_Validation.pdf

    work page 2009

  5. [5]

    CAIDA. [n. d.]. https://catalog.caida.org/. Accessed: 01.2023

    work page 2023

  6. [6]

    Kwan-Wu Chin. 2007. On the characteristics of BGP multiple origin AS conflicts. In 2007 Australasian Telecommunication Networks and Applications Conference. IEEE, 157–162

    work page 2007

  7. [7]

    Taejoong Chung, Emile Aben, Tim Bruijnzeels, Balakrishnan Chandrasekaran, David Choffnes, Dave Levin, Bruce M Maggs, Alan Mislove, Roland van Rijswijk- Deij, John Rula, et al. 2019. RPKI is coming of age: A longitudinal study of RPKI deployment and invalid route origins. In Proceedings of the Internet Measurement Conference. 406–419

    work page 2019

  8. [8]

    CISCO. [n. d.]. BGPMon is now part of CrossworkCloud. https://www.bgpmon.n et/. Accessed: 01.2024

    work page 2024

Show all 60 references
  1. [9]

    Google Cloud. [n. d.]. Bring your own IP addresses. https://cloud.google.com/v pc/docs/bring-your-own-ip. Accessed: 30.07.2024

    2024

  2. [10]

    Cloudflare. [n. d.]. Is BGP safe yet? https://isbgpsafeyet.com/. Accessed: 01.2024

    2024

  3. [11]

    Shivani Deshpande, Marina Thottan, Tin Kam Ho, and Biplab Sikdar. 2009. An online mechanism for BGP instability detection and analysis. IEEE transactions on Computers 58, 11 (2009), 1470–1484

    2009

  4. [12]

    Romain Fontugne, Anant Shah, and Emile Aben. 2017. As hegemony: A robust metric for as centrality. InProceedings of the SIGCOMM Posters and Demos. 48–50

    2017

  5. [13]

    Romain Fontugne, Anant Shah, and Emile Aben. 2018. The (thin) bridges of as connectivity: Measuring dependency using as hegemony. In International Conference on Passive and Active Network Measurement . Springer, 216–227

    2018

  6. [14]

    Jens Frieß, Donika Mirdita, Haya Schulmann, and Michael Waidner. 2024. Byzantine-Secure Relying Party for Resilient RPKI. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, CCS 2024, Salt Lake City, UT, USA, October 14-18, 2024 , Bo Lu...

    2024

  7. [16]

    Yossi Gilad, Avichai Cohen, Amir Herzberg, Michael Schapira, and Haya Shulman

  8. [17]

    Yossi Gilad, Omar Sagga, and Sharon Goldberg. 2017. Maxlength considered harm- ful to the RPKI. In Proceedings of the 13th International Conference on emerging Networking EXperiments and Technologies. 101–107

    2017

  9. [18]

    Tomas Hlavacek, Italo Cunha, Yossi Gilad, Amir Herzberg, Ethan Katz-Bassett, Michael Schapira, and Haya Shulman. 2020. Disco: Sidestepping rpki’s deploy- ment barriers. In Network and Distributed System Security Symposium (NDSS)

    2020

  10. [19]

    Tomas Hlavacek, Philipp Jeitner, Donika Mirdita, Haya Schulmann, and Michael Waidner. 2022. Stalloris: RPKI Downgrade Attack. In 31st USENIX Security Sym- posium, USENIX Security 2022, Boston, MA, USA, August 10-12, 2022 , Kevin R. B. Butler and Kurt Thomas (Eds.). USENIX Asso...

    2022

  11. [20]

    Tomas Hlavacek, Philipp Jeitner, Donika Mirdita, Haya Schulmann, and Michael Waidner. 2023. Beyond Limits: How to Disable Validators in Secure Networks. In Proceedings of the ACM SIGCOMM 2023 Conference, ACM SIGCOMM 2023, New York, NY, USA, 10-14 September 2023 , Henning Schul...

    2023

  12. [21]

    Tomas Hlavacek, Philipp Jeitner, Donika Mirdita, Haya Shulman, and Michael Waidner. 2022. Behind the scenes of RPKI. InProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security . 1413–1426

    2022

  13. [22]

    Tomas Hlavacek, Haya Schulmann, Niklas Vogel, and Michael Waidner. 2023. Keep Your Friends Close, but Your Routeservers Closer: Insights into RPKI Val- idation in the Internet. In 32nd USENIX Security Symposium, USENIX Security 2023, Anaheim, CA, USA, August 9-11, 2023 , Josep...

    2023

  14. [23]

    Tomas Hlavacek, Haya Shulman, and Michael Waidner. 2022. Smart RPKI valida- tion: Avoiding errors and preventing hijacks. InEuropean Symposium on Research in Computer Security. Springer, 509–530

    2022

  15. [24]

    Geoff Huston and George Michaelson. 2012. Validation of route origination using the resource certificate public key infrastructure (PKI) and route origin authoriza- tions (ROAs). Technical Report

    2012

  16. [25]

    Daniele Iamartino, Cristel Pelsser, and Randy Bush. 2015. Measuring bgp route origin registration and validation. In International Conference on Passive and Active Network Measurement. Springer, 28–40

    2015

  17. [26]

    IHR. [n. d.]. Internet Health Report. https://ihr.iijlab.net/ihr/. Accessed: 01.2023

    2023

  18. [27]

    IRR. [n. d.]. IRR Internet Routing Registry. https://www.irr.net/. Accessed: 01.2023

    2023

  19. [28]

    Costas Kalogiros, Marcelo Bagnulo, and Alexandros Kostopoulos. 2009. Under- standing incentives for prefix aggregation in BGP. In Proceedings of the 2009 workshop on Re-architecting the internet . 49–54

    2009

  20. [29]

    Mohsen Karimi, Ali Jahanshahi, Abbas Mazloumi, and Hadi Zamani Sabzi. 2019. Border gateway protocol anomaly detection using neural network. In 2019 IEEE International Conference on Big Data (Big Data) . IEEE, 6092–6094

    2019

  21. [30]

    Josh Karlin, Stephanie Forrest, and Jennifer Rexford. 2005. Pretty Good BGP: Protecting BGP by cautiously selecting routes . Technical Report. Technical report, University of New Mexico

    2005

  22. [31]

    Qrator Lab. 2022. Qrator Blog. https://blog.qrator.net. [Online; accessed 19-November-2022]

    2022

  23. [32]

    Qrator Labs. [n. d.]. Q4 2022 DDoS Attacks and BGP Incidents. https://qratorlabs.medium.com/q2-2023-ddos-attacks-statistics-and-overview- 698682abf508. Accessed: 01.2024

    2022

  24. [33]

    Matt Lepinski and Stephen Kent. 2012. An Infrastructure to Support Secure Internet Routing. RFC 6480. doi:10.17487/RFC6480

    2012 doi

  25. [34]

    Matt Lepinski and Stephen Kent. 2012. An infrastructure to support secure internet routing. Technical Report

    2012

  26. [35]

    Lepinski and K

    M. Lepinski and K. Sriram. September, 2017. BGPsec Protocol Specification. https://datatracker.ietf.org/doc/html/rfc8205

    2017

  27. [36]

    Weitong Li, Zhexiao Lin, Md Ishtiaq Ashiq, Emile Aben, Romain Fontugne, Am- reesh Phokeer, and Taejoong Chung. 2023. RoVista: Measuring and Analyzing the Route Origin Validation (ROV) in RPKI. In Proceedings of the 2023 ACM on Internet Measurement Conference. 73–88

    2023

  28. [37]

    Ratul Mahajan, David Wetherall, and Tom Anderson. 2002. Understanding BGP misconfiguration. ACM SIGCOMM Computer Communication Review 32, 4 (2002), 3–16

    2002

  29. [38]

    Donika Mirdita, Haya Schulmann, Niklas Vogel, and Michael Waidner. 2024. The CURE to Vulnerabilities in RPKI Validation. In 31st Annual Network and Distributed System Security Symposium, NDSS 2024, San Diego, California, USA, February 26 - March 1, 2024 . The Internet Society

    2024

  30. [39]

    Donika Mirdita, Haya Schulmann, and Michael Waidner. 2025. SoK: An Intro- spective Analysis of RPKI Security.. In34nd USENIX Security Symposium, USENIX Security 2025, USA, August, 2025 , Lujo Bauer and Giancarlo Pellegrino (Eds.). USENIX Association

    2025

  31. [40]

    Donika Mirdita, Haya Shulman, and Michael Waidner. 2022. Poster: RPKI kill switch. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 3423–3425

    2022

  32. [41]

    Pablo Moriano, Raquel Hill, and L Jean Camp. 2021. Using bursty announcements for detecting BGP routing anomalies. Computer Networks 188 (2021), 107835

    2021

  33. [42]

    Reynaldo Morillo, Justin Furuness, Cameron Morris, James Breslin, Amir Herzberg, and Bing Wang. 2021. ROV++: Improved Deployable Defense against BGP Hijacking.. In NDSS

    2021

  34. [43]

    NIST. [n. d.]. NIST RPKI Monitor. https://rpki-monitor.antd.nist.gov/

  35. [44]

    NLnetLabs. [n. d.]. An RPKI Validator and RTR server written in Rust. https: //github.com/NLnetLabs/routinator. Accessed: 01.2023

    2023

  36. [45]

    Chiara Orsini, Alistair King, Danilo Giordano, Vasileios Giotsas, and Alberto Dainotti. 2016. BGPStream: a software framework for live and historical BGP data analysis. In Proceedings of the 2016 Internet Measurement Conference . 429–444

    2016

  37. [46]

    Yakov Rekhter, Susan Hares, and Tony Li. 2006. A Border Gateway Protocol 4 (BGP-4). RFC 4271. doi:10.17487/RFC4271

    2006 doi

  38. [47]

    Johann Schlamp, Ralph Holz, Quentin Jacquemart, Georg Carle, and Ernst W Biersack. 2016. HEAP: reliable assessment of BGP hijacking attacks. IEEE Journal on Selected Areas in Communications 34, 6 (2016), 1849–1861

    2016

  39. [48]

    Xingang Shi, Yang Xiang, Zhiliang Wang, Xia Yin, and Jianping Wu. 2012. De- tecting prefix hijackings in the internet with argus. In Proceedings of the 2012 Internet Measurement Conference. 15–28

    2012

  40. [49]

    Snijders, T

    J. Snijders, T. Harrison, and B. Maddison. September, 2022. A profile for Resource Public Key Infrastructure (RPKI) Signed Checklists (RSC). https://datatracker.ie tf.org/doc/html/draft-ietf-sidrops-rpki-rsc

    2022

  41. [50]

    Cecilia Testart, Philipp Richter, Alistair King, Alberto Dainotti, and David Clark

  42. [51]

    Simone van Veen. 2019. Analysing BGP Origin Hijacks. (2019)

    2019

  43. [52]

    Pierre-Antoine Vervier and Olivier Thonnard. 2013. SpamTracer: How stealthy are spammers?. In 2013 Proceedings IEEE INFOCOM . IEEE, 3477–3482

    2013

  44. [53]

    Pierre-Antoine Vervier, Olivier Thonnard, and Marc Dacier. 2015. Mind Your Blocks: On the Stealthiness of Malicious BGP Hijacks.. In NDSS

    2015

  45. [54]

    Matthias Wählisch, Olaf Maennel, and Thomas C Schmidt. 2012. Towards detect- ing BGP route hijacking using the RPKI. ACM SIGCOMM Computer Communica- tion Review 42, 4 (2012), 103–104

    2012

  46. [55]

    Benjamin Wijchers, Benno Overeinder, Paola Grosso, and Spyros Voulgaris. 2014. BGP Route Leaks Analysis. (2014)

    2014

  47. [56]

    Rolf Winter and Iljitsch Van Beijnum. 2012. Explicitly accommodating origin preference for inter-domain traffic engineering. In Proceedings of the 27th Annual ASIA CCS ’25, August 25–29, 2025, Hanoi, Vietnam Haya Schulmann and Shujie Zhao Model Parameter Search range Step size...

    2012

  48. [57]

    Zheng Zhang, Ying Zhang, Y Charlie Hu, Z Morley Mao, and Randy Bush. 2008. iSPY: Detecting IP prefix hijacking on my own. In Proceedings of the ACM SIG- COMM 2008 conference on Data Communication . 327–338

    2008

  49. [58]

    occurrence

    Xiaoliang Zhao, Dan Pei, Lan Wang, Dan Massey, Allison Mankin, S Felix Wu, and Lixia Zhang. 2001. An analysis of BGP multiple origin AS (MOAS) conflicts. In Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement . 31–35. A CDFs of Occurrences and Frequencies of Be...

    2001

  50. [2016]

    Cryptology ePrint Archive (2016)

    Are we there yet? On RPKI’s deployment and security. Cryptology ePrint Archive (2016)

    2016

  51. [2017]

    Are We There Yet? On RPKI’s Deployment and Security. In NDSS

  52. [2019]

    In Proceedings of the Internet Measurement Conference

    Profiling BGP serial hijackers: capturing persistent misbehavior in the global routing table. In Proceedings of the Internet Measurement Conference . 420– 434

Pith tools

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