You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the following scenario things can go really wrong.
A RRDP repository publishes a ROA and a manifest that doesn't refer to the ROA.
After time defined by --cache-lifetime the ROA is GC-ed, because it was never touched by a top-down validation.
After that the repository publishes a new manifest that now refers to the ROA
Top-down validation considers the manifest and the CA invalid, since it has a dangling reference.
Earth collapses to a black hole.
While in practice this scenario doesn't make any sense, it is still technically valid behaviour of a RRDP repository and must be taken into consideration.
The text was updated successfully, but these errors were encountered:
Unsure if the validators should 'fix' this, validator's dont have infinite memory.
RRDP servers should be encouraged to publish RPKI objects as concise coherent bundles. If a signer updates the manifest but does not provide the ROA at the same time, the signer messed up and the validator should reject the manifest. Nor can the signer expect validators to indefinitely cache ROA objects which are not referenced from any valid manifest.
Similarly to how rsync server operators are expected to atomically and gracefully update the rsync server's module contents, I'd expect RRDP server operators to publish in an atomically coherent fashion.
I think GC-ing unused objects is correct behavior, after all, they are unused. :)
I am not planning to change the cache cleanup behaviour on some fundamental level, I wouldn't want RRDP replacements and withdraws to be the only thing controlling lifetime of objects in the local cache.
But some extra heuristics of a kind "if there was an referential integrity problem in the tree, next time download the snapshot instead of deltas" would probably make sense. Or at least a better error message would do.
In the following scenario things can go really wrong.
--cache-lifetime
the ROA is GC-ed, because it was never touched by a top-down validation.While in practice this scenario doesn't make any sense, it is still technically valid behaviour of a RRDP repository and must be taken into consideration.
The text was updated successfully, but these errors were encountered: