Secure Inter-Domain Routing                                 M. Lepinski
Working Group                                                   S. Kent
Internet Draft                                         BBN Technologies
Intended status: Informational                         November 3, 2008                            March 9, 2009
Expires: May 3, September 9, 2009

           An Infrastructure to Support Secure Internet Routing
                        draft-ietf-sidr-arch-04.txt
                        draft-ietf-sidr-arch-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she

   This Internet-Draft is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 3, 2008. September 9, 2009.

Copyright Notice

   Copyright (C) The (c) 2009 IETF Trust (2008). and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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.

Abstract
   This document describes an architecture for an infrastructure to
   support improved security of Internet routing. The foundation of this
   architecture is a public key infrastructure (PKI) that represents the
   allocation hierarchy of IP address space and Autonomous System
   Numbers; and a distributed repository system for storing and
   disseminating the data objects that comprise the PKI, 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.

Table of Contents

   1. Introduction...................................................3
   2. PKI for Internet Number Resources..............................4 Resources..............................5
      2.1. Role in the overall architecture..........................5
      2.2. CA Certificates...........................................5 Certificates...........................................6
      2.3. End-Entity (EE) Certificates..............................7
      2.4. Trust Anchors.............................................8
      2.5. Default Trust Anchor Considerations.......................8 Considerations.....Error! Bookmark not
      defined.
      2.6. Representing Early-Registration Transfers (ERX)..........10 (ERX)...........9
   3. Route Origination Authorizations..............................10
      3.1. Role in the overall architecture.........................11 architecture.........................10
      3.2. Syntax and semantics.....................................11
   4. Repositories..................................................13 Repositories..................................................12
      4.1. Role in the overall architecture.........................14 architecture.........................13
      4.2. Contents and structure...................................14 structure...................................13
      4.3. Access protocols.........................................16 protocols.........................................15
      4.4. Access control...........................................16 control...........................................15
   5. Manifests.....................................................17 Manifests.....................................................16
      5.1. Syntax and semantics.....................................17 semantics.....................................16
   6. Local Cache Maintenance.......................................18 Maintenance.......................................17
   7. Common Operations.............................................18
      7.1. Certificate issuance.....................................19 issuance.....................................18
      7.2. ROA management...........................................20 management...........................................19
         7.2.1. Single-homed subscribers (without portable allocations)
         ...........................................................20
         7.2.2. Multi-homed subscribers.............................21 subscribers.............................20
         7.2.3. Portable allocations................................21
      7.3. Route filter construction................................22 construction......Error! Bookmark not defined.
   8. Security Considerations.......................................23 Considerations.......................................21
   9. IANA Considerations...........................................24 Considerations...........................................21
   10. Acknowledgments..............................................24 Acknowledgments..............................................21
   11. References...................................................25 References...................................................23
      11.1. Normative References....................................25 References....................................23
      11.2. Informative References..................................25 References..................................23
   Authors' Addresses...............................................26 Addresses...............................................24
   Intellectual Property Statement..................................26 Statement..................................24
   Disclaimer of Validity...........................................27 Validity.................Error! Bookmark not defined.

1. Introduction

   This document describes an architecture for an infrastructure to
   support improved security for BGP routing [2] for the Internet. The
   architecture encompasses three principle elements:

     . a public key infrastructure (PKI)

     . digitally-signed routing objects to support routing security

     . 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 S-BGP [10] S-
   BGP [11] or soBGP [11]. [12]. 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 PKIX [3] and the extensions for IP Addresses and
   AS numbers representation defined in RFC 3779 [5]. Also CMS [4] is
   used as the syntax for the newly-defined signed objects required by
   this infrastructure.

   As noted above, the infrastructure 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/CRL 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; this document describes how they can be used to
   improve route filter generation, and to perform several other common
   operations in such a way as to make them cryptographically
   verifiable.

1.1. Terminology

   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" [3], and "X.509
   Extensions for IP Addresses and AS Identifiers" [5].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in

   Throughout this document are to be interpreted as described in RFC-2119 [1].

2. PKI for Internet Number Resources

   Because we use the holder terms "address space holder" or
   "holder of a block IP address space is entitled space" interchangeably to define
   the topological destination refer to a legitimate
   holder of IP datagrams whose destinations fall
   within that block, decisions about inter-domain routing are
   inherently based on knowledge address space who has received this address space
   through the standard IP address allocation of hierarchy. That is, the IP
   address space.
   Thus, a basic function of this architecture is to provide
   cryptographically verifiable attestations as to these allocations. In
   current practice, space holder has either directly received the address space
   as an allocation of IP 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. We use the term "subscriber" to
   refer to an entity (e.g., an enterprise) that receives an IP address
   space and/or AS number allocation, but does not sub-allocate its
   resources.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].

2. PKI for Internet Number Resources

   Because the holder of a block 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
   cryptographically verifiable attestations as to these allocations. In
   current practice, the allocation of IP addresses is hierarchic. 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 and
   (NIRs) as well as Local Internet Registries (LIRs) and subscribers
   with so-called ''portable'' "portable" (provider-independent) 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 portable allocations.

   In general, the holder of a set block of IP addresses address space may sub-allocate sub-
   allocate portions of that set, 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 regional RIRs or national registries. NIRs. Thus allocations of both IP
   addresses and AS numbers can be expressed by the same PKI.  Such a
   PKI is a central component of this architecture.

