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

[Job Snijders <[e-mail]>]

Dear Oleg,

On Tue, Mar 24, 2020, at 16:36, Oleg Muravskiy wrote:
> Your examples so far have showed that continuing with incomplete set of 
> ROAs after a withhold/manipulation on ROA objects might create 
> dangerous situation.
> 
> Are there scenarios where withholding / making invalid a certificate, 
> for example, leads to a similar danger?
> 
> I wonder if this is specific to ROA objects only, and whether we should 
> treat them differently. If it is, then we could “ignore” all published 
> ROAs at the specific publication point, but continue validation to 
> child certificates and their sub-trees.

Good question. My intuition is that it is not entirely relevant what the file type is. My examples are indeed all ROA and CRL specific as the consequences are easier to demonstrate using the real Internet BGP tables in examples.

Treating ROAs differently than other types of files referenced in manifests may lead to pain somewhere down the road when it is discovered that these problems in fact didn't just apply to only ROAs or CRLs. If there happens to be a file type (now or in the future) where proceeding to extract data from subtrees is a safe choice to make, I think /that/ should be be the exception after it has proven to be a safe choice to do so.

The RPKI data does not lend itself for some kind of Solomon-Reed error correction. Manifests allow us to discover that /something/ is missing, but we have no idea /what/ is missing. If we don't know /what/ is missing, all bets are off. It is hard for me to imagine a scenario where the publication point's own ROAs are hosed but it'll still be safe to continue attempting to extract data from non-ROA objects from child certs / sub trees.

Should at some point there be 'business rule' interdependencies between various object types that may exist in the RPKI, and exceptions were made for ROAs but not for other file types - I suspect the complexity of the decision tree will become insurmountable.

Kind regards,

Job