Benchmarking Methodology for RPKI Relying Party
draft-qin-bmwg-rpki-rp-bench-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Lancheng Qin , Yingying Su , Dan Li | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-qin-bmwg-rpki-rp-bench-01
BMWG L. Qin
Internet-Draft Y. Su
Intended status: Informational Zhongguancun Laboratory
Expires: 7 January 2027 D. Li
Tsinghua University
6 July 2026
Benchmarking Methodology for RPKI Relying Party
draft-qin-bmwg-rpki-rp-bench-01
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.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
Qin, et al. Expires 7 January 2027 [Page 1]
Internet-Draft BM for RPKI RP July 2026
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Relying Party Overview . . . . . . . . . . . . . . . . . . . 3
3. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Test Environment . . . . . . . . . . . . . . . . . . . . 4
3.2. System Under Test and Servers . . . . . . . . . . . . . . 5
3.3. Controller . . . . . . . . . . . . . . . . . . . . . . . 5
4. RPKI Relying Party Benchmarking Tests . . . . . . . . . . . . 5
4.1. Baseline Valid Repository Processing . . . . . . . . . . 6
4.2. Object Syntax Validation Correctness . . . . . . . . . . 6
4.2.1. DER Decoding . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Certificate Syntax Validation . . . . . . . . . . . . 8
4.2.3. CRL Syntax Validation . . . . . . . . . . . . . . . . 8
4.2.4. Manifest Syntax Validation . . . . . . . . . . . . . 9
4.2.5. ROA Syntax Validation . . . . . . . . . . . . . . . . 10
4.3. Certification Path Validation Correctness . . . . . . . . 10
4.4. Signed Object Signature Validation Correctness . . . . . 11
4.5. Manifest Processing Correctness . . . . . . . . . . . . . 12
4.5.1. Manifest Hash-Mismatch Check . . . . . . . . . . . . 12
4.5.2. Manifest Object-Mismatch Check . . . . . . . . . . . 13
4.6. Processing Time test . . . . . . . . . . . . . . . . . . 14
5. Report Format . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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.
Qin, et al. Expires 7 January 2027 [Page 2]
Internet-Draft BM for RPKI RP July 2026
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:
* Section 4 defines the functional correctness and performance
tests.
* Section 5 defines the format for reporting test results.
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:
* Object Retrieval: obtaining RPKI objects from Publication Points
(PPs) and keeping them up-to-date.
* Object Syntax Validation: checking DER encoding, syntax, and
structural correctness of RPKI objects, including certificates,
CRLs, ROAs, and manifests.
* Certification Path Validation: constructing and validating
certificate chains from the Trust Anchor to each leaf certificate.
Qin, et al. Expires 7 January 2027 [Page 3]
Internet-Draft BM for RPKI RP July 2026
* Signed Object Signature Validation: verifying digital signatures
of RPKI objects.
* Manifest Processing: ensuring completeness and integrity of
published objects.
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
Qin, et al. Expires 7 January 2027 [Page 4]
Internet-Draft BM for RPKI RP July 2026
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
Qin, et al. Expires 7 January 2027 [Page 5]
Internet-Draft BM for RPKI RP July 2026
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:
Qin, et al. Expires 7 January 2027 [Page 6]
Internet-Draft BM for RPKI RP July 2026
* Certificate and CRL: [RFC5280] and [RFC6487]
* Manifest: [RFC6488] and [RFC9286]
* ROA: [RFC6488] and [RFC9582]
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.
Qin, et al. Expires 7 January 2027 [Page 7]
Internet-Draft BM for RPKI RP July 2026
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.
Qin, et al. Expires 7 January 2027 [Page 8]
Internet-Draft BM for RPKI RP July 2026
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.
Qin, et al. Expires 7 January 2027 [Page 9]
Internet-Draft BM for RPKI RP July 2026
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.
Qin, et al. Expires 7 January 2027 [Page 10]
Internet-Draft BM for RPKI RP July 2026
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.
Qin, et al. Expires 7 January 2027 [Page 11]
Internet-Draft BM for RPKI RP July 2026
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.
Qin, et al. Expires 7 January 2027 [Page 12]
Internet-Draft BM for RPKI RP July 2026
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.
Qin, et al. Expires 7 January 2027 [Page 13]
Internet-Draft BM for RPKI RP July 2026
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.
Qin, et al. Expires 7 January 2027 [Page 14]
Internet-Draft BM for RPKI RP July 2026
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:
* RP implementation name and version
* Relevant SUT configuration used for the test
Test Repository Information:
* Number of objects and object types used in the baseline repository
* Number of expected VRPs in the baseline repository
* Test cases executed
* Test-specific repository modification, if any
Functional Correctness Test Results:
* Baseline Valid Repository Processing: pass/fail
* DER Decoding Correctness:
- Invalid DER Handling: pass/fail
* Object Syntax Validation Correctness:
- Certificate: pass/fail
- CRL: pass/fail
- Manifest: pass/fail
- ROA: pass/fail
Qin, et al. Expires 7 January 2027 [Page 15]
Internet-Draft BM for RPKI RP July 2026
* Certification Path Validation Correctness: pass/fail
* Signed Object Signature Validation Correctness:
- Invalid Signature Handling: pass/fail
* Manifest Processing Correctness:
- Hash-Mismatch Check: pass/fail
- Object-Mismatch Check:
o Missing Object: pass/fail
o Extra Object: pass/fail
Performance Test Results:
* Processing Time Performance Test:
- Number of CAs
- Number of ROAs
- Number of generated VRPs
- Total elapsed time from the start of the one-shot validation
run to the availability of the generated VRP set
Notes:
* Functional correctness tests report pass/fail based on whether the
SUT's output matches the expected output derived from the
controlled repository contents.
* Performance tests report total processing time together with the
test scale parameters defined above.
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.
Qin, et al. Expires 7 January 2027 [Page 16]
Internet-Draft BM for RPKI RP July 2026
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, March 1997,
<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,
May 2017, <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,
February 2012, <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, June 2022,
<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, February 2012,
<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, February 2012,
<https://www.rfc-editor.org/info/rfc6488>.
Qin, et al. Expires 7 January 2027 [Page 17]
Internet-Draft BM for RPKI RP July 2026
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<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, September 2020,
<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, May 2024,
<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, May 2008,
<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, 17 March 2026,
<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, 1 July
2026, <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
Qin, et al. Expires 7 January 2027 [Page 18]
Internet-Draft BM for RPKI RP July 2026
Email: qinlc@mail.zgclab.edu.cn
Yingying Su
Zhongguancun Laboratory
Beijing
China
Email: suyy@mail.zgclab.edu.cn
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Qin, et al. Expires 7 January 2027 [Page 19]