2.1. Role in the overall architecture

   Certificates in this PKI are called Resource Certificates, and
   conform to the certificate profile for such certificates [6].
   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 RFC 3779 [5].

   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.'' "descriptive." That is, this 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 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 CA. Certificate 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). Additionally, signed objects called manifests
   will be used to help ensure the integrity of the repository system,
   and the signature on each manifest will be verified via an EE
   certificate.

2.2. CA Certificates

   Any resource holder of Internet resources who is authorized to sub-allocate
   them 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.  A CA
   certificate also 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 subscribers entities that do not sub-
   allocate their resources also will need to have CA certificates for
   their allocations, e.g., subscribers a multi-homed subscriber with a portable allocations,
   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
   Section 6.2.2) 7.2.2)

   Unlike in most PKIs, the distinguished name of the subject in a CA
   certificate is chosen by the certificate issuer. If the subject of a
   certificate is an RIR or IANA, then the distinguished name of the
   subject will be chosen to convey the identity of the registry and
   should consist of (a subset of) the following attributes: country,
   organization, organizational unit, and common name. For example, an
   appropriate subject name for the APNIC RIR might be:

      . Country: AU

      . Organization: Asia Pacific Network Information Centre

      . Common Name: APNIC Resource Certification Authority

   If the subject of a certificate is not an RIR or IANA, (e.g.,
   the subject is a NIR, or LIR/ISP) the distinguished name MUST consist
   only of the common name attribute and must not
   attempt to convey the identity of the subject in a descriptive
   fashion. Additionally, the The subject's distinguished name must be unique among all
   certificates issued by a given authority. In this PKI, the
   certificate issuer, being an internet registry 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 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 common name in issued certificates.

   Each Resource Certificate attests to an allocation of resources to
   its a
   resource holder, so entities that have allocations from multiple
   sources will have multiple CA certificates. 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.

2.3. End-Entity (EE) Certificates

   The private key corresponding to 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
   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.

   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 holder of
   the specified resources.
   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 this
   is not required for the private keys associated with end-entity
   certificates keys used for verification of ROAs and manifests, as
   described above.

2.4. Trust Anchors

   In any PKI, each relying party (RP) is free to choose chooses its own set of trust
   anchors. This general property of PKIs applies here as well. There is
   an extant IP address space and AS number allocation
   hierarchy. hierarchy, and
   thus IANA is the obvious candidate to be the TA, but
   operational considerations may argue for a multi-TA PKI, e.g., one in
   which both IANA and and/or the five RIRs form a are obvious candidates to be default set of trust anchors.
   TAs here. Nonetheless, every relying party is free to choose a different each RP ultimately chooses the set of trust
   anchors to it will use for certificate validation operations. validation.

   For example, an a 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 certificate certification paths
   terminating at this locally-installed trust anchor will satisfy the
   RFC 3779 validation requirements.

   An A large ISP that uses private
   (i.e., RFC 1918) IP address space and runs BGP internally will need
   to create this sort of trust anchor to accommodate a CA to which all
   private (RFC 1918) 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 a 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.

2.5. Default Trust Anchors

   The profile for resource certificates [6] specifies a format for a
   putative trust anchor to distribute to relying

   It is expected that some parties trust anchor
   material consisting of both a self-signed certificate (which would
   form the root of certification paths in the PKI) along with an
   additional 'trust anchor' certificate used to validate the self-
   signed certificate. Any entity claiming authoritative information
   regarding the allocation of a portion of IP address space may offer
   itself up in the role of a putative trust anchor by distributing such
   material (in an out-of-band fashion). Given within the extant IP address space
   and AS number allocation hierarchy, it is envisioned that IANA
   and the five RIRs will provide hierarchy may wish to publish trust anchor information to relying
   parties and that
   material for possible use by relying parties will generally accept parties. A standard profile for
   the publication of trust anchors
   from anchor material for this set. public key
   infrastructure can be found in [9].

2.5. Representing Early-Registration Transfers (ERX)

   Currently, IANA forms the root of the extant IP allocates IPv4 address space and AS number
   allocation hierarchy. Therefore, it is expected that IANA will
   provide to relying parties trust anchor material whose self-signed
   certificate has RFC 3779 extensions corresponding either to the
   entirety of IP address space, or alternatively that portion RIRs at the level
   of IP
   address space /8 prefixes. However, there exist allocations that has not been sub-allocated to any of the five
   RIRs.

   As cross these RIR
   boundaries. For example, A LACNIC customer may have an example of the use of IANA as a trust anchor, consider the use
   of private IP address space (i.e., 10/8, 172.16/12, and 192.168/16 in
   IPv4 and FC00::/7 in IPv6). IANA could issue allocation
   that falls within a CA certificate for
   these blocks of private address space and then destroy the private
   key corresponding to the public key in /8 prefix administered by ARIN. Therefore, the certificate. In this way,
   any relying party who configured IANA as their sole trust anchor
   would automatically reject any ROA containing private addresses,
   appropriate behavior with regard
   resource PKI must be able to routing in the public Internet.
   On the other hand, represent such an approach would not interfere with an
   organization that wishes transfers from one RIR to use private address space
   another in conjunction
   with BGP and this PKI technology. Such an organization could
   configure its relying parties with an additional, local trust anchor a manner that issues certificates for private addresses used within the
   organization. In this manner, BGP advertisements for these private
   addresses would be accepted within the organization but would be
   rejected if mistakenly sent outside the private address space context
   in question.

   In the DNSSEC context, IANA (as permits the root validation of the DNS) is already
   experimenting with the operational procedures needed to digitally
   sign the root zone. This is very much analogous to the role it would
   play if it were to act as the default trust anchor for the RPKI, even
   though DNSSEC does not make use of X.509 certificates. Nonetheless,
   it is appropriate consider alternative default trust anchor models,
   if IANA does not act in this capacity. This motivates the
   consideration of alternative default trust anchor options for RPKI
   relying parties.

   Essentially all allocated IP address and AS number resources are sub-
   allocated by IANA to one of the five RIRs. Therefore, it is expected
   that each of the five RIRs will provide trust anchor material provide
   to relying parties trust anchor material whose self-signed
   certificate has RFC 3779 extensions corresponding to the IP address
   and AS number resources that they manage.

   One issue that the RIRs will need to consider when providing trust
   anchor material is how to handle the approximately 49 /8 prefixes
   containing legacy IPv4 allocations that are not each allocated to a
   single RIR. Currently, for the purpose of administering reverse DNS
   zones, each of these prefixes is administered by a single RIR who
   delegates authority for allocations within the prefix as appropriate.
   This existing arrangement could be used as the template for the
   assignment of administrative responsibility for the certification of
   these address blocks in the RPKI. Such an arrangement would in no way
   alter the administrative arrangements and the associated policies
   that apply to the individual legacy allocations that have been made
   from these address blocks.

