<?xml version="1.0"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> version="1.0" encoding="utf-8"?>
<!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" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
     docName="draft-ietf-sidrops-rp-06" ipr="trust200902"> number="8897" ipr="trust200902" obsoletes=""
     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>
    <title abbrev="RPKI RP Requirements">Requirements for Resource Public Key
    Infrastructure (RPKI) Relying Parties</title>
    <seriesInfo name="RFC" value="8897"/>
    <author fullname="Di Ma" initials="D." surname="Ma">
      <organization>ZDNS</organization>
      <address>
        <postal>
          <street>4 South 4th St. Zhongguancun</street>
          <city>Haidian</city>
          <code>100190</code>
          <region>Beijing</region>
          <country>China</country>
        </postal>
        <email>madi@zdns.cn</email>
      </address>
    </author>
    <author fullname="Stephen Kent" initials="S." surname="Kent">
      <organization>Independent</organization>
      <address>
        <email>kent@alum.mit.edu</email>
      </address>
    </author>

    <date/>
    <date month="August" year="2020"/>
    <!-- Meta-data Declarations -->

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

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

    <abstract>
        <t>This
<!-- [rfced] ADs, the authors provided an XML file that contained some updates
with the following note:

   We authors made some wording improvements according to the comments from
   some of the IESG members, and further edits that are intended to improve
   readability.

   All of those edits do not change the technical content.

Please review the updates and let us know if you approve.  The changes can be
viewed in this diff, which compares the I-Ds:
   https://www.rfc-editor.org/authors/rfc8897-0607-rfcdiff.html
