Summary

  • Job Snijders and RIPE NCC's Ties de Kock authored RFC 9697, a December 2024 IETF standard for detecting a changed old RRDP delta.
  • A validator compares previously seen serial numbers and hashes; on a mismatch it should warn and rebuild from the latest snapshot.

The revision that reached backwards

The update notification says the repository has moved from serial 1774 to 1775. Ordinary news. Then an older entry, still labelled 1774, arrives with a different hash. The number on the drawer has stayed put while someone has changed the contents. This is the worked example in RFC 9697, not an incident report. Its authors, Job Snijders and Ties de Kock of RIPE NCC, turned that small contradiction into a test a validator can perform.

RPKI repositories distribute signed material that helps networks assess which autonomous system may originate a route. The RRDP protocol moves that material as a sequence of change files, called deltas. A relying party starts with a complete snapshot, then downloads the missing deltas instead of taking the whole collection every time. The update notification lists the current session, serial numbers and file hashes. Static files and web caches make this efficient. They also make an old file changing under an old identifier an unusually poisonous surprise.

Two validators can fetch at different moments, accept different contents for serial 1774 and still report the same session and latest serial. A dashboard that checks only those two labels will see agreement. Their local repositories may disagree. Snijders and de Kock's answer is to keep the serial-and-hash pairs from the previous successful notification. On the next fetch, compare the serials that appear in both notices. In the RFC's example, 1773 keeps its hash; 1774 does not. That is enough to stop trusting the incremental chain. The validator should warn and fetch the latest full snapshot.

Snijders had already described another distribution headache in his 2021 account of OpenBSD rpki-client. When RRDP requests crossed load-balanced back ends that were out of step, a notification could point to a delta the next back end had yet to serve. That earlier race and RFC 9697's mutable-old-delta case are separate failures. Together they show why a signed routing system needs its delivery system to keep an honest calendar.

The stakes are concrete. RFC 9697 says a desynchronized cache can emit a different set of validated routing payloads, including keeping one a certification authority intended to withdraw. A route meant to validate may instead appear unknown or invalid. A stale copy can linger through a long repository session. The fix begins with a prosaic question: did yesterday's hash stay yesterday's hash?