Resource Public Key Infrastructure (RPKI) Repository Requirements
NLnet Labs
tim@nlnetlabs.nl
https://www.nlnetlabs.nl/
Internet Initiative Japan & Arrcus, Inc.
randy@psg.com
APNIC
ggm@apnic.net
http://www.apnic.net
Internet
This document formulates a plan of a phased transition to a state where
RPKI repositories and Relying Party software performing RPKI Validation
will use the RPKI Repository Delta Protocol (RRDP) as the
preferred access protocol, and require rsync as a fallback option only.
In phase 0, today's deployment, RRDP is supported by most, but not all
Repositories, and most but not all RP software.
In the proposed phase 1 RRDP will become mandatory to implement for
Repositories, in addition to rsync. This phase can start as soon as
this document is published.
Phase 2 will start once the proposed updates are implemented by all
compliant Repositories. In this phase RRDP will become mandatory to
implement for all compliant RP software, and rsync will be required
as a fallback option only.
It should be noted that although this document currently includes
descriptions and updates to RFCs for each of these phases, we may find
that it will be beneficial to have one or more separate documents for
these phases, so that it might be more clear to all when the updates
to RFCs take effect.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.
The Resource Public Key Infrastructure (RPKI) as originally defined
uses rsync as its distribution protocol, as outlined in . Later, the
RPKI Repository Delta Protocol (RRDP) was designed to provide an
alternative. In order to facilitate incremental deployment RRDP has been
deployed as an additional optional protocol, while rsync was still mandatory to
implement.
While rsync has been very useful in the initial deployment of RPKI, a number of
issues observed with it motivated the design of RRDP, e.g.:
rsync is CPU and memory heavy on the server side, and easy to DoS
rsync library support is lacking, complicating RP efficiency and error logging
RRDP was designed to leverage HTTPS CDN infrastructure to provide RPKI Repository
content in a resilient way, while reducing the load on the Repository server. It
supports updates being published as atomic deltas, which can help prevent most
of the issues described in section 6 of .
For a longer discussion please see section 1 of .
In conclusion: we believe that while RRDP is not perfect, and we may indeed
need future work to improve it, it is an improvement over using rsync in the
context of RPKI. Therefore, this document outlines a transition plan where RRDP
becomes mandatory to implement, and the operational dependency on rsync is
reduced to that of a fallback option.
Changing the RPKI infrastructure to rely on RRDP instead of rsync is a delicate
operation. There is current deployment of Certification Authorities, Repository
Servers and Relying Party software which relies on rsync, and which may not yet
support RRDP.
Therefore we need to have a plan that ultimately updates the relevant RFCs, but
which uses a phased approach combined with measurements to limit the operational
impact of doing this to (almost) zero.
The general outline of the plan is as follows. We will describe each step in
more detail below.
Phase
Description
0RPKI repositories support rsync, and optionally RRDP
1RPKI repositories support both rsync and RRDP
2All RP software prefers RRDP
This is the situation at the time of writing this document. Relying Parties can
prefer RRDP over rsync today. Therefore all repositories should support RRDP at
their earliest convenience.
Section 3.4.5 of has the following on "Considerations Regarding
Operational Failures in RRDP":
Relying Parties could attempt to use alternative repository access
mechanisms, if they are available, according to the accessMethod
element value(s) specified in the SIA of the associated certificate
(see Section 4.8.8 of [RFC6487]).
The use of the lower case 'could' in this sentence has led some older
versions of RP implementations to conclude that any fallback from RRDP
to rsync as an alternative access mechanism is a local choice. However,
following discussions on this subject it has become clear that there is
a preference to instruct RP software to make use of all possible data
sources. The main motivation being that because of RPKI object security
using a secondary source of data can never lead to a worse outcome in
terms of validation.
Per this document text mentioned above is replaced by the following:
Relying Parties MUST attempt to use alternative repository access
mechanisms, if they are available, according to the accessMethod
element value(s) specified in the SIA of the associated certificate
(see Section 4.8.8 of [RFC6487]).
Note that there is a risk that the rsync repository, as the
alternative access mechanism, becomes overloaded in case all
Relying Parties fall back to it at roughly the same time due
to an issue with RRDP. Therefore it is RECOMMENDED that Relying
Parties use a retry strategy and/or random jitter time before
falling back to rsync. But, the fallback to rsync MUST NOT
be postponed for more than 1 hour.
Section 3.3 of stipulates that RRDP files MUST be made
available by repositories which support RRDP. In other words
expects that RRDP repository availability is treated as a critical
service wherever it is supported.
Per this document the following bullet point is added to the
considerations listed in in section 3 of :
The publication repository MAY be available using the RPKI
Repository Delta Protocol . If RPDP is provided,
it SHOULD be hosted on a highly available platform.
During this phase we will make RRDP mandatory to support for Repository Servers,
and measure whether the deployed Repository Servers have been upgraded to do so,
in as far as they don't support RRDP already.
In this phase the bullet point update to section 3 of
mentioned above, where it was said the publication repository MAY
be available using the RPKI Repository Delta Protocol is replaced by:
The publication repository MUST be available using the RPKI
Repository Delta Protocol . The RRDP server SHOULD
be hosted on a highly available platform.
We can find out whether all RPKI repositories support RRDP by running (possibly)
modified Relying Party software that keeps track of this.
When it is found that Repositories do not yet support RRDP, outreach should be
done to them individually. Since the number of Repositories is fairly low, and
it is in their interest to run RRDP because it addresses availability concerns,
we have confidence that we will find these Repositories willing to make changes.
Once all Repositories support RRDP we can proceed to make RRDP mandatory to
implement for Relying Party software. But note that RP software is not prohibited
from implementing this support sooner. At the time of this writing all known
RP software supports RRDP, although it is not known to the authors whether all
of them have RRDP enabled and use it as the preferred protocol.
From this phase onwards the first paragraph of section 3.4.1 of
is replaced by the following:
When a Relying Party performs RPKI validation and learns about a
valid certificate with an SIA entry for the RRDP protocol, it MUST
use this protocol with preference.
Relying Parties MUST NOT attempt to fetch objects using alternate access
mechanisms, if object retrieval through this protocol is successful.
However, as stipulated in section 3.4.5, Relying Parties MUST attempt to
use alternative repository access mechanisms, if object retrieval through
RRDP is unsuccessful.
Although the tools may support RRDP, users will still need to install updated
versions of these tools in their infrastructure. Any Repository operator can
measure this transition by observing access to their RRDP and rsync repositories
respectively.
But even after new versions have been available, it is expected that there will
be a long, low volume, tail of users who did not upgrade and still depend on rsync.
Note that this section is included for tracking purposes during the discussion
phase of this document and is not intended to be included in an RFC.
The currently known support for RRDP for repositories is as follows:
Repository Implementation
Support for RRDP
afrinicyes
apnicyes
arinyes
lacnicongoing
ripe nccyes
Dragon Research Labsyes(1,2)
krillyes(1)
(1) in use at various National Internet Registries, as well as other resource
holders under RIRs.
(2) not all organizations using this software have upgraded to using RRDP.
All current versions of known Relying Party software support RRDP:
Relying Party Implementation
support
version
since
DRLyes??
FORTyes1.2.002/2021
OctoRPKIyes1.0.002/2019
Routinatoryes0.6.009/2019
rpki-clientyes0.7.004/2021
RPSTIR2yes2.004/2020
But, support for RRDP does not necessarily mean that it is also
enabled and preferred over rsync by default. The authors kindly
request that RP implementors provide the following information:
Relying Party Implementation
prefer
version
since
DRL???
FORTyes??
OctoRPKI???
Routinatoryes0.6.009/2019
rpki-client???
RPSTIR2???
This document has no IANA actions.