Re: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-6486bis-09: (with DISCUSS and COMMENT)

[Job Snijders <[e-mail]>]

On Tue, Mar 22, 2022 at 04:19:53AM -0700, Benjamin Kaduk wrote:
> On Tue, Mar 22, 2022 at 12:06:02PM +0100, Job Snijders wrote:
> > On Mon, Mar 21, 2022 at 01:56:26PM -0700, Benjamin Kaduk wrote:
> > > On Sun, Mar 20, 2022 at 02:44:02PM +0100, Job Snijders wrote:
> > > Thanks for the updates and explanation of the context.
> > > 
> > > I just wanted to check: the -10 still contains in §4.4 this text:
> > > 
> > >    Note: Although it is RECOMMENDED that the thisUpdate and nextUpdate
> > >    fields in the manifest match the corresponding fields in the CRL
> > >    associated with the manifest, RPs SHOULD NOT reject a manifest if
> > >    these fields do not match.
> > > 
> > > Does that pose a potential for interop failure that we should be concerned
> > > about?
> > 
> > I think you are correct observing this discrepancy. The following is
> > perhaps better:
> > 
> > NEW:
> >     """
> >     Note: Although the thisUpdate and nextUpdate fields in the Manifest
> >     eContent MUST match the corresponding fields in the CRL associated
> >     with the Manifest, RPs MUST NOT reject a manifest solely because
> >     these fields are not identical.
> >     """
> > 
> > The above description should provide clear guidance to both CAs and RPs
> > on where we are / we're heading, without needlessly cutting off some
> > existing deployments [1]. 
> > 
> > Thanks for catching this, if this aligns with your understanding -11 can
> > be uploaded.
> 
> This would certainly resolve my concern, yes.  I am not really in a
> position to speak to whether it reflects current reality, though :)

As there are two sides of the coin:

On the CA ('sending') side there are indeed numerous CAs which produce a
"mis-aligned" timestamp values, I anticipate that over time this number
will reduce.

As for the RP ('receiving') side, it is my understanding that the
world's most widely used [1] RP implementations nowadays all consider a
Manifest nextUpdate which is in the past (aka 'stale') to be a hard
error (in the default configuration).

FORT: https://github.com/NICMx/FORT-validator/blob/ce8ed0b9b112d7eebd0330745fb8aac7e73f1e5f/src/object/manifest.c#L73-L77
OctoRPKI: https://github.com/cloudflare/cfrpki/commit/8721e758ee24fb37ee2df81d482d9a453ed52ae3
OpenBSD: https://github.com/openbsd/src/blob/7f8722a4d0c042401934f19a69408a62d0f71ebd/usr.sbin/rpki-client/parser.c#L400-L411
Routinator: https://routinator.docs.nlnetlabs.nl/en/stable/data-processing.html?highlight=stale#stale-objects

Kind regards,

Job

[1] Routinator, OpenBSD rpki-client, FORT, OctoRPKI, popularity gauged
from operating a RPKI Repository as part of the global RPKI, and looking
at strings in the HTTP User-Agent to identify the RP implementation
https://dataplane.org/statistics/rpki.html for a view specific to the
ARIN Trust Anchor (keeping in mind that other Trust Anchors might see
other stats!). Aside from the ones I mentioned on this shortlist, some
other RP implementations can be observed in the wild, some of which
aren't actively maintained (such as the RIPE validator).