nanog mailing list archives
Re: plea for comcast/sprint handoff debug help
From: Tony Tauber <ttauber () 1-4-5 net>
Date: Sat, 31 Oct 2020 02:17:41 -0400
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!
Current thread:
- Re: plea for comcast/sprint handoff debug help, (continued)
- Re: plea for comcast/sprint handoff debug help Lukas Tribus (Oct 28)
- Re: plea for comcast/sprint handoff debug help Alex Band (Oct 29)
- Re: plea for comcast/sprint handoff debug help Randy Bush (Oct 29)
- Re: plea for comcast/sprint handoff debug help Randy Bush (Oct 29)
- Re: plea for comcast/sprint handoff debug help Alex Band (Oct 30)
- Re: plea for comcast/sprint handoff debug help Tom Beecher (Oct 30)
- RPKI over RSYNC vs RRDP (Was: plea for comcast/sprint handoff debug help) Job Snijders (Oct 30)
- Re: plea for comcast/sprint handoff debug help Job Snijders (Oct 30)
- Re: plea for comcast/sprint handoff debug help Tim Bruijnzeels (Oct 30)
- Re: plea for comcast/sprint handoff debug help Randy Bush (Oct 30)
- Re: plea for comcast/sprint handoff debug help Tony Tauber (Oct 30)
- Re: plea for comcast/sprint handoff debug help Randy Bush (Oct 31)
- Re: plea for comcast/sprint handoff debug help Randy Bush (Oct 31)
- Re: plea for comcast/sprint handoff debug help Alex Band (Oct 31)
- Re: plea for comcast/sprint handoff debug help Randy Bush (Oct 31)