Diff: rfc8897xml2.original.xml

	rfc8897xml2.original.xml	rfc8897.xml

	<?xml version="1.0"?>	<?xml version="1.0" encoding="utf-8"?>
	<!-- This template is for creating an Internet Draft using xml2rfc,	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	which is available here: http://xml.resource.org. -->
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!-- One method to get references from the online citation libraries.
	There has to be one entity for each item to be referenced.
	An alternate method (rfc include) is described in the references. -->

	<!ENTITY RFC2535 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.2535.xml">
	<!ENTITY RFC3779 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.3779.xml">
	<!ENTITY RFC4301 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.4301.xml">
	<!ENTITY RFC5280 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.5280.xml">
	<!ENTITY RFC6480 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6480.xml">
	<!ENTITY RFC6481 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6481.xml">
	<!ENTITY RFC6482 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6482.xml">
	<!ENTITY RFC6486 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6486.xml">
	<!ENTITY RFC6487 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6487.xml">
	<!ENTITY RFC6488 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6488.xml">
	<!ENTITY RFC6489 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6489.xml">
	<!ENTITY RFC6493 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6493.xml">
	<!ENTITY RFC6810 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6810.xml">
	<!ENTITY RFC6916 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6916.xml">
	<!ENTITY RFC6480 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6480.xml">
	<!ENTITY RFC7935 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.7935.xml">
	<!ENTITY RFC8182 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8182.xml">
	<!ENTITY RFC8208 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8208.xml">
	<!ENTITY RFC8209 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8209.xml">
	<!ENTITY RFC8210 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8210.xml">
	<!ENTITY RFC8360 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8360.xml">
	<!ENTITY RFC8211 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8211.xml">
	<!ENTITY RFC8416 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8416.xml">
	<!ENTITY RFC8630 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8630.xml">
	<!ENTITY RFC8634 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8634.xml">

	]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<?rfc tocappendix="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="3"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<?rfc comments="no" ?>
	<?rfc inline="yes" ?>
	<rfc category="info" docName="draft-ietf-sidrops-rp-06" ipr="trust200902">


		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
		docName="draft-ietf-sidrops-rp-06" number="8897" ipr="trust200902" obsolete
		s=""
		updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
		tocDepth="3" symRefs="true" sortRefs="true" version="3"
		consensus="true">
		<!-- xml2rfc v2v3 conversion 2.44.0 -->
	<front>	<front>

		<title abbrev="RPKI RP Requirements">Requirements for Resource Public Key
	<title abbrev="RPKI RP Requirements">Requirements for Resource Public Key In	Infrastructure (RPKI) Relying Parties</title>
	frastructure (RPKI) Relying Parties</title>	<seriesInfo name="RFC" value="8897"/>

	<author fullname="Di Ma" initials="D." surname="Ma">	<author fullname="Di Ma" initials="D." surname="Ma">
	<organization>ZDNS</organization>	<organization>ZDNS</organization>
	<address>	<address>
	<postal>	<postal>
	<street>4 South 4th St. Zhongguancun</street>	<street>4 South 4th St. Zhongguancun</street>
	<city>Haidian</city>	<city>Haidian</city>
	<code>100190</code>	<code>100190</code>
	<region>Beijing</region>	<region>Beijing</region>
	<country>China</country>	<country>China</country>
	</postal>	</postal>

	skipping to change at line 83 ¶	skipping to change at line 27 ¶
	<postal>	<postal>
	<street>4 South 4th St. Zhongguancun</street>	<street>4 South 4th St. Zhongguancun</street>
	<city>Haidian</city>	<city>Haidian</city>
	<code>100190</code>	<code>100190</code>
	<region>Beijing</region>	<region>Beijing</region>
	<country>China</country>	<country>China</country>
	</postal>	</postal>
	<email>madi@zdns.cn</email>	<email>madi@zdns.cn</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Stephen Kent" initials="S." surname="Kent">	<author fullname="Stephen Kent" initials="S." surname="Kent">
	<organization>Independent</organization>	<organization>Independent</organization>
	<address>	<address>
	<email>kent@alum.mit.edu</email>	<email>kent@alum.mit.edu</email>
	</address>	</address>
	</author>	</author>

		<date month="August" year="2020"/>
	<date/>

	<!-- Meta-data Declarations -->	<!-- Meta-data Declarations -->

	<area>Routing Area</area>	<area>Routing Area</area>
	<workgroup>SIDROPS</workgroup>	<workgroup>SIDROPS</workgroup>

		<keyword>dns</keyword>
	<!-- <keyword>dns</keyword> -->

	<abstract>	<abstract>

	<t>This document provides a single reference point for requirements for	<!-- [rfced] ADs, the authors provided an XML file that contained some updates
	Relying Party (RP) software for use in the Resource Public Key Infrastructure (R	with the following note:
	PKI) in the context of securing Internet routing. It cites requirements that ap
	pear in several RPKI RFCs, making it easier for implementers to become aware of
	these requirements that are segmented with orthogonal functionalities.</t>
	</abstract>

	</front>

	<middle>

	<section title="Introduction">
	<t>The RPKI Relying Party (RP) software is used by network operators and othe
	rs to acquire and verify Internet Number Resource (INR) data stored in the RPKI
	repository system. RPKI data, when verified, allow an RP to verify assertions a
	bout which Autonomous Systems (ASes) are authorized to originate routes for IP a
	ddress prefixes. RPKI data also establishes binding between public keys and BGP
	routers, and indicates the AS numbers that each router is authorized to represe
	nt.</t>
	<t>Noting that the essential requirements imposed on RPs to support securing
	Internet routing (<xref target="RFC6480" />) are scattered throughout numerous R
	FC documents that are protocol specific or provide best practices, as follows:</
	t>
	<t>
	RFC 6481 (Repository Structure)
	<vspace />
	RFC 6482 (ROA format)
	<vspace />
	RFC 6486 (Manifests)
	<vspace />
	RFC 6487 (Certificate and CRL profile)
	<vspace />
	RFC 6488 (RPKI Signed Objects)
	<vspace />
	RFC 6489 (Key Rollover)
	<vspace />
	RFC 6810 (RPKI to Router Protocol)
	<vspace />
	RFC 6916 (Algorithm Agility)
	<vspace />
	RFC 7935 (Algorithms)
	<vspace />
	RFC 8209 (Router Certificates)
	<vspace />
	RFC 8210 (RPKI to Router Protocol,Version 1)
	<vspace />
	RFC 8360 (Certificate Validation Procedure)
	<vspace />
	RFC 8630 (Trust Anchor Locator)
	</t>
	<t>This makes it hard for an implementer to be confident that he/she has addr
	essed all of these generalized requirements. Besides, software engineering calls
	for how to segment the RP system into components with orthogonal functionalitie
	s, so that those components could be distributed across the operational timeline
	of the user. Taxonomy of generalized RP requirements is going to help have ‘the
	role of the RP’ well framed.</t>
	<t>To consolidate RP requirements in one document, with pointers to all the r
	elevant RFCs, this document outlines a set of baseline requirements imposed on R
	Ps and provides a single reference point for requirements for RP software for us
	e in the RPKI, as segmented with orthogonal functionalities:</t>
	<t>
	• Fetching and Caching RPKI Repository Objects
	<vspace />
	• Processing Certificates and CRLs
	<vspace />
	• Processing RPKI Repository Signed Objects
	<vspace />
	• Distributing Validated Cache of the RPKI Data</t>
	<t>This document will be update to reflect new or changed requirements as the
	se RFCs are updated, or new RFCs are written.</t>
	</section>

	<section title="Fetching and Caching RPKI Repository Objects">


	<t>RP software uses synchronization mechanisms supported by targeted reposit	We authors made some wording improvements according to the comments from
	ories (e.g., <xref target="rsync" />, RRDP <xref target="RFC8182" />) to downloa	some of the IESG members, and further edits that are intended to improve
	d all RPKI changed data objects in the repository system and cache them locally.	readability.
	The software validates the RPKI data and uses it to generate authenticated data
	identifying which ASes are authorized to originate routes for address prefixes,
	and which routers are authorized to sign BGP updates on behalf of ASes.</t>


	<section title="TAL Acquisition and Processing">	All of those edits do not change the technical content.
	<t>In the RPKI, each RP chooses its own set of trust anchors (TAs). Consiste
	nt with the extant INR allocation hierarchy, the IANA and/or the five RIRs are o
	bvious candidates to be default TAs for the RP.</t>
	<t>An RP does not retrieve TAs directly. A set of Trust Anchor Locators (TAL
	s) is used by each RP to retrieve and verify the authenticity of each TA.</t>
	<t>TAL acquisition and processing are specified in Section 3 of <xref target
	="RFC8630" />.</t>
	</section>


	<section title="Locating RPKI Objects Using Authority and Subject Informatio	Please review the updates and let us know if you approve. The changes can be
	n Extensions">	viewed in this diff, which compares the I-Ds:
	<t>The RPKI repository system is a distributed one, consisting of multip	https://www.rfc-editor.org/authors/rfc8897-0607-rfcdiff.html
	le repository instances. Each repository instance contains one or more repositor	-->
	y publication points. An RP discovers publication points using the Subject Infor
	mation Access (SIA) and the Authority Information Access (AIA) extensions from (
	validated) certificates.</t>
	<t>Section 5 of <xref target="RFC6481" /> specifies how an RP locates all RP
	KI objects by using the SIA and AIA extensions. Detailed specifications of SIA
	and AIA extensions in a resource certificate are described in Section 4 of <xref
	target="RFC6487" />.</t>
	</section>


	<section title="Dealing with Key Rollover">	<t> This document provides a single reference point for requirements for
	<t>An RP takes the key rollover period into account with regard to its frequ	Relying Party (RP) software for use in the Resource Public Key
	ency of synchronization with RPKI repository system.</t>	Infrastructure (RPKI). It cites requirements that appear in several RPKI
	<t>RP requirements in dealing with key rollover are described in Section 3 o	RFCs, making it easier for implementers to become aware of these
	f <xref target="RFC6489" /> and Section 3 of <xref target="RFC8634" />.</t>	requirements. This RFC will be updated to reflect changes to the
	</section>	requirements and guidance specified in the RFCs discussed herein.</t>
		</abstract>
		</front>
		<middle>
		<section numbered="true" toc="default">
		<name>Introduction</name>
		<t>RPKI Relying Party (RP) software is used by network operators and
		others to acquire and verify Internet Number Resource (INR) data
		stored in the RPKI repository system. RPKI data, when verified,
		allows an RP to verify assertions about which Autonomous Systems
		(ASes) are authorized to originate routes for IP address prefixes.
		RPKI data also establishes a binding between public keys and BGP
		routers and indicates the AS numbers that each router is authorized
		to represent.</t>


	<section title="Dealing with Algorithm Transition">	<t>The essential requirements imposed on RP software to support
	<t>The set of cryptographic algorithms used with the RPKI is expected to cha	secure Internet routing <xref target="RFC6480" format="default"/> are
	nge over time. Each RP is expected to be aware of the milestones established for	scattered throughout numerous protocol-specific RFCs and Best Current
	the algorithm transition and what actions are required at every juncture.</t>	Practice RFCs. The following RFCs define these
	<t>RP requirements for dealing with algorithm transition are specified in Se	requirements:</t>
	ction 4 of <xref target="RFC6916" />.</t>	<ul spacing="normal">
		<li><xref target="RFC6481" format="default"/> (Repository Structure)</li>
		<li><xref target="RFC6482" format="default"/> (ROA format)</li>
		<li><xref target="RFC6486" format="default"/> (Manifests)</li>
		<li><xref target="RFC6487" format="default"/> (Certificate and CRL profil
		e)</li>
		<li><xref target="RFC6488" format="default"/> (RPKI Signed Objects)</li>
		<li><xref target="RFC6489" format="default"/> (Key Rollover)</li>
		<li><xref target="RFC6810" format="default"/> (RPKI to Router Protocol)</
		li>
		<li><xref target="RFC6916" format="default"/> (Algorithm Agility)</li>
		<li><xref target="RFC7935" format="default"/> (Algorithms)</li>
		<li><xref target="RFC8209" format="default"/> (Router Certificates)</li>
		<li><xref target="RFC8210" format="default"/> (RPKI to Router Protocol,Ve
		rsion 1)</li>
		<li><xref target="RFC8360" format="default"/> (Certificate Validation Pro
		cedure)</li>
		<li><xref target="RFC8630" format="default"/> (Trust Anchor Locator)</li
		>
		</ul>
		<t>The distribution of RPKI RP requirements across these 13 documents
		makes it hard for an implementer to be confident that he/she has
		addressed all of these requirements. Additionally, good software
		engineering practice may call for segmenting the RP system into
		components with orthogonal functionalities so that those components may
		be distributed. A taxonomy of the collected RP software requirements
		can help clarify the role of the RP.</t>
		<t>To consolidate RP software requirements in one document, with
		pointers to all the relevant RFCs, this document outlines a set of
		baseline requirements imposed on RPs and provides a single reference
		point for requirements for RP software for use in the RPKI. The requirements
		are organized into four groups:</t>
		<ul spacing="normal">
		<li>Fetching and Caching RPKI Repository Objects</li>
		<li>Processing Certificates and Certificate Revocation Lists (CRLs)</li>
		<li>Processing RPKI Repository Signed Objects</li>
		<li>Distributing Validated Cache of the RPKI Data</li>
		</ul>
		<t>This document will be updated to reflect new or changed requirements
		as these RFCs are updated or additional RFCs are written.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Strategies for Efficient Cache Maintenance">	<name>Fetching and Caching RPKI Repository Objects</name>
	<t>Each RP is expected to maintain a local cache of RPKI objects. The cache	<t>RP software uses synchronization mechanisms supported by targeted
	needs to be as up to date and consistent with repository publication point data	repositories (e.g., <xref target="rsync" format="default"/> or RRDP <xref
	as the RP’s frequency of checking permits.</t>	target="RFC8182" format="default"/>)
	<t>The last paragraph of Section 5 of <xref target="RFC6481" /> provides gui	to download RPKI signed objects from the repository system in order to
	dance for maintenance of a local cache.</t>	update a local cache. These mechanisms download only those objects that
		have been added or replaced with new versions since the time when the
		RP most recently checked the repository.
		RP software validates the RPKI data and uses it to
		generate authenticated data identifying which ASes are authorized to
		originate routes for address prefixes and which routers are
		authorized to sign BGP updates on behalf of specified ASes.</t>
		<section numbered="true" toc="default">
		<name>TAL Configuration and Processing</name>
		<t>In the RPKI, each RP chooses a set of trust anchors
		(TAs). Consistent with the extant INR allocation hierarchy, the IANA
		and/or the five Regional Internet Registries (RIRs) are obvious
		candidates to be default TAs for the RP.</t>
		<t>An RP does not retrieve TAs directly. A set of Trust Anchor
		Locators (TALs) is used by RP software to retrieve and verify the
		authenticity of each TA.</t>
		<t>TAL configuration and processing are specified in <xref
		target="RFC8630" sectionFormat="of" section="3"/>.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Locating RPKI Objects Using Authority and Subject Information Exte
		nsions</name>
		<t>The RPKI repository system is a distributed one, consisting of
		multiple repository instances. Each repository instance contains one
		or more repository publication points. RP software discovers publication
		points using the Subject Information Access (SIA) and the Authority
		Information Access (AIA) extensions from (validated) certificates.</t>
		<t><xref target="RFC6481" sectionFormat="of" section="5"/> specifies ho
		w RP software
		locates all RPKI objects by using the SIA and AIA extensions.
		Detailed specifications of SIA and AIA extensions in a resource
		certificate are described in Sections <xref target="RFC6487"
		sectionFormat="bare" section="4.8.8"/> and <xref target="RFC6487"
		sectionFormat="bare" section="4.8.7"/> of <xref target="RFC6487"
		format="default"/>, respectively.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Dealing with Key Rollover</name>
		<t>RP software takes the key rollover period into account with regard to
		its
		frequency of synchronization with the RPKI repository system.</t>
		<t>RP software requirements for dealing with key rollover are
		described in <xref target="RFC6489" sectionFormat="of" section="3"/>
		and <xref target="RFC8634" sectionFormat="of" section="3"/>.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Dealing with Algorithm Transition</name>
		<t>The set of cryptographic algorithms used with the RPKI is expected to
		change over time. Each RP is expected to be aware of the milestones
		established for the algorithm transition and what actions are
		required at every juncture.</t>
		<t>RP software requirements for dealing with algorithm transition are
		specified in <xref target="RFC6916" sectionFormat="of" section="4"/>.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Strategies for Efficient Cache Maintenance</name>
		<t>Each RP is expected to maintain a local cache of RPKI objects.
		The cache needs to be brought up to date and made consistent with the
		repository publication point data as frequently as allowed by
		repository publication points and by locally selected RP processing
		constraints.</t>
		<t>The last paragraph of <xref target="RFC6481"
		sectionFormat="of" section="5"/> provides
		guidance for maintenance of a local cache.</t>
		</section>
	</section>	</section>

		<section numbered="true" toc="default">
		<name>Certificate and CRL Processing</name>


	</section>	<t>The RPKI makes use of X.509 certificates and CRLs, but it profiles
		the standard formats described in <xref target="RFC6487" format="default"/
	<section title="Certificate and CRL Processing">	>. The
		major change to the profile established in <xref target="RFC5280"
	<t>The RPKI make use of X.509 certificates and CRLs, but it profiles these s	format="default"/> is the mandatory use of a new extension in RPKI
	tandard formats <xref target="RFC6487" />. The major change to the profile estab	certificates, defined in <xref target="RFC3779" format="default"/>.</t>
	lished in <xref target="RFC5280" /> is the mandatory use of a new extension to X
	.509 certificate <xref target="RFC3779" />.</t>


	<section title="Verifying Resource Certificate and Syntax">	<section numbered="true" toc="default">
	<t>Certificates in the RPKI are called resource certificates, and they are r	<name>Verifying Resource Certificate and Syntax</name>
	equired to conform to the profile <xref target="RFC6487" />. An RP is required t	<t>Certificates in the RPKI are called resource certificates, and they
	o verify that a resource certificate adheres to the profile established by Secti	are required to conform to the profile described in <xref target="RFC6487
	on 4 of <xref target="RFC6487" />. This means that all extensions mandated by Se	"
	ction 4.8 of <xref target="RFC6487" /> must be present and value of each extensi	format="default"/>. An RP is required to verify that a resource
	on must be within the range specified by this RFC. Moreover, any extension exclu	certificate adheres to the profile established by <xref
	ded by Section 4.8 of <xref target="RFC6487" /> must be omitted.</t>	target="RFC6487" sectionFormat="of" section="4"/>. This means that
	<t>Section 7.1 of <xref target="RFC6487" /> gives the procedure that the RP	all extensions mandated by <xref target="RFC6487"
	should follow to verify resource certificate and syntax.</t>	sectionFormat="of" section="4.8"/> must be present and the value of each
		extension
		must be within the range specified by <xref target="RFC6487"
		format="default"/>. Moreover, any extension excluded by
		<xref target="RFC6487" sectionFormat="of" section="4.8"/> must be omitted
		.</t>
		<t><xref target="RFC6487" sectionFormat="of" section="7.1"/> specifies
		the procedure that RP software follows when verifying extensions
		described in <xref target="RFC3779" format="default"/>.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Certificate Path Validation</name>
		<t>Initially, the INRs in the issuer's certificate are required to
		encompass the INRs in the subject's certificate. This is one of the
		necessary principles of certificate path validation in addition to
		cryptographic verification (i.e., verification of the signature on
		each certificate using the public key of the parent certificate).</t>
		<t><xref target="RFC6487" sectionFormat="of" section="7.2"/> specifies
		the procedure that RP software should follow to perform certificate
		path validation.</t>
		<t>Certification Authorities (CAs) that want to reduce aspects of
		operational fragility will migrate to the new OIDs <xref
		target="RFC8360" format="default"/>, informing RP software to use an
		alternative RPKI validation algorithm. An RP is expected to support
		the amended procedure to handle accidental overclaiming, which is
		described in <xref target="RFC8360" sectionFormat="of" section="4"/>.</t>
		</section>
		<section numbered="true" toc="default">
		<name>CRL Processing</name>
		<t>The CRL processing requirements imposed on CAs and RPs are described
		in <xref target="RFC6487" sectionFormat="of" section="5"/>. CRLs in
		the RPKI are tightly constrained; only the AuthorityKeyIndentifier
		(<xref target="RFC6487" sectionFormat="of" section="4.8.3"/>) and
		CRLNumber (<xref target="RFC5280" sectionFormat="of" section="5.2.3"/>)
		extensions are allowed, and they are required to be present. No other
		CRL extensions are allowed, and no CRLEntry extensions are permitted.
		RP software is required to verify that these constraints have been
		met. Each CRL in the RPKI must be verified using the public key from
		the certificate of the CA that issued the CRL.</t>
		<t>In the RPKI, RPs are expected to pay extra attention when dealing
		with a CRL that is not consistent with the manifest associated with
		the publication point associated with the CRL.</t>
		<t>Processing of a CRL that is not consistent with a manifest is a
		matter of local policy, as described in the fifth paragraph of <xref
		target="RFC6486" sectionFormat="of" section="6.6"/>.</t>
		</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Certificate Path Validation">	<name>Processing RPKI Repository Signed Objects</name>
	<t>The INRs in issuer’s certificate are required to encompass the INRs in th	<section numbered="true" toc="default">
	e subject’s certificate. This is one of necessary principles of certificate path	<name>Basic Signed Object Syntax Checks</name>
	validation in addition to cryptographic verification i.e., verification of the	<t>Before an RP can use a signed object from the RPKI repository, RP sof
	signature on each certificate using the public key of the parent certificate).</	tware
	t>	is required to check the signed-object syntax.</t>
	<t>Section 7.2 of <xref target="RFC6487" /> gives the procedure that the RP	<t><xref target="RFC6488" sectionFormat="of" section="3"/> lists all
	should follow to perform certificate path validation.</t>	the steps that RP software is required to execute in order to validate
	<t>Certificate Authorities that want to reduce aspects of operational fragil	the top-level syntax of a repository signed object.</t>
	ity will migrate to the new OIDs <xref target="RFC8360" />, informing the RP of	<t>Note that these checks are necessary but not sufficient.
	using an alternative RPKI validation algorithm. An RP is expected to support the	Additional validation checks must be performed based on the specific
	amended procedure to handle with accidental over-claim.</t>	type of signed object, as described in <xref target="syntax"
		format="default"/>.</t>
		</section>
		<section anchor="syntax" numbered="true" toc="default">
		<name>Syntax and Validation for Each Type of Signed Object</name>
		<section numbered="true" toc="default">
		<name>Manifest</name>
		<t>To determine whether a manifest is valid, RP software is required
		to perform manifest-specific checks in addition to the generic
		signed-object checks specified in <xref target="RFC6488"
		format="default"/>.</t>
		<t>Specific checks for a manifest are described in <xref
		target="RFC6486" sectionFormat="of" section="4"/>. If any of these
		checks fail, indicating that the manifest is invalid, then the
		manifest will be discarded, and RP software will act as though no
		manifest were present.</t>
		</section>
		<section numbered="true" toc="default">
		<name>ROA</name>
		<t>To validate a Route Origin Authorization (ROA), RP software is
		required to perform all the checks specified in <xref
		target="RFC6488" format="default"/> as well as additional,
		ROA-specific validation steps. The IP Address Delegation extension
		<xref target="RFC3779" format="default"/> present in the end-entity
		(EE) certificate (contained within the ROA) must encompass each of
		the IP address prefix(es) in the ROA.</t>
		<t>More details for ROA validation are specified in <xref
		target="RFC6482" sectionFormat="of" section="4"/>.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Ghostbusters</name>
		<t>The Ghostbusters Record is optional; a publication point in the RPK
		I
		can have zero or more associated Ghostbusters Records. If a CA has at
		least one Ghostbusters Record, RP software is required to verify that this
		Ghostbusters Record conforms to the syntax of signed objects defined
		in <xref target="RFC6488" format="default"/>.</t>
		<t>The payload of this signed object is a (severely) profiled
		vCard. RP software is required to verify that the payload of
		Ghostbusters conforms to format as profiled in <xref
		target="RFC6493" format="default"/>.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Verifying BGPsec Router Certificate</name>
		<t>A BGPsec Router Certificate is a resource certificate, so it is
		required to comply with <xref target="RFC6487" format="default"/>.
		Additionally, the certificate must contain an AS Identifier
		Delegation extension (<xref target="RFC6487" sectionFormat="of"
		section="4.8.11"/>) and must not contain an IP Address Delegation
		extension (<xref target="RFC6487" sectionFormat="of"
		section="4.8.10"/>). The validation procedure used for BGPsec
		Router Certificates is analogous to the validation procedure
		described in <xref target="RFC6487" sectionFormat="of"
		section="7"/>, but it uses the constraints defined in <xref
		target="RFC8209" sectionFormat="of" section="3"/>.</t>
		<t>Note that the cryptographic algorithms used by BGPsec routers are
		found in <xref target="RFC8608" format="default"/>. Currently, the
		algorithms specified in <xref target="RFC8608" format="default"/>
		and <xref target="RFC7935" format="default"/> are different. BGPsec
		RP software will need to support algorithms that are used to
		validate BGPsec signatures as well as the algorithms that are needed
		to validate signatures on BGPsec certificates, RPKI CA certificates,
		and RPKI CRLs.</t>
		</section>
		</section>
		<section numbered="true" toc="default">
		<name>How to Make Use of Manifest Data</name>
		<t>For a given publication point, RP software ought to perform tests,
		as specified in <xref target="RFC6486" sectionFormat="of"
		section="6.1"/>, to determine the state of the manifest at the
		publication point. A manifest can be classified as either valid or
		invalid, and a valid manifest is either current or stale. An RP
		decides how to make use of a manifest based on its state, according to
		local (RP) policy.</t>
		<t>If there are valid objects in a publication point that are not
		present on a manifest, <xref target="RFC6486" format="default"/> does
		not mandate specific RP behavior with respect to such objects.</t>
		<t>In the absence of a manifest, an RP is expected to accept all valid
		signed objects present in the publication point (see <xref
		target="RFC6486" sectionFormat="of" section="6.2"/>). If a manifest is
		stale or invalid and an RP has no way to acquire a more recent valid
		manifest, the RP is expected to contact the repository manager via
		Ghostbusters Records and thereafter make decisions according to local
		(RP) policy (see Sections <xref target="RFC6486"
		sectionFormat="bare" section="6.3"/> and <xref target="RFC6486"
		sectionFormat="bare" section="6.4"/> of <xref target="RFC6486" format="de
		fault"/>).</t>
		</section>
		<section numbered="true" toc="default">
		<name>What To Do with Ghostbusters Information</name>
		<t>RP software may encounter a stale manifest or CRL, or an expired CA
		certificate or ROA at a publication point. An RP is expected to use
		the information from the Ghostbusters Records to contact the maintainer
		of the publication point where any stale/expired objects were
		encountered. The intent here is to encourage the relevant CA and/or
		repository manager to update the stale or expired objects.</t>
		</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="CRL Processing">	<name>Distributing Validated Cache</name>
	<t>The CRL processing requirements imposed on CAs and RP are described in Se	<t>On a periodic basis, BGP speakers within an AS request updated
	ction 5 of <xref target="RFC6487" />. CRLs in the RPKI are tightly constrained;	validated origin AS data and router/ASN data from the (local) validated cache
	only the AuthorityKeyIndetifier and CRLNumber extensions are allowed, and they a	of RPKI data.
	re required to be present. No other CRL extensions are allowed, and no CRLEntry	The RP may either transfer the validated data to the BGP speakers directly,
	extensions are permitted. RPs are required to verify that these constraints have	or it may transfer the validated data to a cache server that is responsible
	been met. Each CRL in the RPKI must be verified using the public key from the c	for provisioning such data to BGP speakers. The specifications of the
	ertificate of the CA that issued the CRL.</t>	protocol designed to deliver validated cache data to a BGP Speaker are provid
		ed
	<t>In the RPKI, RPs are expected to pay extra attention when dealing with a	in <xref target="RFC6810" format="default"/> and <xref target="RFC8210" forma
	CRL that is not consistent with the Manifest associated with the publication poi	t="default"/>.</t>
	nt associated with the CRL.</t>
	<t>Processing of a CRL that is not consistent with a manifest is a matter of
	local policy, as described in the fourth paragraph of Section 6.6 of <xref targ
	et="RFC6486" />.</t>
	</section>	</section>

	</section>	<section numbered="true" toc="default">
		<name>Local Control</name>
	<section title="Processing RPKI Repository Signed Objects">	<t>ISPs may want to establish a local view of exceptions to the RPKI
		data in the form of local filters and additions. For instance, a
	<section title="Basic Signed Object Syntax Checks">	network operator might wish to make use of a local override
	<t>Before an RP can use a signed object from the RPKI repository, the RP	capability to protect routes from adverse actions <xref target="RFC8211" form
	is required to check the signed object syntax.</t>	at="default"/>. The
	<t>Section 3 of <xref target="RFC6488" /> lists all the steps that the R	mechanisms developed to provide this capability to network operators
	P is required to execute in order to validate the top level syntax of a reposito	are called Simplified Local Internet Number Resource Management with the
	ry signed object.</t>	RPKI (SLURM). If an ISP wants to implement SLURM, its RP system
	<t>Note that these checks are necessary, but not sufficient. Additional	can follow the instruction specified in <xref target="RFC8416" format="defaul
	validation checks must be performed based on the specific type of signed object	t"/>.</t>
	.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Syntax and Validation for Each Type of Signed Object">	<name>Security Considerations</name>
		<t>This document does not introduce any new security considerations; it
	<section title="Manifest">	is a resource for implementers. The RP links the RPKI provisioning
	<t>To determine whether a manifest is valid, the RP is required	side and the routing system, establishing a verified, local view of global
	to perform manifest-specific checks in addition to those specified in <xref targ	RPKI data to BGP speakers. The security of the RP is critical for exchanging
	et="RFC6488" />.</t>	BGP
	<t>Specific checks for a Manifest are described in Section 4 of	messages. Each RP implementation is expected to offer
	<xref target="RFC6486" />. If any of these checks fails, indicating that the man	cache backup management to facilitate recovery from outages.
	ifest is invalid, then the manifest will be discarded and treated as though no m	RP software should also support secure transport (e.g., IPsec <xref
	anifest were present.</t>	target="RFC4301" format="default"/>) that can protect validated cache
	</section>	delivery in an unsafe environment. This document highlights
		many validation actions applied to RPKI signed objects, an essential
	<section title="ROA">	element of secure operation of RPKI security.</t>
	<t>To validate a ROA, the RP is required perform all the checks
	specified in <xref target="RFC6488" /> as well as the additional ROA-specific va
	lidation steps. The IP address delegation extension <xref target="RFC3779" /> pr
	esent in the end-entity (EE) certificate (contained within the ROA), must encomp
	ass each of the IP address prefix(es) in the ROA.</t>
	<t>More details for ROA validation are specified in Section 4 of
	<xref target="RFC6482" />.</t>
	</section>

	<section title="Ghostbusters">
	<t>The Ghostbusters Record is optional; a publication point in t
	he RPKI can have zero or more associated Ghostbuster Records. If a CA has at lea
	st one Ghostbuster Record, RP is required to verify that this Ghostbusters Recor
	d conforms to the syntax of signed object defined in <xref target="RFC6488" />.<
	/t>
	<t>The payload of this signed object is a (severely) profiled vC
	ard. An RP is required to verify that the payload of Ghostbusters conforms to fo
	rmat as profiled in <xref target="RFC6493" />.</t>
	</section>

	<section title="Verifying BGPsec Router Certificate">
	<t>A BGPsec Router Certificate is a resource certificate, so it
	is required to comply with <xref target="RFC6487"/>. Additionally, the certifica
	te must contain an AS Identifier Delegation extension, and must not contain an I
	P Address Delegation extension. The validation procedure used for BGPsec Router
	Certificates is identical to the validation procedure described in Section 7 of
	<xref target="RFC6487" />, but using the constraints applied come from specifica
	tion of Section 7 of <xref target="RFC8209" />. </t>
	<t>Note that the cryptographic algorithms used by BGPsec routers
	are found in <xref target="RFC8208" />. Currently, the algorithms specified in
	<xref target="RFC8208" />and <xref target="RFC7935" /> are different. BGPsec RP
	s will need to support algorithms that are used to validate BGPsec signatures as
	well as the algorithms that are needed to validate signatures on BGPsec certifi
	cates, RPKI CA certificates, and RPKI CRLs.</t>
	</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="How to Make Use of Manifest Data">	<name>IANA Considerations</name>
	<t>For a given publication point, the RP ought to perform tests, as spec	<t>This document has no IANA actions.</t>
	ified in Section 6.1 of <xref target="RFC6486" />, to determine the state of the
	Manifest at the publication point. A Manifest can be classified as either valid
	or invalid, and a valid Manifest is either current and stale. An RP decides how
	to make use of a Manifest based on its state, according to local (RP) policy.</
	t>
	<t>If there are valid objects in a publication point that are not presen
	t on a Manifest, <xref target="RFC6486" /> does not mandate specific RP behavior
	with respect to such objects. However, most RP software ignores such objects an
	d the authors of this document suggest this behavior be adopted uniformly.</t>
	<t>In the absence of a Manifest, an RP is expected to accept all valid s
	igned objects present in the publication point. If a Manifest is stale or invali
	d (see <xref target="RFC6486" />) and an RP has no way to acquire a more recentl
	y valid Manifest, the RP is expected to contact the repository manager via Ghost
	busters record and thereafter make decision according to local (RP) policy.</t>
	</section>	</section>


	<section title="What to Do with Ghostbusters Information">	</middle>
	<t>An RP may encounter a stale Manifest or CRL, or an expired CA certifi	<back>
	cate or ROA at a publication point. An RP is expected to use the information fr	<references>
	om the Ghostbusters record to contact the maintainer of the publication point wh	<name>References</name>
	ere any stale/expired objects were encountered. The intent here is to encourage	<references>
	the relevant CA and/or repository manager to update the slate or expired objects	<name>Normative References</name>
	.</t>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3779.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5280.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6481.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6482.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6486.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6487.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6488.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6489.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6493.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6810.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6916.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.7935.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8608.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8209.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8210.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8360.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8630.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8634.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4301.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6480.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8182.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8211.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8416.xml"/>
		<reference anchor="rsync" target="http://rsync.samba.org/">
		<front>
		<title>rsync</title>
		<author/>
		<date/>
		</front>
		</reference>
		</references>
		</references>
		<section numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>The authors thank <contact fullname="David Mandelberg"/>, <contact
		fullname="Wei Wang"/>, <contact fullname="Tim Bruijnzeels"/>, <contact
		fullname="George Michaelson"/>, and <contact fullname="Oleg Muravskiy"/>
		for their review, feedback, and editorial assistance in preparing this
		document.</t>
	</section>	</section>


	</section>

	<section title="Distributing Validated Cache">
	<t>On a periodic basis, BGP speakers within an AS request updated validated
	origin AS data and router/ASN data from the validated cache of RPKI data. The RP
	may either transfer the validated data to the BGP speakers directly, or it may
	transfer the validated data to a cache server that is responsible for provisioni
	ng such data to BGP speakers. The specification of the protocol designed to deli
	ver validated cache data to a BGP Speaker is provided in <xref target="RFC6810"
	/> and <xref target="RFC8210" />.</t>
	</section>

	<section title="Local Control">
	<t>ISPs may want to establish a local view of exceptions to the RPKI data in
	the form of local filters and additions. For instance, a network operator might
	wish to make use of a local override capability to protect routes from adverse
	actions <xref target="RFC8211" /> . The mechanisms developed to provide this cap
	ability to network operators are called "Simplified Local Internet Number Resour
	ce Management with the RPKI (SLURM). If an ISP wants to implement SLURM, its RP
	system can follow the instruction specified in <xref target="RFC8416" /> .</t>
	</section>

	<section title="Security Considerations">
	<t>The RP links the RPKI provisioning side and the routing system, establish
	ing the local view of global RPKI data to BGP speakers. The security of the RP i
	s critical to BGP messages exchanging. The RP implementation is expected to off
	er cache backup management to facilitate recovery from outage state. The RP impl
	ementation also should support application of secure transport (e.g., IPsec <xre
	f target="RFC4301" />) that is able to protect validated cache delivery in a uns
	afe environment. </t>
	</section>

	<section title="IANA Considerations">
	<t>This document has no actions for IANA.</t>
	</section>

	<section title="Acknowledgements">
	<t>The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George Mic
	haelson and Oleg Muravskiy for their review, feedback and editorial assistance i
	n preparing this document.</t>
	</section>

	</middle>

	<back>

	<references title="Normative References">
	&RFC3779;
	&RFC5280;
	&RFC6481;
	&RFC6482;
	&RFC6486;
	&RFC6487;
	&RFC6488;
	&RFC6493;
	&RFC6810;
	&RFC7935;
	&RFC8208;
	&RFC8209;
	&RFC8210;
	&RFC8360;
	&RFC8630;
	</references>

	<references title="Informative References">
	&RFC4301;
	&RFC6480;
	&RFC6489;
	&RFC6916;
	&RFC8182;
	&RFC8211;
	&RFC8416;
	&RFC8634;

	<reference anchor="rsync" target="http://rsync.samba.org/">
	<front>
	<title>rsync web page</title>
	<author></author>
	<date />
	</front>
	</reference>

	</references>

	</back>	</back>
	</rfc>	</rfc>

End of changes. 23 change blocks.
	438 lines changed or deleted	443 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/