<pre>Internet Engineering Task Force (IETF)                       M. Lepinski
Request for Comments: 6480                                       S. Kent
Category: Informational                                 BBN Technologies
ISSN: 2070-1721                                            February 2012


          <span class="h1">An Infrastructure to Support Secure Internet Routing</span>

Abstract

   This document describes an architecture for an infrastructure to
   support improved security of Internet routing.  The foundation of
   this architecture is a Resource Public Key Infrastructure (RPKI) that
   represents the allocation hierarchy of IP address space and
   Autonomous System (AS) numbers; and a distributed repository system
   for storing and disseminating the data objects that comprise the
   RPKI, as well as other signed objects necessary for improved routing
   security.  As an initial application of this architecture, the
   document describes how a legitimate holder of IP address space can
   explicitly and verifiably authorize one or more ASes to originate
   routes to that address space.  Such verifiable authorizations could
   be used, for example, to more securely construct BGP route filters.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6480">http://www.rfc-editor.org/info/rfc6480</a>.













<span class="grey">Lepinski &amp; Kent               Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-4">4</a>
   <a href="#section-2">2</a>. Public Key Infrastructure for Internet Number Resources .........<a href="#page-4">4</a>
      <a href="#section-2.1">2.1</a>. Role in the Overall Architecture ...........................<a href="#page-5">5</a>
      <a href="#section-2.2">2.2</a>. CA Certificates ............................................<a href="#page-6">6</a>
      <a href="#section-2.3">2.3</a>. End-Entity (EE) Certificates ...............................<a href="#page-7">7</a>
      <a href="#section-2.4">2.4</a>. Trust Anchors ..............................................<a href="#page-8">8</a>
   <a href="#section-3">3</a>. Route Origination Authorizations ................................<a href="#page-9">9</a>
      <a href="#section-3.1">3.1</a>. Role in the Overall Architecture ...........................<a href="#page-9">9</a>
      <a href="#section-3.2">3.2</a>. Syntax and Semantics ......................................<a href="#page-10">10</a>
   <a href="#section-4">4</a>. Repositories ...................................................<a href="#page-11">11</a>
      <a href="#section-4.1">4.1</a>. Role in the Overall Architecture ..........................<a href="#page-12">12</a>
      <a href="#section-4.2">4.2</a>. Contents and Structure ....................................<a href="#page-12">12</a>
      <a href="#section-4.3">4.3</a>. Access Protocols ..........................................<a href="#page-14">14</a>
      <a href="#section-4.4">4.4</a>. Access Control ............................................<a href="#page-15">15</a>
   <a href="#section-5">5</a>. Manifests ......................................................<a href="#page-15">15</a>
      <a href="#section-5.1">5.1</a>. Syntax and Semantics ......................................<a href="#page-15">15</a>
   <a href="#section-6">6</a>. Local Cache Maintenance ........................................<a href="#page-16">16</a>
   <a href="#section-7">7</a>. Common Operations ..............................................<a href="#page-17">17</a>
      <a href="#section-7.1">7.1</a>. Certificate Issuance ......................................<a href="#page-17">17</a>
      <a href="#section-7.2">7.2</a>. CA Key Rollover ...........................................<a href="#page-18">18</a>
      <a href="#section-7.3">7.3</a>. ROA Management ............................................<a href="#page-19">19</a>
           <a href="#section-7.3.1">7.3.1</a>. Single-Homed Subscribers ...........................<a href="#page-20">20</a>
           <a href="#section-7.3.2">7.3.2</a>. Multi-Homed Subscribers ............................<a href="#page-20">20</a>
           <a href="#section-7.3.3">7.3.3</a>. Provider-Independent Address Space .................<a href="#page-21">21</a>
   <a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-21">21</a>
   <a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-21">21</a>
   <a href="#section-10">10</a>. Acknowledgments ...............................................<a href="#page-22">22</a>
   <a href="#section-11">11</a>. References ....................................................<a href="#page-22">22</a>
      <a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-22">22</a>
      <a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-23">23</a>



<span class="grey">Lepinski &amp; Kent               Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document describes an architecture for an infrastructure to
   support improved security for BGP routing [<a href="./rfc4271" title="&quot;A Border Gateway Protocol 4 (BGP-4)&quot;">RFC4271</a>] for the Internet.
   The architecture encompasses three principle elements:

      o  Resource Public Key Infrastructure (RPKI)

      o  digitally signed routing objects to support routing security

      o  a distributed repository system to hold the PKI objects and the
         signed routing objects

   The architecture described by this document enables an entity to
   verifiably assert that it is the legitimate holder of a set of IP
   addresses or a set of Autonomous System (AS) numbers.  As an initial
   application of this architecture, the document describes how a
   legitimate holder of IP address space can explicitly and verifiably
   authorize one or more ASes to originate routes to that address space.
   Such verifiable authorizations could be used, for example, to more
   securely construct BGP route filters.  In addition to this initial
   application, the infrastructure defined by this architecture also is
   intended to provide future support for security protocols such as
   Secure BGP [<a href="#ref-S-BGP" title="&quot;Secure Border Gateway Protocol (Secure-BGP)&quot;">S-BGP</a>] or Secure Origin BGP [<a href="#ref-soBGP" title="&quot;soBGP&quot;">soBGP</a>].  This architecture
   is applicable to the routing of both IPv4 and IPv6 datagrams.  IPv4
   and IPv6 are currently the only address families supported by this
   architecture.  Thus, for example, use of this architecture with MPLS
   labels is beyond the scope of this document.

   In order to facilitate deployment, the architecture takes advantage
   of existing technologies and practices.  The structure of the PKI
   element of the architecture corresponds to the existing resource
   allocation structure.  Thus management of this PKI is a natural
   extension of the resource-management functions of the organizations
   that are already responsible for IP address and AS number resource
   allocation.  Likewise, existing resource allocation and revocation
   practices have well-defined correspondents in this architecture.
   Note that while the initial focus of this architecture is routing
   security applications, the PKI described in this document could be
   used to support other applications that make use of attestations of
   IP address or AS number resource holdings.

   To ease implementation, existing IETF standards are used wherever
   possible; for example, extensive use is made of the X.509 certificate
   profile defined by the Public Key Infrastructure using X.509 (PKIX)
   [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>] working group and the extensions for IP addresses and AS
   numbers representation defined in <a href="./rfc3779">RFC 3779</a> [<a href="./rfc3779" title="&quot;X.509 Extensions for IP Addresses and AS Identifiers&quot;">RFC3779</a>].  Also,
   Cryptographic Message Syntax (CMS) [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>] is used as the syntax



