Internet-Draft BM for RPKI RP July 2026
Qin, et al. Expires 7 January 2027 [Page]
Workgroup:
BMWG
Internet-Draft:
draft-qin-bmwg-rpki-rp-bench-01
Published:
Intended Status:
Informational
Expires:
Authors:
L. Qin
Zhongguancun Laboratory
Y. Su
Zhongguancun Laboratory
D. Li
Tsinghua University

Benchmarking Methodology for RPKI Relying Party

Abstract

This document defines a benchmarking methodology for evaluating RPKI Relying Party (RP) implementations in controlled laboratory environments. The methodology focuses on whether RP implementations correctly perform required validation steps and on the performance of these operations. RP implementations are treated as black boxes, enabling consistent and objective assessment based on externally observable behavior rather than internal design or implementation details.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 7 January 2027.

▲

Table of Contents

1. Introduction

The Resource Public Key Infrastructure (RPKI) [RFC6480] provides a framework for cryptographically securing Internet routing by allowing Relying Parties (RPs) to validate Route Origin Authorizations (ROAs) and other RPKI objects. Currently, there is no standardized methodology to evaluate whether RP implementations correctly perform the required validation procedures. In addition, the processing performance of RPs, such as the time required to validate objects and generate validated ROA payloads (VRPs), has not been systematically measured.

This document defines a benchmarking methodology for Relying Parties that addresses both functional correctness and processing performance. Specifically, the methodology provides:

  1. Functional correctness tests to evaluate compliance with the RFC requirements.

  2. Performance tests to measure the total processing time from object retrieval to VRP generation.

This document currently focuses on the validation output produced from ROAs, namely the generated VRP set. Validation outputs associated with ASPA objects or other current or future RPKI signed objects are outside the scope of this document, although they may be evaluated using a similar methodology with object-specific validation requirements and expected outputs.

The remainder of this document is structured as follows:

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Relying Party Overview

A Relying Party (RP) in the Resource Public Key Infrastructure (RPKI) is responsible for retrieving, validating, and making available RPKI objects to support secure route validation. [RFC8897] specifies the expected behavior of RPs, which includes:

After validation, the RP produces a Validated Payload for use in routing systems. These functions ensure that only valid and trusted RPKI objects influence routing decisions.

3. Test Setup

This section defines the test setup. The System Under Test (SUT) (i.e., the RP software) is treated as a black box. No internal configuration or implementation behavior of the RP software is mandated. The test setup focuses on providing controlled inputs and observing RP outputs to enable reproducible and comparable measurements.

In this methodology, the input to the SUT is the controlled RPKI repositories configured by the Controller and published through the controlled Servers. The output of the SUT is the generated VRP set, or equivalent validation output that allows the Controller to determine the resulting VRPs. Verification in this methodology is based on the SUT's externally observable output, rather than on its internal cache layout, internal processing pipeline, or implementation-specific debug information. For the correctness metrics defined in this document, a one-shot validation run is sufficient.

3.1. Test Environment

In this methodology, the Tester consists of the Servers and the Controller. Together, they generate the test conditions, trigger events, and support observation of the SUT for functional and performance evaluation. The SUT itself is evaluated for correctness and efficiency in processing RPKI objects.

+----------------------------------+
|             Controller           |
+----------------------------------+
       |                  |
       v                  v
+-------------+      +-------------+
|     SUT     | ---> |   Servers   |
+-------------+      +-------------+
Figure 1: Test environment

To ensure meaningful testing, the environment should include:

  • At least one Trust Anchor (TA)

  • One or more subordinate certificate authority (CA) certificates

  • RPKI objects signed by CAs

The test environment should support multiple RPKI transport protocols for object retrieval, including Rsync [RSYNC], RRDP [RFC8182], or Erik [I-D.ietf-sidrops-rpki-erik-protocol].

3.2. System Under Test and Servers

The SUT is an RPKI Relying Party implementation that retrieves RPKI objects from the controlled repositories, validates them, and generates the VRP set or equivalent validation output.

The Servers should include PPs which host RPKI objects signed by CAs. Each PP at least contains ROAs, a manifest, and a CRL necessary for the tests. RPKI objects can be added, modified, or removed by the Controller.

3.3. Controller

The Controller orchestrates the entire testing process. In Figure 1, the arrows from the Controller to both the SUT and Servers represent the flow of control information.

For the SUT, the Controller controls the start and end of tests. The Controller can obtain the SUT's VRP set or equivalent validation output through an externally observable output interface configured for the test, such as an output file, RTR, or a CCR profile [I-D.ietf-sidrops-rpki-ccr]. The Controller then processes test results and compares them with the expected output derived from the controlled repository contents.

