Re: [Sidrops] 6486bis: referenced object validation

[Job Snijders <[e-mail]>]

Dear group,

On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrote:
> On 6486 in particular there was a strong desire communicated by
> operators that RPs behave the *same* way.

> Which is why we were hesitant to implement the changes suggested by
> you in the GH issue. 

I have a celebratory moment to share with all of you, below is a
terminal transcript and some hashes which will allow you to confirm my
findings.

The below was executed on a modern POSIX.1 implementation with default
settings. I used routinator's '-n' option and a symlink to ensure the
input to both routinator and rpki-client is the same, up and including
to all filesystem metadata.

We have some tals:

    # ls /etc/rpki
    afrinic.tal apnic.tal   arin.tal    disabled    lacnic.tal  ripe.tal

Execute rpki-client, which will fork rsync and gather all data from the
Internet. The system is located in Amsterdam. I've also included the
size of the cache and a hash of all the object filenames that were in
the cache at that moment.

    # rpki-client -jc > /dev/zero 2>&1 && date
    Fri Dec  4 20:33:14 UTC 2020
   
    # cd /var/cache/rpki-client && du -s
    839028  .

    # find . | sha256
    a8c03e2ef66de2532a119f56cdeba0e52acbeb23b8ac3e645d6fa7442c8fed8e

rpki-client VRP set:

    # sort /var/db/rpki-client/csv | sha256
    e0e8de429465def598b18a399d6695968cb7f28db2c2093c95bdc4563240fa4b

routinator 0.8.2-rc1 VRP set:

    # ls -lahtr .rpki-cache/repository/rsync
    lrwxr-xr-x  1 job  job    23B Dec  4 20:09 .rpki-cache/repository/rsync -> /var/cache/rpki-client/

    # ./target/debug/routinator -v -t /etc/rpki vrps -n 2>/dev/zero | sort | sha256
    e0e8de429465def598b18a399d6695968cb7f28db2c2093c95bdc4563240fa4b

>From the above we learn it truly is possible for multiple entirely
different implementations written by different people to arrive at the
**exact** same results, based on data derived from a complex distributed
PKI system with 5 Trust Anchors and 22,084 manifests from tens of
thousands of CAs resulting in the exact same 205,768 unique VRPs.

I *also* went back to December 1st, 2020 at 00:00:13 UTC and fed that
data from the tarball linked at https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html
into both routinator and rpki-client, and the resulting VRP lists from
both rpki-client and routinator resulted in the same hash:
be9e7fd656c3d143f2eb5cbb0b13d299a3534c6043f49a3330f5ac14854e621f

However rocky the road was to get to this point, this really is a
marvelous achievement at scale for the internet engineering community.
Congratulations NLNetLabs. I hope other implementations will soon arrive
at the be9e7fd656c3d143f2eb5cbb0b13d299a3534c6043f49a3330f5ac14854e621f
checksum when mimicking that december 1st moment with that x509 data
set.

Kind regards,

Job

ps. Please note the above two data points are only single snapshots in
time, but encouraging ones. At present I am aware of implementation
differences between RP implementations related to ASN/BER/DER handling,
and possibly other differences, which will probaably manifest themselves
(pun intended) at one point or another in the future, or already have in
the past.