<span class="grey">Lepinski &amp; Kent               Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   for the newly defined signed objects [<a href="./rfc6488" title="&quot;Signed Object Template for the Resource Public Key Infrastructure&quot;">RFC6488</a>] required by this
   infrastructure.

   As noted above, the architecture is comprised of three main
   components: an X.509 PKI in which certificates attest to holdings of
   IP address space and AS numbers; non-certificate signed objects
   (including route origination authorizations and manifests) used by
   the infrastructure; and a distributed repository system that makes
   all of these signed objects available for use by ISPs in making
   routing decisions.  These three basic components enable several
   security functions; most notably the cryptographic validation that an
   autonomous system is authorized to originate routes to a given prefix
   [<a href="./rfc6483" title="&quot;Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)&quot;">RFC6483</a>].

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Terminology</span>

   It is assumed that the reader is familiar with the terms and concepts
   described in "Internet X.509 Public Key Infrastructure Certificate
   and Certificate Revocation List (CRL) Profile" [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>] and "X.509
   Extensions for IP Addresses and AS Identifiers" [<a href="./rfc3779" title="&quot;X.509 Extensions for IP Addresses and AS Identifiers&quot;">RFC3779</a>].

   Throughout this document, we use the terms "address space holder" or
   "holder of IP address space" interchangeably to refer to a legitimate
   holder of IP address space who has received this address space
   through the standard IP address allocation hierarchy.  That is, the
   address space holder has either directly received the address space
   as an allocation from a Regional Internet Registry (RIR) or IANA; or
   else the address space holder has received the address space as a
   sub-allocation from a National Internet Registry (NIR) or Local
   Internet Registry (LIR).  We use the term "resource holder" to refer
   to a legitimate holder of either IP address or AS number resources.

   Throughout this document, we use the terms "registry" and "ISP" to
   refer to an entity that has an IP address space and/or AS number
   allocation that it is permitted to sub-allocate.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in <a href="./rfc2119">RFC</a>
   <a href="./rfc2119">2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Public Key Infrastructure for Internet Number Resources</span>

   Because the holder of a block of IP address space is entitled to
   define the topological destination of IP datagrams whose destinations
   fall within that block, decisions about inter-domain routing are
   inherently based on knowledge of the allocation of the IP address
   space.  Thus, a basic function of this architecture is to provide



<span class="grey">Lepinski &amp; Kent               Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   cryptographically verifiable attestations as to these allocations.
   In current practice, the allocation of IP addresses is hierarchical.
   The root of the hierarchy is IANA.  Below IANA are five Regional
   Internet Registries (RIRs), each of which manages address and AS
   number allocation within a defined geopolitical region.  In some
   regions, the third tier of the hierarchy includes National Internet
   Registries (NIRs) as well as Local Internet Registries (LIRs) and
   subscribers with so-called provider-independent ("portable")
   allocations.  (The term "LIR" is used in some regions to refer to
   what other regions define as an ISP.  Throughout the rest of this
   document, we will use the term "LIR/ISP" to simplify references to
   these entities.)  In other regions, the third tier consists only of
   LIRs/ISPs and subscribers with provider-independent allocations.

   In general, the holder of a block of IP address space may sub-
   allocate portions of that block, either to itself (e.g., to a
   particular unit of the same organization), or to another
   organization, subject to contractual constraints established by the
   registries.  Because of this structure, IP address allocations can be
   described naturally by a hierarchic public key infrastructure, in
   which each certificate attests to an allocation of IP addresses, and
   issuance of subordinate certificates corresponds to sub-allocation of
   IP addresses.  The above reasoning holds true for AS number resources
   as well, with the difference that, by convention, AS numbers may not
   be sub-allocated except by RIRs or NIRs.  Thus, allocations of both
   IP addresses and AS numbers can be expressed by the same PKI.  Such a
   PKI, which is henceforth referred to as the "Resource Public Key
   Infrastructure (RPKI)", is a central component of this architecture.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Role in the Overall Architecture</span>

   Certificates in this PKI are called resource certificates, and
   conform to the certificate profile for such certificates [<a href="./rfc6487" title="&quot;A Profile for X.509 PKIX Resource Certificates&quot;">RFC6487</a>].
   Resource certificates attest to the allocation by the (certificate)
   issuer of IP addresses or AS numbers to the subject.  They do this by
   binding the public key contained in the resource certificate to the
   IP addresses or AS numbers included in the certificate's IP Address
   Delegation or AS Identifier Delegation extensions, respectively, as
   defined in <a href="./rfc3779">RFC 3779</a> [<a href="./rfc3779" title="&quot;X.509 Extensions for IP Addresses and AS Identifiers&quot;">RFC3779</a>].

   An important property of this PKI is that certificates do not attest
   to the identity of the subject.  Therefore, the subject names used in
   certificates are not intended to be "descriptive".  That is, the
   resource PKI is intended to provide authorization, but not
   authentication.  This is in contrast to most PKIs where the issuer
   ensures that the descriptive subject name in a certificate is
   properly associated with the entity that holds the private key
   corresponding to the public key in the certificate.  Because issuers



<span class="grey">Lepinski &amp; Kent               Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   need not verify the right of an entity to use a subject name in a
   certificate, they avoid the costs and liabilities of such
   verification.  This makes it easier for these entities to take on the
   additional role of Certification Authority (CA).

   Most of the certificates in the PKI assert the basic facts on which
   the rest of the infrastructure operates.  CA certificates within the
   PKI attest to IP address space and AS number holdings.  End-entity
   (EE) certificates are issued by resource holder CAs to delegate the
   authority attested by their allocation certificates.  The primary use
   for EE certificates is the validation of Route Origination
   Authorizations (ROAs), signed objects which provide an explicit
   authorization by an address holder that a given AS is permitted to
   originate routes to a set of addresses (see <a href="#section-3">Section 3</a>).  End-entity
   certificates are also used to verify other signed objects, such as
   manifests, which will be used to help ensure the integrity of the
   repository system (see <a href="#section-5">Section 5</a>).

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  CA Certificates</span>

   Any resource holder who is authorized to sub-allocate these resources
   must be able to issue resource certificates to correspond to these
   sub-allocations.  Thus, for example, CA certificates will be
   associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs.
   Also, a CA certificate is required to enable a resource holder to
   issue ROAs, because it must issue the corresponding end-entity
   certificate used to validate each ROA.  Thus, some entities that do
   not sub-allocate their resources also will need to have CA
   certificates for their allocations, e.g., a multi-homed subscriber
   with a provider-independent allocation, to enable them to issue ROAs.
   (A subscriber who is not multi-homed, whose allocation comes from an
   LIR/ISP, and who has not moved to a different LIR/ISP, need not be
   represented in the PKI.  Moreover, a multi-homed subscriber with an
   allocation from an LIR/ISP may or may not need to be explicitly
   represented, as discussed in <a href="#section-7.3.2">Section 7.3.2</a>).

   Unlike in most PKIs, the distinguished name of the subject in a CA
   certificate is chosen by the certificate issuer.  The subject's
   distinguished name must not attempt to convey the identity of the
   subject in a descriptive fashion.  The subject's distinguished name
   must include the CommonName attribute and may additionally include
   the serial attribute.

   In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP,
   is not in the business of verifying the legal right of the subject to
   assert a particular identity.  Therefore, selecting a distinguished
   name that does not convey the identity of the subject in a
   descriptive fashion minimizes the opportunity for the subject to



