RFC 9697

Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization ✨

Internet Engineering Task Force (IETF) 🌐 Request for Comments: 9697 🎀 Authors: J. Snijders (Fastly) and T. de Kock (RIPE NCC) 💖 Category: Standards Track 💅 ISSN: 2070-1721 Date: December 2024 🍓 Updates: RFC 8182 🦋

Abstract 🌸

okay so this doc is about how Resource Public Key Infrastructure (RPKI) Relying Parties can spot a specific kind of RRDP session desynchronization, and then how to recover from it. It updates RFC 8182 ✨

Status of This Memo 🦋

this is an Internet Standards Track document 💅

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check out Section 2 of RFC 7841 🔥

for the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9697 🌈

Copyright Notice 🎀

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read these, bestie, because they describe your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⭐

Table of Contents 💅

1.  Introduction
  1.1.  Requirements Language
2.  Immutability of RRDP Files
3.  Detection of Desynchronization
  3.1.  Example
4.  Recovery After Desynchronization
5.  Changes to RFC 8182
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

---

1. Introduction 🧚

okay so the Resource Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) [RFC8182] is a one-way synchronization protocol for distributing RPKI data as differences (deltas) between sequential repository states 🦋 Relying Parties (RPs) take a contiguous chain of deltas and apply them, so their local copy of the repository matches the current state of the remote Repository Server. the delta files for any given session_id and serial number are supposed to be an immutable record of what the Repository Server looked like at that exact moment. but, ngl, that's not always what happens 🙈

so this document describes how RPs can detect one particular form of RRDP session desynchronization, where the hash of a delta for a given serial number and session_id has changed from what the previous Update Notification File said. it also tells you how to recover 💖

1.1. Requirements Language 💜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here ✨ so if you see them in lowercase, they're just normal words, periodt 💅

2. Immutability of RRDP Files 🌸

Section 3.1 of [RFC8182] explains how discrete publication events, like adding, modifying, or deleting one or more repository objects, can be communicated as immutable files. the perks for publishers are huge, like being able to precalculate files and use caching infrastructure 🔥

now, the global RPKI is understood to be loosely consistent, meaning the view depends on when each cache updates (see Section 6 of [RFC7115]). even so, different caches having different data for the same RRDP session at the same serial is a big no-no, because it violates the principle of least astonishment 😭

if an RRDP server serves differing data for a given session_id and serial number over time, then distinct RP instances would end up with divergent local repositories, depending on the moment they connected to the RRDP server. comparing only the server-provided session_id and latest serial number across distinct RP instances wouldn't reveal that divergence at all 👀

the RRDP specification [RFC8182] hints that immutability is a property of RRDP files, but it doesn't make it clear that immutability is an absolute requirement for RRDP to work well. main character energy for this doc is making that crystal clear ✨

3. Detection of Desynchronization 🦋

Relying Parties can implement a mechanism that keeps a record of the serial and hash attribute values in delta elements from the previous successful fetch of an Update Notification File. then, after fetching a new Update Notification File, the Relying Party should compare whether the serial and hash values of previously seen serials match those in the newly fetched file. if any differences are detected, the Delta files were unexpectedly mutated, and the RP should proceed to Section 4 🔍

3.1. Example 🎀

this section has two versions of an Update Notification File to show an unexpected mutation. here's the initial one 💖

<notification xmlns="http://www.ripe.net/rpki/rrdp" version="1"
session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec" serial="1774">
<snapshot uri="https://rrdp.example.net/1774/snapshot.xml"
hash=
"4b5f27b099737b8bf288a33796bfe825fb2014a69fd6aa99080380299952f2e2"
/>
<delta serial="1774" uri="https://rrdp.example.net/1774/delta.xml"
hash=
"effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00"
/>
<delta serial="1773" uri="https://rrdp.example.net/1773/delta.xml"
hash=
"731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a"
/>
<delta serial="1772" uri="https://rrdp.example.net/1772/delta.xml"
hash=
"d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939"
/>
</notification>

