Resource Public Key Infrastructure (RPKI) is the way to cryptographically sign records that associate a Border Gateway Protocol (BGP) route announcement with the correct originating Autonomous System Number (ASN).

But if you are just getting started learning about RPKI or simply wish to read up on it, you will soon realize there is no one single authoritative Request for Comment (RFC) on the topic. In fact, there are more than 40 RFCs about RPKI found in different categories.

Someone: Read the RFC
Me: Sure 🤷🏽‍♂️#RPKI pic.twitter.com/KoKjnAZKoY

— Aftab Siddiqui (@aftabsiddiqui) August 19, 2020

Figure 1 — There are more than 40 RFCs about RPKI.

The fact that it is not possible to find all the information about RPKI in one place makes it difficult to understand RPKI from scratch.

To give a bit more context, the Internet Engineering Task Force (IETF) is the premier Internet standards body, developing open standards through open processes. The IETF works on a broad range of networking technologies organized into IETF Areas. The IETF Security Area, with more than 20 active Working Groups, provides a focal point for security-related technical work.

RPKI is a framework that was first defined in RFC 6480 (An Infrastructure to Support Secure Internet Routing) in 2012. Different working groups under the IETF Security Area have contributed to the topic, and there are now more than 40 RPKI-related RFCs.

So, if you want to read about RPKI, the questions are many: where should you start? What RFC should you read first? What can you learn from the various RFCs? Should you read all of them?

To help you find useful information efficiently, we try to answer all these questions with a new tool: The RPKI RFCs Graph (source available in Github).

This graph shows the dynamics of all the RPKI-related RFCs and gives you a brief of each. The RFCs are represented in an interactive graph where you can see their relations to each other.

Figure 2 — The RPKI RFCs Graph

Figure 2 shows:

Three categories of RFCs: PROPOSED STANDARD (STANDARD), BEST CURRENT PRACTICE (BCP) and INFORMATIONAL.

RPKI-related RFCs are in blue, RPKI-related RFCs with briefs are in yellow, and other RFCs are in grey.

• Links follows UPDATE (green) or OBSOLETE (red) relationships between RFCs.
• 4 BCPs, 7 INFORMATIONAL, and 52 STANDARD.
• In addition to the list of RFCs in the screenshot above, we have added some RFCs following UPDATE or OBSOLETE relationships where available. For instance, RFC 8212 (not RPKI-related) updated RFC 4271. Reading RFC 4271 alone is a good start, but will only give partial information about BGP-4.
• Filtering options.

In Figure 2, we can also see that non-RPKI RFCs (RFC 8654, RFC 8212, RFC 7705, RFC 7607, RFC 7606, RFC 6793, RFC 6608, RFC 6286) updates RPKI RFC 4271. This shows that reading RFC 4271 will not be sufficient; updates are available on non-RPKI RFCs. From the same Figure, it is clear that reading RFC 1771 is of little value since it has been obsoleted by RFC 4271.

The interactive graph allows these filters:

• Tooltip: Enable/disable RFC metadata information.
• MUST read: According to our classification, there are six RPKI RFCs that MUST be read.
• SHOULD read: These RFCs are useful, but you can read them after reading those in the MUST group.
• MAY read: These are the less important ones.

Figure 3 shows RFC 6484 metadata with the ‘tooltip filtering option’ activated:

Figure 3 — RFCs Graph showing RFC 6484 metadata

The graph shows isolated RFCs (RFCs without relation to any other RFC). It is well understood that BCP and INFORMATIONAL comprise isolated RFCs. Only STANDARD RFCs presents relationships. On this version of the graph, RFCs with summaries are marked in yellow. For instance, a click on RFC 6811 will show the brief as pictured below (Figure 4).

The brief is structured with the following components:

• Title: RFC title.
• Targets: Can be relaying parties, vendor, RIR, and more.
• Terminology: New concepts and acronyms used in the RFC.
• Text of the brief.

An RFC targeting a vendor will be less important to a Regional Internet Registry, for instance. This work focuses on relaying parties, thus our classification was made from the point of view of a relaying party.

We hope you find this tool useful when navigating the many RPKI-related RFCs. If you have any comments or suggestions, please leave us a comment below.

This blog post has been republished from https://blog.apnic.net/2021/03/15/which-rpki-related-rfcs-should-you-read/ published on March 15, 2021. 

About the author

Alfred Arouna is a research engineer for Simula and MANRS’ 2020 Fellow.