<span class="grey">Lepinski &amp; Kent               Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   misuse the certificate to assert an identity, and thus minimizes the
   legal liability of the issuer.  Since all CA certificates are issued
   to subjects with whom the issuer has an existing relationship, it is
   recommended that the issuer select a subject name that enables the
   issuer to easily link the certificate to existing database records
   associated with the subject.  For example, an authority may use
   internal database keys or subscriber IDs as the subject's common name
   in issued certificates.

   Although the subject's common name in a certificate does not convey
   identity, it is still the case that the common name must be unique
   among all subjects to whom a certification authority issues
   certificates.  That is, a CA must not issue certificates to two
   different entities that use the same common name for the subject.

   Each resource certificate attests to an allocation of resources to a
   resource holder, so entities that have allocations from multiple
   sources will have multiple CA certificates.  Note that when an entity
   receives multiple certificates from different issuers, the subject
   names in these certificates will generally be different.  A CA also
   may issue distinct certificates for each distinct allocation to the
   same entity, if the CA and the resource holder agree that such an
   arrangement will facilitate management and use of the certificates.
   For example, an LIR/ISP may have several certificates issued to it by
   one registry, each describing a distinct set of address blocks,
   because the LIR/ISP desires to treat the allocations as separate.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  End-Entity (EE) Certificates</span>

   The private key corresponding to a public key contained in an EE
   certificate is not used to sign other certificates in a PKI.  The
   primary function of end-entity certificates in this PKI is the
   verification of signed objects that relate to the usage of the
   resources described in the certificate, e.g., ROAs and manifests.

   For ROAs and manifests, there will be a one-to-one correspondence
   between end-entity certificates and signed objects, i.e., the private
   key corresponding to each end-entity certificate is used to sign
   exactly one object, and each object is signed with only one key.
   This property allows the PKI to be used to revoke these signed
   objects, rather than creating a new revocation mechanism.  When the
   end-entity certificate used to sign an object has been revoked, the
   signature on that object (and any corresponding assertions) will be
   considered invalid, so a signed object can be effectively revoked by
   revoking the end-entity certificate used to sign it.

   A secondary advantage to this one-to-one correspondence is that the
   private key corresponding to the public key in a certificate is used



<span class="grey">Lepinski &amp; Kent               Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   exactly once in its lifetime, and thus can be destroyed after it has
   been used to sign its one object.  This fact should simplify key
   management, since there is no requirement to protect these private
   keys for an extended period of time.

   The EE certificate used to verify a signed object appears in the
   Cryptographic Message Syntax (CMS) wrapper (see [<a href="./rfc6488" title="&quot;Signed Object Template for the Resource Public Key Infrastructure&quot;">RFC6488</a>]) of the
   signed object.  Therefore, it is not necessary to transmit the EE
   certificate separately from the signed object.  Likewise, it is not
   necessary for the EE certificate to appear in the RPKI repository
   system except as part of the corresponding signed object.

   Although this document describes only two uses for end-entity
   certificates, additional uses will likely be defined in the future.
   For example, end-entity certificates could be used as a more general
   authorization for their subjects to act on behalf of the specified
   resource holder.  This could facilitate authentication of inter-ISP
   interactions, or authentication of interactions with the repository
   system.  These additional uses for end-entity certificates may
   require retention of the corresponding private keys, even though such
   retention is not required for keys used to sign ROAs and manifests.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Trust Anchors</span>

   In any PKI, each relying party (RP) chooses its own set of trust
   anchors (TAs).  This general property of PKIs applies here as well.
   There is an extant IP address space and AS number allocation
   hierarchy, and thus IANA and/or the five RIRs are obvious candidates
   to be default TAs here.  Nonetheless, each RP ultimately chooses the
   set of trust anchors it will use for certificate validation.

   For example, an RP (e.g., an LIR/ISP) could create a trust anchor to
   which all address space and/or all AS numbers are assigned, and for
   which the RP knows the corresponding private key.  The RP could then
   issue certificates under this trust anchor to whatever entities in
   the PKI it wishes, with the result that the certification paths
   terminating at this locally installed trust anchor will satisfy the
   validation requirements specified in <a href="./rfc3779">RFC 3779</a>.  A large ISP that uses
   private IP address space (i.e., <a href="./rfc1918">RFC 1918</a>) and runs BGP internally
   will need to create this sort of trust anchor to accommodate a CA to
   which all private address space is assigned.  The RP could then issue
   certificates under this CA that correspond to the RP's internal use
   of private address space.


   Note that an RP who elects to create and manage its own set of trust
   anchors may fail to detect allocation errors that arise under such
   circumstances, but the resulting vulnerability is local to the RP.



