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

[Stephen Kent <[e-mail]>]

Job,
> On Wed, Feb 26, 2020 at 12:03:33PM -0500, Stephen Kent wrote:
>> As for the considerable leeway accorded to RPs in the Manifest document, I
>> concur that it allows inconsistent local behavior. If the WG can agree on
>> more proscriptive language, that would be good. When we wrote 6486 we were
>> unable to agree on such, as we tried to balance robustness vs. responses to
>> possible active attacks on repositories or communications between an RP and
>> a repository.
> Imagine a scenario where a money-in-the-middle (sic) strategically hides
> a select few ROAs, example:
>
> MITM shows rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r7TSyWn_GbYPjNWvt4r5ewSNAsk.roa
> (80.128.0.0/11 AS 0 - expires July 1st, 2021)
>
> but hides rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/LkKeUPYrfgzjsOIejLjsHGk44cU.roa
> (80.128.0.0/11 AS 3320 - expires July 1st, 2021)
I'm confused by your example. The discussion has been focused on CRL 
issues, not suppression of ROAs.
> If Origin Validating EBGP edge routers ends up honoring only a *subset*
> of VRPs, it may result in catastrophic hard-to-troubleshoot outages. In
> this example, the victim end up being unable to reach half of Germany.
>
> I think the entire repository should be considered invalid if a single
> file is missing but was referenced in the manifest. One can't produce
> rules based upon false or incomplete data, and one can't protect against
> hijacks using unsigned data.
Do you mean the pub point for the address space holder, vs. "the 
repository", which suggests a larger set of data, e.g., RIPE operates a 
repository that contains pub points for their members.
> expired CRL? repository invalid
> any file missing that was referenced in manifest? repository invalid
> the above also means, is the CRL missing? repository invalid
> in addition to any cert being expired? underlaying objects invalid
>
> Any other behaviour is a security problem, unsafe. Leeway does more
> damage than good.
I'm afraid I have to disagree with your conclusions., in  part because 
of confusing use of terminology.
> I believe the premise for Origin Validation to work on the Internet it
> is that in order to get it deployed, BGP has to 'fail open', but in the
> RPKI cache validation process one must 'fail close', which depends on
> all validators being 'strict'. If the RPKI component doesn't fail
> closed, it produces false filters, which goes against our desire for BGP
> to be able to 'fail open'.

A goal RPKI operation is to not make routing worse that it would be in  
the absence of the RPKI. Thus it seems appropriate to tolerate some 
types of operational errors, on a temporary basis, and try to follow up 
with CAs or pub point operators to resolve the errors. I acknowledge 
that different responses may be appropriate depending on  the nature of 
the error - a stales CRL is not the same as a bogus ROA.

Steve