On Fri, Nov 6, 2020 at 1:28 AM Christopher Morrow <morrowc.lists@gmail.com> wrote: <snip>
I think a way forward here is to offer a suggestion for the software folk to cogitate on and improve? "What if (for either rrdp or rsync) there is no successful update[0] in X of Y attempts, attempt the other protocol to sync down to bring the remote PP back to life in your local view."
100% Please do this. I also agree with Job's pleas to consider this work as part of the plath outlined in the RSYNC->RRDP transition draft mentioned below. Tony
This both allows the RP software to pick their primary path (and stick to that path as long as things work) AND helps the PP folk recover a bit quicker if their deployment runs into troubles.
<more snip>
This is a tradeoff. I think that protecting against replay should be considered more important here, given the numbers and time to fix HTTPS issue.
The 'replay' issue you perceive is also present in RRDP. The RPKI is a *deployed* system on the Internet and it is important for Routinator to remain interopable with other non-nlnetlabs implementations.
Routinator not falling back to rsync does *not* offer a security advantage, but does negatively impact our industry's ability to migrate to RRDP. We are in 'phase 0' as described in Section 3 of https://tools.ietf.org/html/draft-sidrops-bruijnzeels-deprecate-rsync
Regards,
Job