2.6. Representing Early-Registration Transfers (ERX)

   Currently, IANA allocates IPv4 address space to the RIRs at the level
   of /8 prefixes. However, there exist allocations that cross these RIR
   boundaries. For example, A LACNIC customer may have an allocation
   that falls within a /8 prefix administered by ARIN. Therefore, the
   resource PKI must be able to represent such transfers from one RIR to
   another in a manner that permits the validation of certificates certificates with
   RFC 3779 extensions.

                       +-------------------------------+
                       |                               |
                       |      LACNIC Administrative    |
                       |             Boundary          |
                       |                               |
        +--------+     |           +--------+          |      +--------+
        |  ARIN  |     |           | LACNIC |          |      |  RIPE  |
        |  ROOT  |     |           |  ROOT  |          |      |  ROOT  |
        +--------+     |           +--------+          |      +--------+
                \      |                               |       /
                 ------------                      ------------
                       |     \                    /    |
                       |   +--------+     +--------+   |
                       |   | LACNIC |     | LACNIC |   |
                       |   |   CA   |     |   CA   |   |
                       |   +--------+     +--------+   |
                       |                               |
                       +-------------------------------+

                          FIGURE 1: Representing EXR
   To represent such transfers, RIRs will need to manage multiple CA
   certificates, each with distinct public (and corresponding private)
   keys. Each RIR will have a single ''root'' "root" certificate (e.g., a self-
   signed certificate or a certificate signed by IANA, see Section 2.5),
   plus one additional CA certificate for each RIR from which it
   receives a transfer. Each of these additional CA certificates will be
   issued under the ''root'' "root" certificate of the RIR from which the
   transfer is received. This means that although the certificate is
   bound to the RIR that receives the transfer, for the purposes of
   certificate path construction and validation, it does not appear
   under that RIR's ''root'' "root" certificate (see Figure 1).

3. Route Origination Authorizations

   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 originate routes to a
   given set of prefixes.

3.1. Role in the overall architecture

   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
   [7].  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. These filters would prevent importation of any route in
   which (See [14] for information on the origin AS use of the AS-PATH attribute is not an AS that is
   authorized (via a valid ROA) ROAs
   to originate validate the route. (See Section 6.3
   for more details.) 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.

3.2. Syntax and semantics

   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. A detailed specification of the ROA syntax can be
   found in [7] but, at a high level, a ROA consists of (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 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 certificate in the PKI. In order for a ROA to be
   valid, its corresponding end-entity (EE) 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 RFC 3779
   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 invoking 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 revoked within time that time is quite low.

             ---------                ---------
             |  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 2: This figure illustrates an ISP with allocations from two
   sources (and RIR and an NIR). It needs two CA certificates due to RFC
   3779 rules.

   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.

4. Repositories

   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 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
   Section 5) 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 to 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.

4.1. Role in the overall architecture

   The repository system is the central 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
   [9].
   [10].

4.2. Contents and structure

   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.

   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 Authority (SIA) extension provides a URI that references
   this directory. Additionally, a certificate's Authority Information
   Authority (AIA) extension 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).

                   +--------+
        +--------->| Cert A |<----+
        |          | CRLDP  |     |        +---------+
        |          |  AIA   |     |    +-->| A's CRL |<-+
        |  +--------- SIA   |     |    |   +---------+  |
        |  |       +--------+     |    |                |
        |  |                      |    |                |
        |  |                  +---+----+                |
        |  |                  |   |                     |
        |  |  +---------------|---|-----------------+   |
        |  |  |               |   |                 |   |
        |  +->|   +--------+  |   |   +--------+    |   |
        |     |   | Cert B |  |   |   | Cert C |    |   |
        |     |   | CRLDP ----+   |   | CRLDP -+--------+
        +----------- AIA   |      +----- AIA   |    |
              |   |  SIA   |          |  SIA   |    |
              |   +--------+          +--------+    |
              |                                     |
              +-------------------------------------+

   FIGURE 3: In this example, certificates B and C are issued under
   certificate A. Therefore, the AIA extensions of certificates B and C
   point to A, and the SIA extension of certificate A points to the
   directory containing certificates B and C.

   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.

