arXiv CSopen access

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

The Fault in Our Drafts: Vulnerabilities in RPKI Specification and Software Oliver Jacobsen∗† , Tobias Kirsch∗† , Haya Schulmann∗† , Niklas Vogel∗† and Michael Waidner∗‡§ ∗ ATHENE – National Research Center for Applied Cybersecurity, Germany † Goethe-Universität Frankfurt, Germany ‡ Fraunhofer SIT, Germany

arXiv:2605.26986v1 [cs.CR] 26 May 2026

§ TU Darmstadt, Germany

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.

1. Introduction The Border Gateway Protocol (BGP) is insecure and vulnerable to prefix hijacks, exposing systems to attacks like espionage, theft of cryptocurrency, outages, distribution of malware [1], [2], [3], [4]. RPKI was designed to protect BGP from prefix hijacks by certifying assigned network resources and allowing routers to validate BGP announcements against the certified resources [2]. Already, more than 55% of the Internet prefixes are certified with RPKI [5], and about 30% of networks validate BGP announcements with RPKI [6]. With the growing adoption of RPKI, it also becomes central to Internet resilience and stability, and is critical for

national security [7]. The recent routing security roadmap of the White-House identifies RPKI as a mature, ready-toimplement technology to mitigate vulnerabilities in BGP and recommends its deployment across all networks [7]. Nevertheless, no comprehensive analysis of RPKI’s resilience and security has been performed to establish its maturity and readiness for real-world adoption; the complexity of RPKI makes such analysis difficult. RPKI is complex. To ease implementation and improve security ( RFC6480 ), the design of RPKI builds on existing concepts and technologies, such as X.509 certificates, incremental update mechanisms, and a hierarchical tree structure, implementing the global distribution of routing security information. This design is specified in over 50 RFC documents, making RPKI one of the most complex cryptography-based infrastructures deployed at Internet scale, with multiple object types, validation workflows, and integration with third-party systems. This complexity makes it hard to trace requirements across documents and identify specificationlevel issues that may lead to divergent or insecure implementations. In the past, research has found vulnerabilities in RPKI, but these have been viewed in isolation, attributed to mere implementation bugs, deviations from the standard, lack of developer tools, or connectivity issues [8], [9], [10], [11], [12], [13], not to systemic flaws in specification. Study of systemic RFC issues. In this work, we perform the first study of the ca. 50 RPKI RFCs and show that bugs, inconsistencies, and vulnerabilities in standard-compliant RPKI implementations are caused by flaws within RFCs. We classify these flaws according to their underlying root causes, deriving systematic problems in the RFCs. In addition to the 50 RPKI RFCs analysis, our study encompasses an in-depth examination of all popular RPKI validator software packages and an investigation of the operational practices and deployments across the Internet. We trace 24 out of the 52 previously known RPKI vulnerabilities directly to flaws in the standard RFC documents, demonstrating that these are not isolated incidents resulting from poor implementation or operational practices, nor are they the result of deviations from the standard requirements. We find that 7 out of 32 registered CVEs in RPKI were caused by flawed requirements in the RFCs. We identify 12

©2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

issues in the specification, all of which manifest in realworld implementations, and 2 vulnerabilities that expose RPKI deployments to attacks. We also find 61 inconsistencies in RPKI implementations, 23 of which can be directly attributed to the aforementioned issues in RFCs. Our analysis reveals that past investigations of RPKI inconsistencies have not been correctly contextualized within the RFCs; as a result, the underlying specification issues have not been addressed. One example is an issue in the extensions within resource certificates that caused 6K Amazon prefixes not to be validated. While the developers attempted different solutions in their implementations, the core issue is still present in the RFC, as we explain in §5.6. Methodology to identify practical issues. Our methodology is designed to uncover specification flaws in RPKI RFCs by observing how they manifest in real-world implementations and deployments, which is a key strength of our approach. Rather than analyzing RFCs in isolation or deriving tests solely from their logic, we begin by identifying practical inconsistencies, vulnerabilities, and deviations observed in the wild. We then trace these issues back to ambiguities, contradictions, or omissions in the relevant standards. To identify such issues, we combine a systematic analysis of RPKI software with an investigation of Internetwide deployments. We use two techniques: (1) a customized differential fuzzing framework to expose discrepancies in validator behavior caused by undefined or conflicting edge cases in the RFCs, and (2) a novel crawler that detects operational inconsistencies and anomalies in RPKI repositories, which often stem from under-specified requirements. The findings from both approaches are combined with issues from public sources, such as CVE reports, GitHub, and related scientific publications. This provides a comprehensive view of both novel and previously reported RPKI problems, which we leverage for identifying their root causes within the specifications. Harnessing practical impact as the primary method for identifying flaws offers advantages over solely relying on specification text, as in formal methods-based approaches [14], [15], [16]. Certain types of issues, such as undefined edge cases, vague language, or under-specified interactions between components, are often difficult to detect by analyzing RFC text in isolation. In contrast, our methodology identifies issues that manifest in real-world software or deployments, ensuring that each finding reflects tangible operational risks rather than a purely theoretical concerns that lack practical impact, such as formatting errors or typos. Real-world impact. Evaluating the real-world impact of identified issues presents its own challenges. The RPKI ecosystem comprises a large and evolving dataset, currently exceeding 400K objects, deployed in around ∼100 repositories with large variance in size, configurations, and response behavior. Currently, no tools exist for systematically analyzing these deployments. We develop a crawler that downloads and compares real-world objects, checks them against RFC specification and the inconsistencies we identify in our analysis, and evaluates their real-world impact. Mitigations and alert tool. We provide recommenda-

Distributed Repository CA cert

Local network TA cert

signs

...

RP points to

issued by RIR

PP

lists

CA cert

MFT

CRL

rsync /RRDP

TAL

RTR

local mirror validation

ROA

signs

VRPs

