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