Which RPKI-related RFCs should you read?

By on 15 Mar 2021

Category: Tech matters

Tags: , ,

Blog home

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 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.

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.

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:

  • 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.
  • 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).

Figure 4 — RFC 6811 brief.
Figure 4 — RFC 6811 brief.

The brief is structured with the following components:

  1. Title: RFC title.
  2. Targets: Can be relaying parties, vendor, RIR, and more.
  3. Terminology: New concepts and acronyms used in the RFC.
  4. 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.

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

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *