Re: plea for comcast/sprint handoff debug help

[Tony Tauber <ttauber () 1-4-5 net>]

As I've pointed out to Randy and others and I'll share here.
We planned, but hadn't yet upgraded our Routinator RP (Relying Party)
software to the latest v0.8 which I knew had some improvements.
I assumed the problems we were seeing would be fixed by the upgrade.
Indeed, when I pulled down the new SW to a test machine, loaded and ran it,
I could get both Randy's ROAs.
I figured I was good to go.
Then we upgraded the prod machine to the new version and the problem
persisted.
An hour or two of analysis made me realize that the "stickiness" of a
particular PP (Publication Point) is encoded in the cache filesystem.
Routinator seems to build entries in its cache directory under either
rsync, rrdp, or http and the rg.net PPs weren’t showing under rsync but
moving the cache directory aside and forcing it to rebuild fixed the issue.

A couple of points seem to follow:

   - Randy says: "finding the fort rp to be pretty solid!"  I'll say that
   if you loaded a fresh Fort and fresh Routinator install, they would both
   have your ROAs.
   - The sense of "stickiness" is local only; hence to my mind the
   protection against "downgrade" attack is somewhat illusory. A fresh install
   knows nothing of history.

Tony

On Fri, Oct 30, 2020 at 11:57 PM Randy Bush <randy () psg com> wrote:

> > If there is a covering less specific ROA issued by a parent, this will
> > then result in RPKI invalid routes.
>
> i.e. the upstream kills the customer.  not a wise business model.
>
> > The fall-back may help in cases where there is an accidental outage of
> > the RRDP server (for as long as the rsync servers can deal with the
> > load)
>
> folk try different software, try different configurations, realize that
> having their CA gooey exposed because they wanted to serve rrdp and
> block, ...
>
> randy, finding the fort rp to be pretty solid!