Tool Helps you Focus on key RFCs

Resource Public Key Infrastructure (RPKI) continues to be a subject of active discussion within the Internet Engineering Task Force (IETF). Several proposed drafts are currently under discussion, and some have successfully transitioned into Request for Comments (RFCs), highlighting the growing importance of RPKI in bolstering the Internet’s security infrastructure over the past few years. 

Reading all RFCs related to a particular standard can provide a thorough understanding, but it is sometimes not feasible to read them all. Instead of reading all the RFCs, you can adopt a more targeted approach by focusing on: 

• Key RFCs, such as Best Current Practice (BCP) RFCs, define the standard and provide valuable guidance and recommendations or those that provide essential information for its implementation. 
• The most recent RFCs that reflect current updates or revisions. 

To help in this task, we’ve listed below the abstracts of key RPKI-related RFCs. We also encourage you to check out our RFC RPKI Graph tool (Figure 1), developed with the help of MANRS 2020 Fellow, Alfred Arouna, which lists all RPKI-related RFCs published since February 2021 and how they are connected to each other.

Let us know what you think. We’re happy to help clarify any questions you might have about RPKI RFCs and work with you on developing/updating new RFCs. 

Key RFC Abstracts 

RFC 8893 Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export. R. Bush, R. Volk, J. Heitz. September 2020. (Updates RFC6811) (Status: PROPOSED STANDARD)

A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the ‘effective origin AS’ of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS. 

RFC 8897 Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties. D. Ma, S. Kent. September 2020. (Status: INFORMATIONAL) 

This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein. 

RFC 9255 The ‘I’ in RPKI Does Not Stand for Identity. R. Bush, R. Housley. June 2022. (Status: PROPOSED STANDARD) 

There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the ‘holder’ of an INR. This document specifies that RPKI does not associate to the INR holder. 

RFC 9286 Manifests for the Resource Public Key Infrastructure (RPKI). R. Austein, G. Huston, S. Kent, M. Lepinski. June 2022. (Obsoletes RFC6486) (Status: PROPOSED STANDARD)

This document defines a “manifest” for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a Relying Party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest’s contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. 

RFC 9319 The Use of maxLength in the Resource Public Key Infrastructure (RPKI). Y. Gilad, S. Goldberg, K. Sriram, J. Snijders, B. Maddison. October 2022. (Status: BEST CURRENT PRACTICE)

This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as “Remotely Triggered Black Hole”) filtering are also highlighted. 

RFC 9323 A Profile for RPKI Signed Checklists (RSCs). J. Snijders, T. Harrison, B. Maddison. November 2022. (Status: PROPOSED STANDARD)

This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of checksums (a ‘checklist’). The objective is to allow for the creation of an attestation, termed an “RPKI Signed Checklist (RSC)”, which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC. 

RFC 9324 Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh. R. Bush, K. Patel, P. Smith, M. Tinka. December 2022. (Updates RFC8481) (Status: PROPOSED STANDARD)

A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or saving paths dropped due to ROV (Route Origin Validation) so they may be re-evaluated with respect to new RPKI data.