rfc9674.original.xml		rfc9674.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 sortrefs="yes"?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<?rfc subcompact="no"?>		tf-sidrops-rrdp-same-origin-04" number="9674" ipr="trust200902" xml:lang="en" sy
	<?rfc symrefs="yes"?>		mRefs="true" sortRefs="true" submissionType="IETF" consensus="true" updates="818
	<?rfc toc="yes"?>		2" obsoletes="" tocInclude="true" version="3">
	<?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-same-origin-04"
	ipr="trust200902"
	xml:lang="en"
	sortRefs="true"
	submissionType="IETF"
	consensus="true"
	updates="8182"
	version="3">
	<front>		<front>
	<title abbrev="RRDP Same-Origin Policy">Same-Origin Policy for the RPKI Repo sitory Delta Protocol (RRDP)</title>		<title abbrev="RRDP Same-Origin Policy">Same-Origin Policy for the RPKI Repo sitory Delta Protocol (RRDP)</title>
			<seriesInfo name="RFC" value="9674"/>
	<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>
	<date />		<date month="November" year="2024"/>
	<area>ops</area>		<area>OPS</area>
	<workgroup>SIDROPS</workgroup>		<workgroup>sidrops</workgroup>
	<keyword>same-origin</keyword>		<keyword>same-origin</keyword>
	<keyword>RPKI</keyword>		<keyword>RPKI</keyword>
	<keyword>RRDP</keyword>		<keyword>RRDP</keyword>
	<abstract>		<abstract>
	<t>		<t>
	This document describes a Same-Origin Policy (SOP) requirement for RPKI		This document describes a Same-Origin Policy (SOP) requirement for Resou
	Repository Delta Protocol (RRDP) servers and clients.		rce Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) servers an
	Application of SOP in RRDP client/server communication isolates resource		d clients.
	s such as Delta and Snapshot files from different Repository Servers, reducing p		Application of a SOP in RRDP client/server communication isolates resour
	ossible attack vectors.		ces such as Delta and Snapshot files from different Repository Servers, reducing
			possible attack vectors.
	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>
	This document specifies a Same-origin policy (SOP) requirement for RPKI Repository Delta Protocol (RRDP) servers and clients.		This document specifies a Same-Origin Policy (SOP) requirement for RPKI Repository Delta Protocol (RRDP) servers and clients.
	The SOP concept is a security mechanism to restrict how a document loade d from one origin can cause interaction with resources from another origin.		The SOP concept is a security mechanism to restrict how a document loade d from one origin can cause interaction with resources from another origin.
	See <xref target="RFC6454"/> for an overview of the concept of an "origi n".		See <xref target="RFC6454"/> for an overview of the concept of an "origi n".
	Application of SOP in RRDP client/server communication isolates resource		Application of a SOP in RRDP client/server communication isolates resour
	s such as Delta and Snapshot files from different Repository Servers, reducing p		ces such as Delta and Snapshot files from different Repository Servers, reducing
	ossible attack vectors.		possible attack vectors.
	Another way to avoid undesirable implications (as described in <xref tar		Another way to avoid undesirable implications (as described in <xref tar
	get="issue"/>) would be for a future version of the RRDP protocol to use relativ		get="issue"/>) would be for a future version of RRDP to use relative URIs instea
	e URIs instead of absolute URIs.		d of absolute URIs.
	This document updates <xref target="RFC8182"/>.		This document updates <xref target="RFC8182"/>.
	</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 4>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14 >SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<b cp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14 >" in this document are to be interpreted as described in BCP&nbsp;14 <xref targ et="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp1 4>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14 >SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<b cp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14 >" in this document are to be interpreted as described in BCP&nbsp;14 <xref targ et="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="Implications of cross-origin resource requests in RRDP" anch		<section anchor="issue">
	or="issue">		<name>Implications of Cross-Origin Resource Requests in RRDP</name>
	<t>		<t>
	The first RRDP protocol specification did not explicitly disallow 'cross -origin' URI references from the Update Notification file (<xref target="RFC8182 " section="3.5.1"/>) towards Delta (<xref target="RFC8182" section="3.5.3"/>) an d Snapshot (<xref target="RFC8182" section="3.5.2"/>) files, and was silent on t he topic of HTTP Redirection (<xref target="RFC9110" section="15.4"/>).		The first RRDP specification did not explicitly disallow 'cross-origin' URI references from the Update Notification file (<xref target="RFC8182" section ="3.5.1"/>) towards Delta (<xref target="RFC8182" section="3.5.3"/>) and Snapsho t (<xref target="RFC8182" section="3.5.2"/>) files, and it was silent on the top ic of HTTP Redirection (<xref target="RFC9110" section="15.4"/>).
	</t>		</t>
	<t>		<t>
	The implication of cross-origin references in Update Notification files is that one Repository Server can reference RRDP resources on another Repository Server and in doing so inappropriately increase the resource consumption for bo th RRDP clients and the referenced Repository Server.		The implication of cross-origin references in Update Notification files is that one Repository Server can reference RRDP resources on another Repository Server and in doing so inappropriately increase the resource consumption for bo th RRDP clients and the referenced Repository Server.
	An adversary could also employ cross-origin HTTP Redirects towards other Repository Servers, causing similar undesirable behavior.		An adversary could also employ cross-origin HTTP Redirects towards other Repository Servers, causing similar undesirable behavior.
	</t>		</t>
	</section>		</section>
	<section title="Changes to RFC 8182">		<section>
			<name>Changes to RFC 8182</name>
	<t>		<t>
	To overcome the aforementioned issue described in <xref target="issue"/> , RRDP Repository Servers and Clients MUST apply a Same-Origin Policy to both th e URIs referenced in an Update Notification File and any HTTP Redirects.		To overcome the issue described in <xref target="issue"/>, RRDP Reposito ry Servers and Clients <bcp14>MUST</bcp14> apply a Same-Origin Policy to both th e URIs referenced in an Update Notification File and any HTTP Redirects.
	</t>		</t>
	<section title="New Requirements for RRDP Repository Servers">		<section>
			<name>New Requirements for RRDP Repository Servers</name>
	<t>		<t>
	The following checklist items are added to <xref target="RFC8182" sect ion="3.5.1.3"/>:		The following checklist items are added to <xref target="RFC8182" sect ion="3.5.1.3"/>:
	</t>		</t>
	<t>NEW</t>		<t>NEW</t>
	<blockquote>		<blockquote>
	<ul>		<ul spacing="normal">
	<li>		<li>The "uri" attribute in the snapshot element and optional delta
	The "uri" attribute in the snapshot element and optional delta ele		elements <bcp14>MUST</bcp14> be part of the same origin (i.e.,
	ments MUST be part of the same origin (i.e., represent the same principal), mean		represent the same principal), meaning referenced URIs
	ing referenced URIs MUST have the same scheme, host, and port as the URI for the		<bcp14>MUST</bcp14> have the same scheme, host, and port as the
	Update Notification File specified in the referring RRDP SIA AccessDescription.		URI for the Update Notification File specified in the referring
	</li>		RRDP SIA AccessDescription.</li>
	<li>		<li>The Repository Server <bcp14>MUST NOT</bcp14> respond with
	The Repository Server MUST NOT respond with HTTP Redirects towards		HTTP Redirects towards locations with an origin different from the
	locations with an origin different from the origin of the Update Notification F		origin of the Update Notification File specified in the referring
	ile specified in the referring RRDP SIA AccessDescription.		RRDP SIA AccessDescription.</li>
	</li>
	</ul>		</ul>
	</blockquote>		</blockquote>
	</section>		</section>
	<section title="New Requirements for Relying Parties using RRDP">		<section>
			<name>New Requirements for Relying Parties Using RRDP</name>
	<t>		<t>
	The following adds to <xref target="RFC8182" section="3.4.1"/>:		The following adds to <xref target="RFC8182" section="3.4.1"/>:
	</t>		</t>
	<t>NEW</t>		<t>NEW</t>
	<blockquote>		<blockquote>
	<ul>		<ul spacing="normal">
	<li>		<li>The Relying Party <bcp14>MUST</bcp14> verify whether the
	The Relying Party MUST verify whether the "uri" attributes in the		"uri" attributes in the Update Notification File are of the same
	Update Notification File are of the same origin as the Update Notification File		origin as the Update Notification File itself. If this
	itself.		verification fails, the file <bcp14>MUST</bcp14> be rejected and
	If this verification fails, the file MUST be rejected and RRDP can		RRDP cannot be used; see Section <xref target="RFC8182" section="3.4
	not be used, see <xref target="RFC8182" section="3.4.5"/> for considerations.		.5" sectionFormat="bare"/>
	Implementations SHOULD log a message when cross-origin referrals a		for considerations. Implementations <bcp14>SHOULD</bcp14> log a
	re detected.		message when cross-origin referrals are detected.
	</li>		</li>
	<li>		<li>The Relying Party <bcp14>MUST NOT</bcp14> follow HTTP
	The Relying Party MUST NOT follow HTTP Redirection following from		Redirection that results from attempts to download Update
	attempts to download Update Notification, Delta, and Snapshot files if the targe		Notification, Delta, and Snapshot files if the target origin is
	t origin is different from the origin of the Update Notification File specified		different from the origin of the Update Notification File
	in the referring RRDP SIA AccessDescription.		specified in the referring RRDP SIA AccessDescription. If this
	If this verification fails, the RRDP session MUST be rejected and		verification fails, the RRDP session <bcp14>MUST</bcp14> be
	RRDP cannot be used, see <xref target="RFC8182" section="3.4.5"/> for considerat		rejected and RRDP cannot be used; see Section <xref target="RFC8182"
	ions.		section="3.4.5" sectionFormat="bare"/> for considerations. Implemen
	Implementations SHOULD log a message when cross-origin redirects a		tations
	re detected.		<bcp14>SHOULD</bcp14> log a message when cross-origin redirects
			are detected.
	</li>		</li>
	</ul>		</ul>
	</blockquote>		</blockquote>
	</section>		</section>
	</section>		</section>
	<section title="Deployability in the Internet&apos;s current RPKI">		<section>
			<name>Deployability in the Internet's Current RPKI</name>
	<t>		<t>
	Analysing the <xref target="rpkiviews"/> archives for the period from Ap		Analyzing the <xref target="rpkiviews"/> archives for the period from Ap
	ril to September 2024, only one RRDP server (reached following the TALs of the f		ril to September 2024, only one RRDP server (reached following the Trust Anchor
	ive Regional Internet Registries) employed a same-origin HTTP redirect.		Locators (TALs) of the five Regional Internet Registries) employed a same-origi
	In the period October 2021 - October 2024 no RRDP Repository Servers wer		n HTTP redirect.
	e observed which employed cross-origin URIs in Update Notification Files.		In the period October 2021 - October 2024 no RRDP Repository Servers wer
			e observed that employed cross-origin URIs in Update Notification Files.
	</t>		</t>
	<t>		<t>
	This means that imposing a requirement for the application of a Same-Ori gin Policy does not cause any existing commonly-used RRDP Repository Server oper ations to become non-compliant.		This means that imposing a requirement for the application of a Same-Ori gin Policy does not cause any existing commonly used RRDP Repository Server oper ations to become non-compliant.
	</t>		</t>
	</section>		</section>
	<section anchor="security">		<section anchor="security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	This document addresses an oversight in the original RRDP protocol speci fication: cross-origin requests are detrimental as they allow one repository ope rator to increase resource consumption for other repository operators and RRDP c lients.		This document addresses an oversight in the original RRDP specification: Cross-origin requests are detrimental as they allow one repository operator to increase resource consumption for other repository operators and RRDP clients.
	</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>
	<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.6
	FC.6454.xml"/>		454.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"/>
	<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.9110.xml"/>		110.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="rpki-client" target="https://www.rpki-client.org/">		<reference anchor="rpkiviews" target="https://www.rpkiviews.org">
	<front>
	<title>rpki-client</title>
	<author fullname="Claudio Jeker"/>
	<author fullname="Job Snijders"/>
	<author fullname="Kristaps Dzonsons"/>
	<author fullname="Theo Buehler"/>
	<date/>
	</front>
	</reference>
	<reference anchor="rpki-prover" target="https://github.com/lolepezy/rpki
	-prover">
	<front>
	<title>rpki-prover</title>
	<author fullname="Mikhail Puzanov"/>
	<date/>
	</front>
	</reference>
	<reference anchor="FORT-validator" target="https://fortproject.net/en/val
	idator">
	<front>
	<title>FORT validator</title>
	<author fullname="Alberto Leiva"/>
	<date/>
	</front>
	</reference>
	<reference anchor="Routinator" target="https://github.com/NLnetLabs/rout
	inator/">
	<front>
	<title>Routinator</title>
	<author>
	<organization>NLNet Labs</organization>
	</author>
	<date/>
	</front>
	</reference>
	<reference anchor="rpkiviews" target="http://www.rpkiviews.org/">
	<front>		<front>
	<title>rpkiviews</title>		<title>rpkiviews</title>
	<author fullname="Job Snijders"/>		<author fullname="Job Snijders" initials="J" surname="Snijders"/>
	<date month="October" year="2024" />		<date/>
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="acknowledgements">		<section anchor="acknowledgements" numbered="false">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t>		<t>
	The author wishes to thank		The author wishes to thank
	<contact fullname="Theo Buehler"/>,		<contact fullname="Theo Buehler"/>,
	<contact fullname="Claudio Jeker"/>,		<contact fullname="Claudio Jeker"/>,
	<contact fullname="Alberto Leiva"/>,		<contact fullname="Alberto Leiva"/>,
	<contact fullname="Tim Bruijnzeels"/>,		<contact fullname="Tim Bruijnzeels"/>,
	<contact fullname="Ties de Kock"/>,		<contact fullname="Ties de Kock"/>,
	<contact fullname="Martin Hoffmann"/>,		<contact fullname="Martin Hoffmann"/>,
	and		and
	skipping to change at line 248 ¶		skipping to change at line 213 ¶
	<contact fullname="Niclas Comstedt "/>,		<contact fullname="Niclas Comstedt "/>,
	<contact fullname="Dan Harkins"/>,		<contact fullname="Dan Harkins"/>,
	<contact fullname="Erik Kline"/>,		<contact fullname="Erik Kline"/>,
	<contact fullname="Roman Danyliw"/>,		<contact fullname="Roman Danyliw"/>,
	and		and
	<contact fullname="Éric Vyncke"/>		<contact fullname="Éric Vyncke"/>
	for their review.		for their review.
	</t>		</t>
	</section>		</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>
	<li>
	OpenBSD's <xref target="rpki-client"/>
	</li>
	<li>
	Mikhail Puzanov's <xref target="rpki-prover"/>
	</li>
	<li>
	FORT project's <xref target="FORT-validator"/>
	</li>
	<li>
	NLNet Labs' <xref target="Routinator"/>
	</li>
	</ul>
	</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 31 change blocks.
	182 lines changed or deleted		94 lines changed or added
This html diff was produced by rfcdiff 1.48.