<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