For the Servers, the Controller handles content changes to ensure that the SUT sees one set of RPKI objects during a validation run and a different set during the next run. Existing tools (e.g., [Barry]) can be used to implement and manage the test environment.

4. RPKI Relying Party Benchmarking Tests

4.1. Baseline Valid Repository Processing

Objective: To establish a baseline for evaluating whether the SUT can process a controlled repository containing valid RPKI objects and generate the expected VRP set. This test verifies the SUT's output for a repository in which all relevant objects are valid and all validation conditions are satisfied. This baseline confirms that valid repository contents produce the expected VRP set before error cases are introduced.

Procedure: The Servers and all RPKI objects are correctly configured prior to the test. The SUT is configured with the URI of the TA.

The following steps are performed:

  1. Publish a baseline repository containing valid certificates, manifests, CRLs, and ROAs on the Servers. The baseline repository MUST be constructed so that each ROA under test produces a distinct VRP payload. This ensures that the absence of a VRP from the generated VRP set can be attributed to the rejection of the corresponding ROA.

  2. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  3. Start the SUT and allow it to perform one validation run over the controlled repository.

  4. Verify that the generated VRP set matches the expected VRP set derived from the baseline repository contents.

Expected Results: The generated VRP set matches the expected VRP set derived from the baseline repository contents. This indicates that, for the baseline repository, the SUT can retrieve, parse, validate, and process the relevant RPKI objects sufficiently to generate the expected VRPs.

4.2. Object Syntax Validation Correctness

This section evaluates whether the SUT correctly performs syntax validation for different RPKI objects. The SUT is expected to perform syntax checks according to the relevant specifications and detect objects that do not conform to the defined syntax requirements.

The syntax requirements for different RPKI objects are defined in the following specifications:

Unless otherwise specified, each test in this section starts from the baseline repository defined in the Baseline Valid Repository Processing test. A single object in the baseline repository is then replaced with a malformed object that violates one specific syntax requirement. The SUT behavior is evaluated by checking whether the generated VRP set matches the expected result derived from this single-object modification. In general, VRPs whose production depends on the malformed object are expected to be absent from the generated VRP set, while unaffected baseline VRPs are expected to remain present.

4.2.1. DER Decoding

Objective: To evaluate whether the SUT correctly rejects an RPKI object that contains invalid Distinguished Encoding Rules (DER) encoding.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one ROA in the baseline repository whose payload is present in the baseline expected VRP set.

  3. Replace only the selected ROA with a malformed DER-encoded version of that ROA, for example by using a BER encoding that is not valid DER.

  4. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  5. Start the SUT and allow it to synchronize the repository contents.

  6. Verify that the generated VRP set matches the baseline expected VRP set with the VRP derived from the malformed ROA removed.

Expected Results: The generated VRP set matches the baseline expected VRP set with the VRP derived from the malformed DER-encoded ROA removed. Unaffected baseline VRPs remain present.

4.2.2. Certificate Syntax Validation

Objective: To evaluate whether the SUT correctly performs syntax validation for CA certificates.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one leaf CA certificate in the baseline repository. The selected leaf CA has no subordinate CAs and issues EE certificates for one or more ROAs that produce baseline VRPs.

  3. Replace only the selected leaf CA certificate with a malformed CA certificate that violates one specific syntax requirement defined in Section 7.2 of [RFC6487] (e.g., missing mandatory fields, invalid field values, incorrect extensions, or malformed structures).

  4. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  5. Start the SUT and allow it to synchronize the repository contents.

  6. Verify that the generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs whose EE certificates are issued by the selected leaf CA removed.

Expected Results: The generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs whose EE certificates are issued by the selected leaf CA removed. Unaffected baseline VRPs remain present.

4.2.3. CRL Syntax Validation

Objective: To evaluate whether the SUT correctly performs syntax validation for CRLs.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one leaf CA in the baseline repository. The selected leaf CA has no subordinate CAs and its publication point contains one or more ROAs that produce baseline VRPs.

  3. Replace only the CRL issued by the selected leaf CA with a malformed CRL that violates one specific syntax requirement defined in [RFC5280] or [RFC6487].

  4. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  5. Start the SUT and allow it to synchronize the repository contents.

  6. Verify that the generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs in the selected leaf CA's publication point removed.

Expected Results: The generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs in the selected leaf CA's publication point removed. Unaffected baseline VRPs remain present.

