please remove me from list
-------- Original Message --------
Subject: [SPAM] Re: plea for comcast/sprint handoff debug help
From: Alex Band <alex@nlnetlabs.nl>
Date: Thu, October 29, 2020 2:14 pm
To: Randy Bush <randy@psg.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
> On 28 Oct 2020, at 16:58, Randy Bush <randy@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"]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"]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