>>> 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.
in fact, <senior op at an isp> has found your bug. if you find an http server, but it is not serving the new and not-required rrdp protocol, it does not then use the mandatory to implement rsync. randy
