pith. sign in

arxiv: 2605.26986 · v1 · pith:VC2ORZAWnew · submitted 2026-05-26 · 💻 cs.CR

The Fault in Our Drafts: Vulnerabilities in RPKI Specification and Software

Oliver Jacobsen , Tobias Kirsch , Haya Schulmann , Niklas Vogel , Michael Waidner This is my paper

Pith reviewed 2026-06-29 16:39 UTC · model grok-4.3

classification 💻 cs.CR
keywords RPKIRFC specification flawsdifferential fuzzingBGP routing securityimplementation inconsistenciesROA validationcertificate revocationCVE
0
0 comments X

The pith

Vague and conflicting requirements in RPKI RFCs produce inconsistent validation across implementations and create vulnerabilities

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

The paper establishes that vague, conflicting, or underspecified requirements across 50 RPKI RFCs directly produce divergent behavior in how different implementations validate certificates, ROAs, manifests, and CRLs. Through differential fuzzing of major implementations plus large-scale crawling of live deployments, the authors trace 61 inconsistencies, of which 23 stem from the RFCs themselves, and they identify two previously unknown vulnerabilities that received CVEs. A reader should care because RPKI is the mechanism intended to prevent route hijacks in BGP; when validation differs between parties, the security guarantees fail in practice. The work treats these problems as systemic outcomes of how the standards are written rather than isolated coding mistakes.

Core claim

The central claim is that vague, conflicting, or underspecified requirements in the 50 RPKI RFCs propagate into inconsistent implementation behavior and operational failures; 61 previously undocumented inconsistencies were found, 23 were traced directly to RFC flaws, and two novel vulnerabilities received CVEs. These issues are presented as inherent to the specification and implementation process rather than random errors.

What carries the argument

Differential fuzzing of major RPKI implementations combined with Internet-wide crawling and validation log analysis to map observed inconsistencies back to specific RFC requirements.

Load-bearing premise

That the inconsistencies uncovered by fuzzing and crawling are caused by flaws in the RFC specifications rather than by independent implementation decisions or unrelated coding errors.

What would settle it

A controlled test in which the 23 RFC ambiguities are clarified in updated documents and the number of observed inconsistencies across implementations does not decrease.

Figures

Figures reproduced from arXiv: 2605.26986 by Haya Schulmann, Michael Waidner, Niklas Vogel, Oliver Jacobsen, Tobias Kirsch.

