RSYNC

RSYNC has been the de-facto protocol for the distribution of RPKI objects since the beginning. It allows Relying Party software to connect to RPKI repositories to synchronize a local copy by downloading the certificates, RPKI-signed objects (ROAs), manifest and CRLs files. While RSYNC has served its initial purpose of providing synchronization in the early stages of RPKI deployment, it has proved to be operationally unfit for a number of reasons (as per RFC 8182):

• RSYNC is designed to limit the amount of data that needs to be transferred between client and server. However, the server needs to spend significant resources in terms of CPU and memory for every connection. This is a problem in an envisioned RPKI deployment where thousands of Relying Parties query a small number of central repositories, and it makes these repositories weak to denial-of-service attacks.
• A secondary concern is the lack of supported rsync server and client libraries. In practice, all implementations have to make system calls to an rsync binary. This is inefficient; it introduces fragility with regards to updates of this binary, makes it difficult to catch and report problems to operators, and complicates software development and testing.

To this end, the IETF SIDROPS community proposed an alternative repository access protocol called RRDP (RPKI Delta Protocol - RFC 8182), based on Update Notification, Snapshot and a set of Delta files that Relying Parties can retrieve using the HTTPS protocol.

How does it work?

RPKI Certificate Authorities use a Repository server to publish their RPKI products, such as certificates, manifest and crl files and RPKI-signed objects. They need to indicate the location of this repository through the SIA (Subject Information Access) found in each certificate published. For example, the SIA for the AFRINIC RPKI Trust anchor is rsync://rpki.afrinic.net/repository/04E8B0D80F4D11E0B657D8931367AE7D/

With RRDP, we will have an additional SIA entry that points to an Update Notification file. The notification file contains a unique session_id and a serial number that is used by the Relying Party to maintain synchronization between its local copy and the repository. The notification file includes a link to the latest snapshot of the most recent copy of the repository alongside links to delta files. When a Relying Party learns about the notification file, it first downloads the latest snapshots to create a local copy, then it polls the server every minute to check for latest changes through the delta files. Should the serial number gets incremented on the server, the Relying Party would do a full re-synchronization. The validation process then follows. Below is how the SIA entry looks like in the APNIC Trust Anchor.

How does it affect the AFRINIC RPKI repository?

All certificates issued by AFRINIC, including the self-signed Trust Anchor (http://rpki.afrinic.net/repository/AfriNIC.cer), must contain the URI to the Update Notification file in the SIA section. This means that all certificates issued by AFRINIC will be refreshed. The refresh will not have any operational impact on RPKI validation and AFRINIC members’ objects will continue to be fetched by Relying Parties through either RSYNC or RRDP. While RRDP has been designed to eventually replace RSYNC, it will, for the time being, co-exist with the latter until there is a full-phase out.

RRDP support

AFRINIC plans to support RRDP by latest end of Q1 in 2020. Development and testing will be carried out in Q4 2019 and Q1 2020. Once the new SIA entry will appear in the certificate, members will be notified and they will be able to test validation using RRDP-enabled validation software such as the RIPE Validator, Routinator or OctoRPKI, amongst others.

UPDATE

01.04.2020: AFRINIC now publishes it's RPKI repository through the RRDP protocol.

Most information can be found here: The RPKI Repository Delta Protocol (RRDP) - https://tools.ietf.org/html/rfc8182