Re: [Sidrops] 6486bis: referenced object validation

[Job Snijders <[e-mail]>]

On Fri, Dec 04, 2020 at 02:13:41PM +0100, Ties de Kock wrote:
> > You list two manifests, which means that software should:
> > 
> > round 1: process Manifest 1 containing AS0.roa + sub-CA.cer + crl
> >    check if as0.roa and sub-CA.cer + crl are present and if the hashes
> >    match
> > 
> > round 2: process Manifest 2 containing AS64496.roa + crl
> >    check if AS64496.roa + crl are present and if the hashes match
> > 
> > Now let's image sub-CA.cer is present and the hash match, but turns out
> > to be expired, it just invalidates sub-CA.cer and thus the software
> > would never even open manifest 2, because sub-CA.cer is expired.
> > 
> > If sub-CA.cer is expired the ROA for AS64496 indeed will 'disappear' (as
> > if never existed), leaving just the AS0 ROA. This is as the CA intended.
> 
> Compare that to:
> 
> Valid CA certificate with <AS64496, 192.0.2.0/24>
>  * Manifest, with valid EE certificate, containing
>    * valid CRL
>    * ROA: AS0, 192.0.2.0/24, EE cert with 2020-12-01 expiration
>    * ROA: AS64496, 192.0.2.0/25, EE cert with 2021-01-01 expiration
> 
> This results in a failed fetch when validated today.
>
> Under our interpretation of -00, this manifest would be rejected,
> since all objects on a manifest need to be valid (present, hash match,
> correct, non-expired) for a fetch to succeed.

The objects ON the manifest must be present and matching hashes, and the
manifest's EE certificate being correct, non-expired. I think this is
what is meant with the manifest must be 'valid', and 'current'

> I would argue that to be consistent, this should not result in failed
> fetch, the expired ROA should not apply, because this is what the CA
> intended.
> 
> What do you think the outcome should be?

Current versions of rpki-client and FORT consider the fetch successful,
but the 'AS0 ROA' in your example is expired, so that ROA will not be
emitted as VRP, as the ROA did not pass validation.

Imagine this scenario: I am an IP prefix broker, and I have a /16. For
this /16 I create a AS0 ROA because I don't want anyone to use the /16
unless I've given explicit permission through the creation of a ROA.
In december customer A leases a /24 for 3 months. In January customer B
leases a different /24 for 5 months, starting at February 2020.

Current time: 4 december 2020, 15:03 UTC
Valid CA <10.0.0.0/16>
  * Manifest, with valid EE certificate, containing
    * valid current CRL
    * ROA: AS0 10.0.0.0/16 (start date 1 july 2020, end date 1 july 2030)
    * ROA: AS1, 10.0.0.0/24 (start date 1 december 2020, end march 2021)
    * ROA: AS2, 10.0.1.0/24 (start date 1 february 2021, end juli 2021)

I believe the above to be real-world examples of how people perceive the
functionality of the RPKI, and this is confirmed by APNIC indicating
that the expiration dates on CA .cer files can match the expiration of
APNIC membership status. 

The beauty here is that a CA (an internet number resource holder) can
pre-provision the routing authorisations ahead of time. Each ROA on this
manifest represents a cryptographic 'product' (think something tangible
you can buy and hold), in this case authorizations to originate IP
space. The CA can also pre-provision the decommissioning of the product,
this is done by aligning the ROA expiration dates to the business
contract. This is an important cryptographic feature to be able to
pre-provision contract terminations.

Different expiration dates (and also start dates) for different objects
on the same manifest is an expected state of the RPKI. I believe the
CA's wishes are honored by checking that all files are present & hashes
matched, and that then in a second step each individual object is
validated (both signatures and validity time)

Kind regards,

Job