4.3. Access protocols

   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 need
   implement all of these functions (although this may be the case), but
   each function must be implemented by at least one access protocol.

   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
   Section 4.4).

   Current efforts to implement a repository system use RSYNC [12] as
   the single access protocol.  RSYNC, as used in this implementation,
   provides all of the above functionality. A document specifying the
   conventions for use of RSYNC in the PKI will be prepared.

4.4. Access control

   In order to maintain the integrity of information in the repository,
   controls must be put in place to prevent 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 Section 2.3
   above.

5. Manifests

   A manifest is a signed object listing of all of the signed objects
   issued by an authority responsible for a publication in the
   repository system. For each certificate, CRL, or ROA issued by the
   authority, are issued under
   certificate A. Therefore, the manifest contains both AIA extensions of certificates B and C
   point to A, and the name SIA extension of certificate A points to the file
   directory containing
   the object, certificates B and C.

   If a hash of the file content.

   As with ROAs, a manifest CA certificate is signed by a private key, for which reissued with the
   corresponding same public key appears in key, it should
   not be necessary to reissue (with an end-entity certificate. This
   EE certificate, in turn, is updated AIA URI) all
   certificates signed by the CA in question. The EE certificate private key may be used to issue one for more manifests.
   If the private key is used to sign only being reissued. Therefore, a single manifest, then the
   manifest can be revoked by revoking the EE certificate. In such
   certification authority SHOULD use a
   case, to avoid needless CRL growth, persistent URI naming scheme for
   issued certificates. That is, reissued certificates should use the EE certificate used to
   validate a manifest SHOULD expire at
   same publication point as previously issued certificates having the
   same time subject and public key, and should overwrite such certificates.

4.3. Access protocols

   Repository operators will choose one or more access protocols that the manifest
   expires. If an EE certificate is used
   relying parties can use to issue multiple (sequential)
   manifests for access the CA in question, then there is no revocation
   mechanism for these individual manifests.

   Manifests may repository system.  These
   protocols will be used by relying parties when constructing a local
   cache (see Section 6) to mitigate numerous participants in the risk infrastructure
   (e.g., all registries, ISPs, and multi-homed subscribers) to maintain
   their respective portions of an attacker who deletes
   files from a repository or replaces current signed objects with stale
   versions it.  In order to support these
   activities, certain basic functionality is required of the same object. Such protection is needed because
   although suite of
   access protocols, as described below.  No single access protocol need
   implement all objects in of these functions (although this may be the repository system are signed, case), but
   each function must be implemented by at least one access protocol.

   Download: Access protocols MUST support the bulk download of
   repository system itself is untrusted.

5.1. Syntax contents and semantics

   A manifest constitutes a list subsequent download of (the hashes of) all changes to the files
   downloaded contents, since this will be the most common way in a which
   relying parties interact with the repository point at a particular point in time. A detailed
   specification system.  Other types of manifest syntax is provided in [8] but, at a high
   level, a manifest consists
   download interactions (e.g., download of (1) a manifest number; (2) the time the
   manifest was issued; (3) the time of single object) MAY also be
   supported.

   Upload/change/delete: Access protocols MUST also support mechanisms
   for the next planned update; and (4)
   a list issuers of filename certificates, CRLs, and hash value pairs.

   The manifest number is a sequence number that is incremented each
   time a manifest is issued by other signed objects to
   add them to the authority. An authority is required repository, and to issue a new manifest any time it alters any of its items remove them.  Mechanisms for
   modifying objects in the
   repository, repository MAY also be provided.  All access
   protocols that allow modification to the repository (through
   addition, deletion, or when the specified time modification of its contents) MUST support
   verification of the next update is reached.
   A manifest is thus valid until the specified time authorization of the next update
   or until a manifest is issued with a greater manifest number,
   whichever comes first. (Note entity performing the
   modification, so that when an EE certificate is used appropriate access controls can be applied (see
   Section 4.4).

   Current efforts to
   sign only implement a single manifest, whenever the authority issues the new
   manifest, repository system use RSYNC [13] as
   the CA MUST also issue a new CRL which includes single access protocol.  RSYNC, as used in this implementation,
   provides all of the EE
   certificate corresponding to above functionality. A document specifying the old manifest. The revoked EE
   certificate
   conventions for use of RSYNC in the old manifest PKI will be removed from the CRL when it
   expires, thus this procedure ought not result in significant CRLs
   growth.)

6. Local Cache Maintenance prepared.

4.4. Access control

   In order to utilize signed objects issued under this PKI (e.g. for
   route filter construction, see Section 6.3), a relying party maintain the integrity of information in the repository,
   controls must
   first obtain a local copy be put in place to prevent addition, deletion, or
   modification of objects in the valid EE certificates for repository by unauthorized parties.
   The identities of parties attempting to make such changes can be
   authenticated through the PKI.
   To do so, relevant access protocols.  Although
   specific access control policies are subject to the relying party performs local control of
   repository operators, it is recommended that repositories allow only
   the following steps:

     1. Query issuers of signed objects to add, delete, or modify them.

   Alternatively, it may be advantageous in the registry system future to obtain define a copy
   formal delegation mechanism to allow resource holders to authorize
   other parties to act on their behalf, as suggested in Section 2.3
   above.

