Hi Randy, all, > On 31 Oct 2020, at 04:55, Randy Bush <ra...@psg.com> wrote: > >> If there is a covering less specific ROA issued by a parent, this will >> then result in RPKI invalid routes. > > i.e. the upstream kills the customer. not a wise business model.
I did not say it was. But this is the problematic case. For the vast majority of ROAs the sustained loss of the repository would lead to invalid ROA *objects*, which will not be used in Route Origin Validation anymore leading to the state 'Not Found' for the associated announcements. This is not the case if there are other ROAs for the same prefixes published by others (most likely the parent). Quick back of the envelope analysis: this affects about 0.05% of ROA prefixes. >> 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) > > folk try different software, try different configurations, realize that > having their CA gooey exposed because they wanted to serve rrdp and > block, ... We are talking here about the HTTPS server being unavailable, while rsync *is*. So this means, your HTTPS server is down, unreachable, or has an issue with its HTTPS certificate. Your repository could use a CDN if they don't want to do all this themselves. They could monitor, and fix things.. there is time. Thing is even if HTTPs becomes unavailable this still leaves hours (8 by default for the Krill CA, configurable) to fix things. Routinator (and the RIPE NCC Validator, and others) will use cached data if they cannot retrieve new data. It's only when manifests and CRLs start to expire that the objects would become invalid. So the fallback helps in case of incidents with HTTPS that were not fixed within 8 hours for 0.05% of prefixes. 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 tradeoff. I think that protecting against replay should be considered more important here, given the numbers and time to fix HTTPS issue. > randy, finding the fort rp to be pretty solid! Unrelated, but sure I like Fort too. Tim
