Re: [Sidrops] what to do when the CRL is hosed?

[Lukas Tribus <[e-mail]>]

Hello,


On Thu, 2 Apr 2020 at 22:48, Jay Borkenhagen <[e-mail]> wrote:
> No network operators want to specify any 'local policy' on their RP
> instances to control under which conditions an RPKI object would be
> accepted.  Some network operators in this WG have voiced strong
> opinions about how such acceptance should be decided, but that's not
> because they want the ability to exert local policy there.  Such
> opinions are all toward the goal we share of all implementations
> reliably creating a correct/consistent VRP set.
>
>
> I encourage feedback from other network operators on this one simple
> point.  Hopefully we all see this 'local policy' matter the same way,
> and the WG can turn its attention to consistent handling of the corner
> cases.

As a network operator, and without commenting on low-level aspects, I
expect (TL;DR: all the good and none of the bad stuff please):

- all RP's to produce the same VRP sets, given the same input
(otherwise we slow down detection of bugs, misconfigurations and
attacks), I suggest to NOT implement different code paths and local
policy exceptions.
- the end-result of rsync vs RRDP to be the same, in every case, under
every attack scenario
- no MITM attacks possible that lead to incomplete VRP sets (with the
supported retrieval methods, which still includes rsync)

I wanna be able to run different RP's in my network, without my
routers behaving differently based on whether they are currently
considering RP implementation A or RP implementation B.

I also expect some outages of RPKI infrastructure in the coming years,
just as we had outages in the past and just like other ecosystems have
(DNS, DNSSEC, TLS, etc). I consider that acceptable and realistic,
realizing that there are some scenarios where this will not only cause
NOTFOUNDs, but also false-positive INVALIDs. That's really bad, but it
also will be very rare (losing a subset of ROAs at IRR level). But I
would strongly encourage not to weaken or simplify the checks that are
in place, despite being aware that hosting the repository is hard
(atomic updates and all). Maybe we could come up with some best
practices documentation about setup, maintenance of a repository
(BCP?) for repository operators.

I would like for the ecosystem to stay extendable if someday we want
to add something other than ROA to it, and I would still like it to be
cryptographically reliable and consistent in that (and every other)
case.


I know it's not that black and white, I realize I am grossly
oversimplifying. But if I think about TLS or the WebPKI in general,
lax rules, simplifications and fallbacks always turned out to be a bad
idea in the end.



lukas