4.2.4. Manifest Syntax Validation

Objective: To evaluate whether the SUT correctly performs syntax validation for manifests.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one leaf CA in the baseline repository. The selected leaf CA has no subordinate CAs and its publication point contains one or more ROAs that produce baseline VRPs.

  3. Replace only the manifest associated with the selected leaf CA's publication point with a malformed manifest that violates one specific syntax requirement defined in [RFC6488] or [RFC9286].

  4. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  5. Start the SUT and allow it to synchronize the repository contents.

  6. Verify that the generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs in the selected leaf CA's publication point removed.

Expected Results: The generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs in the selected leaf CA's publication point removed. Unaffected baseline VRPs remain present.

4.2.5. ROA Syntax Validation

Objective: To evaluate whether the SUT correctly performs syntax validation for ROAs.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one ROA in the baseline repository and record the VRP payload expected from that ROA.

  3. Replace only the selected ROA with a malformed ROA that violates one specific syntax requirement defined in [RFC6488] or [RFC9582].

  4. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  5. Start the SUT and allow it to synchronize the repository contents.

  6. Verify that the VRP payload expected from the malformed ROA is absent from the generated VRP set.

Expected Results: The generated VRP set matches the baseline expected VRP set with the VRP payload expected from the malformed ROA removed. Unaffected baseline VRPs remain present.

4.3. Certification Path Validation Correctness

Objective: To evaluate whether the SUT correctly performs certification path validation for the EE certificate associated with a selected ROA.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one ROA in the baseline repository and identify the EE certificate associated with that ROA.

  3. Modify only the relationship between the selected ROA's EE certificate and its issuing CA certificate to introduce one certification path violation. Examples of such violations include, but are not limited to:

    • Invalid certificate signature, where the EE certificate cannot be verified using the issuing CA's public key.

    • Resource extension violation, where the resources listed in the EE certificate are not encompassed by the resources listed in the issuing CA certificate.

    • Invalid issuer-subject relationship, where the issuer information in the EE certificate is inconsistent with the issuing CA certificate.

  4. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  5. Start the SUT and allow it to synchronize the repository contents.

  6. Verify that the VRP payload expected from the selected ROA is absent from the generated VRP set.

Expected Results: The generated VRP set matches the baseline expected VRP set with the VRP payload expected from the selected ROA removed. Unaffected baseline VRPs remain present.

4.4. Signed Object Signature Validation Correctness

Objective: To evaluate whether the SUT correctly verifies the digital signature of an RPKI signed object using the corresponding public key in the associated certificate.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one RPKI signed object in the baseline repository whose validity is required for producing one or more expected VRPs. For a ROA signature test, select one ROA and record the VRP payload expected from that ROA.

  3. Replace only the selected signed object with a version whose signature is intentionally invalid (e.g., the object content is modified after signing or the signature does not match the corresponding certificate).

  4. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  5. Start the SUT and allow it to synchronize the repository contents.

  6. Verify that the generated VRP set matches the baseline expected VRP set with the VRPs that depend on the invalidly signed object removed.

Expected Results: The generated VRP set matches the baseline expected VRP set with the VRPs whose production depends on the invalidly signed object removed. For a ROA signature test, this means that the VRP payload expected from the selected ROA is removed. Unaffected baseline VRPs remain present.

4.5. Manifest Processing Correctness

This section evaluates whether the SUT correctly uses manifests to verify the integrity and completeness of RPKI repository objects.

Manifests are expected to be used to:

  • Verify that the content of each RPKI object matches the hash listed in the manifest.

  • Verify that objects accepted from a publication point are consistent with the object list declared in the corresponding manifest.

4.5.1. Manifest Hash-Mismatch Check

Objective: To evaluate whether the SUT correctly handles a retrieved RPKI object whose content does not match the hash declared in its associated manifest.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one leaf CA in the baseline repository. The selected leaf CA has no subordinate CAs and its publication point contains one or more ROAs that produce baseline VRPs.

  3. Select one ROA listed in the manifest associated with the selected leaf CA's publication point.

  4. Modify only the selected ROA after the manifest has been generated, so that the ROA hash no longer matches the hash listed in the manifest.

  5. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  6. Start the SUT and allow it to synchronize the repository contents.

  7. Verify that the generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs in the selected leaf CA's publication point removed.

Expected Results: The generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs in the selected leaf CA's publication point removed. Unaffected baseline VRPs from other publication points remain present. This reflects that, in a cold-start validation run, a hash mismatch causes the fetch for that publication point to fail.