-->

      <t> This document provides a single reference point for requirements for
      Relying Party (RP) software for use in the Resource Public Key
      Infrastructure (RPKI) in the context of securing Internet routing. (RPKI). It cites requirements that appear in several RPKI
      RFCs, making it easier for implementers to become aware of these
      requirements. This RFC will be updated to reflect changes to the
      requirements that are segmented with orthogonal functionalities.</t> and guidance specified in the RFCs discussed herein.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
   <t>The RPKI 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, allow
   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,
   routers and indicates the AS numbers that each router is authorized
   to represent.</t>
   <t>Noting that the

      <t>The essential requirements imposed on RPs RP software to support securing
      secure Internet routing (<xref <xref target="RFC6480" />) format="default"/> are
      scattered throughout numerous RFC documents that are protocol specific or provide best practices, as follows:</t>
   <t>
       RFC 6481 protocol-specific RFCs and Best Current
      Practice RFCs. The following RFCs define these
      requirements:</t>
      <ul spacing="normal">
       <li><xref target="RFC6481" format="default"/> (Repository Structure)
       <vspace />
       RFC 6482 Structure)</li>
       <li><xref target="RFC6482" format="default"/> (ROA format)
       <vspace />
       RFC 6486 (Manifests)
       <vspace />
       RFC 6487 format)</li>
       <li><xref target="RFC6486" format="default"/> (Manifests)</li>
       <li><xref target="RFC6487" format="default"/> (Certificate and CRL profile)
       <vspace />
       RFC 6488 profile)</li>
       <li><xref target="RFC6488" format="default"/> (RPKI Signed Objects)
       <vspace />
       RFC 6489 Objects)</li>
       <li><xref target="RFC6489" format="default"/> (Key Rollover)
       <vspace />
       RFC 6810 Rollover)</li>
       <li><xref target="RFC6810" format="default"/> (RPKI to Router Protocol)
       <vspace />
       RFC 6916 Protocol)</li>
       <li><xref target="RFC6916" format="default"/> (Algorithm Agility)
       <vspace />
       RFC 7935 (Algorithms)
       <vspace />
       RFC 8209 Agility)</li>
       <li><xref target="RFC7935" format="default"/> (Algorithms)</li>
       <li><xref target="RFC8209" format="default"/> (Router Certificates)
       <vspace />
       RFC 8210 Certificates)</li>
       <li><xref target="RFC8210" format="default"/> (RPKI to Router Protocol,Version 1)
       <vspace />
       RFC 8360 1)</li>
       <li><xref target="RFC8360" format="default"/> (Certificate Validation Procedure)
       <vspace />
       RFC 8630 Procedure)</li>
       <li><xref target="RFC8630" format="default"/>  (Trust Anchor Locator)
   </t>
   <t>This 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 generalized requirements. Besides, Additionally, good software
      engineering calls practice may call for how to segment segmenting the RP system into
      components with orthogonal functionalities, functionalities so that those components could may
      be distributed across the operational timeline distributed.  A taxonomy of the user. Taxonomy of generalized collected RP software requirements is going to
      can help have ‘the clarify the role of the RP’ well framed.</t> 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, as segmented with orthogonal functionalities:</t>
   <t>
       • Fetching RPKI. The requirements
   are organized into four groups:</t>
      <ul spacing="normal">
       <li>Fetching and Caching RPKI Repository Objects
       <vspace />
       • Processing Objects</li>
       <li>Processing Certificates and CRLs
       <vspace />
       • Processing Certificate Revocation Lists (CRLs)</li>
       <li>Processing RPKI Repository Signed Objects
       <vspace />
       • Distributing Objects</li>
       <li>Distributing Validated Cache of the RPKI Data</t> Data</li>
      </ul>
      <t>This document will be update updated to reflect new or changed requirements
   as these RFCs are updated, updated or new additional RFCs are written.</t>
    </section>
    <section title="Fetching numbered="true" toc="default">
      <name>Fetching and Caching RPKI Repository Objects"> Objects</name>
      <t>RP software uses synchronization mechanisms supported by targeted
   repositories (e.g., <xref target="rsync" />, format="default"/> or RRDP  <xref
   target="RFC8182" />) format="default"/>)
   to download all RPKI changed data signed objects in from the repository system and cache them locally. The in order to
   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, prefixes and which routers are
   authorized to sign BGP updates on behalf of specified ASes.</t>
      <section title="TAL Acquisition numbered="true" toc="default">
        <name>TAL Configuration and Processing"> Processing</name>
        <t>In the RPKI, each RP chooses its own a set of trust anchors
	(TAs). Consistent with the extant INR allocation hierarchy, the IANA
	and/or the five RIRs 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 each RP software to retrieve and verify the
	authenticity of each TA.</t>
        <t>TAL acquisition configuration and processing are specified in Section 3 of <xref
	target="RFC8630" />.</t> sectionFormat="of" section="3"/>.</t>
      </section>
      <section title="Locating numbered="true" toc="default">
        <name>Locating RPKI Objects Using Authority and Subject Information Extensions"> Extensions</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. An  RP software discovers publication
   points using the Subject Information Access (SIA) and the Authority
   Information Access (AIA) extensions from (validated) certificates.</t>
    <t>Section 5 of <xref
        <t><xref target="RFC6481" /> sectionFormat="of" section="5"/>  specifies how an 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 Section 4 Sections <xref target="RFC6487"
	sectionFormat="bare" section="4.8.8"/> and <xref target="RFC6487"
	sectionFormat="bare" section="4.8.7"/> of <xref target="RFC6487" />.</t>
	format="default"/>, respectively.</t>
      </section>
      <section title="Dealing numbered="true" toc="default">
        <name>Dealing with Key Rollover">
    <t>An RP 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 in for dealing with key rollover are
	described in Section 3 of <xref target="RFC6489" /> sectionFormat="of" section="3"/>
	and Section 3 of <xref target="RFC8634" />.</t> sectionFormat="of" section="3"/>.</t>
      </section>
      <section title="Dealing numbered="true" toc="default">
        <name>Dealing with Algorithm Transition"> 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 Section 4 of <xref target="RFC6916" />.</t> sectionFormat="of" section="4"/>.</t>
      </section>
      <section title="Strategies numbered="true" toc="default">
        <name>Strategies for Efficient Cache Maintenance"> Maintenance</name>
        <t>Each RP is expected to maintain a local cache of RPKI objects.
