Re: [Sidrops] Reason for Outage report

[Martin Hoffmann <[e-mail]>]

Mikael Abrahamsson wrote:
> 
> At this point in time, everybody I am aware of who are implementing
> RPKI in the routing system are doing invalid=drop, and nothing else.
> 
> The overall goal right now is to make sure the ROA is correctly
> validated, all the way. If a ROA is gone, it doesn't cause an outage.
> It causes lack of protection. It's not a competition which validator
> can validate the most ROAs, the competition should be to get things
> *right*.
> 
> If something doesn't validate correctly, drop it. Drop all it depends
> on. If all ROAs from a RIR are gone for an hour or a day, it's not
> the end of the world. It's not an outage.
> 
> We need to make sure the entire ecosystem gets things right, correct,
> and have procedures in place to do things right, all the time. Other
> parts of the Internet ecosystem had teething problems in the
> beginning, but they worked it out. RPKI ecosystem needs to do the
> same.
> 
> The goal of the validator should be to validate. It should be picky.
> It should throw things away that doesn't look right. You're
> advocating for something else, and I don't understand why.

Two separate things.

First, you will notice that I talked about delaying modifications, not
refusing modifications. I strongly believe that a change in
invalidation strategy should be discussed in the community and the best
possible strategy found. We are talking about security here which is
never easy and the obvious answers are frequently wrong.

For instance: If a ROA is found to be invalid, should all the ROAs
published by the issuing CA and its child CAs be dropped or should not
in fact all statements made for resources owned by the CA be filtered
completely, even those made by unrelated CAs? Only the latter covers
for cases where a route might accidentally become invalid because its
prefix was authorized to two or more CAs.

Further, the current proposal suggests to reuse non-expired cached data
instead. Routinator, for example, does not in fact do that and needs
significant changes to its architecture to make that possible. Do I
want to make those changes before the community agrees that using old
objects is a good idea? Doing so may make it easier to block object
revocation. Do we prefer that over just not having certain objects at
all? I don’t think there is consensus yet.

Second and entirely independent of the first, the matter of the
validity of that ARIN manifest. Some of us have concluded that it
didn’t need rejecting because it was not in fact invalid. While it was
indeed encoded in a way that is not allowed by the respective specs for
encoders, the specs instruct decoders to be more forgiving. Such
forgiveness is a decision an implementer makes. The particular mistake
did not alter the meaning of these fields or endangered the
cryptographic integrity of the certificate as an RPKI resource
certificate, hence the decision to accept such certificates.

This assessment might be different were the certificate used in another
context and thus it may indeed need to be rejected by a general purpose
library, but a library that only and exclusively deals in RPKI resource
certificates does not.

Should it be picky nonetheless and drop anything that looks vaguely
suspicious? Would you be surprised to hear that if we indeed did that,
out of the currently 175,330 VRPs, a mere 3,571 would be left. Even if
we interpreted unclear RFCs in favour of implementers, we still would be
down to 54,258 or about a third.

Would dropping all these VRPs out of caution make the Internet more
secure? It is kind of hard to argue for that. I believe that whether a
security system in itself is more or less secure is an entirely
irrelevant question. It needs to be assessed in terms of whether
it makes the thing it serves more secure. And so need concrete
implementations and all the decisions made along the way.

Kind regards,
Martin