By Alfred Arouna, MANRS Fellow (2020 cohort)
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 AS number.
But if you are just getting started learning about RPKI or simply wish to read up on it, you will soon realize there is not one single authoritative Request for Comment (RFC) on the topic. In fact, there are more than 40 RFCs about RPKI found in different categories.
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 RFC6480 (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 (external page).
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 shows:
- Three categories of RFCs: PROPOSED STANDARD (STANDARD), BEST CURRENT PRACTICE (BCP) and INFORMATIONAL
- RPKI-related RFCs are in blue, RPKI-related RFCs with brief are in yellow, and other RFCs are in gray.
- 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
On Figure 2, we can also see that non-RPKI RFCs (RFC8654, RFC8212, RFC7705, RFC7607, RFC7606, RFC6793, RFC6608, RFC6286) updates RPKI RFC4271. This shows that reading RFC4271 will not be sufficient; updates are available on non-RPKI RFCs. From the same Figure, it is clear that reading RFC1771 is of little value, since it has been obsoleted by RFC4271.
The interactive graph allows filtering:
- 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 RFC6484 metadata with the “tooltip” filtering option activated:
The graph shows isolated RFCs (RFCs without relation to any other RFC). It is well understood that BCP and INFORMATIONAL are composed of 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 RFC6811 will show the brief as pictured below (Figure 4).
The brief is structured with following components:
- Title: RFC title
- Targets: can be relaying parties, vendor, RIR, etc.
- 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 (RIR), 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.
Editor’s note: This is a guest post by a MANRS fellow. Viewpoints expressed in this post are those of the author’s and may or may not reflect official positions.