[Sidrops] note on flipping back and forth between RRDP / RSYNC

[Job Snijders <[e-mail]>]

Dear all,

I'd like to share a simple terminal transcript on how to efficiently
switch from RRDP to RSYNC. This note is in reponse to a previous message
in which the author appeared to assume rsync clients would fall back
with a 'clean copy': https://mailarchive.ietf.org/arch/msg/sidrops/AtFXCBnwGQR97C7tu2ePXd2WpaI/

For this demonstration an open source utility authoried by Nils Fisher
(development supported by APNIC & ARIN) is used: https://github.com/nilsmf/rrdp
This 'rrdp' utility the reverse of https://github.com/NLnetLabs/rrdpit

First bootstrap with empty cache (Amsterdam) from the latest RRDP snapshot:

    $ time ../rrdp -d arin https://rrdp.arin.net/notification.xml
        1m21.37s real     0m05.41s user     0m04.39s system

    $ du -sh arin
    84.0M   arin

    $ ls arin/repository/
    arin-rpki-ta     arin-rpki-ta.cer

The 'rrdp' utility creates a filesystem hierarchy based on the URI XML
attribute which in a subsequent validation phase is expected to map to
each object's SIA attribute.

Because of how URIs in RRDP snapshots / deltas map to SIAs (filepaths) and
'CA Repositories' (directories) on RSYNC servers, it is now possible to
switch over from RRDP to RSYNC, as demonstrated below:

    $ rsync -zrt --stats rsync://rpki.arin.net/repository/ arin/repository/
    Number of files: 30,396 (reg: 28,719, dir: 1,677)
    Number of created files: 0
    Number of deleted files: 0
    Number of regular files transferred: 28,719
    Total file size: 60,399,704 bytes
    Total transferred file size: 60,399,704 bytes
    Literal data: 0 bytes
    Matched data: 60,399,704 bytes
    File list size: 1,495,650
    File list generation time: 0.001 seconds
    File list transfer time: 0.000 seconds
    Total bytes sent: 1,219,102
    Total bytes received: 2,776,383
    
    sent 1,219,102 bytes  received 2,776,383 bytes  319,638.80 bytes/sec
    total size is 60,399,704  speedup is 15.12

Only a total of ~ 4 megabytes of network traffic, instead of the full 84
megabyte repo!

Recycling information retrieved via RRDP (or any other means) is far
more efficient than reaching out to the RSYNC endpoint with an empty
cache:

    $ rm -rf arin && mkdir -p arin/repository
    $ time rsync -zrt --stats rsync://rpki.arin.net/repository/arin/repository/ | tail -3
    sent 560,295 bytes  received 46,906,887 bytes  1,460,528.68 bytes/sec
    total size is 60,406,353  speedup is 1.27
        0m32.66s real     0m02.16s user     0m06.09s system

Wrapping up
-----------

In the above demonstration an *unvalidated* RRDP-seeded cache was synced
with the RSYNC server. Relying Parties are best off if they separately
maintain a copy of the validated cache, and 'incoming' datastores for
RRDP & RSYNC sync attempts. A rogue RRDP / RSYNC server ideally is not
able to wipe out the locally stored validated cache with trash.

Rob Austein mentioned his implementation has such an elegant mechanism:
https://mailarchive.ietf.org/arch/msg/sidrops/rAk9iyjD3fuPLie3DriFgldWPUk/

RPs syncing up with the RSYNC server (because RRDP service is unavailable)
can keep copies of previously fetched RRDP delta files in hopes that
when the RRDP service comes back the RRDP session can be resumed.

All in all - switching back and forth between RSYNC and RRDP should not
impose undue burden on either RPs or the Publication Point servers, iff
the RPs are specifically designed to minimize load.

Arguably HTTPS "If-Modified-Since" fetches to https://rrdp.arin.net/notification.xml
consume less resources than RSYNC requests. Thus it makes sense to
prefer RRDP, and if RRDP is not available not query the RSYNC service as
frequently as one would query the RRDP notification URL.

Kind regards,

Job