<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-IE" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> <p class="MsoNormal"><span lang="EN-GB">Hi Nathalie, <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB"><br> Thank you for addressing this RIPE NCC infra issue. <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-GB">It looks like the RIPE NCC RPKI infra for rsync is updating the ROA’s in the same directory while the RPKI clients that use rsync, are still fetching the files. <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-GB">This is common knowledge on using rsync .. but with the use of MD5 of crypto checks on the files, that becomes an issue. <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-GB">It is best practise to dump the files in a specific (timestamp)directory .. symlink the download link to the timestamp directory .. and keep things read-only once the stuff is written on disk.. so there are no improper updates that would cause crypto or MD5 hash issues. <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB">Once there is new RPKI data, create a new timestamp dir, move the symlink to the new location and be done with it. <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-GB">As a RPKI-client user that is happy with the security within the software, that starts to barf over improper RPKI data .. as one should hope it would .. I would like to ask the NCC to update their rsync method quicker than ‘perhaps in 6 months … ‘ <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-GB">This looks to be a 3 line bash script fix on a cronjob … So why isn’t this just tested on a testbed and updated before the end of the week ? <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-GB">Regards,<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB">Erik Bais <o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> <p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">routing-wg <routing-wg-bounces@ripe.net> on behalf of Nathalie Trenaman <nathalie@ripe.net><br> <b>Date: </b>Monday 12 April 2021 at 12:04<br> <b>To: </b>"routing-wg@ripe.net" <routing-wg@ripe.net><br> <b>Subject: </b>[routing-wg] Issue affecting rsync RPKI repository fetching<o:p></o:p></span></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Dear colleagues,<o:p></o:p></p> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal">We have been made aware of an issue that may affect some users who use RPKI relying party (RP) software that uses rsync. Please note that by default, only rpki-client reads from rsync; the rest of the RPs prefer the RPKI Repository Delta Protocol (RRDP). <o:p></o:p></p> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal">The issue appears to create some inconsistency between the RPKI repository and rsync clients. In more detail, an RRDP client reads a complete state for a specific “serial” from the repository. In contrast, an rsync client syncs the state in multiple steps. First, a list of files is copied, followed by updates for files that have been copied. In an affected scenario, a certificate is added and one of the other files (the manifest) is modified after the file list has been sent. By reading the new manifest, but not copying the new file (it is not on the rsync file list), the repository copied by the rsync client contains an invalid manifest (a file is missing) and the RP software rejects it.<o:p></o:p></p> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal">We are planning on changing our publication infrastructure and using the same "revisions" RRDP uses for the content of the rsync repository. Rsync is an officially supported distribution protocol for RPKI repository data, and it is one of our highest priorities that the data published is atomic and consistent. We plan to release the new publication infrastructure in Q2/Q3 2021. Part of this work will mitigate these non-repeatable-reads for clients using rsync.<o:p></o:p></p> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal">We will update you on our progress during RIPE 82, taking place online from 17-21 May 2021.<o:p></o:p></p> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal">Kind regards,<o:p></o:p></p> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal">Nathalie Trenaman<o:p></o:p></p> </div> <div> <p class="MsoNormal">RIPE NCC<o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="font-family:"Arial",sans-serif"><br> <br> </span><o:p></o:p></p> </div> </div> </body> </html>