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

[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.

> 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 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.

> 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 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!

Kind regards,

Job