4.5.2. Manifest Object-Mismatch Check

Objective: To evaluate whether the SUT correctly handles an object that is missing from or extra in relation to the object list declared in a manifest.

Procedure:

  1. Start from the baseline repository defined in the Baseline Valid Repository Processing test.

  2. Select one leaf CA in the baseline repository. The selected leaf CA has no subordinate CAs and its publication point contains one or more ROAs that produce baseline VRPs.

  3. For a missing-object test case, remove only one object listed in the manifest from the selected leaf CA's publication point.

  4. For an extra-object test case, add one otherwise valid ROA to the selected leaf CA's publication point without listing it in the corresponding manifest, and record the VRP payload that would be expected from that ROA if it were accepted.

  5. Each test case introduces only one manifest object mismatch at a time.

  6. Initialize the SUT for a cold-start validation run (e.g., with no previously cached repository state).

  7. Start the SUT and allow it to synchronize the repository contents.

  8. Verify that the generated VRP set matches the expected result for the specific object-mismatch test case.

Expected Results: For a missing-object test case, the generated VRP set matches the baseline expected VRP set with the VRPs derived from ROAs in the selected leaf CA's publication point removed. Unaffected baseline VRPs from other publication points remain present. This reflects that, in a cold-start validation run, a missing object listed in the manifest causes the fetch for that publication point to fail.

For an extra-object test case, the generated VRP set matches the baseline expected VRP set. The VRP payload that would be derived from the extra ROA is absent from the generated VRP set.

4.6. Processing Time test

Objective: To measure the end-to-end processing time of the SUT for a one-shot validation run. Processing time is measured as the elapsed wall-clock time between the moment the Controller starts the validation run and the moment the SUT makes the generated VRP set or equivalent validation output available.

Procedure:

  1. Prepare a test repository containing a predefined set of RPKI objects.

  2. Start the SUT for a one-shot validation run and record the start timestamp.

  3. Allow the SUT to complete the validation run and produce the generated VRP set or equivalent validation output.

  4. Record the end timestamp when the generated VRP set or equivalent validation output becomes available.

  5. Calculate the total processing time as the difference between the start and end timestamps.

  6. Repeat the test for different numbers of CAs, ROAs, and generated VRPs to evaluate performance under varying load conditions.

5. Report Format

This section defines the format for reporting the results of RPKI Relying Party benchmarking tests. The format is concise and suitable for documenting both functional correctness and performance results.

System Under Test (SUT) Information:

Test Repository Information:

Functional Correctness Test Results:

Performance Test Results:

Notes:

6. Security Considerations

This document defines benchmarking methodologies for RPKI RP implementations in controlled laboratory environments using dedicated address space and constrained resources. No additional security considerations are identified within the scope of this document.

7. IANA Considerations

This document has no IANA requests.

Acknowledgements

The authors would like to thank Jorge Cano and the FORT team for their detailed reviews and constructive feedback, which helped clarify and improve the scope and methodology of this work. The authors also thank Mikhail Puzanov for his valuable feedback on the RP/SUT model and the externally observable validation output used in this methodology.

References

Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Informative References

[RFC6480]
Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, , <https://www.rfc-editor.org/info/rfc6480>.
[RFC9286]
Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, , <https://www.rfc-editor.org/info/rfc9286>.
[RFC6487]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, , <https://www.rfc-editor.org/info/rfc6487>.
[RFC6488]
Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, , <https://www.rfc-editor.org/info/rfc6488>.
[RFC8182]
Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, , <https://www.rfc-editor.org/info/rfc8182>.
[RFC8897]
Ma, D. and S. Kent, "Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties", RFC 8897, DOI 10.17487/RFC8897, , <https://www.rfc-editor.org/info/rfc8897>.
[RFC9582]
Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, , <https://www.rfc-editor.org/info/rfc9582>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.
[I-D.ietf-sidrops-rpki-erik-protocol]
Snijders, J., Bruijnzeels, T., Harrison, T., and W. Ohgai, "The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-erik-protocol-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-erik-protocol-04>.
[I-D.ietf-sidrops-rpki-ccr]
Snijders, J., Bakker, B., Bruijnzeels, T., and T. Buehler, "A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-ccr-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ccr-11>.
[RSYNC]
"The rsync web pages", n.d., <https://rsync.samba.org>.
[Barry]
"BaRRy", n.d., <https://github.com/lacnic/barry>.

Authors' Addresses

Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Yingying Su
Zhongguancun Laboratory
Beijing
China
Dan Li
Tsinghua University
Beijing
China