<span class="grey">Lepinski &amp; Kent               Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   It is expected that some parties within the extant IP address space
   and AS number allocation hierarchy may wish to publish trust anchor
   material for possible use by relying parties.  A standard profile for
   the publication of trust anchor material for this public key
   infrastructure can be found in [<a href="./rfc6490" title="&quot;Resource Public Key Infrastructure (RPKI) Trust Anchor Locator&quot;">RFC6490</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Route Origination Authorizations</span>

   The information on IP address allocation provided by the PKI is not,
   in itself, sufficient to guide routing decisions.  In particular, BGP
   is based on the assumption that the AS that originates routes for a
   particular prefix is authorized to do so by the holder of that prefix
   (or an address block encompassing the prefix); the PKI contains no
   information about these authorizations.  A Route Origination
   Authorization (ROA) makes such authorization explicit, allowing a
   holder of IP address space to create an object that explicitly and
   verifiably asserts that an AS is authorized to originate routes to a
   given set of prefixes.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Role in the Overall Architecture</span>

   A ROA is an attestation that the holder of a set of prefixes has
   authorized an autonomous system to originate routes for those
   prefixes.  A ROA is structured according to the format described in
   [<a href="./rfc6482" title="&quot;A Profile for Route Origin Authorizations (ROAs)&quot;">RFC6482</a>].  The validity of this authorization depends on the signer
   of the ROA being the holder of the prefix(es) in the ROA; this fact
   is asserted by an end-entity certificate from the PKI, whose
   corresponding private key is used to sign the ROA.

   ROAs may be used by relying parties to verify that the AS that
   originates a route for a given IP address prefix is authorized by the
   holder of that prefix to originate such a route.  For example, an ISP
   might use validated ROAs as inputs to route filter construction for
   use by its BGP routers.  (See [<a href="./rfc6483" title="&quot;Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)&quot;">RFC6483</a>] for information on the use of
   ROAs to validate the origination of BGP routes.)

   Initially, the repository system will be the primary mechanism for
   disseminating ROAs, since these repositories will hold the
   certificates and CRLs needed to verify ROAs.  In addition, ROAs also
   could be distributed in BGP UPDATE messages or via other
   communication paths, if needed to meet timeliness requirements.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Syntax and Semantics</span>

   A ROA constitutes an explicit authorization for a single AS to
   originate routes to one or more prefixes, and is signed by the holder
   of those prefixes.  Conceptually, the ROA syntax consists of two
   parts, a general CMS template common to all RPKI signed objects



<span class="grey">Lepinski &amp; Kent               Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   [<a id="ref-RFC6488">RFC6488</a>] and an encapsulated content specific to the ROA that
   expresses the authorization [<a href="./rfc6482" title="&quot;A Profile for Route Origin Authorizations (ROAs)&quot;">RFC6482</a>].

   At a high level, the ROA's content contains (1) an AS number; (2) a
   list of IP address prefixes; and, optionally, (3) for each prefix,
   the maximum length of more specific (longer) prefixes that the AS is
   also authorized to advertise.  (This last element facilitates a
   compact authorization to advertise, for example, any prefixes of
   length 20 to 24 bits contained within a given length 20 prefix.)

   Note that a ROA contains only a single AS number.  Thus, if an ISP
   has multiple AS numbers that will be authorized to originate routes
   to the prefix(es) in the ROA, an address space holder will need to
   issue multiple ROAs to authorize the ISP to originate routes from any
   of these ASes.

   A ROA is signed using the private key corresponding to the public key
   in an end-entity (EE) certificate in the PKI.  In order for a ROA to
   be valid, its corresponding end-entity certificate must be valid, and
   the IP address prefixes of the ROA must exactly match the IP address
   prefix(es) specified in the EE certificate's <a href="./rfc3779">RFC 3779</a> extension.
   Therefore, the validity interval of the ROA is implicitly the
   validity interval of its corresponding certificate.  A ROA is revoked
   by revoking the corresponding EE certificate.  There is no
   independent method of revoking a ROA.  One might worry that this
   revocation model could lead to long CRLs for the CA certification
   that is signing the EE certificates.  However, routing announcements
   on the public Internet are generally quite long lived.  Therefore, as
   long as the EE certificates used to verify a ROA are given a validity
   interval of several months, the likelihood that many ROAs would need
   to be revoked within that time is quite low.




















<span class="grey">Lepinski &amp; Kent               Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


             ---------                ---------
             |  RIR  |                |  NIR  |
             |  CA   |                |  CA   |
             ---------                ---------
                 |                        |
                 |                        |
                 |                        |
             ---------                ---------
             |  ISP  |                |  ISP  |
             |  CA 1 |                |  CA 2 |
             ---------                ---------
              |     \                      |
              |      -----                 |
              |           \                |
          ----------    ----------      ----------
          |  ISP   |    |  ISP   |      |  ISP   |
          |  EE 1a |    |  EE 1b |      |  EE 2  |
          ----------    ----------      ----------
              |             |               |
              |             |               |
              |             |               |
          ----------    ----------      ----------
          | ROA 1a |    | ROA 1b |      | ROA 2  |
          ----------    ----------      ----------

   Figure 1: This figure illustrates an ISP with allocations from two
   sources (an RIR and an NIR).  It needs two CA certificates due to the
   rules defined in <a href="./rfc3779">RFC 3779</a>.

   Because each ROA is associated with a single end-entity certificate,
   the set of IP prefixes contained in a ROA must be drawn from an
   allocation by a single source, i.e., a ROA cannot combine allocations
   from multiple sources.  Address space holders who have allocations
   from multiple sources, and who wish to authorize an AS to originate
   routes for these allocations, must issue multiple ROAs to the AS.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Repositories</span>

   Initially, an LIR/ISP will make use of the resource PKI by acquiring
   and validating every ROA, to create a table of the prefixes for which
   each AS is authorized to originate routes.  To validate all ROAs, an
   LIR/ISP needs to acquire all the certificates and CRLs.  The primary
   function of the distributed repository system described here is to
   store these signed objects and to make them available for download by
   LIRs/ISPs.  Note that this repository system provides a mechanism by
   which relying parties can pull fresh data at whatever frequency they
   deem appropriate.  However, it does not provide a mechanism for
   pushing fresh data to relying parties (e.g., by including resource



<span class="grey">Lepinski &amp; Kent               Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   PKI objects in BGP or other protocol messages) and such a mechanism
   is beyond the scope of the current document.

   The digital signatures on all objects in the repository ensure that
   unauthorized modification of valid objects is detectable by relying
   parties.  Additionally, the repository system uses manifests (see
   <a href="#section-5">Section 5</a>) to ensure that relying parties can detect the deletion of
   valid objects and the insertion of out-of-date, valid signed objects.

   The repository system is also a point of enforcement for access
   controls for the signed objects stored in it, e.g., ensuring that
   records related to an allocation of resources can be manipulated only
   by authorized parties.  The use of access controls prevents denial-
   of-service attacks based on deletion of or tampering with repository
   objects.  Indeed, although relying parties can detect tampering with
   objects in the repository, it is preferable that the repository
   system prevent such unauthorized modifications to the greatest extent
   possible.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Role in the Overall Architecture</span>

   The repository system is the untrusted clearing-house for all signed
   objects that must be globally accessible to relying parties.  When
   certificates and CRLs are created, they are uploaded to this
   repository, and then downloaded for use by relying parties (primarily
   LIRs/ISPs).  ROAs and manifests are additional examples of such
   objects, but other types of signed objects may be added to this
   architecture in the future.  This document briefly describes the way
   signed objects (certificates, CRLs, ROAs, and manifests) are managed
   in the repository system.  As other types of signed objects are added
   to the repository system, it will be necessary to modify the
   description, but it is anticipated that most of the design principles
   will still apply.  The repository system is described in detail in
   [<a href="./rfc6481" title="&quot;A Profile for Resource Certificate Repository Structure&quot;">RFC6481</a>].

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Contents and Structure</span>

   Although there is a single repository system that is accessed by
   relying parties, it is comprised of multiple databases.  These
   databases will be distributed among registries (RIRs, NIRs,
   LIRs/ISPs).  At a minimum, the database operated by each registry
   will contain all CA and EE certificates, CRLs, and manifests signed
   by the CA(s) associated with that registry.  Repositories operated by
   LIRs/ISPs also will contain ROAs.  Registries are encouraged to
   maintain copies of repository data from their customers, and their
   customer's customers (etc.), to facilitate retrieval of the whole
   repository contents by relying parties.  Ideally, each RIR will hold
   PKI data from all entities within its geopolitical scope.



<span class="grey">Lepinski &amp; Kent               Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   For every certificate in the PKI, there will be a corresponding file
   system directory in the repository that is the authoritative
   publication point for all objects (certificates, CRLs, ROAs, and
   manifests) verifiable via this certificate.  A certificate's Subject
   Information Access (SIA) extension [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>] contains a URI that
   references this directory.  Additionally, a certificate's Authority
   Information Access (AIA) extension [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>] contains a URI that
   references the authoritative location for the CA certificate under
   which the given certificate was issued.  That is, if certificate A is
   used to verify certificate B, then the AIA extension of certificate B
   points to certificate A, and the SIA extension of certificate A
   points to a directory containing certificate B (see Figure 2).

                         +--------+
              +---------&gt;| Cert A |&lt;----+
              |          | CRLDP  |     |
              |          |  AIA   |     |
              |  +--------- SIA   |     |
              |  |       +--------+     |
              |  |                      |
              |  |                      |
              |  |                      |
              |  |  +-------------------|------------------+
              |  |  |                   |                  |
              |  +-&gt;|   +--------+      |   +--------+     |
              |     |   | Cert B |      |   | Cert C |     |
              |     |   | CRLDP ----+   |   | CRLDP -+-+   |
              +----------- AIA   |  |   +----- AIA   | |   |
                    |   |  SIA   |  |       |  SIA   | |   |
                    |   +--------+  |       +--------+ |   |
                    |               V                  |   |
                    |           +---------+            |   |
                    |           | A's CRL |&lt;-----------+   |
                    |           +---------+                |
                    | A's Repository Publication Directory |
                    +--------------------------------------+

           Figure 2: Use of SIA and AIA extensions in the RPKI

   In Figure 2, certificates B and C are issued by CA A.  Therefore, the
   AIA extensions of certificates B and C point to (certificate) A, and
   the SIA extension of certificate A points to the repository
   publication point of CA A's subordinate products, which includes
   certificates B and C, as well as the CRL issued by A.  The CRL
   Distribution Points (CRLDP) extension in certificates B and C both
   point to the CRL issued by A.





<span class="grey">Lepinski &amp; Kent               Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   If a CA certificate is reissued with the same public key, it should
   not be necessary to reissue (with an updated AIA URI) all
   certificates signed by the certificate being reissued.  Therefore, a
   certification authority SHOULD use a persistent URI naming scheme for
   issued certificates.  That is, reissued certificates should use the
   same publication point as previously issued certificates having the
   same subject and public key, and should overwrite such certificates.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Access Protocols</span>

   Repository operators will choose one or more access protocols that
   relying parties can use to access the repository system.  These
   protocols will be used by numerous participants in the infrastructure
   (e.g., all registries, ISPs, and multi-homed subscribers) to maintain
   their respective portions of it.  In order to support these
   activities, certain basic functionality is required of the suite of
   access protocols, as described below.  No single access protocol
   needs to implement all of these functions (although that may be the
   case), but each function MUST be implemented by at least one access
   protocol deployed by a repository operator.

   Download: Access protocols must support the bulk download of
   repository contents and subsequent download of changes to the
   downloaded contents, since this will be the most common way in which
   relying parties interact with the repository system.  Other types of
   download interactions (e.g., download of a single object) may also be
   supported.

   Upload/change/delete: Access protocols must also support mechanisms
   for the issuers of certificates, CRLs, and other signed objects to
   add them to the repository, and to remove them.  Mechanisms for
   modifying objects in the repository may also be provided.  All access
   protocols that allow modification to the repository (through
   addition, deletion, or modification of its contents) must support
   verification of the authorization of the entity performing the
   modification, so that appropriate access controls can be applied (see
   <a href="#section-4.4">Section 4.4</a>).

   To ensure all relying parties are able to acquire all RPKI signed
   objects, all publication points MUST be accessible via rsync (see
   [<a href="./rfc5781" title="&quot;The rsync URI Scheme&quot;">RFC5781</a>] and [<a href="#ref-RSYNC">RSYNC</a>]), although other download protocols MAY also be
   supported.  A repository publication point may provide
   update/change/delete functionality via (set of) access protocols that
   it desires, provided that the supported protocols are clearly
   communicated to all certification authorities publishing data at a
   given publication point.





<span class="grey">Lepinski &amp; Kent               Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Access Control</span>

   In order to maintain the integrity of information in the repository,
   controls must be put in place to prevent the addition, deletion, or
   modification of objects in the repository by unauthorized parties.
   The identities of parties attempting to make such changes can be
   authenticated through the relevant access protocols.  Although
   specific access control policies are subject to the local control of
   repository operators, it is RECOMMENDED that repositories allow only
   the issuers of signed objects to add, delete, or modify them.
   Alternatively, it may be advantageous in the future to define a
   formal delegation mechanism to allow resource holders to authorize
   other parties to act on their behalf, as suggested in <a href="#section-2.3">Section 2.3</a>.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Manifests</span>

   A manifest is a signed object listing of all of the signed objects
   (except for the manifest itself) issued by an authority responsible
   for a publication in the repository system.  For each unexpired
   certificate, CRL, or ROA issued by the authority, the manifest
   contains both the name of the file containing the object, and a hash
   of the file content.

   As with ROAs, a manifest is signed by a private key, for which the
   corresponding public key appears in an end-entity certificate.  This
   EE certificate, in turn, is signed by the CA in question.  Since the
   private key in an EE certificate is used to sign only a single
   manifest, then the manifest can be revoked by revoking the EE
   certificate.  In such a case, to avoid needless CRL growth, the EE
   certificate used to validate a manifest SHOULD expire at the same
   time that the manifest expires.

   Manifests may be used by relying parties when constructing a local
   cache (see <a href="#section-6">Section 6</a>) to mitigate the risk of an attacker who deletes
   files from a repository or replaces current signed objects with stale
   versions of the same object.  Such protection is needed because,
   although all objects in the repository system are signed, the
   repository system itself is untrusted.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Syntax and Semantics</span>

   A manifest constitutes a list of (the hashes of) all the files in a
   repository point at a particular point in time.  A detailed
   specification of the manifest's content is provided in [<a href="./rfc6486" title="&quot;Manifests for the Resource Public Key Infrastructure&quot;">RFC6486</a>] but,
   at a high level, a manifest consists of (1) a manifest number; (2)
   the time the manifest was issued; (3) the time of the next planned
   update; and (4) a list of filename and hash value pairs.




<span class="grey">Lepinski &amp; Kent               Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   The manifest number is a sequence number that is incremented each
   time a manifest is issued by the authority.  An authority is REQUIRED
   to issue a new manifest any time it alters any of its items in the
   repository, or when the specified time of the next update is reached.
   A manifest is thus valid until the specified time of the next update
   or until a manifest is issued with a greater manifest number,
   whichever comes first.  (Note that when an EE certificate is used to
   sign only a single manifest, whenever the authority issues the new
   manifest, the CA MUST also issue a new CRL that includes the EE
   certificate corresponding to the old manifest.  The revoked EE
   certificate for the old manifest will be removed from the CRL when it
   expires; thus, this procedure ought not to result in significant CRL
   growth.)

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Local Cache Maintenance</span>

   In order to utilize signed objects issued under this PKI, a relying
   party must first obtain a local copy of the valid EE certificates for
   the PKI.  To do so, the relying party performs the following steps:

      1. Query the repository system to obtain a copy of all
         certificates, manifests, and CRLs issued under the PKI.

      2. For each CA certificate in the PKI, verify the signature on the
         corresponding manifest.  Additionally, verify that the current
         time is earlier than the time indicated in the nextUpdate field
         of the manifest.

      3. For each manifest, verify that certificates and CRLs issued
         under the corresponding CA certificate match the hash values
         contained in the manifest.  Additionally, verify that no
         certificate or manifest listed on the manifest is missing from
         the repository.  If the hash values do not match, or if any
         certificate or CRL is missing, notify the appropriate
         repository administrator that the repository data has been
         corrupted.

      4. Validate each EE certificate by constructing and verifying a
         certification path for the certificate (including checking
         relevant CRLs) to the locally configured set of TAs.  (See
         [<a href="./rfc6487" title="&quot;A Profile for X.509 PKIX Resource Certificates&quot;">RFC6487</a>] for more details.)

   Note that since relying parties will perform these operations
   regularly, it is more efficient for the relying party to request from
   the repository system only those objects that have changed since the
   relying party last updated its local cache.





<span class="grey">Lepinski &amp; Kent               Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   Note also that by checking all issued objects against the appropriate
   manifest, the relying party can be certain that it is not missing an
   updated version of any object.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Common Operations</span>

   Creating and maintaining the infrastructure described above will
   entail additional operations as "side effects" of normal resource
   allocation and routing authorization procedures.  For example, a
   subscriber with provider-independent ("portable") address space who
   enters a relationship with an ISP will need to issue one or more ROAs
   identifying that ISP, in addition to conducting any other necessary
   technical or business procedures.  The current primary use of this
   infrastructure is for route filter construction; using ROAs, route
   filters can be constructed in an automated fashion with high
   assurance that the holder of the advertised prefix has authorized the
   origin AS to originate an advertised route.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Certificate Issuance</span>

   There are several operational scenarios that require certificates to
   be issued.  Any allocation that may be sub-allocated requires a CA
   certificate, e.g., so that certificates can be issued as necessary
   for the sub-allocations.  Holders of provider-independent IP address
   space allocations also must have certificates, so that a ROA can be
   issued to each ISP that is authorized to originate a route to the
   allocation (since the allocation does not come from any ISP).
   Additionally, multi-homed subscribers may require certificates for
   their allocations if they intend to issue the ROAs for their
   allocations (see <a href="#section-7.3.2">Section 7.3.2</a>).  Other resource holders need not be
   issued CA certificates within the PKI.

   In the long run, a resource holder will not request resource
   certificates, but rather receive a certificate as a side effect of
   the allocation process for the resource.  However, initial deployment
   of the RPKI will entail issuance of certificates to existing resource
   holders as an explicit event.  Note that in all cases, the authority
   issuing a CA certificate will be the entity who allocates resources
   to the subject.  This differs from most PKIs in which a subject can
   request a certificate from any certification authority.

   If a resource holder receives multiple allocations over time, it may
   accrue a collection of resource certificates to attest to them.  If a
   resource holder receives multiple allocations from the same source,
   the set of resource certificates may be combined into a single
   resource certificate, if both the issuer and the resource holder
   agree.  This is accomplished by consolidating the IP Address
   Delegation and AS Identifier Delegation extensions into a single



<span class="grey">Lepinski &amp; Kent               Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   extension (of each type) in a new certificate.  However, if these
   certificates attest to allocations that are valid for different
   periods of time, creating a certificate that combines them might
   create problems, as the combined certificate can express only a
   single validity interval.

   If a resource holder's allocations come from different sources, they
   will be signed by different CAs and cannot be combined.  When a set
   of resources is no longer allocated to a resource holder, any
   certificates attesting to such an allocation MUST be revoked.  A
   resource holder SHOULD NOT use the same public key in multiple CA
   certificates that are issued by the same or differing authorities, as
   reuse of a key pair complicates path construction.  Note that since
   the subject's distinguished name is chosen by the issuer, a subject
   who receives allocations from two sources generally will receive
   certificates with different subject names.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  CA Key Rollover</span>

   Whenever a certification authority wishes to change the public key
   (and corresponding private key) associated with its RPKI CA
   certificate, it MUST perform a key rollover procedure.  Key rollover
   is typically performed on a periodic basis, where the frequency of
   key rollovers is specified in the certification practice statement of
   the given CA.  Additionally, unscheduled rollovers may be required in
   the event of suspected key compromises.

   Note that rollover is only required when the CA's key actually
   changes; it is not required in cases where a new CA certificate is
   issued with the same key as the previous certificate for this CA.
   For example, a new CA certificate must be issued if the CA gains or
   relinquishes a resource, or if the validity period of the resource
   allocation is extended.  However, in such cases, the new certificate
   will generally use the same public (and private) key as the previous
   certificate; thus, key rollover is not required.

   The document [<a href="./rfc6489" title="&quot;Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)&quot;">RFC6489</a>] specifies a conservative key rollover
   procedure that should be used by a certification authority when it
   changes the public (and private) keys associated with its RPKI CA
   certificate.  At a high level, the two key properties of the rollover
   procedure are as follows.  First, as data from RPKI signed objects
   may be used in routing operations, the procedure ensures that at any
   point in the rollover procedure, a relying party will never reach
   incorrect conclusions about the validity of a signed object.  Note in
   particular, that the CA cannot assume that a relying party will use
   any particular algorithm for constructing a certificate path from an
   EE certificate to (one of) the relying party's trust anchor(s);
   therefore, the key rollover procedure is designed to preserve the



<span class="grey">Lepinski &amp; Kent               Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   integrity of the SIA and AIA points within the RPKI hierarchy to the
   greatest extent possible.  Second, the key rollover procedure is
   designed so that the reissuance of all certificates below the CA in
   the RPKI hierarchy is not required.  Of course, it is necessary to
   re-sign all certificates issued directly under the CA whose key is
   changing.  However, the SIA and AIA pointers within the certificates
   are populated so that no further reissuance is required.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  ROA Management</span>

   Whenever a holder of IP address space wants to authorize an AS to
   originate routes for a prefix within his holdings, he MUST issue an
   end-entity certificate containing that prefix in an IP Address
   Delegation extension.  He then uses the corresponding private key to
   sign a ROA containing the designated prefix and the AS number for the
   AS.  The resource holder MAY include more than one prefix in the EE
   certificate and corresponding ROA if desired.  As a prerequisite,
   then, any address space holder that issues ROAs for a prefix must
   have a resource certificate for an allocation containing that prefix.
   The standard procedure for issuing a ROA is as follows:

      1. Create an end-entity certificate containing the prefix(es) to
         be authorized in the ROA.

      2. Construct the payload of the ROA, including the prefixes in the
         end-entity certificate and the AS number to be authorized.

      3. Sign the ROA using the private key corresponding to the end-
         entity certificate (the ROA is comprised of the payload
         encapsulated in a CMS signed message [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>]).

      4. Upload the end-entity certificate and the ROA to the repository
         system.

   The standard procedure for revoking a ROA is to revoke the
   corresponding end-entity certificate by creating an appropriate CRL
   and uploading it to the repository system.  The revoked ROA and end-
   entity certificate SHOULD be removed from the repository system.

   Care must be taken when revoking ROAs in that revoking a ROA may
   cause a relying party to treat routing advertisements corresponding
   to the prefixes and origin AS number in the ROA as unauthorized (and
   potentially even change routing behavior to no longer forward packets
   based on those advertisements).  In particular, resource holders
   should adhere to the principle of "make before break" as follows.
   Before revoking a ROA corresponding to a prefix that the resource
   holder wishes to be routable on the Internet, it is very important
   for the resource holder to ensure that there exists another valid



<span class="grey">Lepinski &amp; Kent               Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   alternative ROA that lists the same prefix (possibly indicating a
   different AS number).  Additionally, the resource holder should
   ensure that the AS indicated in the valid alternative ROA is actually
   originating routing advertisements to the prefixes in question.
   Furthermore, a relying party must fetch new ROAs from the repository
   system before taking any routing action in response to a ROA
   revocation.

<span class="h4"><a class="selflink" id="section-7.3.1" href="#section-7.3.1">7.3.1</a>.  Single-Homed Subscribers</span>

   In BGP, a single-homed subscriber with Provider Aggregatable (PA)
   address space does not need to explicitly authorize routes to be
   originated for the prefix(es) it is using, since its ISP will already
   advertise a more general prefix and route traffic for the
   subscriber's prefix as an internal function.  Since no routes are
   originated specifically for prefixes held by these subscribers, no
   ROAs need to be issued under their allocations; rather, the
   subscriber's ISP will issue any necessary ROAs for its more general
   prefixes under resource certificates from its own allocation.  Thus,
   a single-homed subscriber with an IP address allocation from his
   service provider is not included in the RPKI, i.e., it does not
   receive a CA certificate, nor issue EE certificates or ROAs.

<span class="h4"><a class="selflink" id="section-7.3.2" href="#section-7.3.2">7.3.2</a>.  Multi-Homed Subscribers</span>

   Here we consider a subscriber who receives Provider Aggregatable (PA)
   IP address space from a primary ISP (i.e., the IP addresses used by
   the subscriber are a subset of ISP A's IP address space allocation)
   and receives redundant upstream connectivity from one or more
   secondary ISPs, in addition to the primary ISP.  The preferred option
   for such a multi-homed subscriber is for the  subscriber to obtain an
   AS number and run BGP with each of its upstream providers.  In such a
   case, there are two RECOMMENDED ways for ROA management to be
   handled.  The first is that the primary ISP issues a CA certificate
   to the subscriber, and the subscriber issues a ROA to containing the
   subscriber's AS number and the subscriber's IP address prefixes. The
   second possibility is that the primary ISP does not issue a CA
   certificate to the subscriber, and instead issues a ROA on the
   subscriber's behalf that contains the subscriber's AS number and the
   subscriber's IP address prefixes.

   If the subscriber is unable or unwilling to obtain an AS number and
   run BGP, the another option is that the multi-homed subscriber can
   request that the primary ISP create a ROA for each secondary ISP that
   authorizes the secondary ISP to originate routes to the subscriber's
   prefixes.  The primary ISP will also create a ROA containing its own
   AS number and the subscriber's prefixes, as it is likely in such a
   case that the primary ISP wishes to advertise precisely the



<span class="grey">Lepinski &amp; Kent               Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   subscriber's prefixes and not an encompassing aggregate.  Note that
   this approach results in inconsistent origin AS numbers for the
   subscriber's prefixes that are considered undesirable on the public
   Internet; thus, this approach is NOT RECOMMENDED.

<span class="h4"><a class="selflink" id="section-7.3.3" href="#section-7.3.3">7.3.3</a>.  Provider-Independent Address Space</span>

   A resource holder is said to have provider-independent (portable)
   address space if the resource holder received its allocation directly
   from a RIR or NIR.  Because the prefixes represented in such
   allocations are not taken from an allocation held by an ISP, there is
   no ISP that holds and advertises a more general prefix.  A holder of
   a portable IP address space allocation MUST authorize one or more
   ASes to originate routes to these prefixes.  Thus, the resource
   holder MUST generate one or more EE certificates and associated ROAs
   to enable the AS(es) to originate routes for the prefix(es) in
   question.  This ROA is required because none of the ISP's existing
   ROAs authorize it to originate routes to the subscriber's provider-
   independent allocation.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Security Considerations</span>

   The focus of this document is security; hence, security
   considerations permeate this specification.

   The security mechanisms provided by and enabled by this architecture
   depend on the integrity and availability of the infrastructure it
   describes.  The integrity of objects within the infrastructure is
   ensured by appropriate controls on the repository system, as
   described in <a href="#section-4.4">Section 4.4</a>.  Likewise, because the repository system is
   structured as a distributed database, it should be inherently
   resistant to denial-of-service attacks; nonetheless, appropriate
   precautions should also be taken, both through replication and backup
   of the constituent databases and through the physical security of
   database servers.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  IANA Considerations</span>

   Instructions for IANA's participation in the RPKI are provided in
   [<a href="./rfc6491" title="&quot;Resource Public Key Infrastructure (RPKI) Objects Issued by IANA&quot;">RFC6491</a>].











<span class="grey">Lepinski &amp; Kent               Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Acknowledgments</span>

   The architecture described in this document is derived from the
   collective ideas and work of a large group of individuals.  This work
   would not have been possible without the intellectual contributions
   of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of
   APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim
   Christensen and Cathy Murphy of ARIN, Rob Austein of ISC, and Randy
   Bush of IIJ.

   Although we are indebted to everyone who has contributed to this
   architecture, we would like to especially thank Rob Austein for the
   concept of a manifest, Geoff Huston for the concept of managing
   object validity through single-use EE certificate key pairs, and
   Richard Barnes for help in preparing an early version of this
   document.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  References</span>

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC3779">RFC3779</a>]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", <a href="./rfc3779">RFC 3779</a>, June 2004.

   [<a id="ref-RFC4271">RFC4271</a>]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", <a href="./rfc4271">RFC 4271</a>, January
              2006.

   [<a id="ref-RFC5280">RFC5280</a>]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", <a href="./rfc5280">RFC 5280</a>, May 2008.

   [<a id="ref-RFC5652">RFC5652</a>]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              <a href="./rfc5652">RFC 5652</a>, September 2009.

   [<a id="ref-RFC5781">RFC5781</a>]  Weiler, S., Ward, D., and R. Housley, "The rsync URI
              Scheme", <a href="./rfc5781">RFC 5781</a>, February 2010.

   [<a id="ref-RFC6481">RFC6481</a>]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure", <a href="./rfc6481">RFC 6481</a>,
              February 2012.

   [<a id="ref-RFC6482">RFC6482</a>]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", <a href="./rfc6482">RFC 6482</a>, February 2012.



<span class="grey">Lepinski &amp; Kent               Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


   [<a id="ref-RFC6486">RFC6486</a>]  Austein, R., Huston., G., Kent, S., and M. Lepinski,
              "Manifests for the Resource Public Key Infrastructure",
              <a href="./rfc6486">RFC 6486</a>, February 2012.

   [<a id="ref-RFC6487">RFC6487</a>]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", <a href="./rfc6487">RFC 6487</a>, February
              2012.

   [<a id="ref-RFC6488">RFC6488</a>]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
              Template for the Resource Public Key Infrastructure", <a href="./rfc6488">RFC</a>
              <a href="./rfc6488">6488</a>, February 2012.

   [<a id="ref-RFC6491">RFC6491</a>]  Manderson, T., Vegoda, L., and S. Kent, "Resource Public
              Key Infrastructure (RPKI) Objects Issued by IANA", <a href="./rfc6491">RFC</a>
              <a href="./rfc6491">6491</a>, February 2012.

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Informative References</span>

   [<a id="ref-RFC6483">RFC6483</a>]  Huston, G. and G. Michaelson, "Validation of Route
              Origination Using the Resource Certificate Public Key
              Infrastructure (PKI) and Route Origin Authorizations
              (ROAs)", <a href="./rfc6483">RFC 6483</a>, February 2012.

   [<a id="ref-RFC6489">RFC6489</a>]  Huston, G., Michaelson, G., and S. Kent, "Certification
              Authority (CA) Key Rollover in the Resource Public Key
              Infrastructure (RPKI)", <a href="https://www.rfc-editor.org/bcp/bcp174">BCP 174</a>, <a href="./rfc6489">RFC 6489</a>, February 2012.

   [<a id="ref-RFC6490">RFC6490</a>]  Huston, G., Weiler, S., Michaelson, G., and S. Kent,
              "Resource Public Key Infrastructure (RPKI) Trust Anchor
              Locator", <a href="./rfc6490">RFC 6490</a>, February 2012.

   [<a id="ref-RSYNC">RSYNC</a>]    rsync web pages, &lt;<a href="http://rsync.samba.org/">http://rsync.samba.org/</a>&gt;.

   [<a id="ref-S-BGP">S-BGP</a>]    Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway
              Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
              Communications Vol. 18, No. 4, April 2000.

   [<a id="ref-soBGP">soBGP</a>]    White, R., "soBGP", May 2005,
              &lt;<a href="ftp://ftp-eng.cisco.com/sobgp/index.html">ftp://ftp-eng.cisco.com/sobgp/index.html</a>&gt;












<span class="grey">Lepinski &amp; Kent               Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6480">RFC 6480</a>                    RPKI Architecture              February 2012</span>


Authors' Addresses

   Matt Lepinski
   BBN Technologies
   10 Moulton St.
   Cambridge, MA 02138

   EMail: mlepinski@bbn.com


   Stephen Kent
   BBN Technologies
   10 Moulton St.
   Cambridge, MA 02138

   EMail: kent@bbn.com



































Lepinski &amp; Kent               Informational                    [Page 24]
</pre>