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

[Di Ma <[e-mail]>]

Job,

> 2020年5月9日 02:00，Job Snijders <[e-mail]> 写道：
> 
> Dear Di Ma,
> 
> On Sat, May 09, 2020 at 01:33:29AM +0800, Di Ma wrote:
>> 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. 
> 
> Can you elaborate on why it is hard in RSTPIR2? I am not familiar with
> this implementation and can perhaps learn from it, or offer suggestions.

When I say hard, I mean I cannot estimate when ‘a specific object’ will be retrieved from a specific historic version of local cache. 

And we don’t know then we need to cache all the historic versions in case of missing objects. 

And it is even worse when the missing stuff is Resource Certificate, the SIA of which will affect where the RP to find the subordinate repository. This happens in the middle of sync. Accordingly the RP will use a well-designed algorithm to search all the historic versions efficiently.

I am not saying we cannot do that but this is really deserves an effort.

I really look forwards to seeing your big idea or suggestions:-)

> 
>> 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.
> 
> An RP can't know if it is in sync with the global repository. The trust
> derives from the pre-obtained RPKI TALs, through the X509 validation
> procedure and outputs Validated ROA Payloads.
> 
> In this process the data that can be *least* trusted is what came in via
> the untrusted network channel (be it rsync or RRDP). Withholding or
> corruption by issuing 'withdraws' (RRDP)  or '--delete' (rsync) cannot
> be trusted at all. With this in mind, one really really aught to
> reconstruct the original publication point's repository, suppplementing
> it with locally cached data as much as possible.
> 
>> 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.
> 
> This already always is the case, and will not change. RPs pull from the
> CA's publication point from different places on the Internet, at
> different times.


I have to admit that keep all the RP throughout the Internet keep in pace for sync is over-ideal. 


> 
>> 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.
> 
> How will the RP stay in alignment with the PP when the RP is under
> attack? Intercepting and corrupting rsync connections is trivial and the
> RRDP protocol does not offer protections against unauthorised
> modification of the data presented to the RP.

I am considering deploying multiple RP instances by diversifying its locations to avoid MITM attack. 

> 
>> 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.
> 
> What is the 'timing' of the process you describe under (2)? I cannot
> imagine any manual intervention in the validation process to scale for
> the purpose of the Internet routing system. Perhaps I'm
> misunderstanding.

I expect this work this way:

1) A missing object found;
2) Warning issued to RP operator, indicating which VRP will be adversely affected and providing suggested SLURM Assertion;
3) SLURM acknowledged to add this Assertion to the validated cache affected by the missing object (ROA for example)

> 
>> I therefore really look forwards to hearing from folks of other RP
>> software to comment on this.
> 
> It is my intention to provide the working group with an implementation
> report of OpenBSD's current rpki-client version in relation to the text
> that Stephen Kent provided today as 'rev 4'. I hope to be able to do
> that next week. My report will be usable as a template for other
> implementation maintainers. Comparing and sharing implementation notes
> is fun, stay tuned!

Always glad to see someone sharing RP implementation notes :-)

Di