<div dir="ltr">Alex:<div><br></div><div>When I follow the RFC rabbit hole : </div><div><br></div><div>RFC6481 : A Profile for Resource Certificate Repository Structure<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">The publication repository MUST be available using rsync
[<a href="https://tools.ietf.org/html/rfc5781" title=""The rsync URI Scheme"">RFC5781</a>] [<a href="https://tools.ietf.org/html/rfc6481#ref-RSYNC">RSYNC</a>]. 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.</pre></blockquote><div><br></div><div>Then :</div><div><br></div><div>RFC8182 : The RPKI Repository Delta Protocol (RRDP)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"> This document allows the use of RRDP as an additional repository
distribution mechanism for RPKI. In time, RRDP may replace rsync
[<a href="https://tools.ietf.org/html/rfc8182#ref-RSYNC" title=""rsync"">RSYNC</a>] as the only mandatory-to-implement repository distribution
mechanism. However, this transition is outside of the scope of this
document.</pre></blockquote><div><br></div><div>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? </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 30, 2020 at 7:49 AM Alex Band <<a href="mailto:alex@nlnetlabs.nl">alex@nlnetlabs.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On 30 Oct 2020, at 01:10, Randy Bush <<a href="mailto:randy@psg.com" target="_blank">randy@psg.com</a>> wrote:<br>
> <br>
> i'll see your blog post and raise you a peer reviewed academic paper and<br>
> two rfcs :)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
> perhaps go over to your unbound siblings and discuss this analog.<br>
<br>
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. <br>
<br>
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. <br>
<br>
We’re proud of what we’ve been able to achieve and look forward to a continued open discussion with the community.<br>
<br>
Respectfully,<br>
<br>
Alex<br>
</blockquote></div>