The cache needs to be as brought up to date and made consistent with the
repository publication point data as the RP’s frequency of checking permits.</t> frequently as allowed by
repository publication points and by locally selected RP processing
constraints.</t>
        <t>The last paragraph of Section 5 of <xref target="RFC6481" />
	sectionFormat="of" section="5"/> provides
    guidance for maintenance of a local cache.</t>
      </section>
    </section>
    <section title="Certificate numbered="true" toc="default">
      <name>Certificate and CRL Processing"> Processing</name>

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

      <section title="Verifying numbered="true" toc="default">
        <name>Verifying Resource Certificate and Syntax"> Syntax</name>
        <t>Certificates in the RPKI are called resource certificates, and they
	are required to conform to the profile described in <xref target="RFC6487" />.
	format="default"/>.  An RP is required to verify that a resource
	certificate adheres to the profile established by Section 4 of <xref
	target="RFC6487" />. sectionFormat="of" section="4"/>.  This means that
	all extensions mandated by Section 4.8 of <xref target="RFC6487" />
	sectionFormat="of" section="4.8"/> must be present and the value of each extension
	must be within the range specified by this RFC. <xref target="RFC6487"
	format="default"/>.  Moreover, any extension excluded by Section 4.8 of
	<xref target="RFC6487" /> sectionFormat="of" section="4.8"/> must be omitted.</t>
    <t>Section 7.1 of <xref
        <t><xref target="RFC6487" /> gives sectionFormat="of" section="7.1"/> specifies
	the procedure that the RP should follow to verify resource certificate and syntax.</t> software follows when verifying extensions
	described in <xref target="RFC3779" format="default"/>.</t>
      </section>
      <section title="Certificate numbered="true" toc="default">
        <name>Certificate Path Validation">
    <t>The Validation</name>
        <t>Initially, the INRs in issuer’s the issuer's certificate are required to
	encompass the INRs in the subject’s subject's certificate.  This is one of the
	necessary principles of certificate path validation in addition to
	cryptographic verification i.e., (i.e., verification of the signature on
	each certificate using the public key of the parent certificate).</t>
    <t>Section 7.2 of <xref
        <t><xref target="RFC6487" /> gives sectionFormat="of" section="7.2"/> specifies
	the procedure that the RP software should follow to perform certificate
	path validation.</t>
    <t>Certificate
        <t>Certification Authorities (CAs) that want to reduce aspects of
	operational fragility will migrate to the new OIDs <xref
	target="RFC8360" />, format="default"/>, informing the RP of using software to use an
	alternative RPKI validation algorithm.  An RP is expected to support
	the amended procedure to handle with accidental over-claim.</t> overclaiming, which is
	described in <xref target="RFC8360" sectionFormat="of" section="4"/>.</t>
      </section>
      <section title="CRL Processing"> numbered="true" toc="default">
        <name>CRL Processing</name>
        <t>The CRL processing requirements imposed on CAs and RP RPs are described
	in Section 5 of <xref target="RFC6487" />. sectionFormat="of" section="5"/>.  CRLs in
	the RPKI are tightly constrained; only the AuthorityKeyIndetifier 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. RPs are
	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 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 fourth fifth paragraph of Section 6.6 of <xref
	target="RFC6486" />.</t> sectionFormat="of" section="6.6"/>.</t>
      </section>
    </section>
    <section title="Processing numbered="true" toc="default">
      <name>Processing RPKI Repository Signed Objects"> Objects</name>
      <section title="Basic numbered="true" toc="default">
        <name>Basic Signed Object Syntax Checks"> Checks</name>
        <t>Before an RP can use a signed object from the RPKI repository, the RP software
   is required to check the signed object signed-object syntax.</t>
        <t>Section 3 of <xref
        <t><xref target="RFC6488" /> sectionFormat="of" section="3"/> lists all
	the steps that the RP software is required to execute in order to validate
	the top level top-level syntax of a repository signed object.</t>
        <t>Note that these checks are necessary, necessary but not sufficient.
	Additional validation checks must be performed based on the specific
	type of signed object.</t> object, as described in <xref target="syntax"
	format="default"/>.</t>
      </section>
      <section title="Syntax anchor="syntax" numbered="true" toc="default">
        <name>Syntax and Validation for Each Type of Signed Object"> Object</name>
        <section title="Manifest"> numbered="true" toc="default">
          <name>Manifest</name>
          <t>To determine whether a manifest is valid, the RP software is required
	  to perform manifest-specific checks in addition to those the generic
	  signed-object checks specified in <xref target="RFC6488" />.</t>
	  format="default"/>.</t>
          <t>Specific checks for a Manifest manifest are described in Section 4 of <xref
	  target="RFC6486" />. sectionFormat="of" section="4"/>.  If any of these
	  checks fails, fail, indicating that the manifest is invalid, then the
	  manifest will be discarded discarded, and treated RP software will act as though no
	  manifest were present.</t>
        </section>
        <section title="ROA"> numbered="true" toc="default">
          <name>ROA</name>
          <t>To validate a ROA, the Route Origin Authorization (ROA), RP software is
	  required to perform all the checks specified in <xref
	  target="RFC6488" /> format="default"/> as well as the additional additional,
	  ROA-specific validation steps.  The IP address delegation Address Delegation extension
	  <xref target="RFC3779" /> format="default"/> present in the end-entity
	  (EE) certificate (contained within the ROA), ROA) must encompass 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> sectionFormat="of" section="4"/>.</t>
        </section>
        <section title="Ghostbusters"> numbered="true" toc="default">
          <name>Ghostbusters</name>
          <t>The Ghostbusters Record is optional; a publication point in the RPKI
   can have zero or more associated Ghostbuster Ghostbusters Records.  If a CA has at
   least one Ghostbuster Ghostbusters Record, RP software is required to verify that this
   Ghostbusters Record conforms to the syntax of signed object objects defined
   in <xref target="RFC6488" />.</t> format="default"/>.</t>
          <t>The payload of this signed object is a (severely) profiled
	  vCard. An RP software is required to verify that the payload of
	  Ghostbusters conforms to format as profiled in <xref
	  target="RFC6493" />.</t> format="default"/>.</t>
        </section>
        <section title="Verifying numbered="true" toc="default">
          <name>Verifying BGPsec Router Certificate"> Certificate</name>
          <t>A BGPsec Router Certificate is a resource certificate, so it is
	  required to comply with <xref target="RFC6487"/>. target="RFC6487" format="default"/>.
	  Additionally, the certificate must contain an AS Identifier
	  Delegation extension, extension (<xref target="RFC6487" sectionFormat="of"
	  section="4.8.11"/>) and must not contain an IP Address Delegation extension.
	  extension (<xref target="RFC6487" sectionFormat="of"
	  section="4.8.10"/>).  The validation procedure used for BGPsec
	  Router Certificates is identical analogous to the validation procedure
	  described in Section 7 of <xref target="RFC6487" />, sectionFormat="of"
	  section="7"/>, but using it uses the constraints applied come from specification of Section 7 of defined in <xref
	  target="RFC8209" />. </t> sectionFormat="of" section="3"/>.</t>
          <t>Note that the cryptographic algorithms used by BGPsec routers are
	  found in <xref target="RFC8208" />. target="RFC8608" format="default"/>.  Currently, the
	  algorithms specified in <xref target="RFC8208" />and target="RFC8608" format="default"/>
	  and <xref target="RFC7935" /> format="default"/> are different.  BGPsec RPs
	  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 title="How numbered="true" toc="default">
        <name>How to Make Use of Manifest Data"> Data</name>
        <t>For a given publication point, the RP software ought to perform tests,
	as specified in Section 6.1 of <xref target="RFC6486" />, sectionFormat="of"
	section="6.1"/>, to determine the state of the Manifest manifest at the
	publication point.  A Manifest manifest can be classified as either valid or
	invalid, and a valid Manifest manifest is either current and or stale.  An RP
	decides how to make use of a Manifest 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, manifest, <xref target="RFC6486" /> format="default"/> does
	not mandate specific RP behavior with respect to such objects. However, most RP software ignores such objects and the authors of this document suggest this behavior be adopted uniformly.</t> objects.</t>
        <t>In the absence of a Manifest, manifest, an RP is expected to accept all valid
	signed objects present in the publication point. point (see <xref
	target="RFC6486" sectionFormat="of" section="6.2"/>). If a Manifest manifest is
	stale or invalid (see <xref target="RFC6486" />) and an RP has no way to acquire a more recently recent valid Manifest,
	manifest, the RP is expected to contact the repository manager via
	Ghostbusters record Records and thereafter make decision decisions according to local
	(RP) policy.</t> 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="default"/>).</t>
      </section>
      <section title="What to numbered="true" toc="default">
        <name>What To Do with Ghostbusters Information">
        <t>An RP Information</name>
        <t>RP software may encounter a stale Manifest 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 record 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 slate stale or expired objects.</t>
      </section>
    </section>
    <section title="Distributing numbered="true" toc="default">
      <name>Distributing Validated Cache"> Cache</name>
      <t>On a periodic basis, BGP speakers within an AS request updated
   validated origin AS data and router/ASN data from the (local) 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 provisioning such data to BGP speakers.  The specification specifications of the
   protocol designed to deliver validated cache data to a BGP Speaker is are provided
   in <xref target="RFC6810" /> format="default"/> and <xref target="RFC8210" />.</t> format="default"/>.</t>
    </section>
    <section title="Local Control"> numbered="true" toc="default">
      <name>Local Control</name>
      <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" /> . format="default"/>. The
   mechanisms developed to provide this capability to network operators
   are called "Simplified Simplified Local Internet Number Resource 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> format="default"/>.</t>
    </section>
    <section title="Security Considerations">
    <t>The numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document does not introduce any new security considerations; it
   is a resource for implementers.  The RP links the RPKI provisioning
   side and the routing system, establishing the a verified, local view of global
   RPKI data to BGP speakers.  The security of the RP is critical to for exchanging BGP messages exchanging.  The
   messages.  Each RP implementation is expected to offer
   cache backup management to facilitate recovery from outage state. The outages.
   RP implementation also software should also support application of secure transport (e.g., IPsec <xref
   target="RFC4301" />) format="default"/>) that is able to can protect validated cache
   delivery in a an unsafe environment. </t> This document highlights
   many validation actions applied to RPKI signed objects, an essential
   element of secure operation of RPKI security.</t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.</t> IANA actions.</t>
    </section>

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6482.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6486.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6489.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6493.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6810.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6916.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7935.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8608.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8209.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8210.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8360.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8630.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8634.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8182.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8211.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8416.xml"/>
        <reference anchor="rsync" target="http://rsync.samba.org/">
          <front>
            <title>rsync</title>
            <author/>
            <date/>
          </front>
        </reference>
      </references>
    </references>
    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George Michaelson and Oleg Muravskiy <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 feedback, and editorial assistance in 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>
</rfc>