5. Manifests

   A manifest is a signed object listing of all certificates,
        manifests and CRLs of the signed objects
   issued under by an authority responsible for a publication in the PKI.

     2.
   repository system. For each CA certificate in the PKI, verify certificate, CRL, or ROA issued by the signature on
   authority, the
        corresponding manifest. Additionally, verify that manifest contains both the current
        time is earlier than name of the time indicated in file containing
   the nextUpdate field object, and a hash of the manifest.

     3. For each manifest, verify that certificates and CRLs issued
        under file content.

   As with ROAs, a manifest is signed by a private key, for which the
   corresponding CA certificate match the hash values
        contained public key appears in an end-entity certificate. This
   EE certificate, in turn, is signed by the manifest. CA in question. The EE
   certificate private key may be used to issue one for more manifests.
   If the hash values do not match, use
        an out-of-band mechanism private key is used to notify sign only a single manifest, then the appropriate repository
        administrator that
   manifest can be revoked by revoking the repository data has been corrupted.

     4. Validate each EE certificate by constructing and verifying certificate. In such a
        certification path for
   case, to avoid needless CRL growth, the EE certificate (including checking
        relevant CRLs) used to the locally configured set of TAs. (See [6]
        for more details.)

   Note
   validate a manifest SHOULD expire at the same time that when a relying party performs these operations regularly,
   it the manifest
   expires. If an EE certificate is more efficient used to issue multiple (sequential)
   manifests for the CA in question, then there is no revocation
   mechanism for these individual manifests.

   Manifests may be used by relying party parties when constructing a local
   cache (see Section 6) to request from mitigate the risk of an attacker who deletes
   files from a repository system only those or replaces current signed objects that have changed since with stale
   versions of the
   relying party last updated its local cache. Note also that by
   checking same object. Such protection is needed because
   although all issued objects against in the appropriate manifest, repository system are signed, the
   relying party can be certain that it
   repository system itself is not missing an updated
   version of any object.

7. Common Operations

   Creating untrusted.

5.1. Syntax and maintaining the infrastructure described above will
   entail additional operations as ''side effects'' semantics

   A manifest constitutes a list of normal resource
   allocation and routing authorization procedures.  For example, (the hashes of) all the files in a
   subscriber with ''portable'' address space who entes
   repository point at a relationship
   with an ISP will need to issue one or more ROAs identifying that ISP, particular point in addition to conducting any other necessary technical or business
   procedures.  The current primary use time. A detailed
   specification of this infrastructure manifest syntax is for
   route filter construction; using ROAs, route filters can be
   constructed provided in an automated fashion with [8] but, at a high assurance that
   level, a manifest consists of (1) a manifest number; (2) the time the
   manifest was issued; (3) the
   holder time of the advertised prefix has authorized the first-hop AS to
   originate an advertised route.

7.1. Certificate issuance

   There are several operational scenarios that require certificates to
   be issued.  Any allocation that may be sub-allocated requires next planned update; and (4)
   a CA
   certificate, e.g., so that certificates can be issued as necessary
   for the sub-allocations. Holders list of ''portable'' address allocations
   also must have certificates, so that filename and hash value pairs.

   The manifest number is a ROA can be issued to each ISP sequence number that is authorized to originate incremented each
   time a route to the allocation (since manifest is issued by the
   allocation does not come from any ISP). Additionally, multi-homed
   subscribers may require certificates for their allocations if they
   intend authority. An authority is required
   to issue a new manifest any time it alters any of its items in the ROAs for their allocations (see Section 6.2.2).
   Other holders
   repository, or when the specified time of resources need not be issued CA certificates within the PKI.

   In next update is reached.
   A manifest is thus valid until the long run, specified time of the next update
   or until a resource holder will not request resource
   certificates, but rather receive manifest is issued with a greater manifest number,
   whichever comes first. (Note that when an EE certificate as is used to
   sign only a side effect of single manifest, whenever the allocation process for authority issues the resource. However, initial deployment
   of new
   manifest, the RPKI will entail issuance of certificates CA MUST also issue a new CRL which includes the EE
   certificate corresponding to existing resource
   holders as an explicit event. Note that in all cases, the authority
   issuing a CA old manifest. The revoked EE
   certificate for the old manifest will be removed from the entity who allocates resources CRL when it
   expires, thus this procedure ought not to the subject. This differs from most PKIs result in which a subject can
   request a certificate from any certification authority.

   If significant CRLs
   growth.)

6. Local Cache Maintenance

   In order to utilize signed objects issued under this PKI, a resource holder receives multiple allocations over time, it may
   accrue relying
   party must first obtain a collection local copy of resource the valid EE certificates for
   the PKI. To do so, the relying party performs the following steps:

     1. Query the registry system to attest to them.  If obtain a
   resource holder receives multiple allocations from copy of all certificates,
        manifests and CRLs issued under the same source, PKI.

     2. For each CA certificate in the set of resource certificates may be combined into a single
   resource certificate, if both PKI, verify the issuer and signature on the resource holder
   agree. This
        corresponding manifest. Additionally, verify that the current
        time is effected by consolidating earlier than the IP Address Delegation
   and AS Identifier Delegation Extensions into a single extension (of
   each type) time indicated in a new certificate.  However, if the nextUpdate field
        of the manifest.

     3. For each manifest, verify that certificates for
   these allocations contain different validity intervals, creating a and CRLs issued
        under the corresponding CA certificate match the hash values
        contained in the manifest. Additionally, verify that combines them might create problems, and thus 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 NOT
   RECOMMENDED.

   If a resource holder's allocations come from different sources, they
   will be signed missing, notify the appropriate repository
        administrator that the repository data has been corrupted.

     4. Validate each EE certificate by different CAs, constructing and cannot be combined.  When verifying a
        certification path for the certificate (including checking
        relevant CRLs) to the locally configured set of resources is no longer allocated to TAs. (See [6]
        for more details.)

   Note that when a resource holder, any
   certificates attesting to such an allocation MUST be revoked. A
   resource holder SHOULD NOT to use relying party performs these operations regularly,
   it is more efficient for the same public key in multiple CA
   certificates that are issued by relying party to request from the same or differing authorities, as
   reuse of a key pair complicates path construction. Note
   repository system only those objects that have changed since the subject's distinguished name is chosen by the issuer, a subject
   who receives allocations
   relying party last updated its local cache. A relying party may
   choose any frequency it desires for downloading and validating
   updates from two sources generally will receive
   certificates with different subject names.

