Re: [Sidrops] trying to limit RP processing variability

[Job Snijders <[e-mail]>]

Hi,

On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote:
> *Terminology*
> 
> Valid: a signed object (other than a certificate or CRL) is deemed
> *valid* if it is encoded in a fashion consistent with the relevant
> RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s
> signature can be verified consistent with RFC 6488.
> 
> Current: A CRL or Manifest is *current* if the current date & time is
> before the Next Update date and the CRLNumber (or ManifestNumber) is
> greater than any prior, valid CRLs or Manifests processed by the RP.
> 
> Stale: A CRL or Manifest is stale if the current date & time is later
> than the Next Update date. A stale CRL or Manifest is not “expired”
> it’s just not as current as it is supposed to be. The case analysis
> below examines what to do when a Manifest, or CRL, or both are stale.
> 
> Missing: an object named in a Manifest, but not available for download
> from a PP, is termed *missing*. An RP has no obvious way to acquire
> missing objects, but operators SHOULD be warned about which objects
> are missing.
> 
> Corrupted: if an object named in a Manifest, is available for download
> from a PP, but it’s hash does not match the corresponding value in the
> Manifest, the object is termed *corrupted* and the object SHOULD be
> ignored.
> 
> *Case analysis*
> 
> If we can agree to ignore any objects at a PP that do not appear on
> the current manifest, the case analysis is easier. (The discussion of
> corrupted objects above addresses the case where an object is named on
> the Manifest, but the hash does not match.)
> 
> Below is a proposed outline for the cases. The group needs to decide
> what action is to be taken in each case.
> 
> 
> 1.Manifest present, valid, current
> 1.1.CRL present, valid, current

pass. all lights are green.

> [ snip lots of variants ]

All cases we can come up with (except the 'all green') probably require
some mailinglist back and forth as to why it is that we can safely
ignore one or another validation check. If nobody steps up to advocate a
particular case, perhaps we don't need it.

My suggestion to the group is that we go through Kent's list and start
with a justification for the simplest of cases (as described above), and
then construct justifications for any other variants, if they exist.

I imagine some of the cases have already been discussed in years prior,
but RPKI OV deployment on the Internet at scale is still fairly new,
taking a fresh look at things is exciting :)

Kind regards,

Job