> On 28 Oct 2020, at 16:58, Randy Bush <ra...@psg.com> wrote: > >> tl;dr: >> >> comcast: does your 50.242.151.5 westin router receive the announcement >> of 147.28.0.0/20 from sprint's westin router 144.232.9.61? > > tl;dr: diagnosed by comcast. see our short paper to be presented at imc > tomorrow https://archive.psg.com/200927.imc-rp.pdf > > lesson: route origin relying party software may cause as much damage as > it ameliorates > > randy
To clarify this for the readers here: there is an ongoing research experiment where connectivity to the RRDP and rsync endpoints of several RPKI publication servers is being purposely enabled and disabled for prolonged periods of time. This is perfectly fine of course. While the resulting paper presented at IMC is certainly interesting, having relying party software fall back to rsync when RRDP is unavailable is not a requirement specified in any RFC, as the paper seems to suggest. In fact, we argue that it's actually a bad idea to do so: https://blog.nlnetlabs.nl/why-routinator-doesnt-fall-back-to-rsync/ We're interested to hear views on this from both an operational and security perspective. -Alex
