Re: [Sidrops] trying to limit RP processing variability

[Claudio Jeker <[e-mail]>]

On Wed, Apr 15, 2020 at 04:14:15PM +0200, Martin Hoffmann wrote:
> Job Snijders wrote:
> > On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote:
> > >
> > > > 1.Manifest present, valid, current  
> > > 
> > > If there is a present, valid, and current manifest, the CRL can
> > > safely be ignored for all objects.  
> > 
> > I'd like to ask you for some clarification, Stephen Kent listed 4
> > different cases, I parapharsed here:
> > 
> > 1.1. Manifest present, valid, current AND CRL present, valid, current
> > 1.2. Manifest present, valid, current AND CRL present, stale
> > 1.3. Manifest present, valid, current AND CRL present, invalid
> > 1.4. Manifest present, valid, current AND CRL missing
> > 
> > When you say "can safely be ignored", do you mean, MAY be ignored,
> > SHOULD be ignored? or MUST be ignored? In all four cases?
> 
> In all cases. Since it is ignored, it doesn’t really matter whether it
> is good or bad or ugly. 
> 
> I suppose I would go with "SHOULD be ignored" here.

Which CRL are we talking about? The ones listed in the manifest or the one
referenced by the manifest certificate?
I agree that the CRL for manifests is ignored mainly because of the chicken
and egg situation (the manifest holds the CRL fileAndHash which is uses by
the manifest itself).

For CRL listed in manifests I think the situation is different. If a CRL,
ROA or CERT in a manifest is missing then the manifest must be considered
invalid and everything under it ignored. This is so that missing ROA would
not suddenly result in RPKI invalid routes because only part of a set was
processed.
 
> > > In order to avoid using partial sets of information, the entire
> > > content of the PP is ignored if any object is missing, corrupted, or
> > > invalid.  
> > 
> > It appears we are inching towards consensus on avoiding to use partial
> > sets, I think that's good news.
> 
> Keep in mind that there is still a possibility that partial sets are
> created if a resource is delegated to two separate entities and one of
> them goes kaputt. I have no idea how likely that is in practice. This
> rule should, however, cover the rather more likely case of partial sets
> because of partial breakage of a single publication point.

-- 
:wq Claudio