Re: [Sidrops] trying to limit RP processing variability

[Jay Borkenhagen <[e-mail]>]

Job Snijders writes:
 > On Wed, Apr 15, 2020, at 12:46, Martin Hoffmann wrote:
 > > An attacker who can delete files can as easily replace them with
 > > something else with the same result. So I am not sure the added code
 > > complexity is worth it.
 > 
 > Agreed. 
 > 
 > fwiw: rpki-client runs as "openrsync -rlt --delete rsync://xxx/repository xxx/repository"
 > 

I agree with this behavior as well.

Further, it leads me to make a new straw man proposal for our
pre-Interim/Virtual meeting discussion.

Earlier in a related thread I wrote "[...] in the context of the RPKI,
we need to reach a point where all RFC-compliant RPs will generate
identical sets of VRPs when presented with the same input."  That
statement did not generate any pushback (but feel free to disagree now
if you want). 

Now I would like to push to see if we can take it further.  Please
bash this proposed goal:

 Each validation run of each RFC-compliant RP will generate the same
 set of VRPs when presented with identical input, using unexpired
 records from previous retrievals to deal with only complete failure
 to retrieve from a PP.

This implies that the "cache" aspects of an RP serve two purposes: 

 (1) reducing the amount of data to be downloaded on subsequent runs

and:

 (2) addressing the case of a PP that is temporarily completely
 unreachable, for only as long as those retrieved records have not
 expired. 

In other words, RPs should assume an empty cache, except in the case
where a previously-reached PP is now temporarily completely
unreachable. 

Commence bashing. :)

						Jay B.