7.2. ROA management

   Whenever the repository. However, a holder of IP address space wants to authorize an AS typical ISP might reasonably
   choose to
   originate routes for perform these operations on a prefix within his holdings, he MUST issue an
   end-entity certificate containing daily schedule.  Note also
   that prefix in an IP Address
   Delegation extension. He then uses the corresponding private key to
   sign a ROA containing by checking all issued objects against the designated prefix and appropriate manifest,
   the AS number for relying party can be certain that it is not missing an updated
   version of any object.

7. Common Operations

   Creating and maintaining the
   AS.  The infrastructure described above will
   entail additional operations as "side effects" of normal resource holder MAY include more than one prefix in the EE
   certificate
   allocation and corresponding ROA if desired. As routing authorization procedures.  For example, a prerequisite,
   then, any
   subscriber with "portable" address holder that issues ROAs for a prefix must have space who enters a
   resource certificate for relationship
   with an allocation containing ISP will need to issue one or more ROAs identifying that prefix. ISP,
   in addition to conducting any other necessary technical or business
   procedures.  The
   standard procedure for issuing a ROA current primary use of this infrastructure is as follows:

     1. Create an end-entity certificate containing the prefix(es) to for
   route filter construction; using ROAs, route filters can be
        authorized
   constructed in an automated fashion with high assurance that the ROA.

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

     3. Sign the ROA using the private key corresponding
   originate an advertised route.

7.1. Certificate issuance

   There are several operational scenarios that require certificates to the end-
        entity certificate (the ROA is comprised of the payload
        encapsulated in
   be issued.  Any allocation that may be sub-allocated requires a CMS signed message [7]).

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

   The standard procedure CA
   certificate, e.g., so that certificates can be issued as necessary
   for revoking the sub-allocations. Holders of "portable" IP address space
   allocations also must have certificates, so that a ROA can be issued
   to each ISP that is authorized to revoke the
   corresponding end-entity certificate by creating an appropriate CRL
   and uploading it originate a route to the repository system.  The revoked ROA and end-
   entity certificate SHOULD BE removed from allocation
   (since the repository system.

7.2.1. Single-homed subscribers (without portable allocations)

   In BGP, a single-homed subscriber with a non-portable allocation 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 come from any ISP). Additionally,
   multi-homed subscribers may require certificates for their
   allocations if they intend to issue the subscriber's prefix as an
   internal function.  Since no routes are originated specifically for
   prefixes held by these subscribers, no ROAs for their allocations
   (see Section 7.2.2). Other resource holders need to not be issued under
   their allocations; rather, CA
   certificates within the subscriber's ISP PKI.

   In the long run, a resource holder will issue any
   necessary ROAs for its more general prefixes under not request resource
   certificates its own allocation. Thus,
   certificates, but rather receive a single-homed subscriber with certificate as a non-portable side effect of
   the allocation is not included in process for the RPKI, i.e., it does
   not receive a CA certificate, nor issue EE resource. However, initial deployment
   of the RPKI will entail issuance of certificates or ROAs.

7.2.2. Multi-homed subscribers

   In order for multiple ASes to originate routers for prefixes held by
   a multi-homed subscriber, each AS must have a ROA that explicitly
   authorizes such route origination. There are two ways that this can
   be accomplished.

   One option is for existing resource
   holders as an explicit event. Note that in all cases, the multi-homed subscriber to obtain authority
   issuing a CA certificate from will be the ISP entity who allocated the prefixes allocates resources
   to the
   subscriber. The multi-homed subscriber subject. This differs from most PKIs in which a subject can then create
   request a ROA (and
   associated end-entity certificate) that authorizes certificate from any certification authority.

   If a second ISP resource holder receives multiple allocations over time, it may
   accrue a collection of resource certificates to
   originate routes attest to them.  If a
   resource holder receives multiple allocations from the subscriber prefix(es). The ROA for same source,
   the second
   ISP generally SHOULD be set to require an exact match, of resource certificates may be combined into a single
   resource certificate, if both the intent
   is to enable backup paths for the prefix. Note that issuer and the first ISP,
   who allocated resource holder
   agree. This is accomplished by consolidating the prefixes, will want to advertise IP Address
   Delegation and AS Identifier Delegation Extensions into a single
   extension (of each type) in a new certificate.  However, if the more specific
   prefix
   certificates for this subscriber (vs. the encompassing prefix). Either the
   subscriber or the first ISP will need to issue an EE these allocations contain different validity
   intervals, creating a certificate that combines them might create
   problems, and
   ROA for the (more specific) prefix, authorizing this ISP thus is NOT RECOMMENDED.

   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 advertise
   this more specific prefix. a resource holder, any
   certificates attesting to such an allocation MUST be revoked. A second option is
   resource holder SHOULD NOT use the same public key in multiple CA
   certificates that are issued by the multi-homed subscriber can request same or differing authorities, as
   reuse of a key pair complicates path construction. Note that since
   the ISP that allocated subject's distinguished name is chosen by the prefixes create issuer, a subject
   who receives allocations from two sources generally will receive
   certificates with different subject names.

