Re: plea for comcast/sprint handoff debug help

[Randy Bush <randy () psg com>]

> > > 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