On Mon, Nov 02, 2020 at 09:13:16AM +0100, Tim Bruijnzeels wrote:
On the other hand, the fallback exposes a Malicious-in-the-Middle replay attack surface for 100% of the prefixes published using RRDP, 100% of the time. This allows attackers to prevent changes in ROAs to be seen.
This is a mischaracterization of what is going on. The implication of what you say here is that RPKI cannot work reliably over RSYNC, which is factually incorrect and an injustice to all existing RSYNC based deployment. Your view on the security model seems to ignore the existence of RPKI manifests and the use of CRLs, which exist exactly to mitigate replays. Up until 2 weeks ago Routintar indeed was not correctly validating RPKI data, fortunately this has now been fixed: https://mailman.nanog.org/pipermail/nanog/2020-October/210318.html Also via the RRDP protocol old data be replayed, because because just like RSYNC, the RRDP protocol does not have authentication. When RPKI data is transported from Publication Point (RP) to Relying Party, the RP cannot assume there was an unbroken 'chain of custody' and therefor has to validate all the RPKI signatures. For example, if a CDN is used to distribute RRDP data, the CDN is the MITM (that is literally what CDNs are: reverse proxies, in the middle). The CDN could accidentally serve up old (cached) content or misserve current content (swap 2 filenames with each other).
This is a tradeoff. I think that protecting against replay should be considered more important here, given the numbers and time to fix HTTPS issue.
The 'replay' issue you perceive is also present in RRDP. The RPKI is a *deployed* system on the Internet and it is important for Routinator to remain interopable with other non-nlnetlabs implementations. Routinator not falling back to rsync does *not* offer a security advantage, but does negatively impact our industry's ability to migrate to RRDP. We are in 'phase 0' as described in Section 3 of https://tools.ietf.org/html/draft-sidrops-bruijnzeels-deprecate-rsync Regards, Job