7.2. ROA that authorizes the
   second ISP management

   Whenever a holder of IP address space wants to authorize an AS to
   originate routes to the subscriber's prefixes. (The ISP
   also creates for a prefix within his holdings, he MUST issue an EE
   end-entity certificate and ROA for its own advertisement of
   the subscriber prefix, as above.) This option does not require containing that prefix in an IP Address
   Delegation extension. He then uses the subscriber be issued corresponding private key to
   sign a certificate or participate in ROA
   management. Therefore, this option is simpler for containing the subscriber, designated prefix and
   is preferred if the option is supported by the ISP performing AS number for the
   allocation.

7.2.3. Portable allocations

   A
   AS.  The resource holder is said to have a portable (provider independent)
   allocation if MAY include more than one prefix in the resource EE
   certificate and corresponding ROA if desired. As a prerequisite,
   then, any address space holder received its allocation from that issues ROAs for a
   regional or national registry.  Because the prefixes represented in
   such allocations are not taken from prefix must
   have a resource certificate for an allocation held by an ISP,
   there is no ISP containing that holds and advertises a more general prefix. A
   holder of
   The standard procedure for issuing a portable allocation MUST authorize one or more ASes to
   originate routes ROA is as follows:

     1. Create an end-entity certificate containing the prefix(es) to these prefixes. Thus be
        authorized in the resource holder MUST
   generate one or more EE certificates ROA.

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

     3. Sign the AS(es) ROA using the private key corresponding to originate routes for the prefix(es) in question. This end-
        entity certificate (the ROA is required because none comprised of the ISP's existing ROAs authorize it
   to originate routes to that portable allocation.

7.3. Route filter construction

   The goal of this architecture is to support improved routing
   security.  One way to do this is to use ROAs payload
        encapsulated in a CMS signed message [7]).

     4. Upload the end-entity certificate and the ROA to construct route
   filters that reject routes that conflict with the origination
   authorizations asserted by current ROAs. repository
        system.

   The following is intended to
   provide standard procedure for revoking a high-level description of how the architecture might be
   used ROA is to construct a route filter. Additional guidance on revoke the use of
   ROAs
   corresponding end-entity certificate by creating an appropriate CRL
   and uploading it to derive inferences about the validity of BGP UPDATE messages
   is provided in [14]. repository system.  The guidance in [14] is particularly important
   during revoked ROA and end-
   entity certificate SHOULD BE removed from the repository system.

7.2.1. Single-homed subscribers (without portable allocations)

   In BGP, a transition period where single-homed subscriber with a non-portable allocation does
   not all ISPs implement this
   architecture (and thus need to explicitly authorize routes to be originated for the filter described below which naively
   rejects all UPDATES without
   prefix(es) it is using, since its ISP will already advertise a corresponding ROA would incorrectly
   reject valid 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 ISPs that do not yet implement this
   architecture).

     1. Obtain a local copy of all currently valid EE certificates, as
        specified in Section 5.

     2. Query the repository system to obtain a local copy of all these subscribers, no ROAs need to be issued under
   their allocations; rather, the PKI.

     3. Verify that the each ROA matches the hash value contained 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 a non-portable allocation is not included in the
        manifest of the RPKI, i.e., it
   does not receive a CA certificate used to verify the certificate, nor issue EE certificate
        that issued the ROA and that no ROAs are missing.

     4. Validate each ROA by verifying that its signature is verifiable
        by certificates or ROAs.

