Alex: When I follow the RFC rabbit hole :
RFC6481 : A Profile for Resource Certificate Repository Structure The publication repository MUST be available using rsync > [RFC5781 <https://tools.ietf.org/html/rfc5781>] [RSYNC > <https://tools.ietf.org/html/rfc6481#ref-RSYNC>]. Support of additional > retrieval mechanisms > is the choice of the repository operator. The supported > retrieval mechanisms MUST be consistent with the accessMethod > element value(s) specified in the SIA of the associated CA or > EE certificate. > > Then : RFC8182 : The RPKI Repository Delta Protocol (RRDP) This document allows the use of RRDP as an additional repository > distribution mechanism for RPKI. In time, RRDP may replace rsync > [RSYNC <https://tools.ietf.org/html/rfc8182#ref-RSYNC>] as the only > mandatory-to-implement repository distribution > mechanism. However, this transition is outside of the scope of this > document. > > Is this not the case then that currently rsync is still mandatory, even if RRDP is in place? Or is there a more current RFC that has defined the transition that I did not locate? On Fri, Oct 30, 2020 at 7:49 AM Alex Band <[email protected]> wrote: > > > On 30 Oct 2020, at 01:10, Randy Bush <[email protected]> wrote: > > > > i'll see your blog post and raise you a peer reviewed academic paper and > > two rfcs :) > > For the readers wondering what is going on here: there is a reason there > is only a vague mention to two RFCs instead of the specific paragraph where > it says that Relying Party software must fall back to rsync immediately if > RRDP is temporarily unavailable. That is because this section doesn’t > exist. The point is that there is no bug and in fact, Routinator has a > carefully thought out strategy to deal with transient outages. Moreover, we > argue that our strategy is the better choice, both operationally and from a > security standpoint. > > The paper shows that Routinator is the most used RPKI relying party > software, and we know many of you here rely on it for route origin > validation in a production environment. We take this responsibility and > therefore this matter very seriously, and would not want you to think we > have been careless in our software design. Quite the opposite. > > We have made several attempts within the IETF to have a discussion on > technical merit, where aspects such as overwhelming an rsync server with > traffic, or using aggressive fallback to rsync as an entry point to a > downgrade attack have been brought forward. Our hope was that our arguments > would be considered on technical merit, but that did not happen yet. Be > that as it may, operators can rest assured that if consensus goes against > our logic, we will change our design. > > > perhaps go over to your unbound siblings and discuss this analog. > > The mention of Unbound DNS resolver in this context is interesting, > because we have in fact discussed our strategy with the developers on this > team as there is a lot to be learned from other standards and operational > experiences. > > We feel very strongly about this matter because the claim that using our > software negatively affects Internet routing robustness strikes at the core > of NLnet Labs’ existence: our reputation and our mission to work for the > good of the Internet. They are the core values that make it possible for a > not-for-profit foundation like ours to make free, liberally licensed open > source software. > > We’re proud of what we’ve been able to achieve and look forward to a > continued open discussion with the community. > > Respectfully, > > Alex >