Figure 1
Figure 1. Figure 1: Simplified overview of RPKI operations. tions for resolving the issues identified in this work and for improving the RFCs. We notified members of the IETF working group for Secure Interdomain Routing Operations (SIDROPS)1 about these issues and are in active discussions on how to resolve them in the specification. Additionally, we develop a web service with an alert tool for the community that notifies use… view at source ↗
Figure 2
Figure 2. Figure 2: Evolution of RPKI specification in RFCs. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Methodology of the RFC analysis. from open-source repositories. This allows us to construct a comprehensive dataset of impact issues: practical RPKI issues that have a security impact by affecting validation outcomes or the observable system state. In the subsequent RFC analysis, we trace whether these issues are rooted in the RFCs or stem from non-RFC causes, like benign imple￾menter errors. When an issue… view at source ↗
Figure 4
Figure 4. Figure 4: Missing comment on CP Qualifiers in RFC8360 [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
read the original abstract

The Resource Public Key Infrastructure (RPKI) secures the Internet's routing system by defining a complex trust and validation framework for certificates, Route Origin Authorizations (ROAs), manifests, and Certificate Revocation Lists (CRLs). These mechanisms are specified across dozens of RFCs. This paper presents the first comprehensive analysis of the causal link between flaws in RPKI Requests for Comments (RFCs) and vulnerabilities in implementations and real-world deployments. We reveal how vague, conflicting, or underspecified requirements in 50 RPKI RFCs propagate into inconsistent implementation behavior and operational failures. We conduct the first large-scale, impact-driven evaluation of RPKI specifications. Our methodology combines differential fuzzing of major RPKI implementations with Internet-wide crawling and validation log analysis, enabling us to trace practical vulnerabilities back to flawed RFC requirements. We uncover 61 previously undocumented inconsistencies in validation behavior, trace 23 directly to RFC flaws, and identify two novel vulnerabilities that were assigned CVEs. Our findings reveal that these are not isolated coding errors but rather systemic issues inherent in how RPKI standards are written, interpreted, and implemented. To mitigate these threats, we propose concrete recommendations and introduce a novel alerting service that monitors and reports live inconsistencies in RPKI deployments. Our open-source datasets, code, and tools support reproducibility and further research.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper claims that vague, conflicting, or underspecified requirements across 50 RPKI RFCs cause inconsistent validation behavior in implementations and real-world operational failures. Using differential fuzzing of major RPKI implementations combined with Internet-wide crawling and validation log analysis, the authors identify 61 previously undocumented inconsistencies, trace 23 of them directly to flaws in the RFC specifications, discover two novel vulnerabilities assigned CVEs, and propose recommendations plus a live alerting service for inconsistencies.

Significance. If the causal attributions from observed divergences to specific RFC ambiguities are rigorously established, the work would be significant for highlighting systemic issues in how security-critical standards are written and interpreted. The empirical scale (61 inconsistencies across implementations, live deployment data) and reproducibility artifacts (open datasets, code, tools) strengthen the contribution to the RPKI and standards community.

major comments (3)
  1. [§4 and §5] §4 (Methodology) and §5 (Results): The central claim that 23 inconsistencies are 'traced directly to RFC flaws' requires explicit per-case evidence that the relevant RFC passage is ambiguous or contradictory and that each implementation's behavior corresponds to a distinct spec-permitted reading. The provided description of differential fuzzing and crawling surfaces behavioral differences but does not detail the criteria or process used to establish the causal mapping versus alternative explanations (independent implementation choices, stricter checks, or unrelated bugs). This mapping is load-bearing for the propagation argument.
  2. [§5.3] §5.3 (CVE cases): For the two novel vulnerabilities assigned CVEs, the paper should include the specific RFC text passages that were underspecified or conflicting, together with the distinct interpretations taken by the affected implementations. Without this, it is difficult to confirm that the issues originate in the specification rather than in implementation-specific decisions.
  3. [§6] §6 (Recommendations and alerting service): The proposed alerting service and recommendations assume that the identified inconsistencies are primarily spec-driven; if the attribution in §5 is not strengthened, the practical utility of these mitigations for addressing root causes would need re-evaluation.
minor comments (2)
  1. [Abstract] The abstract states that inconsistencies were traced to RFC flaws but supplies limited methodological detail; expanding the abstract or adding a forward reference to the attribution process in §4 would improve clarity for readers.
  2. [Tables/Figures in §5] Table or figure presenting the 61 inconsistencies should include columns for the implicated RFC section(s) and the specific ambiguity identified, to make the tracing more transparent.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the detailed and constructive comments. We agree that the causal mapping from RFC ambiguities to implementation behaviors requires more explicit documentation to strengthen the central claims. Below we address each major comment and describe the revisions we will make.

read point-by-point responses

  1. Referee: [§4 and §5] §4 (Methodology) and §5 (Results): The central claim that 23 inconsistencies are 'traced directly to RFC flaws' requires explicit per-case evidence that the relevant RFC passage is ambiguous or contradictory and that each implementation's behavior corresponds to a distinct spec-permitted reading. The provided description of differential fuzzing and crawling surfaces behavioral differences but does not detail the criteria or process used to establish the causal mapping versus alternative explanations (independent implementation choices, stricter checks, or unrelated bugs). This mapping is load-bearing for the propagation argument.

    Authors: We acknowledge that the current manuscript describes the overall process but does not present per-case evidence in sufficient detail. Our tracing involved systematic review of the relevant RFC sections for each inconsistency to identify vagueness, contradictions, or underspecification, followed by mapping observed behaviors to distinct permitted readings. In the revision we will add a dedicated appendix containing, for each of the 23 cases: (1) the exact RFC passage, (2) the identified ambiguity or conflict, (3) the distinct interpretations, and (4) the corresponding implementation behaviors. This will make the criteria and exclusion of alternative explanations explicit. revision: yes

  2. Referee: [§5.3] §5.3 (CVE cases): For the two novel vulnerabilities assigned CVEs, the paper should include the specific RFC text passages that were underspecified or conflicting, together with the distinct interpretations taken by the affected implementations. Without this, it is difficult to confirm that the issues originate in the specification rather than in implementation-specific decisions.

    Authors: We will expand §5.3 to quote the precise RFC text passages for both CVEs and explicitly contrast the differing interpretations adopted by the affected implementations. This addition will directly demonstrate that the vulnerabilities arise from specification underspecification rather than purely implementation choices. revision: yes

  3. Referee: [§6] §6 (Recommendations and alerting service): The proposed alerting service and recommendations assume that the identified inconsistencies are primarily spec-driven; if the attribution in §5 is not strengthened, the practical utility of these mitigations for addressing root causes would need re-evaluation.

    Authors: Once the per-case evidence is added to §5, the recommendations and alerting service in §6 will rest on a firmer foundation. We will also insert a short paragraph noting that the service remains useful for detecting divergences even when some stem from implementation decisions, while emphasizing its primary value in surfacing spec-related issues. revision: partial

Circularity Check

0 steps flagged

No circularity: empirical security analysis with direct external validation

full rationale

The paper conducts an empirical study via differential fuzzing of implementations, Internet-wide crawling, and log analysis to surface behavioral inconsistencies and map 23 of them to RFC text issues. No mathematical derivations, equations, fitted parameters, predictions, or ansatzes appear in the provided text. The central claim rests on observable differences across independent external implementations and live deployments rather than on any self-referential construction or self-citation chain. This matches the default expectation for non-circular empirical work; the analysis is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim depends on the domain assumption that differential testing can isolate specification-induced differences and that the RFCs are the primary source of observed validation inconsistencies.

axioms (1)
  • domain assumption RPKI implementations are expected to follow the requirements stated in the RFCs
    The attribution of inconsistencies to RFC flaws presupposes that implementations intend to comply with the specifications.

pith-pipeline@v0.9.1-grok · 5781 in / 1126 out tokens · 51358 ms · 2026-06-29T16:39:51.480050+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

39 extracted references · 8 canonical work pages

  1. [1]

    Six worst internet routing attacks,

    C. D. Marsan, “Six worst internet routing attacks,” January 2009, accessed Aug 6 2025. [Online]. Available: http://www.networkworld. com/news/2009/011509-bgp-attacks.html

    2009

  2. [2]

    Securing internet applications from routing attacks,

    Y . Sun, M. Apostolaki, H. Birge-Lee, L. Vanbever, J. Rexford, M. Chiang, and P. Mittal, “Securing internet applications from routing attacks,”Commun. ACM, vol. 64, no. 6, pp. 86–96, 2021

    2021

  3. [3]

    KlaySwap crypto users lose funds after BGP hijack,

    C. Cimpanu, “ KlaySwap crypto users lose funds after BGP hijack,” https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp- hijack, 2022, accessed 09/09/2024

    2022

  4. [4]

    Cloudflare 1.1.1.1 incident on June 27, 2024,

    B. Herdes, M. Zhang, and T. Ryan, “ Cloudflare 1.1.1.1 incident on June 27, 2024,” https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27- 2024/, 2024, accessed Aug 5 2025

    2024

  5. [5]

    Nist rpki monitor,

    NIST, “Nist rpki monitor,” https://rpki-monitor.antd.nist.gov/, 2025, accessed Jul 7 2025

    2025

  6. [6]

    ROVista measurement,

    Netsecurelabs, “ROVista measurement,” https://rovista.netsecurelab.org/analytics/, 2025, accessed Aug 5 2025

    2025

  7. [7]

    Roadmap to Enhancing Internet Routing Security,

    T. W. House, “Roadmap to Enhancing Internet Routing Security,” September 2024. [Online]. Avail- able: https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/ 09/Roadmap-to-Enhancing-Internet-Routing-Security.pdf

    2024

  8. [8]

    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,”NDSS, 2017

    2017

  9. [9]

    DISCO: Sidestepping RPKI’s de- ployment barriers,

    T. Hlavacek, I. Cunha, Y . Gilad, A. Herzberg, E. Katz-Bassett, M. Schapira, and H. Shulman, “DISCO: Sidestepping RPKI’s de- ployment barriers,” inNetwork and Distributed System Security Sym- posium (NDSS), 2020

    2020

  10. [10]

    rpkiller: Threat analysis of the BGP resource public key infrastructure,

    K. van Hove, J. van der Ham-de V os, and R. van Rijswijk- Deij, “rpkiller: Threat analysis of the BGP resource public key infrastructure,”Digital Threats, vol. 4, no. 4, Oct. 2023. [Online]. Available: https://doi.org/10.1145/3617182

    work page doi:10.1145/3617182 2023

  11. [11]

    Stalloris: RPKI downgrade attack,

    T. Hlavacek, P. Jeitner, D. Mirdita, H. Shulman, and M. Waidner, “Stalloris: RPKI downgrade attack,” in31st USENIX Security Sym- posium (USENIX Security 22), 2022, pp. 4455–4471

    2022

  12. [12]

    The CURE to vulnerabilities in RPKI validation,

    D. Mirdita, H. Schulmann, N. V ogel, and M. Waidner, “The CURE to vulnerabilities in RPKI validation,” in31st Annual Network and Distributed System Security Symposium, NDSS 2024, San Diego, California, USA, February 26 - March 1, 2024. The Internet Society,

    2024

  13. [13]

    Available: https://www.ndss-symposium.org/ndss- paper/the-cure-to-vulnerabilities-in-rpki-validation/

    [Online]. Available: https://www.ndss-symposium.org/ndss- paper/the-cure-to-vulnerabilities-in-rpki-validation/

  14. [14]

    SoK: An Introspective Analysis of RPKI Security,

    D. Mirdita, H. Schulmann, and M. Waidner, “SoK: An Introspective Analysis of RPKI Security,”arXiv preprint arXiv:2408.12359, 2024

    work page arXiv 2024

  15. [15]

    Automated attack synthesis by extracting finite state machines from protocol specification documents,

    M. L. Pacheco, M. von Hippel, B. Weintraub, D. Goldwasser, and C. Nita-Rotaru, “Automated attack synthesis by extracting finite state machines from protocol specification documents,” in2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 51–68

    2022

  16. [16]

    Formal analysis of RFC 8120 authentication protocol for HTTP under different assumptions,

    N. Okumura, K. Ogata, and Y . Shinoda, “Formal analysis of RFC 8120 authentication protocol for HTTP under different assumptions,” Journal of Information Security and Applications, vol. 53, p. 102529, 2020

    2020

  17. [17]

    Semi-automated protocol disambiguation and code generation,

    J. Yen, T. L ´evai, Q. Ye, X. Ren, R. Govindan, and B. Raghavan, “Semi-automated protocol disambiguation and code generation,” inProceedings of the 2021 ACM SIGCOMM 2021 Conference, ser. SIGCOMM ’21. New York, NY , USA: Association for Computing Machinery, 2021, p. 272–286. [Online]. Available: https://doi.org/10.1145/3452296.3472910

    work page doi:10.1145/3452296.3472910 2021

  18. [18]

    NLnet Labs RPKI statistics,

    N. Labs, “NLnet Labs RPKI statistics,” [Online; accessed 20-January- 2025]. [Online]. Available: https://rov-measurements.nlnetlabs.net/ stats/

    2025

  19. [19]

    Poster: Kill Krill or Proxy RPKI,

    L. Cattepoel, D. Mirdita, H. Schulmann, and M. Waidner, “Poster: Kill Krill or Proxy RPKI,” inProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’24. New York, NY , USA: Association for Computing Machinery, 2024, p. 4922–4924. [Online]. Available: https://doi.org/10.1145/3658644.3691390

    work page doi:10.1145/3658644.3691390 2024

  20. [20]

    Poster: From Fort to Foe: The Threat of RCE in RPKI,

    O. Jacobsen, H. Schulmann, N. V ogel, and M. Waidner, “Poster: From Fort to Foe: The Threat of RCE in RPKI,” inProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’24. New York, NY , USA: Association for Computing Machinery, 2024, p. 5015–5017. [Online]. Available: https://doi.org/10.1145/3658644.3691387

    work page doi:10.1145/3658644.3691387 2024

  21. [21]

    Rpki: Not perfect but good enough,

    H. Schulmann, N. V ogel, and M. Waidner, “Rpki: Not perfect but good enough,”arXiv preprint arXiv:2409.14518, 2024. 15

    work page arXiv 2024

  22. [22]

    Aflnet: A greybox fuzzer for network protocols,

    V .-T. Pham, M. B ¨ohme, and A. Roychoudhury, “Aflnet: A greybox fuzzer for network protocols,” in2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST). IEEE, 2020, pp. 460–465

    2020

  23. [23]

    Differential testing of certificate validation in SSL/TLS implementations: An RFC-guided approach,

    C. Tian, C. Chen, Z. Duan, and L. Zhao, “Differential testing of certificate validation in SSL/TLS implementations: An RFC-guided approach,”ACM Transactions on Software Engineering and Method- ology (TOSEM), vol. 28, no. 4, pp. 1–37, 2019

    2019

  24. [24]

    Large language model guided protocol fuzzing,

    R. Meng, M. Mirchev, M. B ¨ohme, and A. Roychoudhury, “Large language model guided protocol fuzzing,” inProceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS), vol. 2024, 2024

    2024

  25. [25]

    TCP- Fuzz: Detecting memory and semantic bugs in TCP stacks with fuzzing,

    Y .-H. Zou, J.-J. Bai, J. Zhou, J. Tan, C. Qin, and S.-M. Hu, “TCP- Fuzz: Detecting memory and semantic bugs in TCP stacks with fuzzing,” in2021 USENIX Annual Technical Conference (USENIX ATC 21), 2021, pp. 489–502

    2021

  26. [26]

    An analysis of NIST SP 800-90A,

    J. Woodage and D. Shumow, “An analysis of NIST SP 800-90A,” in Advances in Cryptology–EUROCRYPT 2019: 38th Annual Interna- tional Conference on the Theory and Applications of Cryptographic Techniques, Darmstadt, Germany, May 19–23, 2019, Proceedings, Part II 38. Springer, 2019, pp. 151–180

    2019

  27. [27]

    A formal security analysis of the W3C web payment apis: Attacks and verification,

    Q. H. Do, P. Hosseyni, R. K ¨usters, G. Schmitz, N. Wenzler, and T. W ¨urtele, “A formal security analysis of the W3C web payment apis: Attacks and verification,” in2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 215–234

    2022

  28. [28]

    Downgrading DNSSEC: How to Exploit Crypto Agility for Hijacking Signed Zones,

    E. Heftrig, H. Schulmann, and M. Waidner, “Downgrading DNSSEC: How to Exploit Crypto Agility for Hijacking Signed Zones,” in32nd USENIX Security Symposium, USENIX Security 2023, Anaheim, CA, USA, August 9-11, 2023, J. A. Calandrino and C. Troncoso, Eds. USENIX Association, 2023, pp. 7429–7444

    2023

  29. [29]

    A security evaluation of DNSSEC with NSEC3,

    J. Bau and J. C. Mitchell, “A security evaluation of DNSSEC with NSEC3,” inNetwork and Distributed Systems Security (NDSS) Symposium. The Internet Society, 2010. [Online]. Available: http://www.isoc.org/isoc/conferences/ndss/10/

    2010

  30. [30]

    We really need to talk about session tickets: A Large-Scale analysis of cryptographic dangers with TLS session tickets,

    S. Hebrok, S. Nachtigall, M. Maehren, N. Erinola, R. Merget, J. So- morovsky, and J. Schwenk, “We really need to talk about session tickets: A Large-Scale analysis of cryptographic dangers with TLS session tickets,” in32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 4877–4894

    2023

  31. [31]

    Behind the scenes of RPKI,

    T. Hlavacek, P. Jeitner, D. Mirdita, H. Shulman, and M. Waidner, “Behind the scenes of RPKI,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 1413–1426

    2022

  32. [32]

    Poster: RPKI kill switch,

    D. Mirdita, H. Shulman, and M. Waidner, “Poster: RPKI kill switch,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 3423–3425

    2022

  33. [33]

    Beyond limits: How to disable validators in secure networks,

    T. Hlavacek, P. Jeitner, D. Mirdita, H. Shulman, and M. Waidner, “Beyond limits: How to disable validators in secure networks,” inProceedings of the ACM SIGCOMM 2023 Conference, ser. ACM SIGCOMM ’23. New York, NY , USA: Association for Computing Machinery, 2023, p. 950–966. [Online]. Available: https://doi.org/10.1145/3603269.3604861

    work page doi:10.1145/3603269.3604861 2023

  34. [34]

    Smart greybox fuzzing,

    V .-T. Pham, M. B¨ohme, A. E. Santosa, A. R. C ˘aciulescu, and A. Roy- choudhury, “Smart greybox fuzzing,”IEEE Transactions on Software Engineering, vol. 47, no. 9, pp. 1980–1997, 2019

    1980

  35. [35]

    dRR: A decentralized, scalable, and auditable architecture for RPKI repository,

    Y . Su, D. Li, L. Chen, Q. Li, and S. Ling, “dRR: A decentralized, scalable, and auditable architecture for RPKI repository,” inNDSS, 2024

    2024

  36. [36]

    From generation to judgment: Opportunities and challenges of llm-as-a-judge,

    D. Li, B. Jiang, L. Huang, A. Beigi, C. Zhao, Z. Tan, A. Bhattacharjee, Y . Jiang, C. Chen, T. Wuet al., “From generation to judgment: Opportunities and challenges of llm-as-a-judge,” inProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, 2025, pp. 2757–2791

    2025

  37. [37]

    Ethical issues in computer security research: What practitioners say,

    M. Bishop and D. V . Bailey, “Ethical issues in computer security research: What practitioners say,” inProceedings of the 4th Workshop on Ethics in Computer Security Research (WECSR). Springer, 2008

    2008

  38. [38]

    The Menlo Report: Ethical principles guiding information and communication technology research,

    D. Dittrich and E. Kenneally, “The Menlo Report: Ethical principles guiding information and communication technology research,” U.S. Department of Homeland Security, Tech. Rep. 11-01, August 2012

    2012

  39. [39]

    Sharing sensitive data with confidence: The data tags system,

    L. Sweeney, M. Crosas, and M. Bar-Sinai, “Sharing sensitive data with confidence: The data tags system,”Technology Science, Septem- ber 2015. [Online]. Available: https://techscience.org/a/2015092901 Appendix A. Fuzzer Design To test RPKI implementations we need to simulate a real world RPKI setup. For this, the fuzzer creates RPKI repositories and assign...

    work page arXiv 2015