RTR BGP speakers performing ROV

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 users of current problems in RPKI in the wild (https://rpki-notify.site). The tool constantly monitors the live RPKI infrastructure, provides information on newly occurring issues, and alerts operators in cases of unreachable publication points, erroneous RPKI objects, and inconsistencies between the Relying Parties (RPs). Furthermore, we use the insights gained through our empirical analysis to explore how LLM-based tools could assist future research in identifying flawed requirements in RFCs. Based on the types of issues we encountered in our practical analysis, the LLM tool receives a keyword or requirement as input and retrieves the relevant sections from the RFCs. This enables a broader application of our findings for performing future semi-automated specification reviews; for example, during the creation of new RFCs. We open-source our compiled datasets, test cases, and implementations to aid developers in mitigating the issues.2 Organization. We review RPKI in §2 and Related work in §3. Our methodology is in §4. In §5, we identify RFC flaws and their propagation into RPKI implementations, and in §6 their impact on RPKI validation. In §7 we attribute the issues to core design principles of RPKI and explain their real-world impact. Mitigations, conclusions, and ethics are in §8, §9, and §10 respectively.

2. Overview of RPKI Routing information exchanged by BGP speakers does not carry any verifiable authenticity. This makes BGP susceptible to attacks, such as prefix origin hijacks, where malicious actors claim origin for an IP prefix and redirect traffic to their Autonomous System (AS). RPKI was designed to add security to inter-domain routing with BGP, making use of the principles of Public Key Infrastructure to bind the ownership of Internet resources, e.g., IP addresses or AS identifiers, to the ownership of a public key. Figure 1 gives an overview of RPKI. Resource owners act as Certificate 1. https://datatracker.ietf.org/wg/sidrops/about/ 2. https://github.com/tkh42/rfc-analysis

2

Authorities (CAs) owning a certificate that binds their key to their resources. At the root of the RPKI hierarchy are the Regional Internet Registries (RIRs) serving as trust anchors. They authenticate subordinate CAs, e.g., Local Internet Registries, which can have their own children. CAs issue RPKI objects to make statements on the valid use of their resources in BGP. Prominently, Route Origin Authorizations (ROAs) allow a certain AS to announce a set of IP prefixes in BGP. Other objects include Certificate Revocation Lists (CRLs) for revoking objects, and manifests containing signed lists of all objects issued by a CA. Objects are stored on RPKI repositories hosted as Publication Points (PPs). To validate BGP announcements with ROAs, networks need to set up a Relying Party (RP) validator. An RP fetches and validates all objects from all available RPKI repositories and maintains a local cache. Periodically, the RPs synchronize their caches with the PPs, using either rsync or the RPKI Repository Delta Protocol (RRDP). While rsync mirrors a file system directory, RRDP servers host HTTPS-accessible notification files listing deltas (incremental changes) and snapshots (complete states) of the repository. The RP parses and validates all RPKI objects and outputs Validated ROA Payloads (VRPs). BGP speaking routers obtain these from the local RP via the RPKI to Router Protocol (RTR) and perform Route Origin Validation (ROV), comparing the BGP update messages against the VRPs to detect bogus announcements. RPKI is specified in RFC documents. Each RFC defines a specific component of the architecture and generally contains a mix of implicit and explicit requirements for implementations and stakeholders. Explicit normative requirements make use of well-defined BCP14 upper-case words MUST/SHOULD/MAY etc. to unambiguously express if and how requirements are binding. RFCs build upon, clarify, update, or partially or fully replace another. The core components of RPKI are specified in 50 RFCs, starting with RFC6480 published in 2012. We illustrate this in Figure 2. Informational RFCs provide general, nonbinding recommendations to operators and implementers. Seven RFCs cover the general operations, PKI structure, and repository organization, including the RFC6484 Certificate Policy (CP) defining the use and life-cycle of certificates and RFC6481 repository profile. The majority of normative RFCs define the RPKI object syntax, semantics, and validation logic, like RFC6492, 9455, 9582 on ROAs. Non-certificate objects are embedded as content in signed objects ( RFC6488, 9589 ). Certificates follow the RPKI’s PKIX profile ( RFC6487, 7318, 9829 ), building upon the X.509 specification’s RFC5280 general profile and RFC3779 IpAddrBlocks extension. Protocols for production services, specifying the management of repository contents, are drafted in RFC6492, 8181 . RRDP is mainly specified in RFC8182 . A detailed breakdown of all RPKI RFCs is in Appendix C. According to NLNetlabs ROV-measurement [17], the currently most popular RP implementations are Routinator (72%), rpki-client (21%), and FORT-validator (5%). We include these three RPs in our study. A small fraction (< 3%)

of other RPs exists, such as OctoRPKI and RPKI Validator, which are no longer maintained and are thus excluded from our study.

3. Related Work Vulnerabilities in RPKI. Previous research discovered vulnerabilities in RPKI [8], [11], [10], [12], [13], [18], [19], [20], with most issues related to parsing logic. These were typically attributed to developer errors or implementation bugs rather than to problems in the underlying specifications. Our research traces the root causes of the bugs to flaws in the RPKI specification, showing that a substantial portion of the issues originates from ambiguities, contradictions, or underspecified behavior in the standard documents themselves. Implementation bugs. Research has utilized insights into the underlying protocols to improve vulnerability detection in implementations [21], [22], [23], [24], without tracing the issues to the factors causing them, such as implementation errors or flaws in the specification. We use implementation issues as a vector to identify problematic sections of the specification that lead to faulty implementation. For example, vague or conflicting requirements lead to divergent implementations, even in the absence of implementation errors. Such issues cannot be identified by the techniques used in previous work, as those treat RFCs as the ground truth of the protocol rather than as a potential source of implementation issues. Formal analysis of specifications. Detecting issues in the specification differs from identifying implementation issues and has historically been difficult: The specification is complex, the RFCs have inter-dependencies through references, updates, or obsoletions, and subtle issues in packet formats, state transitions, or corner cases may only appear during execution in a real-world implementation. Consequently, flawed or underspecified RFC recommendations, which potentially expose systems to detrimental attacks, often remain undiscovered in the specification for decades. A common approach in research for identifying problems in RFCs is based on the formal verification of protocols. First, the protocol behavior is extracted from RFCs and translated into a formal model using a specification language. Then, proof techniques or automated verification tools are used to identify logical or security flaws in the protocol described by the RFC. Formal verification focuses on self-contained, closed systems; this is not suitable for the analysis of RPKI, which lacks a unified model of the entire system and operates in a distributed and asynchronous environment. Formal verification can reason about specification correctness in a standard when applied to an individual component, e.g., handshake logic, [25], [15], [16], [14]. For instance, formal verification analysis of specific security properties of the deterministic random bit generator in the NIST SP 800-90A standard showed that the design was vulnerable [25]. The authors concluded that their attack was theoretical, demonstrating that the standard specification did not achieve weak forward security. A formal analysis of the Web Payments API (WPA) found two vulnerabilities in

3

Figure 2: Evolution of RPKI specification in RFCs. vague formulations constitute a problem with practical impact is challenging based solely on specification text. In contrast to the analysis of specifications using formal methods, we develop a systematic approach based on real-world impacts derived from the analysis of scientific work, GitHub Issues, and CVEs, as well as differential fuzzing of the implementations and evaluations of real-world operations to identify problems in the RPKI specification. This impact-driven analysis of the specification in the RFCs allows us to reveal practical flaws and their real-world impact, which the formal verification models cannot do, since formal methods operate at a mathematical modelbased level, abstracted from the implementation. We focus on standard compliant behavior. In contrast to research that explores deviations from the standard, like [29], which found that no library implementing the TLS session ticket mechanism fully adheres to the standard recommendations in RFC5077 , our goal is to identify flaws in the specification of RFCs. We focus on standard-compliant behavior that produces unexpected realworld outcomes, such as failures or vulnerabilities. The flaws can be conflicts between different RFCs, vagueness (e.g., due to underspecification), or even vulnerable or buggy recommendations.

the specification [26]. The authors did not demonstrate a practical impact but suggested that WPA were expected to be adopted by payment providers in the future. However, formal verification has inherent key limitations. A fundamental issue is that the construction of a formal model is prone to errors. This is further exacerbated when the specification is complex, and RFCs contain interdependencies with references and updates that obsolete older RFCs. As a result, vulnerabilities stemming from underspecification or vagueness may not even be expressible in a formal model. Indeed, although recent research showed DNSSEC to be vulnerable to downgrade attacks [27], an earlier formal analysis of the DNSSEC standard proved the protocol’s correctness and security [28]. Another inherent limitation is that formal verification tools suffer from state explosion, which makes them unsuitable for fully analyzing protocols that consist of multiple components, such as DNSSEC and RPKI. Therefore, previous studies encompass a single mechanism or an isolated component that corresponds to one RFC. Our methodology enables us to perform the first comprehensive study of a complex mechanism composed of multiple components (trust anchors, RPKI objects – certificates, ROAs, manifests, CRLs – PPs, RPs, ROV, transport protocols, ...) which correspond to 50 RFC documents on RPKI. The inter-RFC dependencies in RPKI, which reference, update, or obsolete others, as well as non-obvious interactions, make it hard to find what to verify. The effort to build a comprehensive formal model is huge, error-prone, and leads to state explosion. Finally, formal verification typically applies to abstract models, proving the correctness of a simplified or ideal model, which does not capture the impact in the real world, including implementation-specific behavior or deploymentspecific assumptions (e.g., NAT devices or firewalls); hence, it overlooks aspects that are implementation- or operationspecific. Fuzzing captures realistic models, e.g., PP unresponsiveness and how RPs react to this, which cannot be directly formalized using formal methods. Classifying which

4. Methodology Our methodology is designed to uncover flaws in RPKI specifications by analyzing how they manifest in validator implementations and operational deployments. To achieve this, we combine three techniques: (1) differential fuzzing of major RPKI relying party software, (2) large-scale Internet crawling of RPKI repositories to capture real-world deployment behavior, and (3) manual semantic tracing of observed discrepancies to the relevant RFCs. Importantly, we do not solely rely on newly discovered issues. Instead, we combine these results with publicly available information, including CVEs, previous academic publications, and bug reports

4

Name Scientific Work CVE GitHub Fuzzing Crawler

Sourced 22 surveyed works 40 CVEs 601 GitHub issues Fuzzing 3 RPs 99 repositories

Nr. Issues before 35 40 66 61 3

Nr. Issues after 35 32 49 61 3

Overlap 11 (10 CVE, 1 Fuzz.) 13 (4 GH, 9 Sc.w.) 5 (4 CVE, 1 Fuzz. & Sc.w.) 1 (1 GH & Sc.w.) 0

RFC-related 23 12 23 23 3

Table 1: Sources, Nr. of issues before/after de-duplication, Overlap. how issues in the RPKI RFCs manifest and identify classes of problems.

4.1. Data Aggregation and De-duplication Many issues in RPKI have been identified in the past. These range from vulnerabilities in implementations to operational problems and inconsistent validation. We systematically collect issues from these sources to create a dataset of RPKI-specific issues: Scientific Publications. We include all issues from RPKI publications from the past 5 years that mention the terms vulnerability, issue, inconsistency, or attack. We exclude problems that are the result of RPKI interacting with other protocols and infrastructures, such as DNS components interacting with RPKI [30] and discussions of RPKI design. From 22 surveyed works, we identify 35 issues in seven publications [10], [11], [12], [19], [31], [18], [32] that correspond to our criteria. CVEs. We utilize the keyword search of the National Vulnerability Database (https://nvd.nist.gov/vuln) using the keywords RPKI, RTR, RRDP, and names of the most popular RP implementations (Routinator, Fort, rpki-client). In total, we find 40 CVEs. After coalescing CVEs that describe the same problems across implementations, we obtain 32 issues. GitHub Issues. Additionally, we analyze the GitHub Issues for the repositories of the three RP implementations. At the time of writing, there are 601 GitHub Issues. We filter out any unconfirmed issues, feature requests, and problems not impacting RPKI operations (e.g., bugs in logging), as well as issues related to third-party software, leaving 66 GitHub Issues. We group those with equal causes, whether within or between implementations, into 49 issues to be added to our dataset. We also leverage GitHub’s crosslinking: if multiple issues are linked in comments and fixed through a shared commit/pull-request, we de-duplicate them (e.g., Fort GitHub-Issues 58–60 are expressions of one underlying cause). The analysis of contextual RPKI publications and reports yields past problems; most have already been addressed in current implementations and deployments. To systematically identify security issues that affect current systems, we additionally perform new studies on RP implementations and PP deployments using fuzzing and a crawler. Fuzzing campaign. RPKI is a global trust infrastructure whose purpose is to produce consistent validation outcomes across independently deployed validators. A fundamental requirement for such a system is determinism: given the same repository state, all standard-compliant validators must derive the same validation result. We conduct a structure-aware differential

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 implementer errors. When an issue is RFC-related, we can deduce that its causes in the RFCs are flaws by construction, as we do not start the analysis from inconsequential specification ambiguities or implementation differences in general, but from confirmed security issues. For each confirmed RFC issue, we generate targeted test cases and analyze validator behavior to assess divergence, compliance, and potential security impacts. Our methodology consists of four phases, illustrated in Figure 3 and quantified in Table 1. 1 Data aggregation. We collect a dataset on problems in RPKI from past reports and using automated testing. We source existing reports on problems in RPKI implementations from scientific publications, CVEs, and GitHub Issues. To identify new issues in RPKI, we run a fuzzing campaign based on the publicly available fuzzer CURE [12] to study RP implementations and develop a crawler to find issues in currently deployed PPs. 2 De-duplication. To quantify the output of each source, we first perform de-duplication on the extracted data. We manually group reports on issues if they have equal underlying causes, e.g., two CVEs for distinct implementations relating to the same vulnerability. This is based on descriptions/comments of CVEs, GitHub-Issues, scientific publications, and publication timing. Documentation quality varies, so this is done case-by-case. 3 Correlation analysis. We compare how the sets of issues yielded through each of our source channels contribute to the final dataset and quantify the overlap. 4 RFC analysis Based on the resulting dataset, we conduct an analysis of the RPKI RFCs. We systematically map the issues to the clauses in the relevant RFCs. We analyze the causal relationship between problems in specification and how these problems translate into implementation and deployment. Based on our results, we systematize patterns of

5

fuzzing campaign on RPKI RP implementations to identify current inconsistencies in their processing, i.e., to find inputs that lead to divergent validation results. If validators produce different results on the same input, this violates determinism and leads to inconsistent trust decisions across the ecosystem. This breaks the guarantee of uniform policy enforcement, i.e., that the same routing object is treated consistently by all the RPs. For this reason validation inconsistency is inherently security critical, it undermines the correctness and reliability of the trust infrastructure itself, even if a concrete exploit is not immediately demonstrated. The violation of determinism alone already constitutes a security weakness in a system whose purpose is to provide globally consistent trust decisions. Validation inconsistencies are thus interesting for RFC analysis: if they result from misinterpretation or problems in the specification, validation inconsistencies in RPs uncover systemic problems in the RPKI RFCs. Therefore, we complement the dataset of problems with validation inconsistencies detected through fuzzing. For our analysis, we extend the CURE fuzzer [12] to support inconsistency detection and de-duplication. We run it 3x1h on each RPKI object type, totaling around 20 million test-objects. We use structure-aware mutations guided by the RPKI object grammar and encoding rules [33]. This ensures that generated objects are parseable and reach the semantic validation logic, where RFC inconsistencies and ambiguities occur, maximizing the number of detected issues. An interested reader is referred to Appendix A for more details. Using our fuzzer, we find 61 unique inconsistencies between the different RP implementations, identified through differences in the validated output of RPs and their error logs. 38 inconsistencies (62%) stem from certificate processing. This relatively large share is expected, as certificates are the most complex RPKI objects, with specification mandating 29 different fields and attributes per certificate (e.g., compared to 4 different fields in ROA content). We identify 11 more inconsistencies within the parsing logic, i.e., how the RP handles structural elements, illustrating that inconsistencies stem not only from object processing but also from basic parsing functionality. Additionally, we find 12 inconsistencies that occur within non-certificate object validation: ROA (5), CRL (6), and manifest (1). During our fuzzing campaign, we also identified two vulnerabilities causing crashes: one in Fort and one in Routinator. We disclosed both vulnerabilities to the vendors and received CVEs. Vulnerability descriptions are in Appendix E. RPKI crawler. To assess the real-world impact of RFC specification issues, we developed a custom RPKI crawler that systematically fetches and validates the global set of published RPKI objects and compares the behavior of RRDP-repositories to RFC requirements. We analyze the repository connectivity, transmitted data, and HTTPS behavior. Our crawler implements both RRDP and rsync fetching mechanisms and mirrors the repository structures of all five RIRs and the delegated repositories. In total, we process over 400K files (ROAs, CRLs, manifests, certificates), reflecting the full operational state of the RPKI ecosystem. The design of our crawler takes into

consideration the highly decentralized and latency-sensitive constraints of the RPKI ecosystem. Our crawler employs a distributed and throttled scheduler to balance coverage, speed, and ethics, e.g., by adhering to RRDP minimum repeat query intervals for RPs. It integrates with the differential analysis of RP implementations in a controlled environment to capture validation divergence through validator logs, outcomes, and error codes. The core engineering innovation of our crawler lies in the provenance tracking engine, which constructs a dependency graph linking validation failures to their root causes, e.g., object fields, chain anchors, manifest mismatches, or deployment issues. This allows us to differentiate between failures due to malformed objects and those stemming from under-specified or contradictory RFC semantics. This component allows us to bridge the gap between abstract RFC analysis and its concrete operational consequences. By quantifying how many objects are affected by each class of flaw discovered through fuzzing or manual analysis, we can systematically analyze their prevalence and real-world relevance. Moreover, we utilize the crawling mechanics to measure divergence in RRDP behavior of PPs, including message payloads, transport metadata, and availability behavior. Through this, we identify 3 issues leading to inconsistent behavior of PPs: availability, RRDP file syntax, and TLS certificate deployment. An interested reader is referred to Appendix D for a more detailed description of the crawler implementation. We open-source the full collected dataset and our implementations as artifacts.3

4.2. Correlation Analysis We evaluate how each data source contributes to the final dataset by determining the overlap between the collected issues, i.e., which RPKI issues we identify in more than one source, listed in Table 1. We find that 11 issues (31%) of scientific publications overlap with issues from CVEs (10) and GitHub Issues/Fuzzing (1). 5 issues (10%) from GitHub Issues are also discussed in CVE issues (4) or scientific works/fuzzing (1). The minor overlap between GitHub issues and scientific work shows a discrepancy in how identified problems are reported in RPKI, with researchers not opening issues on GitHub and contributors to GitHub not writing scientific publications. Inversely, 13 issues (41%) from CVEs are also retrievable from either scientific works or GitHub Issues. We observe only one overlapping issue found with fuzzing and no overlap for the crawler issues, which shows that our practical studies almost exclusively identified new problems. Generally, none of our data sources is fully encompassed by the others, and the overlap between all sources is small, illustrating that utilizing different sources to obtain a comprehensive overview of practical RPKI issues is beneficial. 3. https://github.com/tkh42/rfc-analysis

6

4.3. RFC Analysis

but also allows ignoring unknown extensions. Identifying and contextualizing all relevant, overlapping requirements can reveal such conflicts and allow us to identify how they lead to inconsistent implementation. Unspecified cases. Specifications need to be precise and deterministic for any conditional decisions, such as handling inputs or validation states, and instruct behavior in corner cases. When specification language is absent from RFCs, implementations need to make their own assumptions on how to handle these unspecified cases. This can lead to inconsistency and vulnerabilities. For example, the RRDP RFC does not define how processing should proceed after a failed hash verification of a file in a notification, requiring RPs to decide whether to ignore this single file or abort the entire update operation. We classify RFC issues based on whether they lack explicit requirements for all possible cases. Vagueness. Vagueness is imprecise language where specification is formally complete (all cases are covered) but allows for multiple diverging interpretations due to phrasing. This forces implementers to concretize the requirements themselves, leading to inconsistencies. This is inherently different from legitimate RFC flexibility where RFCs permit explicit divergence on how things are implemented, but which should not lead to security impact such as different validation results on the same object. We classify vagueness based on whether two different, conflicting implementations are possible and valid according to a given requirement. Complexity. The nature of RFCs leads to related requirements being distributed over a large number of distinct RFC documents. Even if the RFC language is precise, this can lead to operational issues when implementers are unaware of the full context of a requirement while implementing specific RFC requirements. We define complexity as cases in which interconnected requirements for a feature are distributed among multiple RFCs or multiple sections within an RFC without adequate, concrete references. For example, RPKI certificate extension processing steps are defined in RFC6487 as differences to the validation of the general PKIX RFC5280 , selectively and partially overriding requirements without contextualization. Infeasible requirements. RFC requirements must be translated into real-world deployments and can prove operationally infeasible; e.g., if the requirement leads to validation failures in benignly misconfigured objects. This manifests in implementations that deliberately oppose RFC specification, traceable through documentation on issues and inconsistent behavior.

With the dataset of issues, we systematically investigate the root causes in the specification RFCs. To aid this process, we first map the RPKI RFCs by purpose in the RPKI infrastructure, as visualized in Figure 2. Thus, when an issue relates to the implementation of a specific part of the infrastructure, e.g., publication, we narrow the set of relevant RFCs for analysis. We incorporate the RFC errata in this process, as they provide insights into previously identified problems with the specification text. For each dataset issue, we perform a manual analysis consisting of the following steps: 1. We collect all relevant RFC sections. This is aided by performing a keyword search over the RFC text to identify sections that share terminology with the issue. 2. We investigate how the phrasing of the specification relates to the issue. 3. We classify whether the issue has roots in the specification. We document novel findings on how specification problems translate into implementation and deployment. 4. We evaluate the operational impact of the issue by developing implementation-specific test cases. RFCs may allow flexibility in how implementations realize certain behaviors, including differences, such as in processing, data structures, or error handling. Such flexibility is explicitly defined in the specification and operates at the level of implementation choices. However, specification flexibility is bounded by its security impact. In a global trust infrastructure, such as RPKI, acceptable flexibility must not affect security relevant properties, in particular the consistency of validation results across independently deployed validators. We therefore define specification flexibility as permissible only as long as it preserves security-relevant equivalence of system behavior. In contrast, the RFC issues we identify lead to observable negative security impact, such as divergent validation outcomes, VRPs or protocol behavior resulting in inconsistent trust decisions. This security impact indicates that the specification fails to define acceptable behavior in a way that preserves security-relevant equivalence across implementations and we therefore classify it as a specification flaw rather than an expression of flexibility. We therefore start from impact issues as indicators of candidate specification flaws. This allows us to distinguish intended flexibility from under-specification, vagueness or conflicting requirements that affect trust decisions. Our analysis classifies such specification flaws into the following categories, capturing how they arise in RFCs: Conflicting requirements. RFCs frequently contain multiple distinct requirements that apply to the same functionality. For instance, in RPKI, whether an object is considered ‘valid’ is subject to several distinct requirement conditions. When these requirements are in opposition, implementations cannot fully comply with the specification and must make deliberate choices on which parts of the specification take precedence. For example, implementing validation of PKIX certificate extensions, RFC6487 states that the extensions not explicitly mentioned in §1 MUST be absent,

5. Flaws in RPKI Standard Specification Applying our methodology, we identify 12 problems within the RPKI RFCs with practical impact on RPKI implementations and deployments. An overview is given in Table 2, also listing which identified issues are novel. Four RFC problems (2, 6, 7, 8) have been reported on previously, either as errata or in scientific contributions; however, our analysis offers new insights by identifying the underlying

7

Issue 1 2 3 4 5 6 7 8 9 10 11 12

Sources Used

Categorization

Operational Impact RP Repos. IV MF DoS NC OR

Novel SW CVE GH DF RC V CR UC C IR NC CP Qualifiers and RFC8360 ∗ X.509 Extensions HTTPS Certificate Validation ∗ Use of DER Encoding ∗ RRDP Withdraw ∗ Term Definitions Repository Chain Limit Service Availability ASN.1 INTEGER ∗ IP Address Representation ∗ RRDP Entry Duplication ∗ Notification File Hash ∗ Sources. SW: Scientific Works, GH: GitHub Issues, DF: Differential Fuzzing, RC: RPKI Crawler RFC Issue. V: Vagueness, CR: Conflicting Requirements, UC: Unspecified Cases, C: Complexity, IR: Infeasible Requirement Operational Impact. NC: Non-Compliance, IV: Inconsistent Validation, MF: Missing Feature, DoS: Denial of Service, OR: Objects rejected

Table 2: Identified issues, the methods we used, their categorization and operational impact in RPs and repositories. RFC sections and evaluating their impact. The other eight RFC problems are novel. For each identified flaw, we create test cases to evaluate how the requirement is implemented, detecting non-compliance, inconsistent validation, missing features, denial-of-service (DoS) vectors in RPs and noncompliance in PPs. We additionally test whether they cause the rejection of real-world standard-compliant RPKI objects. We discuss the identified flaws next.

5.1. CP Qualifiers and

Figure 4: Missing comment on CP Qualifiers in RFC8360 . If, e.g., RIPE NCC were to issue a new certificate with the RFC8360 policy to supposedly increase resilience against errors, it would instead invalidate the entire RIPE NCC RPKI tree in any system using rpki-client or Fort.

RFC8360

RFC7318 (Jul 2014) updates RFC6487§4.8.9 (Feb 2012) by allowing the optional inclusion of zero or one CP qualifier in the Certificate Policies extension. Moreover, §3 acknowledges that strictly following old RFC6487 validation invalidates RFC7318 -conforming objects. In RFC8360 (April 2018), an alternative profile for PKIX Resource Certificates was published. This update changes the object validation algorithm to be more errorresistant without changing the syntax and, to avoid inconsistent implementations, defines new OIDs to signal the new algorithm. For this, it updates RFC6487 , but conflictingly replaces RFC6487§4.8.9 again, not acknowledging the RFC7318 changes. We illustrate this conflict in Figure 4. Implementation compliance. We test the support of RFC8360 validation by encoding a certificate and an entire publication point with the new OIDs. We find multiple inconsistencies. First, rpki-client does not support the new OIDs and rejects any object using them, while Routinator and Fort support them and apply the new validation algorithm. Second, we find that Fort only succeeds validation if both the ROA and its respective certificate use a consistent set of OIDs, which is neither mandated in the RFC nor necessary for security. Investigating the Fort code, we find this constitutes a bug in the validation procedure failing to handle mixed CP validation. The observation of these inconsistencies puts the idea of the new validation policy into question. It was designed to ensure child certificates remain valid if unrelated parent resources change and the change is not fully propagated to the children. However, with the lacking or faulty support in rpkiclient and Fort, using the new policy renders the certificate invalid, also recursively invalidating all its child repositories.

5.2. X.509 Extensions Within the specification of X.509 certificate extensions, we identify a multitude of findings. RFC6487§1 specifies that extensions not explicitly mentioned MUST be absent in resource certificates. However, later in §4.8, the formal requirements are: 1. The extensions listed in §4.8 “MUST be present in a conforming resource certificate, except where explicitly noted otherwise.” 2. Systems “MUST reject the certificate if it encounters a critical extension it does not recognize.” 3. Systems “MAY ignore unrecognized non-critical extensions.” While these three requirements do not contradict each other, point (3), allowing that unrecognized extensions “MAY” be ignored, directly contradicts §1. Moreover, this also contradicts the more recent informational, hence explicitly non-normative, RFC8897§3.1 on requirements for RPs stating “any extension excluded by Section 4.8 of [RFC6487] must be omitted.” This conflict has also been mentioned in erratum eid3168 but persists to date. The conflicting requirements on how extensions must be validated by RPs leads to a slate of vague specifications and undefined cases. Complicating this issue, RFC6487 explicitly inherits PKIX general specification ( RFC5280 ) and its requirements, without clarifying how inherited requirements interact with new requirements (1), (2), and (3).

8

For example, RFC5280§4.2 explicitly says that a certificate “MUST NOT include more than one instance of a particular extension.” An RP could either ignore a duplicate non-critical, non-RPKI extension and assume validity as RFC6487§4.8 suggests, or fail validation due to RFC5280 requirements. Cases of invalid, illstructured, duplicate, or syntactically correct extensions with unrecognized OIDs are not clearly defined. Implementation compliance. We find many cases of inconsistent processing of X.509 extensions. Rpki-client is the only RP that accepts critical extensions that are unknown to RPKI specification but known to OpenSSL, like subject alt name RFC4985 . Code investigations show that rpkiclient relies on OpenSSL for initial extension validation. Since the extension is known to OpenSSL, the extension is accepted even though rpki-client cannot process it. Routinator is the only implementation not failing validation if duplicate unknown extensions are present in a certificate. While all RPs accept an unknown non-critical extension if its internal formatting is correct, only rpki-client and Fort fail if the encoded extension value cannot be decoded. Evidently, overriding requirements from established technologies, like PKIX, can cause substantial inconsistency when implementations incorporate existing libraries that implement the original requirements, leading to conflicts.

schemes like BER and CER, or the X.509 encoding requirements, which mandate DER for “data to be signed” ( RFC5280§4.1 ), but not the entire object. Implementation compliance. We create a test case by encoding a valid RPKI object in CER. No RP enforces the requirement from RFC6488 that objects must be DER encoded. This is likely rooted in operational necessity. Manual investigation shows that a subset of otherwise valid CAs (1,627 objects, 0.3% of objects) use non-DER compliant encoding, impacting 1,952 prefixes. These would not be available if RPs strictly followed RFC encoding rules. The non-compliance illustrates implementations will disregard non-essential RFC requirements if they improve practical resilience against misconfigurations.

5.5. RRDP Withdraw RPKI offers two separate mechanisms to remove a nonexpired object from a CA to exclude its content from the validated output. CAs can either add the object to the CRL and revoke its certificate, or withdraw the object through a withdraw entry in an RRDP delta file. While revocation with CRLs is comprehensively defined in RFC6487 , RRDP RFC8182 is vague on the implementation of withdraws, not defining concrete steps or requirements on how they should be performed. This causes conflicts if an object is withdrawn through RRDP, signaling deletion, but is still listed in a manifest, thus required for validation. The RFC does not specify whether the signed manifest entry should override the unsigned RRDP withdraw. Implementation compliance. We test RP behavior through three tests: First, we issue a withdraw to a ROA while keeping it listed in the manifest, testing how RPs interpret the conflicting information. Fort deletes the object from its local cache, then fails the validation of the manifest as it cannot find the listed ROA. Routinator and rpki-client detect the conflict and prioritize the signed manifest, ignoring the withdraw and succeeding manifest validation. Next, we withdraw and unlist the ROA from the manifest, then re-list it in the next delta’s manifest to test if RPs respect withdraws once the object is no longer in the manifest. All RPs delete the ROA from their local cache and thus fail validation once the ROA is re-listed. Lastly, we test removing and re-adding the ROA to the manifest without a withdraw. All RPs keep the ROA in their local cache and succeed validation once it is re-added to the manifest. The issue shows that overlapping mechanisms in RFCs require clear advice on which take precedent.

5.3. HTTPS Certificate Validation RPKI uses HTTPS to ensure transport security. However, RRDP RFC8182 mandates that RP implementations ignore HTTPS validation failures. Specifically, RPs must continue to retrieve data even if HTTPS validation fails, as this is usually a symptom of benign configuration errors and RPKI objects are protected by signatures anyway. This design contradicts the validation procedures in HTTPS RFC8446 . Implementation compliance. We test RPs by setting up a valid repository with a self-signed, an expired, a malformed, and no HTTPS certificate. No current RP implementation follows the RFC8182 requirements; they stop retrieving data if a repository has a faulty HTTPS certificate, in line with how HTTPS was designed. Interestingly, proper adoption of the RFC requirement in the now deprecated RIPE validator has been scolded in CVE-2020-16163, complaining about the implementation dissenting HTTPS validation rules. The issue shows that defining requirements that go against the initial use-case of a technology, like HTTPS, leads to non-compliance if the benefit is insufficient to warrant the overwrite.

5.6. Term Definitions

5.4. Use of DER Encoding

RFCs take special care in explicitly defining specific terms to ensure no misinterpretation of requirements. We still find wordings in RFCs that are not clearly defined and lead to diverging interpretations. A prominent example of this problem is RFC6487§4 , requiring that listed fields must be present in a valid resource certificate; any

RFC6488 (signed objects) mandates that all RPKI objects must use DER encoding to ensure the encoding is predictable and deterministic. This imposes stricter rules on RPKI objects than the general CMS specification in RFC5652 , which allows more generic encoding

9

other field must not be present. Yet, the section does not define the term “field.” RFC6487§4 instructs that, if not explicitly overruled in RFC6487 , RFC5280 specifications apply. Looking into RFC5280 , the term field is used to generically describe elements of the ASN.1 encoded structure. When referring to values within some specific fields, including Issuer, attributes is used, but no clear distinction is drawn. With the requirement that no additional fields are allowed in a resource certificate, it is unclear if this rule encompasses what RFC5280 calls attributes. In practice, the lack of proper definitions results in vagueness in RFC6487§4.4 on the Issuer field in resource certificates. The CommonName in an Issuer field is required, the serialNumber is optional, but there is no clarification on whether any other attributes are allowed and how their inclusion affect certificate validity. As neither attribute nor field have concrete definitions, the RPKI requirements on fields are of no aid to implementers. One interpretation of RFC6487§4 reads Issuer attributes being encompassed by the term field value. Then, RFC6487§4.4 (specifying a field value) implicitly forbids other unmentioned attributes since field values as specified in RFC6487 “MUST be used in conforming resource certificates” ( RFC6487§4 ). However, if attributes are distinct from fields (as the use of these terms in RFC5280 implies), RFC6487 4.4 makes no statement on additional attributes, thus not explicitly overriding RFC5280 . In theory, RFC5280§4.1.2.4 should then apply, which explicitly states that implementations “MUST be prepared to receive certificates” with certain Issuer standard attribute types, including the OrganisationName attribute. Note that this is itself vague as to what constitutes prepared to receive, leading to ambiguity in if and how this rule would be overruled by RFC6487 ; however, RFC5280 does not forbid valid certificates from using these well-known attributes. Implementation compliance. The vagueness and complexity led implementers to different conclusions on allowed attributes in resource certificates. Fort implementers interpreted that no additional attributes must be present within fields, causing Fort to treat more than 6K Amazon prefixes as not ‘RPKI protected,’ since their RPKI objects contained an OrganisationName attribute [12]. Our test shows that rpki-client now also applies this interpretation, rejecting objects with the attribute. Only Routinator accepts objects with an additional attribute. Evidently, without proper guidance on how a term should be interpreted, implementations will make their own assessment. RFCs thus must ensure terms are fully defined before introducing requirements that rely on correct understanding of the term. The conflict is yet to be addressed in the specification.

lead to long validation chains and thereby stall RPs through deep delegations. The RFC addresses this by proposing RPs to implement a maximum chain length, but not providing guidance on what this length should be. Further, the RFC does not limit the maximum chain breadth, exposing RPs to attacks by repositories that have arbitrarily many children [10]. RRDP RFC8182 further states an RP should have some kind of bound to the amount of work it is willing to do, not addressing how this should be applied in practice. Even under benign operation, no concrete recommendations on limits can lead to scalability issues. Previous work [13] found RPs struggle to find fitting limits when requesting unresponsive repositories, increasing validation times. Implementation compliance. To test the repository chain limit, we test RPs for the maximum allowed repository chain depth and breadth. We place each repository on its own domain to simulate a realistic deployment of a stalling attack [10], [11]. Our tests show that all RPs limit the maximum depth, complying with RFC6481 . The limits differ across RPs, with rpkiclient enforcing a default max. depth of 11, Fort 30 and Routinator 31. No RP limits the maximum breadth of child repositories for a given CA. Thus, creating repositories with many children stalls all RP implementations. Clearly, relying on vague statements, like requiring that some kind of bound should applied, is insufficient for protecting implementations against attacks.

5.8. Service Availability Availability of services is essential for the functionality of RPKI. The RFCs acknowledge this, with RFC6481 stating, the “publication repository SHOULD be hosted on a highly available service and high-capacity publication platform.” RFC6484 is more stringent, saying CAs or repository operators must not “intentionally use technical means of limiting read access.” This blanket rule disbarring repository operators from any means of limiting access would not allow blackholing or denying access to attackers, even when subjected to DoS attacks. Prior work [11] reported that operators use rate-limiting to safeguard to their server, which conflicts with RFC6484 . This may not align with realworld circumstances, leading to service degradation if CA or repository reliability fails RFC expectations, for instance, when large delays are caused by unresponsive repositories, observed in [13]. For provisioning, RFC6492 explicitly acknowledges the necessity of flow control in servers and suggests using HTTP status codes. However, this is unspecified for RRDP in RFC8182 , a vagueness that has been investigated in [10]. Implementation compliance. We replicate the HTTP response code study in [10], and measure RP delays when confronted with low response rates or unresponsive repositories. First, we set up a repository that replies with an HTTP 404 error, indicating resource unavailability. All RPs immediately stop fetching from the repository. If a repository replies with an error code of temporal unavailability, like 503, we observe that Routinator and rpki-client treat

5.7. Repository Chain Limit RPs interact with untrusted servers when downloading repository data. RFC6481 acknowledges that allowing repositories to create an arbitrary number of children may

10

the repository identically to a 404 error message while Fort retries after 4 seconds, subsequently concluding that the resource is unavailable. This is a change to the results in [10], where no RP was honoring response codes. Additionally, we test if a slow replying repository can stall RPs by setting up a repository rate-limited to 100 bytes/s. We find that Fort implements a protection against a slow-replying repository, aborting the connection after 24s if the answer rate is below 10kB/s. Routinator and rpki-client get stalled, continuing the slow connection until all data has been downloaded or the RRDP timeout value has been reached: 360s in Routinator and 900s in rpki-client. While these protections are an improvement over [10], they are still insufficient to protect against long stalling attacks, as attackers may abuse long validation chains and stall RPs at every link.

ROA RFC6482 posed no equivalent restrictions for its IpAddrBlocks field, which shares its name with the extension type but has a different definition. Update RFC9582 resolves this and encourages CAs to order the IP address prefixes in ROA similarly to RFC3779 and to expect RPs to enforce this. BCP RFC9455 , published before RFC9582 , recommends to not including more than one IP address prefix in ROAs at all. Specification spread across multiple documents and contradictions lead to inconsistent enforcement. Implementation compliance. We create three certificates with non-canonical RFC3779 extensions. First, we add two neighboring IP prefixes that could be combined into one prefix. Routinator accepts the object; Fort and rpkiclient reject it as both use OpenSSL for validation, which considers the extension value malformed. Second, if the extension contains two neighboring prefixes that cannot be combined into one prefix, the object is still rejected by Fort and rpki-client as both prefixes could instead be one address range, as is RFC-mandated. Third, if a range is erroneously used instead of a prefix, only Fort rejects the object. The strict rejection of non-canonical IP addresses is deterministic, but also increases the burden on repository operators, who must ensure perfect encoding of IP addresses to get objects accepted by all RPs. The inconsistent enforcement complicates identifying issues, as a non-canonically encoded extension may be accepted by one RP.

5.9. ASN.1 INTEGER The ASN.1 object specifications in RPKI have two distinct types for AS numbers. In the RFC3779 AS Identifier Delegation extension, the ASId type is an ASN.1 INTEGER and used for the min/max of AS number ranges. Similarly, in RFC6482 ROA eContent, the ASID type is an ASN.1 INTEGER with the concretization that the field asID of type ASID holds an AS number. Both types are vaguely defined, lacking formal bounds or a reference to what constitutes an AS number. In BGP, AS numbers are 32bit representable unsigned integers, but ASN.1 INTEGERS can be negative or larger than 32-bit. It is unspecified how unexpected values shall be treated by RPs when parsing these types. The lack of bounds to ASN.1 INTEGER decoding is not universal within the RPKI RFCs. For example, the ROAIPAddress type within the ROA profile contains the maxLength field of type INTEGER and has clear bounds in RFC6482§3.3 , illustrating that bounds are sometimes applied to decoding and indicating unintended vagueness in the ASId/ASID cases. Implementation compliance. We test integer processing in the RPs by creating a ROA with an AS number 0xFF. Since INTEGERs are two-complement numbers and the first bit of 0xFF is 1, its value is −1 and thus constitutes an illegal AS number. Routinator and rpki-client both detect the error and discard the ROA as invalid. Fort, however, implements integer decoding differently, ignoring that integers are two-complement numbers and instead parsing the value as unsigned, corresponding with how AS numbers are defined ( RFC6793 ). Fort thus interprets 0xFF as the valid AS number 255, leading to an inconsistent cache state between RPs. This parsing issue illustrates that distinct, yet similarly named terms with similar purposes introduce complexity and lead to discrepancies in implementation.

5.11. RRDP Entry Duplication The RRDP RFC8182 does not define how RPs should handle duplicate entries within a delta, e.g., two identical ROAs being added. It is unclear if RPs should ignore the duplicate, fail validation of the delta, or ultimately abort the RRDP update; implementations diverge on this issue. Implementation compliance. We find RPs react differently to duplicate entries, with Routinator falling back to snapshot, rpki-client failing the update and reverting to rsync, and Fort ignoring the duplicate and applying the delta.

5.12. Notification File Hash RRDP update notification files list one snapshot and a series of delta entries; each entry has a URI and a hash value. RFC8182§3.4.1 describes the notification file processing by RPs, referring to §3.5.1.3 for required validation steps. In case of failure, the notification file must be rejected. §3.5.1.3 lists validation rules that “MUST be observed;” one requires each entry’s hash to match the hash sum of the file located under the URI. In case of mismatch, the RP “MUST reject the file,” but the specification is vague if this constitutes a notification format violation. The phrase “reject the file” implies that only the entry delta/snapshot is rejected, not the notification. This conflicts with the wording in §3.4.1, i.e., when any validation step (one is hash verification) fails, the notification file must be rejected and RRDP cannot be used.

5.10. IP Address Representation RFC3779 imposes a strict syntax for IpAddrBlocks in the PKIX IP Address Delegation Extension. IP prefixes must be ordered by IP address family, then by bit value of the prefix with no overlapping. In contrast, the original

11

6.1. Study Methodology

Implementation compliance. All RPs validate the hash of the delta file before applying the update. In our test case, we break the delta hash, keeping it 256 bit but invalid. While all RPs detect the broken hash, Routinator and Fort fall back to the snapshot, as required by the specification, but rpkiclient aborts the PP update and falls back to the previously stored version in the local cache. After the update, the RPs have an inconsistent state: Routinator and Fort apply the new snapshot while rpki-client remains in the old state.

We install the three RPs locally and execute them simultaneously every 15 minutes, which we found experimentally to be the minimal possible update cycle without overlapping runs. To study validation failures during operation, we analyze the VRPs output and error logs of the RPs. Limitation of RP output for studying impact. Solely studying the plain output is limited; during validation failures, the RPs exclude failed objects from the output and subsequently erase all information on these objects, as well as the scope and impact of the failure. For example, consider an RPKI repository with an expired TLS certificate. The RP will fail validation of that certificate and log the error. However, it will not download data from this repository, making it impossible to quantify the exact impact of the expired certificate on the set of VRPs. To overcome this limitation, we utilize our crawler with validations disabled, running it simultaneously with the RPs to capture a full view of the global RPKI objects. Our measurement was conducted on January 5, 2025.

5.13. RFC Non-Compliance The above issues can all be traced back to RFC problems. In this section, we list issues we found, that arise from RFC non-compliance, i.e., issues in implementations disregarding clear requirements in RFCs. We find 38 cases of inconsistent validation rooted in direct non-compliance with RFCs, which we classify as follows. Implementation of non-standard features. Only rpkiclient implements Elliptic Curve Cryptography (ECC), which is yet to be supported by the RPKI RFCs. Routinator and Fort reject objects signed with ECC. Ignoring non-canonical object contents. The RPKI RFCs are generally strict about disallowing unspecified fields within objects. These requirements are not security critical but ensure objects adhere to the strict RPKI syntax. In 16 cases, we observe implementations that do not enforce these checks and ignore non-canonical fields. Examples include rpki-client and Routinator ignoring additional signedObject URIs in the SubjectInformationAccess extension, defying RFC6487 , or Routinator accepting additional qualifiers in the Certificate Policies extension, defying RFC7318 . The implication of this RP non-compliance is poor object hygiene; CAs have less incentive to ensure that no RFC-undesired fields are in their objects if RPs accept them nevertheless. Ignoring value constraints. In 20 instances, RP implementations do not enforce checks on object values. For example, only Fort enforces an object’s signedObjectURI to match its actual location. Furthermore, Routinator ignores a mismatch between the issuer name in a child certificate and the subject name of its parent. In both cases, these checks are irrelevant to the operational correctness of the RP. In the latter case, Fort and rpki-client use the issuer name in processing to map children to parent certificates, thus enforcing the check, while Routinator does not. While the enforcement of field value constraints may appear superfluous to RPs, novel features in RPKI could change this and make checks security-critical. This has already been the case for the AS Number Delegation Extension, which had no applications in RPKI operations until the introduction of ASPAs.

6.2. Inconsistencies in VRPs In most runs, the RPs yield differing VRPs outputs. This observation is consistent with prior work [12], which, however, did not analyze the source of these inconsistencies. Our study shows that inconsistencies are caused by: (1) frequent changes to RPKI objects and (2) discrepancies between RP implementations. Since the crawler provides us with a view of all RPKI data before validation, we can map which differences are caused by validation inconsistencies and which are simply due to new objects being added or removed between requests by different RPs. Our findings show that most inconsistencies are short-lived and caused by natural fluctuations in object counts. We do find two causes for persistent validation inconsistency between RPs impacting VPRs: First, we find that enforcement of manifest number increments discards up to five VRPs. This check is only enforced by Routinator and rpki-client, not Fort, adding these VRPs only to the Fort VRPs. We observe that the number of VRPs impacted by this enforcement fluctuates. Investigating the objects that create this inconsistency, we find that they do not always violate the requirement; the manifest number is incremented only in some updates, not in all. Since this is an incremental validation, i.e., the check is only conducted when using the incremental update algorithm over deltas, it leads to inconsistencies between snapshot updates and delta updates. This makes the detection of this inconsistency even more difficult for an operator, as they might issue the new object, update over snapshot and get the correct VRPs output, whereas an update over delta would fail and exclude the VRPs. This breaks with the design philosophy of RRDP that applying snapshot or delta updates should always lead to the same deterministic state. The second persistent inconsistency occurs in Routinator, resulting in 11 missing VRPs entries. Routinator is the

6. VRPs’ Inconsistencies in the Wild Next, we analyze inconsistencies in deployments to identify real-world impact of issues.

12

only RP that discards URIs referred to as Dubious hosts: URIs of unexpected structure, e.g., those including a port number. We find that three repositories are not downloaded by Routinator because of the port numbers in their URIs. The issue with inconsistencies. Our measurements show that most inconsistencies we identified in RFCs and implementations are currently not present in real-world objects; even the Amazon prefix case was fixed after disclosure and does not currently lead to real-world inconsistencies. Our findings are still important to address to ensure resilience of the architecture: Any of the identified issues could be triggered if an operator makes benign changes to their objects, e.g., adding an additional extension or changing how they use withdraw in RRDP, in compliance with the RFC. Depending on the test setup used by the operator, the resulting inconsistency can go unnoticed, as with Amazon, leading to a silent downgrade of security for protected resources. To ensure that such issues are mitigated before they reach production, it is vital to improve RFC quality and address the flaws identified in this paper.

use of existing implementations, the substantial changes and new requirements limit the re-usability of existing libraries, as acknowledged by RFC6487 , and require RPKI software to re-implement large parts. As evident in §5, this is challenging and leads to inconsistencies and vulnerabilities. Developers must not only implement and maintain the overhead complexity but also navigate complex interactions of the utilized technologies within RPKI. Examples of how this can lead to issues include implementation vulnerabilities in interacting with HTTPS URIs, rsync URIs, DNS, and X.509 processing [10], [30], [12]. Single point of failure in a distributed system. RPKI requires RPs to retain an up-to-date view of current data, necessitating a high degree of availability of PPs. RFC6480§8 says that RPKI as a distributed repository “should be inherently resistant to denial-of-service attacks.” In practice, the way availability is handled in RPKI renders it vulnerable. Once a PP is unavailable, RPs can no longer determine whether its CRL has changed and must not retrieve nor validate its entire sub-tree ( RFC9286§6 ); even benign misconfigurations or just a single file missing are specified as a failure condition. Effectively, every unavailable repository in the validation path is a single point of failure for its entire sub-tree. Compared to other distributed repositories like DNS, RPKI does not reduce system load by distributing its data. Every RP must walk the full RPKI tree for each validation run. This makes RPKI unique among decentralized security infrastructures, as its operations depend on both trust in and availability of the anchors.

7. Factors Introducing the Issues into RPKI A number of principles and decisions have shaped RPKI design in its present form. We discuss how the design decisions have led to systematic issues that we find in this work. We also explain why RPKI remains functional and effective today, and how future developments could compromise this. Tradeoff of building on existing technologies. The design of RPKI builds on top of the existing concepts of PKI and applies them to a new use case. Accordingly, RPKI heavily re-uses existing technologies. Resource delegation and validation are realized using X.509 certificate validation chains and CRLs. HTTPS and rsync serve as transport channels for exchanging files. Existing object formats like Cryptographic Message Syntax (CMS), XML, ASN.1, and DER are used to structurally represent data. The application of these existing solutions to RPKI has trade-offs. The RPKI specification requires heavy adaptation and patching of the utilized technologies to fit the RPKI use-case. For example, the X.509 certificate structure was designed to be expressive to ensure that certificates are self-sustaining and that distribution does not rely on services like PPs. RPKI does not use self-sustaining certificates, as it has a rigid repository structure without out-of-band distribution. Moreover, X.509 is designed to be very flexible and extensible. Since RPKI only has a fixed use-case and distribution (hierarchical PPs), flexibility and extendability are not required ( RFC6487 ). The RPKI specification acknowledges this and mandates strictness; allowing only specific object formats and disallowing optional and unknown fields ( RFC6487 ), which leads to significant complexity for implementations enforcing this. Similar observations hold for other adopted technologies. RPKI uses HTTPS without requiring certificate validation (§5.3); and ASN.1 encoding rules are limited to DER (§5.4). These adaptations and “tweaks” introduce complexity to RPKI implementations. Instead of facilitating the re-

Limited impact due to low RPKI adoption. Our study finds that many problematic design choices of RPKI are currently masked by operational realities. Compared to ∼45K CAs currently participating in RPKI, the number of self-hosted repositories remains small, with only 100 active instances. This low number masks the limited scalability caused by deep and slow repository chains. Moreover, few active use-cases apart from ROAs are widely deployed yet in RPKI. ASPAs, BGPsec, Ghostbuster Records (GBRs), and RFC8360 validation see little to no use. Thus, we see low object diversity and little divergence from specifications. Most of the issues we illustrate in §5 do not yet occur in real-world objects. Fixing these issues before they manifest in deployments is, however, essential to ensure RPKI can scale to a resilient and secure architecture with diverse usecases. Existing operational trends indicate a change in the infrastructure that will gradually unmask specification issues. We measure that the number of repositories has been steadily growing, reaching 100 repositories as of 2025, up from 93 one year ago, which is consistent with observations from previous work [34]. While current divergences are mostly benign, they indicate an increase with more repositories. Continuing adoption will lead to growth in interoperability issues and implementations defying specifications to account for real-world diversity, e.g., as discussed in §5.4.

13

8. Mitigations and Recommendations

of updates and obsoletions. We then use section titles and references to specific sections to identify which old sections are explicitly updated or replaced by the new RFC. This automation yields a set of specific RFC sections relevant to analyzing a reference between RFCs. (2) Problems 5, 6 and 9 arise from lacking or conflicting definitions for keywords, e.g., ASId. To assist in identifying future issues like this, we utilize LLMs. We use GPT-4o by OpenAI for all our evaluations; however, our pipeline supports different models and APIs. First, we algorithmically identify all sections from the RFCs containing the keyword in question through a regular expression. Then, we pass all sections one-by-one to the LLM and task it with deciding whether the section contains a textual or formal (e.g., ASN.1) definition of the term and, if so, to return the definition in the section. Using this approach, we were able to find all definitions of the term ASId, as well as its type and contents, across the various documents, enabling the detection of the mismatch between the expected contents and the overly broad ASN.1 type INTEGER. (3) Problems 7 and 8 result from significant complexity in the RFCs. Interdependent requirements distributed over multiple sections/RFCs, lacking proper references, lead to implementers overlooking conflicts and unspecified (corner) cases. We implement an LLM-based search functionality to extract the inter-dependencies. When given a description of a specific requirement to extract, like ‘limits on the number of validated children repositories,‘ the tool iterates over all RPKI RFC sections and extracts relevant texts. The text can then be manually checked to identify problems. In our evaluation, this approach successfully identifies the recommendation to use a maximum chain length from RFC6491 . The code for our tools is available on GitHub. Further examples of how our tooling could aid a similar RFC analysis can be found in Appendix B.

Test cases for inconsistencies in software. Investigating RPKI implementations, we find that unit tests are used to ensure the correct functionality of the software.4 To facilitate additional inconsistency testing, we opensource our implementation-specific tests. Minimizing standard complexity. RPKI specifications explicitly state that they prioritize the minimalism of objects over extensibility ( RFC6487 ) and are only intended for one very specific use-case ( RFC9255 ). Yet, as we show in this work, the design of RPKI has significant complexity. We recommend that the design of new RPKI standards should strongly assess the necessity of enforced checks for the respective use-case. Validation should only be strictly enforced when necessary for security or operation and applied leniently in other cases. To prevent the divergence of objects, the standard should be stricter on object issuers than on RPs. Inconsistency notification. We develop a web service that continuously searches for the issues explored in this work and aggregates information on erroneous or inconsistently handled objects or unreachable repositories (https://rpki-notify.site). Stakeholders may register to be notified when new problems occur. Additionally, we utilize the contact information in existing GBRs. According to RFC8897§4.4 , RPs are expected “to use the information from GBRs to contact the maintainer of the PP where any stale/expired objects were encountered.” As of today, this is not implemented in any of the RPs. Our service closes this implementation gap and, for the first time, makes use of the GBRs for their intended purpose by informing affected parties about the problematic objects we detect. We hope that by offering this service, we further encourage the deployment and usage of GBRs in PPs. Paving the road for LLMs. LLMs offer automated techniques to reduce manual effort in identifying issues. However, recent work on LLMs found that they remain unreliable for reasoning on complex tasks, like RFC issues [35]. We thus do not employ LLMs to find and evaluate issues by themselves. Instead, based on the results presented in this work, we explore how LLMs could assist human researchers in detecting and avoiding future issues. We build an easily customizable LLM-assisted pipeline for identifying candidate sections of specification problems observed in our work and extracting important context for these sections, allowing researchers and RFC authors to better assess potential problems. (1) Multiple observed problems (e.g., 1, 2, 10) stem from conflicts between sections that reference or update each other. To identify potential conflicts, we implement an algorithmic routine to contextualize every RFC section by finding all incoming and outgoing references using regular expressions and collecting the referenced sections. Additionally, we parse all RFC headers and construct the graph

9. Conclusion Developing implementations from standards requires the interpretation of specification text into code and configurations. Defining requirements is a tradeoff: On the one hand, standards should provide exact details for implementations. On the other hand, they should still leave room for flexibility to allow for competitive implementations. Flaws or vagueness in standard requirements not only create hurdles for implementers developing the software but also expose adopters of the standard-compliant technology to attacks. This work provides the first systematic analysis of vulnerabilities in RPKI standards and their propagation into implementations and operational deployments. Our findings demonstrate that many security and stability issues in RPKI stem not from implementation mistakes but from flaws in the RFC specifications, such as vagueness, conflicting requirements, and underspecified behavior. By combining impactdriven specification analysis, differential fuzzing, and realworld validation, we reveal deep-rooted issues and their concrete impact on Internet routing security.

4. https://github.com/NICMx/FORT-validator/blob/main/test/rrdp test.c

14

In addition to reducing RPKI complexity and improving the resilience of RPKI deployments on the Internet, our research also offers a transferable approach for evaluating other complex, multi-RFC protocols. Future work can build on our open-source tooling and datasets to extend this analysis to other protocols and formalize specification testing workflows to support the development of robust standards. To address identified flaws, we are actively working with SIDROPS members to develop fixes to flawed RFC sections.

[4]

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-272024/, 2024, accessed Aug 5 2025.

[5]

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

[6]

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

[7]

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

10. Ethics Considerations

[8]

Y. Gilad, A. Cohen, A. Herzberg, M. Schapira, and H. Shulman, “Are we there yet? on RPKI’s deployment and security,” NDSS, 2017.

We ensure that our research is ethical by following best practices for research in network and software security [36], [37], [38]. All testing, evaluations and fuzzing activities were performed in controlled environments, isolated from live production systems. We limit crawler requests to 1/min, as outlined by RRDP specification RFC 8182. We disclosed all discovered vulnerabilities and inconsistencies to the developers of RPKI software, and two CVEs have been assigned.

[9]

T. Hlavacek, I. Cunha, Y. Gilad, A. Herzberg, E. Katz-Bassett, M. Schapira, and H. Shulman, “DISCO: Sidestepping RPKI’s deployment barriers,” in Network and Distributed System Security Symposium (NDSS), 2020.

11. LLM Usage Considerations

[12] D. Mirdita, H. Schulmann, N. Vogel, and M. Waidner, “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. [Online]. Available: https://www.ndss-symposium.org/ndsspaper/the-cure-to-vulnerabilities-in-rpki-validation/

[10] K. van Hove, J. van der Ham-de Vos, and R. van RijswijkDeij, “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 [11] T. Hlavacek, P. Jeitner, D. Mirdita, H. Shulman, and M. Waidner, “Stalloris: RPKI downgrade attack,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 4455–4471.

The methodology used for this paper does not include any LLM usage. None of the results presented in our analysis (§5) have been evaluated by LLMs; all identified flaws were manually checked by us, mapped to the RFCs, built into a test-case, and manually run against the implementations to understand how all reacted. Datasets included as artifacts have been compiled without the use of LLMs. Building on the results of the methodology and analysis, we develop an LLM tool (referred to in the introduction and §8) to assist future work in analyzing RFCs based on the results obtained from our study. In our exploration, we limited the number of queries to those necessary to gain insights into the capabilities of LLMs in the tasks explored.

[13] D. Mirdita, H. Schulmann, and M. Waidner, “SoK: An Introspective Analysis of RPKI Security,” arXiv preprint arXiv:2408.12359, 2024. [14] 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,” in 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 51–68. [15] 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. [16] J. Yen, T. Lévai, Q. Ye, X. Ren, R. Govindan, and B. Raghavan, “Semi-automated protocol disambiguation and code generation,” in Proceedings 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

Acknowledgments This research work was supported by the National Research Center for Applied Cybersecurity ATHENE. ATHENE is funded jointly by the German Federal Ministry of Research, Technology and Space and the Hessian Ministry of Science and Research, Arts and Culture.

[17] N. Labs, “NLnet Labs RPKI statistics,” [Online; accessed 20-January2025]. [Online]. Available: https://rov-measurements.nlnetlabs.net/ stats/ [18] L. Cattepoel, D. Mirdita, H. Schulmann, and M. Waidner, “Poster: Kill Krill or Proxy RPKI,” in Proceedings 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

References [1]

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

[2]

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.

[3]

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

[19] O. Jacobsen, H. Schulmann, N. Vogel, and M. Waidner, “Poster: From Fort to Foe: The Threat of RCE in RPKI,” in Proceedings 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 [20] H. Schulmann, N. Vogel, and M. Waidner, “Rpki: Not perfect but good enough,” arXiv preprint arXiv:2409.14518, 2024.

15

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

[37] 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. [38] L. Sweeney, M. Crosas, and M. Bar-Sinai, “Sharing sensitive data with confidence: The data tags system,” Technology Science, September 2015. [Online]. Available: https://techscience.org/a/2015092901

[22] 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 Methodology (TOSEM), vol. 28, no. 4, pp. 1–37, 2019.

Appendix A. Fuzzer Design

[23] R. Meng, M. Mirchev, M. Böhme, and A. Roychoudhury, “Large language model guided protocol fuzzing,” in Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS), vol. 2024, 2024.

To test RPKI implementations we need to simulate a real world RPKI setup. For this, the fuzzer creates RPKI repositories and assigns each a ROA with a unique AS number and IP prefix for fingerprinting. The fuzzer ensures objects are validly structured and encoded to allow objects to pass through parsing and test validation code. To improve deeper penetration of the RP code, the fuzzer guides mutations with coverage guidance. After creating test inputs, the fuzzer executes the RPs and analyzes their output. We implement a parsing module that reads the output logs of the RPs, and maps error messages to the objects that caused the inconsistency. We build a new de-duplication module that aggregates inconsistencies that can be traced back to the same cause. This is necessary, as after one minute of running the fuzzer, already over 99% of reported inconsistencies are duplicates, requiring substantial manual analysis to filter for new unique findings. Implementing de-duplication is not trivial, as RP log messages follow non-deterministic formats and different variations of error messages can map to the same underlying issue. The module uses the input object type, the pattern of RPs that accept/reject the object, the processed error messages, and the code lines that results in the error condition to de-duplicate. We run the fuzzer 3 times for 1h on all RPKI object types and log all new unique inconsistencies. We determine the runtime to be sufficient, as we observe no new inconsistencies in longer runs. Fuzzing is done on the following versions: Routinator 0.14.2, Fort 1.6.6., rpki-client 9.5.

[24] Y.-H. Zou, J.-J. Bai, J. Zhou, J. Tan, C. Qin, and S.-M. Hu, “TCPFuzz: Detecting memory and semantic bugs in TCP stacks with fuzzing,” in 2021 USENIX Annual Technical Conference (USENIX ATC 21), 2021, pp. 489–502. [25] J. Woodage and D. Shumow, “An analysis of NIST SP 800-90A,” in Advances in Cryptology–EUROCRYPT 2019: 38th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Darmstadt, Germany, May 19–23, 2019, Proceedings, Part II 38. Springer, 2019, pp. 151–180. [26] Q. H. Do, P. Hosseyni, R. Küsters, G. Schmitz, N. Wenzler, and T. Würtele, “A formal security analysis of the W3C web payment apis: Attacks and verification,” in 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 215–234. [27] E. Heftrig, H. Schulmann, and M. Waidner, “Downgrading DNSSEC: How to Exploit Crypto Agility for Hijacking Signed Zones,” in 32nd 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. [28] J. Bau and J. C. Mitchell, “A security evaluation of DNSSEC with NSEC3,” in Network and Distributed Systems Security (NDSS) Symposium. The Internet Society, 2010. [Online]. Available: http://www.isoc.org/isoc/conferences/ndss/10/ [29] S. Hebrok, S. Nachtigall, M. Maehren, N. Erinola, R. Merget, J. Somorovsky, and J. Schwenk, “We really need to talk about session tickets: A Large-Scale analysis of cryptographic dangers with TLS session tickets,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 4877–4894. [30] T. Hlavacek, P. Jeitner, D. Mirdita, H. Shulman, and M. Waidner, “Behind the scenes of RPKI,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 1413–1426. [31] D. Mirdita, H. Shulman, and M. Waidner, “Poster: RPKI kill switch,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 3423–3425.

Appendix B. Automated Analysis

[32] T. Hlavacek, P. Jeitner, D. Mirdita, H. Shulman, and M. Waidner, “Beyond limits: How to disable validators in secure networks,” in Proceedings 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

We conduct a number of experiments to illustrate how the application of our LLM pipeline could facilitate further research in terms of contextualizing and tracking requirements across RFCs. Service Availability. During our analysis, we found that the requirements regarding the availability of RPKI services are spread across a significant number of RFCs, rendering it difficult to obtain a full overview. We task the LLM with extracting concrete claims regarding the availability of the RPKI, of which we find 10 text passages. The LLM correctly includes the sections in the CP RFC6484 , provisioning RFC6492 , and DoS guidelines in RFC6487§6 that we analyzed in Section 5.8. This demonstrates how the LLM pipeline can be used to help keep track of requirements spread out across RFCs.

[33] V.-T. Pham, M. Böhme, A. E. Santosa, A. R. Căciulescu, and A. Roychoudhury, “Smart greybox fuzzing,” IEEE Transactions on Software Engineering, vol. 47, no. 9, pp. 1980–1997, 2019. [34] Y. Su, D. Li, L. Chen, Q. Li, and S. Ling, “dRR: A decentralized, scalable, and auditable architecture for RPKI repository,” in NDSS, 2024. [35] D. Li, B. Jiang, L. Huang, A. Beigi, C. Zhao, Z. Tan, A. Bhattacharjee, Y. Jiang, C. Chen, T. Wu et al., “From generation to judgment: Opportunities and challenges of llm-as-a-judge,” in Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, 2025, pp. 2757–2791. [36] M. Bishop and D. V. Bailey, “Ethical issues in computer security research: What practitioners say,” in Proceedings of the 4th Workshop on Ethics in Computer Security Research (WECSR). Springer, 2008.

16

Use of DER Encoding. In Section 5.4, we find that the RFCs mandate DER encoding and do not require support for CER encoding. However, “CER” is mentioned multiple times within the RPKI RFCs. To test our LLM pipeline, we search for all sections containing the keyword “CER” and task the LLM with identifying any support requirements. We find 13 occurrences, none of which the LLM wrongly classifies as support requirements in the RPKI. X.509 Extensions. In RFC5280 and RFC6487 , we observe the keywords “differs” and “relates” being used to describe differing requirements, leading to the complexity issue described in Section 5.2. We explore how our LLM tool can be used to investigate potentially recurring patterns. We perform a keyword search for “differs” and “relates,” yielding 7 and 3 occurrences, respectively. We let the LLM decide whether the keywords are used to describe varying or conflicting requirements, and it correctly concludes that none of the occurrences match the observed pattern.

(TAL) serves the purpose of linking to the trust anchor CA certificate and is defined in RFC8630 , obsoleting the former versions RFC7730 and RFC6490 . RFC6485 , replaced by RFC7935 , defines the algorithms and key sizes in use in the RPKI. RFC7318 amends RFC6487 by permitting CP Qualifiers, RFC9829 clarifies CRL number handling in RFC6487 . RFC8360 “Validation Reconsidered” introduces an alternative validation algorithm and new identifiers for use within certificates. BGPsec ( RFC8205, 8206 ) enables path validation of BGP UPDATE messages and makes use of the RPKI. RFCs that make changes to the RPKI are RFC8208 , obsoleted by RFC8608 , which amends the algorithms used for BGPsec in RPKI, and RFC8209 , which defines the BGPsec router certificate among others. Production Services. RFCs in this category include protocols that do not involve RPs, instead cover PP services. A provisioning protocol for the RPKI is defined in RFC6492 , defining the interaction between CA and subject. RFC8183 describes how a publication relationship can be established out-of-band between a CA and a repository operator; RFC8181 specifies the publication protocol. Transport Protocols. RPs make use of rsync and the RRDP ( RFC8182, 9674, 9697 ) to retrieve objects from the RPKI distributed repository. RFC6810, 8210 define the RTR, RFC6945 the monitoring of RTR. Validation in Routers. The validation of BGP prefix origin announcements in routers using ROA information is specified in RFC6811 and RFC7115 . RFC8481 adds clarifications, RFC9324 provides fixes to excessive route refreshing, and RFC8893 defines ROV for routes sent to BGP neighbors. Not included, but closely related to the core set of RFCs, are RFCs of the X.509 PKIX (namely RFC3779, 5280, 6818 ) and vCard format ( RFC6530 ), which provide the specifications for the RPKI X.509 objects and GBRs, respectively. RFC7909 provides an application of RPKI for securing Routing Policy Specification Language (RPSL) objects. RFC9255 touches on RPKI misuse and forbids the usage of the RPKI to authenticate non-RPKI, real-world data.

Appendix C. RPKI RFCs This section provides a full description of the RPKI RFCs and their categorization. Informational RFCs give general recommendations and provide extensive descriptions for stakeholders. Their contents are generally non-binding to implementers. RFC6480 provides an introduction of the structure, operations and purpose of the RPKI. RFC6483 describes the semantics of ROAs and how route validity is determined on the basis of ROA payloads. RFC6907, 8897 contain implementation and deployment advice. RFC7128, 8488 discuss specific implementations. RFC8211 describes threats to the RPKI from adversarial CAs. RPKI Operations / PKI Structure. Central to the RPKI operations is the RFC6484 Certificate Policy which specifies how certificates must be issued, distributed, and used. RFC6489, 6916 describe the transition procedures between key pairs and algorithms, respectively. RFC6491 lists RPKI objects issued by IANA. RFC8416 Simplified Local Internet Number Resource Management (SLURM) is a mechanism for a RP to specify local exceptions to RPKI. RFC9319, 9455 are updated guidelines on issuing ROAs. Repository Object Format and Validation. RFCs in this category define specific objects in the RPKI, their syntax, semantics, use, and validation. The repository structure and distribution of objects in PPs is defined in RFC6481 . The profiles of certificates and CRLs in the RPKI are defined in RFC6487 , and RFC9829 and build upon the general X.509 certificate profile in RFC5280 . They make use of the X.509 IP address and AS identifier delegation extensions of RFC3779 . RPKI signed objects, such as ROAs ( RFC6482 , since obsoleted by RFC9582 ), manifests ( RFC6486 , since obsoleted by RFC9286 ), and GBRs ( RFC6493 ) are the content of a CMS ( RFC5652 ) signed object, whose template is defined in RFC6488 and RFC9589 . The Trust Anchor Locator

Appendix D. Repository Crawler In contrast to RP software packages, which are publicly available, the software of most RPKI repositories, like software used by the five RIRs, are closed-source and not publicly available. We develop the repository crawler to evaluate RFC compliance of RPKI repository instances. This serves two purposes: (1) Evaluate repository instance compliance with nonobject related RFC8182 requirements that impact RPs. We validate repositories based on their availability, RRDP message syntax, and HTTPS certificates, since these are the mandatory RFC8182 requirements that impact whether the responses can be validated by RPs.

17

(2) Collect a complete view of all RPKI objects published in the distributed repository that serves as a benchmark for the validation in RPs. We collect a ground truth of published data against which we can compare the validated output of RPs to estimate how much data is “lost” due to issues preventing proper validation. We achieve this by designing the crawler to accept any repository data, regardless of whether it can be validated. By running the crawler, we obtain a dataset of properties that the repositories uphold and can correlate these data points to inconsistencies between the VRPs after RP validation. Crawler operation. The crawler begins with the TALs of the five RIRs and recursively downloads all repositories by parsing CA certificates, linking manifests, and retrieving all listed objects. RPKI crawler supports downloads over both RRDP and rsync, preferring RRDP as per RFC8182 . It validates, but not enforces transport security requirements as mandated by RFC8182 , accepting repositories hosted on non-default ports or with invalid or expired TLS certificates. For RRDP messages, the crawler checks syntax requirements, but forgoes enforcement beyond requiring that objects are generally parseable. Our measurement is conducted on January 5, 2025. In the following, we present the evaluation results. Repository availability. We crawl 99 RRDP notification URLs in the full RPKI tree. Of these, 10 are permanently offline, meaning the URLs to the repository are included in some certificates Subject Information Access extension, but the address did not respond to HTTPS requests from our crawler for any measurement. 3 repository servers are reachable but serve invalid notifications, like nginx error pages, indicating that an HTTPS server is available, but misconfigured. This leaves 85 repositories that serve RFCconforming notifications, listing 85 snapshots and 4581 delta files. RRDP file syntax. In RFC8182§3.5 , there are explicit MUST-requirements on the syntax of notification, delta, and snapshot files. We evaluate all repository files, checking the XML namespace, US-ASCII encoding, version, amount of snapshot entries, and contiguous deltas sequence. The evaluations show a consistent formatting of RRDP files in repository servers. We parse 86 notification which include 86 snapshot files, and 4573 delta files. All XML files use the correct encoding, version, have exactly one snapshot, and obey the sequencing rules for delta entries. However, no single file has the correct XML namespace parameter in the root element, indicating that implementers have deliberately deviated from specification, omitting the namespace to reduce the size of RRDP files. As the namespace is not used for disambiguating XML files, the omitted value does not impact RP operation, however, only because RPs forgo enforcing the namespace in violation of RFC8182 . RRDP HTTPS certificates. Data published in the RPKI repository is fully signed. By design, repository servers and communication channels to RPs are untrusted. Nevertheless, RRDP utilizes HTTP over TLS (HTTPS) for downloading

RPKI data. RFC8182§4.3 has the explicit requirement that RPs should validate TLS certificates obtained from the servers, but they must not reject data based on this. Furthermore, several guidelines on TLS certificates are listed, against which we evaluate the TLS certificates of repository servers: DNS-ID identifiers should be present, DNS names should not contain the wildcard “*,” and a Common Name field may be present but should not be used for authentication. We run the crawler to collect all HTTPS certificates of available RPKI repository servers. Of the 65 obtained certificates, 62 are valid. Two certificates had been issued by LetsEncrypt, but have since expired, and one certificate is self-signed and lacks DNS-IDs. Moreover, 16 (25%) have DNS wildcard characters, and one has no common name.

Appendix E. Vulnerabilities During our work we identified two vulnerabilities and received two CVEs for our findings (CVE-2025-0638, CVE2024-56375). Routinator. The Routinator vulnerable enables DoS of the implementation by uploading a malformed RPKI object to a repository. The vulnerability results from a UTF-8 parsing error that led to an unhandled exception in the code. Specifically, if a manifest entry contains the UTF-8 continuation character without a proper termination in the next character, Routinator will crash. Fort. The Fort vulnerability results from a missing bounds check in the manifest entry iteration not considering the case of an empty list. If an empty list was provided, the loop check overflowed, and the loop executed with a length of zero, leading to a field accessed in an uninitialized array and crashing the binary.

Appendix F. Meta-Review The following meta-review was prepared by the program committee for the 2026 IEEE Symposium on Security and Privacy (S&P) as part of the review process as detailed in the call for papers.

F.1. Summary This paper analyzes the Resource Public Key Infrastructure (RPKI) ecosystem to identify how vagueness and inconsistencies in RFC specifications lead to implementation bugs and security vulnerabilities.

F.2. Scientific Contributions • •

18

Identifies an Impactful Vulnerability Provides a Valuable Step Forward in an Established Field

F.3. Reasons for Acceptance 1) 2)

Identifies an Impactful Vulnerability: The scope of the study is comprehensive: it spans many RFCs and provides a holistic view of the RPKI landscape. Provides a Valuable Step Forward in an Established Field: The “impact-driven” reverse-direction analysis provides a powerful template for analyzing other complex protocol; it goes from implementation errors to specification flaws.

F.4. Noteworthy Concern Causality and Root Cause Attribution: A significant discussion point was whether implementation divergences are truly caused by RFC flaws or if they represent flexible developer choices that do not necessarily lead to security impacts. The paper must carefully distinguish between these two.

19