Following a failed fetch, use a previously cached and valid Manifest

RPKI Manifests enable Relying Parties (RPs) to detect replay attacks,
unauthorized in-flight modification, or deletion of signed objects. RPs
can accomplish these security functions by comparing (what is expected
to be) a monotonically increasing counter (the 'manifestNumber') - to
determine what the latest Manifest is; a list of filenames - in order to
establish whether the complete set of files was fetched; and a list of
SHA256 message digests to ascertain whether the content's of said files
are exactly the same as the CA intended them to be.

Over time, two schools of thought arose. One philosophy is that the
highest numbered cryptographically valid Manifest represents the express
intent of the CA, so if manifest-listed files are missing, someone
upstream messed up and gets to enjoy the broken pieces. After all, RFC
9286 section 5.2 puts the onus firmly on the repository operator to
publish in a consistent manner. Here, "consistent" means that newly
issued manifests - in the same RRDP delta - are bundled together with
all new or changed ROAs, and that remote RSYNC repositories are
atomically updated (for example, using symlink pivots).

To overcome various types of inconsistent, transient, or intermediate
states of the remote publication point - previous versions of rpki-client
did construct the full CARepository state using a mix of objects from both
its local validated cache and the RRDP/RSYNC staging directories
(which contain purported new versions of the objects).

However, another take on RFC 9286 section 6.6's "use cached versions of
the objects" is that 'the objects' not only refers to the listed
subordinate products (such as ROAs/Certificates/ASPAs), but also to
Manifests themselves. The philosophy being that lower numbered
cryptographically valid Manifests with a complete & untampered set of
files are to be preferred over a higher numbered cryptographically valid
Manifests accompanied by incomplete sets of files. Consequently -
potentially - producing more stable VRP outputs, at the expense of being
magnanimous towards sloppy CAs and repository operators.

Going forward, rpki-client logs errors when inconsistent publications
are encountered, but also proceeds to use older cryptographically valid
Manifests (from previous successful fetches) in order to construct
the tree.

With and OK tb@, and also thanks to Ties de Kock from RIPE NCC.

0 files changed, 0 insertions, 0 deletions