plea for comcast/sprint handoff debug help

Fri Oct 30 12:19:34 UTC 2020

Hi Job, all,

> On 30 Oct 2020, at 11:06, Job Snijders <job at ntt.net> wrote:
> 
> On Thu, Oct 29, 2020 at 09:14:16PM +0100, Alex Band wrote:
>> 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.
> 
> I don't see a compelling reason to not use rsync when RRDP is
> unavailable.
> 
> Quoting from the blog post:
> 
>    "While this isn’t threatening the integrity of the RPKI – all data
>    is cryptographically signed making it really difficult to forge data
>    – it is possible to withhold information or replay old data."
> 
> RRDP does not solve the issue of withholding data or replaying old data.
> The RRDP protocol /also/ is unauthenticated, just like rsync. The RRDP
> protocol basically is rsync wrapped in XML over HTTPS.
> 
> Withholding of information is detected through verification of RPKI
> manifests (something Routinator didn't verify up until last week!),
> and replaying of old data is addressed by checking validity dates and
> CRLs (something Routinator also didn't do until last week!).
> 
> Of course I see advantages to this industry mainly using RRDP, but those
> are not security advantages. The big migration towards RRDP can happen
> somewhere in the next few years.

Routinator does TLS verification when it encounters an RRDP repository. If the repository cannot be reached, or its HTTPS certificate is somehow invalid, it will use rsync instead. It's only after it found a *valid* HTTPS connection, that it refuses to fall back.

There is a security angle here.

Malicious-in-the-middle attacks can lead an RP to a bogus HTTPS server and force the software to downgrade to rsync, which has no channel security. The software can then be given old data (new ROAs can be withheld), or the attacker can simply withhold a single object. With the stricter publication point completeness validation introduced by RFC6486-bis this will lead to the rejecting of all ROAs published there.

The result is the exact same problem that Randy et al.'s research pointed at. If there is a covering less specific ROA issued by a parent, this will then result in RPKI invalid routes.

The fall-back may help in cases where there is an accidental outage of the RRDP server (for as long as the rsync servers can deal with the load), but it increases the attack surface for repositories that keep their RRDP server available.

Regards,
Tim

> 
> The arguments brought forward in the blog post don't make sense to me.
> The '150,000' number in the blog post seems a number pulled from thin
> air.
> 
> Regards,
> 
> Job