On Fri, Nov 6, 2020 at 1:28 AM Christopher Morrow <morrowc.li...@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 >