Figure 1 📸

based on that Update Notification File, an RP implementation could record this state 🧠

fe528335-db5f-48b2-be7e-bf0992d0b5ec
1774 effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00
1773 731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a
1772 d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939

Figure 2 📝

now a new version of the Update Notification File gets published like this 👀

<notification xmlns="http://www.ripe.net/rpki/rrdp" version="1"
session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec" serial="1775">
<snapshot uri="https://rrdp.example.net/1775/snapshot.xml"
hash=
"cd430c386deacb04bda55301c2aa49f192b529989b739f412aea01c9a77e5389"
/>
<delta serial="1775" uri="https://rrdp.example.net/1775/delta.xml"
hash=
"d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc"
/>
<delta serial="1774" uri="https://rrdp.example.net/1774/delta.xml"
hash=
"10ca28480a584105a059f95df5ca8369142fd7c8069380f84ebe613b8b89f0d3"
/>
<delta serial="1773" uri="https://rrdp.example.net/1773/delta.xml"
hash=
"731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a"
/>
</notification>

Figure 3 🔥

using its previously recorded state (see Figure 2), the RP can compare the hash values for serials 1773 and 1774. for serial 1774, a different hash value is now listed compared to the earlier version of the Update Notification File. that means an unexpected delta mutation happened 😱

4. Recovery After Desynchronization 🌈

once RRDP session desynchronization is detected, RP implementations SHOULD issue a warning and SHOULD download the latest Snapshot File, then process it as described in Section 3.4.3 of [RFC8182]. that's how they get back to a synchronized state 💖

see Section 6 for an overview of the risks linked to desynchronization ⚠️

5. Changes to RFC 8182 ✨

the following paragraph gets added to Section 3.4.1 of [RFC8182], "Processing the Update Notification File", right after the paragraph that ends with "The Relying Party MUST then download and process the Snapshot File specified in the downloaded Update Notification File as described in Section 3.4.3." 🎀

NEW

|  If the session_id matches the last known session_id, the Relying
|  Party SHOULD compare whether hash values associated with
|  previously seen files for serials match the hash values of the
|  corresponding serials in the newly fetched Update Notification
|  File.  If any differences are detected, this means that files were
|  unexpectedly mutated (see [RFC9697]).  The Relying Party SHOULD
|  then download and process the Snapshot File specified in the
|  downloaded Update Notification File as described in Section 3.4.3.

8.2. Informative References

Okay, now the bonus reading, aka the stuff that's not required but is super helpful for understanding the vibe 🧚💜

[ASPA] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-verification-19, 27 September 2024, https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-19.

[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, https://www.rfc-editor.org/info/rfc6811.

[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, https://www.rfc-editor.org/info/rfc7115.

[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, https://www.rfc-editor.org/info/rfc9286.

---

Acknowledgements 🙌

Okay, the origin story is so good 😭 During the hallway track at RIPE 86, Ties de Kock came up with the idea for detecting this particular form of RRDP desynchronization. Then Claudio Jeker, Job Snijders, and Theo Buehler built an implementation on top of rpki-client 🛠️ Once they had tooling that could catch this exact error condition, it became clear over the next few months that unexpected delta mutations in the global RPKI repositories really do happen from time to time. Main character energy for the hallway track, honestly 🦋

The authors want to thank Theo Buehler, Mikhail Puzanov, Alberto Leiva, Tom Harrison, Warren Kumari, Behcet Sarikaya, Murray Kucherawy, Éric Vyncke, Roman Danyliw, Tim Bruijnzeels, and Michael Hollyman for their careful review and feedback on this document. Thank you all, you're literally the reason this is so solid 🫶💖

---

Authors' Addresses 💌

Job Snijders
Fastly
Amsterdam
Netherlands
Email: job@fastly.com


Ties de Kock
RIPE NCC
Amsterdam
Netherlands
Email: tdekock@ripe.net