rfc9697.original.xml		rfc9697.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
			<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
	]>		]>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<?rfc sortrefs="yes"?>		tf-sidrops-rrdp-desynchronization-04" number="9697" ipr="trust200902" xml:lang="
	<?rfc subcompact="no"?>		en" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="3" submissionType
	<?rfc symrefs="yes"?>		="IETF" consensus="true" updates="8182" obsoletes="" version="3">
	<?rfc toc="yes"?>
	<?rfc tocdepth="3"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	category="std"
	docName="draft-ietf-sidrops-rrdp-desynchronization-04"
	ipr="trust200902"
	xml:lang="en"
	sortRefs="true"
	submissionType="IETF"
	consensus="true"
	updates="8182"
	version="3">
	<front>		<front>
	<title>Detecting RRDP Session Desynchronization</title>		<title abbrev="Detecting RRDP Session Desynchronization">Detecting RPKI Repo
			sitory Delta Protocol (RRDP) Session Desynchronization</title>
			<seriesInfo name="RFC" value="9697"/>
	<author fullname="Job Snijders" initials="J." surname="Snijders">		<author fullname="Job Snijders" initials="J." surname="Snijders">
	<organization>Fastly</organization>		<organization>Fastly</organization>
	<address>		<address>
	<postal>		<postal>
	<street/>
	<code/>
	<city>Amsterdam</city>		<city>Amsterdam</city>
	<country>Netherlands</country>		<country>Netherlands</country>
	</postal>		</postal>
	<email>job@fastly.com</email>		<email>job@fastly.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Ties de Kock" initials="T." surname="de Kock">		<author fullname="Ties de Kock" initials="T." surname="de Kock">
	<organization>RIPE NCC</organization>		<organization>RIPE NCC</organization>
	<address>		<address>
	<postal>		<postal>
	<city>Amsterdam</city>		<city>Amsterdam</city>
	<country>Netherlands</country>		<country>Netherlands</country>
	</postal>		</postal>
	<email>tdekock@ripe.net</email>		<email>tdekock@ripe.net</email>
	</address>		</address>
	</author>		</author>
	<date />		<date month="November" year="2024"/>
	<area>ops</area>		<area>OPS</area>
	<workgroup>SIDROPS</workgroup>		<workgroup>sidrops</workgroup>
	<keyword>desynchronization</keyword>		<keyword>desynchronization</keyword>
	<keyword>RPKI</keyword>		<keyword>RPKI</keyword>
	<keyword>RRDP</keyword>		<keyword>RRDP</keyword>
	<abstract>		<abstract>
	<t>		<t>
	This document describes an approach for Resource Public Key Infrastructu re (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta P rotocol (RRDP) session desynchronization and how to recover.		This document describes an approach for Resource Public Key Infrastructu re (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta P rotocol (RRDP) session desynchronization and how to recover.
	This document updates RFC 8182.		This document updates RFC 8182.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="intro">		<section anchor="intro">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	The Resource Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) <xref target="RFC8182"/> is a one-way synchronization protocol for distri buting RPKI data in the form of <em>differences</em> (deltas) between sequential repository states.		The Resource Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) <xref target="RFC8182"/> is a one-way synchronization protocol for distri buting RPKI data in the form of <em>differences</em> (deltas) between sequential repository states.
	Relying Parties apply a contiguous chain of deltas to synchronize their local copy of the repository with the current state of the remote Repository Ser ver.		Relying Parties (RPs) apply a contiguous chain of deltas to synchronize their local copy of the repository with the current state of the remote Reposito ry Server.
	Delta files for any given session_id and serial number are expected to c ontain an immutable record of the state of the Repository Server at that given p oint in time, but this is not always the case.		Delta files for any given session_id and serial number are expected to c ontain an immutable record of the state of the Repository Server at that given p oint in time, but this is not always the case.
	</t>		</t>
	<t>		<t>
	This document describes an approach for Relying Parties (RPs) to detect a form of RRDP session desynchronization where the hash of a delta for a given s erial number and session_id have mutated from the previous Update Notification F ile and how to recover.		This document describes an approach for RPs to detect a form of RRDP ses sion desynchronization where the hash of a delta for a given serial number and s ession_id have mutated from the previous Update Notification File and how to rec over.
	</t>		</t>
	<section anchor="requirements">		<section anchor="requirements">
	<name>Requirements Language</name>		<name>Requirements Language</name>
	<t>		<t>
	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp1		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	4>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<b		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	cp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	>" in this document are to be interpreted as described in BCP&nbsp;14 <xref targ		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	et="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all		be interpreted as
	capitals, as shown here.		described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="immutability">		<section anchor="immutability">
	<name>Immutability of RRDP files</name>		<name>Immutability of RRDP Files</name>
	<t>		<t>
	<xref target="RFC8182" section="3.1"/> describes how discrete publicatio n events such as the addition, modification, or deletion of one or more reposito ry objects <em>can</em> be communicated as immutable files, highlighting advanta ges for publishers, such as the ability to pre-calculate files and make use of c aching infrastructure.		<xref target="RFC8182" section="3.1"/> describes how discrete publicatio n events such as the addition, modification, or deletion of one or more reposito ry objects <em>can</em> be communicated as immutable files, highlighting advanta ges for publishers, such as the ability to precalculate files and make use of ca ching infrastructure.
	</t>		</t>
			<!-- [rfced] We are having trouble parsing this text. We see this text appears
			in RFC 7115:
			Like the DNS, the global RPKI presents only a loosely consistent
			view, depending on timing, updating, fetching, etc.
			When combined in the new sentence, it is unclear how "depending on timing..." re
			lates to the rest of the sentence. Perhaps the sentence should be broken into t
			wo? Please clarify.
			Original:
			While the global RPKI is understood to present a loosely consistent
			view, depending on timing, updating, fetching (see Section 6 of
			[RFC7115]), different caches having different data for the same RRDP
			session at the same serial violates the principle of least
			astonishment.
			-->
	<t>		<t>
	While the global RPKI is understood to present a loosely consistent view , depending on timing, updating, fetching (see <xref target="RFC7115" section="6 "/>), different caches having different data for the same RRDP session at the sa me serial violates the principle of least astonishment.		While the global RPKI is understood to present a loosely consistent view , depending on timing, updating, and fetching (see <xref target="RFC7115" sectio n="6"/>), different caches having different data for the same RRDP session at th e same serial violates the principle of least astonishment.
	</t>		</t>
	<t>		<t>
	If an RRDP server over time serves differing data for a given session_id and serial number, distinct RP instances (depending on the moment they connecte d to the RRDP server) would end up with divergent local repositories.		If an RRDP server over time serves differing data for a given session_id and serial number, distinct RP instances (depending on the moment they connecte d to the RRDP server) would end up with divergent local repositories.
	Comparing only the server-provided session_id and latest serial number a cross distinct RP instances would not bring such divergence to light.		Comparing only the server-provided session_id and latest serial number a cross distinct RP instances would not bring such divergence to light.
	</t>		</t>
			<!-- [rfced] May the word 'protocol' be removed from the following
			(as shown below) because it's redundant with the expansion of RRDP?
			Original:
			... is an absolute requirement for the RRDP protocol to work well.
			Perhaps:
			... is an absolute requirement for RRDP to work well.
			-->
	<t>		<t>
	The <xref target="RFC8182"/> specification does allude to immutability b eing a property of RRDP files, but doesn't make it clear that immutability is an absolute requirement for the RRDP protocol to work well.		The RRDP specification <xref target="RFC8182"/> alludes to immutability being a property of RRDP files, but it doesn't make it clear that immutability i s an absolute requirement for the RRDP protocol to work well.
	</t>		</t>
	</section>		</section>
	<section anchor="detection">		<section anchor="detection">
	<name>Detection of Desynchronization</name>		<name>Detection of Desynchronization</name>
	<t>		<t>
	Relying Parties can implement a mechanism to keep a record of the serial and hash attribute values in delta elements of the previous successful fetch of an Update Notification File.		Relying Parties can implement a mechanism to keep a record of the serial and hash attribute values in delta elements of the previous successful fetch of an Update Notification File.
	Then, after fetching a new Update Notification File, the Relying Party s hould compare if the serial and hash values of previously seen serials match tho se in the newly fetched file.		Then, after fetching a new Update Notification File, the Relying Party s hould compare if the serial and hash values of previously seen serials match tho se in the newly fetched file.
	If any differences are detected, this means that the Delta files were un expectedly mutated, and the RP should proceed to <xref target="recovery"/>.		If any differences are detected, this means that the Delta files were un expectedly mutated, and the RP should proceed to <xref target="recovery"/>.
	</t>		</t>
	<section anchor="example">		<section anchor="example">
	<name>Example</name>		<name>Example</name>
	<t>		<t>
	This section contains two versions of an Update Notification File to d emonstrate an unexpected mutation.		This section contains two versions of an Update Notification File to d emonstrate an unexpected mutation.
	The initial Update Notification File is as follows:		The initial Update Notification File is as follows:
	</t>		</t>
	<sourcecode>		<!-- [rfced] We have added a closing quote to the last line of figure 1 so it's
	<![CDATA[		well formed. Please review and let us know if corrections are needed.
			Original:
			<delta serial="1772"
			hash="d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939"
			uri="https://rrdp.example.net/1772/delta.xml />
			Current:
			<delta serial="1772"
			hash="d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939"
			uri="https://rrdp.example.net/1772/delta.xml" />
			We updated figure 3 similarly. Please review.
			Original:
			<delta serial="1775"
			hash="d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc"
			uri="https://rrdp.example.net/1775/delta.xml />
			Current:
			<delta serial="1775"
			hash="d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc"
			uri="https://rrdp.example.net/1775/delta.xml" />
			-->
			<figure>
			<sourcecode type=""><![CDATA[
	<notification xmlns="http://www.ripe.net/rpki/rrdp" version="1"		<notification xmlns="http://www.ripe.net/rpki/rrdp" version="1"
	session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec"		session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec"
	serial="1774">		serial="1774">
	<snapshot uri="https://rrdp.example.net/1774/snapshot.xml"		<snapshot uri="https://rrdp.example.net/1774/snapshot.xml"
	hash="4b5f27b099737b8bf288a33796bfe825fb2014a69fd6aa99080380299952f2e2"/>		hash="4b5f27b099737b8bf288a33796bfe825fb2014a69fd6aa99080380299952f2e2"/>
	<delta serial="1774"		<delta serial="1774"
	hash="effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00"		hash="effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00"
	uri="https://rrdp.example.net/1774/delta.xml" />		uri="https://rrdp.example.net/1774/delta.xml" />
	<delta serial="1773"		<delta serial="1773"
	hash="731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a"		hash="731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a"
	uri="https://rrdp.example.net/1773/delta.xml" />		uri="https://rrdp.example.net/1773/delta.xml" />
	<delta serial="1772"		<delta serial="1772"
	hash="d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939"		hash="d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939"
	uri="https://rrdp.example.net/1772/delta.xml />		uri="https://rrdp.example.net/1772/delta.xml" />
	</notification>		</notification>]]>
	]]>
	</sourcecode>		</sourcecode>
			</figure>
	<t>		<t>
	Based on the above Update Notification File, an RP implementation coul d record the following state:		Based on the above Update Notification File, an RP implementation coul d record the following state:
	</t>		</t>
	<figure anchor="state">		<figure anchor="state">
	<sourcecode>		<sourcecode type=""><![CDATA[
	fe528335-db5f-48b2-be7e-bf0992d0b5ec		fe528335-db5f-48b2-be7e-bf0992d0b5ec
	1774 effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00		1774 effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00
	1773 731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a		1773 731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a
	1772 d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939		1772 d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939
	</sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<t>		<t>
	A new version of the Update Notification File is published, as followi ng:		A new version of the Update Notification File is published as follows:
	</t>		</t>
	<sourcecode>		<figure>
	<![CDATA[		<sourcecode type=""><![CDATA[
	<notification xmlns="http://www.ripe.net/rpki/rrdp" version="1"		<notification xmlns="http://www.ripe.net/rpki/rrdp" version="1"
	session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec"		session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec"
	serial="1775">		serial="1775">
	<snapshot uri="https://rrdp.example.net/1775/snapshot.xml"		<snapshot uri="https://rrdp.example.net/1775/snapshot.xml"
	hash="cd430c386deacb04bda55301c2aa49f192b529989b739f412aea01c9a77e5389"/>		hash="cd430c386deacb04bda55301c2aa49f192b529989b739f412aea01c9a77e5389"/>
	<delta serial="1775"		<delta serial="1775"
	hash="d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc"		hash="d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc"
	uri="https://rrdp.example.net/1775/delta.xml />		uri="https://rrdp.example.net/1775/delta.xml" />
	<delta serial="1774"		<delta serial="1774"
	hash="10ca28480a584105a059f95df5ca8369142fd7c8069380f84ebe613b8b89f0d3"		hash="10ca28480a584105a059f95df5ca8369142fd7c8069380f84ebe613b8b89f0d3"
	uri="https://rrdp.example.net/1774/delta.xml" />		uri="https://rrdp.example.net/1774/delta.xml" />
	<delta serial="1773"		<delta serial="1773"
	hash="731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a"		hash="731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a"
	uri="https://rrdp.example.net/1773/delta.xml" />		uri="https://rrdp.example.net/1773/delta.xml" />
	</notification>		</notification>]]>
	]]>
	</sourcecode>		</sourcecode>
			</figure>
	<t>		<t>
	Using its previously recorded <xref target="state">state</xref>, the R P can compare the hash values for serials 1773 and 1774.		Using its previously recorded state (see <xref target="state" />), the RP can compare the hash values for serials 1773 and 1774.
	For serial 1774, compared to the earlier version of the Update Notific ation File, a different hash value is now listed, meaning an unexpected delta mu tation occurred.		For serial 1774, compared to the earlier version of the Update Notific ation File, a different hash value is now listed, meaning an unexpected delta mu tation occurred.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="recovery">		<section anchor="recovery">
	<name>Recovery after Desynchronization</name>		<name>Recovery After Desynchronization</name>
	<t>		<t>
	Following the detection of RRDP session desynchronization, in order to r eturn to a synchronized state, RP implementations SHOULD issue a warning and SHO ULD download the latest Snapshot File and process it as described in <xref targe t="RFC8182" section="3.4.3"/>.		Following the detection of RRDP session desynchronization, in order to r eturn to a synchronized state, RP implementations <bcp14>SHOULD</bcp14> issue a warning and <bcp14>SHOULD</bcp14> download the latest Snapshot File and process it as described in <xref target="RFC8182" section="3.4.3" sectionFormat="of"/>.
	</t>		</t>
	<t>		<t>
	See the <xref target="security"/> for an overview of risks associated wi th desynchronization.		See <xref target="security"/> for an overview of risks associated with d esynchronization.
	</t>		</t>
	</section>		</section>
	<section anchor="rfc8182">		<section anchor="rfc8182">
	<name>Changes to RFC 8182</name>		<name>Changes to RFC 8182</name>
	<t>		<t>
	The following paragraph is added to <xref target="RFC8182" section="3.4 .1"/> "Processing the Update Notification File", after the paragraph which ends "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."		The following paragraph is added to <xref target="RFC8182" section="3.4 .1"/>, "Processing the Update Notification File", after the paragraph that ends "The Relying Party <bcp14>MUST</bcp14> then download and process the Snapshot Fi le specified in the downloaded Update Notification File as described in Section 3.4.3."
	</t>		</t>
			<!-- [rfced] As this text would be added to RFC 8182, it would be odd to refer t
			o itself. We updated the text to indicate "Section 3.4.3", where 3.4.3 links to
			Section 3.4.3 in RFC 8182. Please review and let us know if you have any conce
			rns.
			Original:
			| ... 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 of [RFC8182]
			Current:
			| ... 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.
			-->
	<t>NEW</t>		<t>NEW</t>
	<blockquote>		<blockquote>
	<t>		<t>
	If the session_id matches the last known session_id, the Relying Party		If the session_id matches the last known session_id, the Relying Party
	SHOULD compare whether hash values associated with previously seen files for se		<bcp14>SHOULD</bcp14> compare whether hash values associated with previously se
	rials match the hash values of the corresponding serials in the newly fetched Up		en files for serials match the hash values of the corresponding serials in the n
	date Notification File.		ewly fetched Update Notification File.
	If any differences are detected, this means that files were unexpected		If any differences are detected, this means that files were unexpected
	ly mutated (See <xref target="I-D.ietf-sidrops-rrdp-desynchronization"/>).		ly mutated (see [RFC9697]).
	The Relying Party SHOULD then download and process the Snapshot File s		The Relying Party <bcp14>SHOULD</bcp14> then download and process the
	pecified in the downloaded Update Notification File as described in <xref target		Snapshot File specified in the downloaded Update Notification File as described
	="RFC8182" section="3.4.3"/>		in Section <xref target="RFC8182" section="3.4.3" sectionFormat="bare"/>.
	</t>		</t>
	</blockquote>		</blockquote>
	</section>		</section>
	<section anchor="security">		<section anchor="security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	Due to the lifetime of RRDP sessions (often measured in months), desynch ronization can persist for an extended period if undetected.		Due to the lifetime of RRDP sessions (often measured in months), desynch ronization can persist for an extended period if undetected.
	</t>		</t>
	<t>		<t>
	skipping to change at line 234 ¶		skipping to change at line 287 ¶
	</t>		</t>
	<t>		<t>
	Missing Validated Payloads negatively impact the ability to validate BGP announcements using mechanisms such as those described in <xref target="RFC6811 "/> and <xref target="I-D.ietf-sidrops-aspa-verification"/>.		Missing Validated Payloads negatively impact the ability to validate BGP announcements using mechanisms such as those described in <xref target="RFC6811 "/> and <xref target="I-D.ietf-sidrops-aspa-verification"/>.
	</t>		</t>
	<t>		<t>
	<xref target="RFC9286" section="6.6"/> advises RP implementations to con tinue to use cached versions of objects, but only until such time as they become stale.		<xref target="RFC9286" section="6.6"/> advises RP implementations to con tinue to use cached versions of objects, but only until such time as they become stale.
	By detecting whether the remote Repository Server is in an inconsistent state and then immediately switching to using the latest Snapshot File, RPs incr ease the probability to successfully replace objects before they become stale.		By detecting whether the remote Repository Server is in an inconsistent state and then immediately switching to using the latest Snapshot File, RPs incr ease the probability to successfully replace objects before they become stale.
	</t>		</t>
	</section>		</section>
	<section anchor="iana" title="IANA Considerations">		<section anchor="iana">
			<name>IANA Considerations</name>
	<t>		<t>
	No IANA actions required.		This document has no IANA actions.
	</t>		</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.ietf-sidrops-aspa-verification" to="ASPA"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	FC.2119.xml"/>		119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8174.xml"/>		174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8182.xml"/>		182.xml"/>
	<reference anchor="I-D.ietf-sidrops-rrdp-desynchronization" target="http
	s://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rrdp-desynchronization">
	<front>
	<title>Detecting RRDP Session Desynchronization</title>
	<author fullname="Job Snijders" initials="J." surname="Snijders">
	<organization>Fastly</organization>
	</author>
	<author fullname="Ties de Kock" initials="T." surname="de Kock">
	<organization>RIPE NCC</organization>
	</author>
	<date />
	<abstract>
	<t>
	This document describes an approach for Resource Public Key Infra
	structure (RPKI) Relying Parties (RPs) to detect a form of RPKI Repository Delta
	Protocol (RRDP) session desynchronization where the hash of a Delta for a given
	serial number and session_id have mutated compared to the previous Update Notif
	ication File and how to recover.
	This document updates RFC 8182.
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-rrdp-desync
	hronization"/>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	FC.6811.xml"/>		811.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	FC.7115.xml"/>		115.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	FC.9286.xml"/>		286.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	ietf-sidrops-aspa-verification.xml"/>
	<reference anchor="rpki-client" target="https://www.rpki-client.org/">
	<front>
	<title>rpki-client 8.5</title>
	<author fullname="Claudio Jeker"/>
	<author fullname="Job Snijders"/>
	<author fullname="Kristaps Dzonsons"/>
	<author fullname="Theo Buehler"/>
	<date month="July" year="2023" />
	</front>
	</reference>
	<reference anchor="rpki-prover" target="https://github.com/lolepezy/rpki
	-prover">
	<front>
	<title>rpki-prover 0.9.0</title>
	<author fullname="Mikhail Puzanov"/>
	<date month="February" year="2024" />
	</front>
	</reference>
	<reference anchor="FORT-validator" target="https://github.com/NICMx/FORT-
	validator/compare/main...draft-spaghetti-sidrops-rrdp-desynchronization">
	<front>
	<title>FORT validator 1.7.0</title>
	<author fullname="Alberto Leiva"/>
	<date month="March" year="2024" />
	</front>
	</reference>
	<reference anchor="Routinator" target="https://github.com/NLnetLabs/rout		<!-- [I-D.ietf-sidrops-aspa-verification] IESG State: I-D Exists as of 11/20/24
	inator/pull/951">		-->
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	<title>Routinator</title>		ietf-sidrops-aspa-verification.xml"/>
	<author>
	<organization>NLNet Labs</organization>
	</author>
	<date/>
	</front>
	</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="acknowledgements">		<section anchor="acknowledgements" numbered="false">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t>
	During the hallway track at RIPE 86, <contact fullname="Ties de Kock"/>
	shared the idea for detecting this particular form of RRDP desynchronization, af
	ter which <contact fullname="Claudio Jeker"/>, <contact fullname="Job Snijders"/
	>, and <contact fullname="Theo Buehler"/> produced an implementation based on rp
	ki-client.
	Equipped with tooling to detect this particular error condition, in subs
	equent months it became apparent that unexpected delta mutations in the global R
	PKI repositories do happen from time to time.
	</t>
	<t>
	The authors wish to thank
	<contact fullname="Theo Buehler"/>,
	<contact fullname="Mikhail Puzanov"/>,
	<contact fullname="Alberto Leiva"/>,
	<contact fullname="Tom Harrison"/>,
	<contact fullname="Warren Kumari"/>,
	<contact fullname="Behcet Sarikaya"/>,
	<contact fullname="Murray Kucherawy"/>,
	<contact fullname="Éric Vyncke"/>,
	<contact fullname="Roman Danyliw"/>,
	<contact fullname="Tim Bruijnzeels"/>, and
	<contact fullname="Michael Hollyman"/>
	for their careful review and feedback on this document.
	</t>
	</section>
	<section removeInRFC="true">
	<name>Implementation status</name>
	<t>
	This section records the status of known implementations of the protocol
	defined by this specification at the time of posting of this Internet-Draft, an
	d is based on a proposal described in RFC 7942.
	The description of implementations in this section is intended to assist
	the IETF in its decision processes in progressing drafts to RFCs.
	Please note that the listing of any individual implementation here does
	not imply endorsement by the IETF.
	Furthermore, no effort has been spent to verify the information presente
	d here that was supplied by IETF contributors.
	This is not intended as, and must not be construed to be, a catalog of a
	vailable implementations or their features.
	Readers are advised to note that other implementations may exist.
	</t>
	<t>
	According to RFC 7942, "this will allow reviewers and working groups to
	assign due consideration to documents that have the benefit of running code, whi
	ch may serve as evidence of valuable experimentation and feedback that have made
	the implemented protocols more mature.
	It is up to the individual working groups to use this information as the
	y see fit".
	</t>
	<ul>		<t>During the hallway track at RIPE 86, <contact fullname="Ties de
	<li>		Kock"/> shared the idea for detecting this particular form of RRDP
	OpenBSD <xref target="rpki-client"/> 8.5 and higher		desynchronization, after which <contact fullname="Claudio Jeker"/>,
	</li>		<contact fullname="Job Snijders"/>, and <contact fullname="Theo
	<li>		Buehler"/> produced an implementation based on rpki-client. Equipped
	Mikhail Puzanov's <xref target="rpki-prover"/> 0.9.0 and higher		with tooling to detect this particular error condition, in subsequent
	</li>		months it became apparent that unexpected delta mutations in the global
	<li>		RPKI repositories do happen from time to time.</t>
	FORT project's <xref target="FORT-validator"/> 1.7.0 and higher		<t>The authors wish to thank <contact fullname="Theo Buehler"/>,
	</li>		<contact fullname="Mikhail Puzanov"/>, <contact fullname="Alberto
	<li>		Leiva"/>, <contact fullname="Tom Harrison"/>, <contact fullname="Warren
	NLnet Labs' <xref target="Routinator"/> main branch		Kumari"/>, <contact fullname="Behcet Sarikaya"/>, <contact
	</li>		fullname="Murray Kucherawy"/>, <contact fullname="Éric Vyncke"/>,
	</ul>		<contact fullname="Roman Danyliw"/>, <contact fullname="Tim
			Bruijnzeels"/>, and <contact fullname="Michael Hollyman"/> for their
			careful review and feedback on this document.</t>
	</section>		</section>
	</back>		</back>
			<!-- [rfced] Please review the sourcecode in Figures 1 and 3 as there are a
			few lines that exceed the 69-character limit and let us know how we may
			add line breaks.
			Additionally, please consider whether the "type" attribute of any sourcecode
			element should be set. Note that it is also acceptable to leave the "type"
			attribute not set.
			The current list of preferred values for "type" is available at
			<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
			If the current list does not contain an applicable type, feel free to
			suggest additions for consideration.
			-->
			<!-- [rfced] In the html and pdf outputs, the text enclosed in <em> is output
			in italics. In the txt output, the text enclosed in <em> appears with an
			underscore before and after.
			Please review carefully and let us know if the output is acceptable or if any
			updates are needed. <em> is used as follows (1x each):
			<em>differences</em>
			<em>can</em>
			<em>failed fetch</em>
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			Note that our script did not flag any words in particular, but this should
			still be reviewed as a best practice.
			-->
	</rfc>		</rfc>
End of changes. 45 change blocks.
	216 lines changed or deleted		204 lines changed or added
This html diff was produced by rfcdiff 1.48.