7.2.2. Multi-homed subscribers (without portable allocations)

   Here we consider a valid end-entity certificate that matches the subscriber who receives IP address
        allocation in space from a
   primary ISP (i.e., the ROA. (See [7] for more details.)

     5. Based on IP addresses used by the validated ROAs, construct subscriber are a table
   subset of prefixes ISP A's IP address space allocation) and
        corresponding authorized origin ASes (or vice versa).

   A BGP speaker that applies receives redundant
   upstream connectivity from the primary ISP, as well as one or more
   secondary ISPs. The preferred option for such a filter multi-homed
   subscribers is thus guaranteed that for
   a given IP address prefix, all routes that the BGP speaker accepts
   for that prefix were originated by subscriber to obtain an AS that is authorized by the
   owner of the prefix to authorize routes number (from an RIR
   or NIR) and run BGP with each of its upstream providers. In such a
   case, there are two ways for ROA management to that prefix. be handled. The first three steps in
   is that the above procedure might incur primary ISP issues a
   substantial overhead if all objects in CA certificate to the repository system were
   downloaded subscriber,
   and validated every time a route filter was constructed.
   Instead, it will be more efficient for users of the infrastructure subscriber issues a ROA to
   initially download all of containing the signed objects subscriber's AS
   number and perform the
   validation algorithm described above. Subsequently, subscriber's IP address prefixes. The second
   possibility is that the primary ISP does not issue a relying party
   need only perform incremental downloads ROA to the
   subscriber, and validations on instead issues a regular
   basis.  A typical ISP using ROA on the infrastructure may choose any
   frequency it desires for downloading updates from subscriber's behalf that
   contains the repository,
   uploading any modifications it has made, subscriber's AS number and constructing route
   filters. However, the subscriber's IP address
   prefixes.

   If the subscriber is unable or unwilling to obtain an AS number and
   run BGP, the other option is that the multi-homed subscriber can
   request that the primary ISP might reasonably choose to perform these
   actions on create a daily schedule.

   It should be noted ROA for each secondary ISP that
   authorizes the transition to 4-byte AS numbers (see RFC
   4893 [13]) weakens the security guarantees achieved by BGP speakers
   who do not support 4-byte AS numbers (referred secondary ISP to as OLD BGP
   speakers). RFC 4893 specifies that all 4-byte AS numbers (except
   those whose first two bytes are entirely zero) be mapped originate routes to the
   reserved value 23456 before being sent to a BGP speaker who does not
   understand 4-byte AS numbers. Therefore, when an subscriber's
   prefixes. The primary ISP creates will also create a route
   filter for use by an OLD BGP speaker, it must allow any 4-byte 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 routes for precisely the
   subscriber's prefixes and not an IP address prefix if there exists a
   ROA encompassing aggregate. Note that authorizes any 4-byte
   this approach results in inconsistent origin AS number to advertise routes numbers for the
   subscribers prefixes which are considered undesirable on the public
   Internet; thus this approach is NOT RECOMMENDED.

7.2.3. Portable allocations

   A resource holder is said to that
   prefix. This means that have a portable (provider independent)
   allocation if an OLD BGP speaker accepts the resource holder received its allocation from a route that
   was originated RIR
   or NIR.  Because the prefixes represented in such allocations are not
   taken from an allocation held by an AS with a 4-byte AS number, ISP, there is no
   guarantee ISP that it was originated by an authorized 4-byte AS number
   (unless 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 route was propagated by an intermediate NEW BGP speaker
   who performed route filtering as described above). 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 that portable allocation.

8. Security Considerations

   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 Section 4.4. 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 servers.

9. IANA Considerations

   This document makes no request of IANA.

   Note requests that the IANA issue RPKI Certificates for the
   resources for which it is authoritative, i.e., reserved IPv4
   addresses, IPv6 ULAs, and address space not yet allocated by IANA to RFC Editor: this section may be removed on publication as an
   RFC
   the RIRs. IANA SHOULD make available trust anchor material in the
   format defined in [10] in support of these functions.

10. Acknowledgments

   The architecture described in this draft 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, Time 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.

11. References

11.1. Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
         (BGP-4)", RFC 4271, January 2006

   [3]   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", RFC
         5280, May 2008.

   [4]   Housley, R., ''Cryptographic "Cryptographic Message Syntax'', Syntax", RFC 3852, July
         2004.

   [5]   Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
         Addresses and AS Identifiers", RFC 3779, June 2004.

   [6]   Huston, G., Michaelson, G., and Loomans, R., "A Profile for
         X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-
         14, October 2008.
         16, February 2009.

   [7]   Lepinski, M., Kent, S., and Kong, D., "A Profile for Route
         Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-04,
         November 2008.

   [8]   Austein, R., et al., ''Manifests "Manifests for the Resource Public Key
         Infrastructure'',
         Infrastructure", draft-ietf-sidr-rpki-manifests-04, October
         2008.

   [9]   Michaelson, G., Kent, S., and Huston, G., "A Profile for Trust
         Anchor Material for the Resource Certificate PKI", draft-ietf-
         sidr-ta-00, February 2009.

11.2. Informative References

   [9]

   [10]  Huston, G., Michaelson, G., and Loomans, R., ''A "A Profile for
         Resource Certificate Repository Structure'', Structure", draft-ietf-sidr-
         repos-struct-01, October 2008.

   [10]

   [11]  Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway
         Protocol (Secure-BGP)'', (Secure-BGP)", IEEE Journal on Selected Areas in
         Communications Vol. 18, No. 4, April 2000.

   [11]

   [12]  White, R., "soBGP", May 2005, <ftp://ftp-
         eng.cisco.com/sobgp/index.html>
   [12]

   [13]   Tridgell, A., "rsync", April 2006,
         <http://samba.anu.edu.au/rsync/>

   [13]  Vohra, Q., and Chen, E., ''BGP Support for Four-octet AS Number
         Space'', RFC 4893, May 2007.

   [14]  Huston, G., Michaelson, G., ''Validation "Validation of Route Origination in
         BGP using the Resource Certificate PKI'', draft-ietf-sidr-
         roa-validation-01, PKI", draft-ietf-sidr-roa-
         validation-01, October 2008.

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

Intellectual Property Statement

   The

Pre-5378 Material Disclaimer

   This document may contain material from IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights Documents or other rights that might be claimed to
   pertain to the implementation IETF
   Contributions published or use of made publicly available before November
   10, 2008. The person(s) controlling the technology described copyright in some of this document or the extent to which any license under such rights
   might or might
   material may not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on have granted the procedures with respect IETF Trust the right to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies allow
   modifications of IPR disclosures made to such material outside the IETF Secretariat and any
   assurances of licenses to be made available, or the result of Standards Process.
   Without obtaining an
   attempt made to obtain a general adequate license or permission for from the use of person(s) controlling
   the copyright in such proprietary rights by implementers or users of materials, this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that document may not be required to implement
   this standard.  Please address the information to modified
   outside the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document Standards Process, and derivative works of it may
   not be created outside the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and Standards Process, except to format
   it for publication as set forth therein, the authors
   retain all their rights. an RFC or to translate it into languages other
   than English.