plea for comcast/sprint handoff debug help

Fri Oct 30 15:21:12 UTC 2020

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 <alex at nlnetlabs.nl> wrote:

>
> > On 30 Oct 2020, at 01:10, Randy Bush <randy at psg.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201030/285ba594/attachment.html>