Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

[Di Ma <[e-mail]>]

Steve,

Thanks for your efforts for writing MFT update and reflecting the feedback from the mailing list.

I am fine with it except the re-use of previous local cache.

I find it is hard to implement the logic about retrieving objects from local cache with RPSTIR2. 

As I replied to Robert in your discussion with him, in terms of synchronization, RPSTIR2 keeps its incumbent local version exactly the same with global repositories.

Although RPSTIR2 keeps the historic versions locally, they are stored for diagnose and analysis (maybe to trigger SLURM)

If some RP can retrieve missing objects while others can not, data inconsistence will occur among different RPs.

I think we just need to keep RP in alignment with PP and then can perform some analysis and diagnose (if necessary) to ascertain errors (RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP operator is confident enough that he catch the wrong data and knows how to remedy locally.

To sum up, I would like to see :

1) RPs are encouraged to store historic versions locally especially the validated RTR-output

2) If the RP finds some missing objects (not in the CRL, still in the MFT) , it is suggested to issue warning to operators and SLURM can be used by the historic data.

I therefore really look forwards to hearing from folks of other RP software to comment on this.

Di

> 2020年5月8日 23:26，Stephen Kent <stkent=[e-mail]> 写道：
> 
> 
> 6.  Relying Party Use of Manifests
>  
> Each RP must determine which signed objects it will use for
> validating assertions about INRs and their use (e.g., which ROAs to
> use in the construction of route filters). Manifests are designed 
> to allow an RP to detect manipulation of repository data and/or 
> errors by a CA or repository manager. Unless all of the files 
> enumerated in a manifest can be obtained by an RP (either from a 
> publication point or from a local cache), an RP MUST ignore the
> data associated with the publication point. This stringent response
> is needed to prevent an RP from misinterpreting data associated with
> a publication point, and thus possibly treating invalid routes as
> valid, or vice versa.
>  
> The processing described below is designed to cause all RPs with 
> access to the same local cache and RPKI repository data to achieve 
> the same results with regard to validation of RPKI data. However, in
> operation, different RPs will access repositories at different times,
> and some RPs may experience local cache failures, so there is no 
> guarantee that all RPs will achieve the same results with regard to 
> validation of RPKI data
>  
> Note that there is a “chicken and egg” relationship between the 
> manifest and the CRL for a given CA instance. If the EE certificate 
> for the current manifest is revoked, i.e., it appears in the current CRL,
> then the CA or publication point manager has made a serious error. In this 
> case all signed objects associated with the CA instance MUST be ignored. 
> Similarly, if the CRL is not listed on a valid, current manifest, all 
> signed objects associated with the CA instance MUST be ignored, because 
> the CRL is considered missing. 
>  
>  
>  
> 6.1. Manifest Processing Overview
> 
> For a given publication point, an RP MUST perform a series of tests to
> determine which signed object files at the publication point are
> acceptable. The tests described below are to be performed using the 
> manifest identified by the id-ad-rpkiManifest URI extracted from a CA certificate’s SIA. All of the files referenced by the manifest MUST be 
> be located at the publication point specified by the id-ad-caRepository 
> URI from the (same) certificate’s SIA. If the manifest and the files it
> references do not reside at the same publication point, an RP MUST ???
>  
> A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be at 
> the location specified in the CRLDP in the manifest’s EE certificate.
> If more than one .crl file appears in the manifest, only file names 
> matching the CRL specified by the CRLDP will be processed. If more than 
> one .crl entry appears in the manifest, and matches the CRLDP, the first 
> one encountered MUST be used.  Any other .crl files MUST be ignored and a warning MUST be issued.
>  
> Note that, during CA key rollover [RFC6489], signed objects for two or 
> more different CA instances will appear at the same publication point. 
> Manifest processing is to be performed separately for each CA instance, 
> guided by the SIA id-ad-rpkiManifest URI in each CA certificate.
>  
> Note also that the processing described here will be performed using 
> locally cached files if an RP does not detect newer versions of the files
> in the RPKI repository system.
> 
> 
> 6.2 Acquiring a Manifest for a CA
>  
> Acquire the manifest identified by the SIA id-ad-rpkiManifest URI
> in the CA certificate. If an RP cannot retrieve a manifest using this 
> URI, or if the manifest is not valid (Section 4.4), an RP SHOULD examine 
> the most recent, cached manifest matching this URI. If that manifest is 
> current (Section 4.4) proceed to 6.3. If the publication point 
> does not contain a valid manifest, and the cached manifest is not current,
> proceed to 6.7.
> 
> 
> 6.3 Detecting Stale and or Prematurely-issued Manifests
>  
> Check that the current time (translated to UTC) is between 
> thisUpdate and nextUpdate. If the current time lies within this interval, 
> proceed to 6.4. If the current time is earlier than thisUpdate, the CA 
> has made an error. If the RP cache contains a current manifest, use that manifest instead and issue a warning. If an RP has no access to a current manifest, processing stops and a warning MUST be issued. If the current 
> time is later than nextUpdate, then the manifest is stale. If the RP cache contains a current manifest, use that manifest instead and issue a warning.
> If no current manifest is available, proceed to 6.7.
> 
> 
> 6.4 Acquiring Files Referenced by a Manifest
>  
> Acquire all files enumerated in the manifest (fileList) from 
> the publication point. This includes the CRL, each object containing an 
> EE certificate issued by the C, and all subordinate CA and EE certificates. 
> If  there are files listed in the manifest that cannot be retrieved from 
> the publication point, or if they fail the validity tests specified in 
> [RFC6488], the RP SHOULD examine its cache to determine if these files 
> are available locally. If all of the missing/invalid files are available
> from the RP’s cache, i.e., each file name matches the list extracted from 
> the manifest, the RP SHOULD use the cached files to replace those missing 
> from the publication point, and proceed to 6.5. However, if any of the missing/invalid files cannot be replaced in this fashion, then proceed to 6.7.
> 
> 6.5 Matching File Names and Hashes
>  
> Verify that the hash value of every file listed in the 
> manifest matches the value obtained by hashing the file acquired from the 
> publication point or local cache. If the computed hash value of a file 
> listed on the manifest does not match the hash value contained in the 
> manifest, then an RP SHOULD examine its local cache to determine if the
> same file is available. The RP SHOULD use cached files to replace any 
> (damaged) downloaded files, so long as the hash of the cached file matches 
> the hash from the manifest. If any of the files with hash mismatches 
> cannot be replaced in this fashion, proceed to 6.7. Otherwise proceed to 6.6.
> 
> 
> 6.6 Out of Scope Manifest Entries
>  
> If a current manifest contains entries for objects that are not 
> within the scope of the manifest (Section 2), then the out-of-scope 
> entries MUST be disregarded. 
> 
> 
> 6.7 Termination of Processing
>  
> If an RP cannot acquire a current, valid manifest, or acquire current, 
> valid instances of all of the objects enumerated in a current valid 
> manifest, then processing of the signed objects associated with the CA
> has failed. The RP MUST issue a warning indicating the reason(s) for termination of processing with regard to this CA. 
>  
> Termination or processing means that all of the ROAs and subordinate certificates (CA and EE) MUST be considered invalid. This implies that 
> the RP MUST not try to acquire and validate subordinate signed objects, 
> until the next interval when the RP is scheduled to process data for 
> this part of the RPKI repository system.
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>