Secure Inter-Domain Routing                                   R. Barnes                                 M. Lepinski
Working Group                                                   S. Kent
Internet Draft                                         BBN Technologies                                                R. Barnes
Intended status: Informational                        February 23, 2007                         BBN Technologies
Expires: August January 2008                                      July 8, 2007

           An Infrastructure to Support Secure Internet Routing
                        draft-ietf-sidr-arch-00.txt
                        draft-ietf-sidr-arch-01.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 is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   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

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

   This Internet-Draft will expire on August 23, January 8, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes an architecture for an infrastructure to
   support secure 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;
   certificates from this PKI are used to verify signed objects that
   authorize autonomous systems to originate routes for specified IP
   address prefixes. The data objects that comprise the PKI, as well as
   other signed objects necessary for secure routing, are stored and
   disseminated through a distributed repository system. This document
   also describes at a high level how this architecture can be used to
   add security features to common operations such as IP address space
   allocation and route filter construction.

Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   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].

Table of Contents

   1. Introduction...................................................3
   2. PKI for Internet Number Resources..............................4
      2.1. Role in the overall architecture..........................4 architecture..........................5
      2.2. CA Certificates...........................................5
      2.3. End-Entity Certificates...................................5 (EE) Certificates..............................7
      2.4. Trust Anchors.............................................6 Anchors.............................................7
      2.5. Default Trust Anchor Considerations.......................8
      2.6. Representing Early-Registration Transfers (ERX)...........9
   3. Route Origination Authorizations...............................6 Authorizations..............................10
      3.1. Role in the overall architecture..........................7 architecture.........................10
      3.2. Syntax and semantics......................................7
      3.3. Revocation................................................8 semantics.....................................11
   4. Repository system..............................................8 Repositories and Manifests....................................13
      4.1. Role in the overall architecture..........................9 architecture.........................13
      4.2. Contents and structure....................................9 structure...................................13
      4.3. Access protocols.........................................10 Manifests................................................15
      4.4. Access control...........................................10 protocols.........................................16
      4.5. Access control...........................................17
   5. Local Cache Maintenance.......................................17
   6. Common Operations.............................................11
      5.1. Operations.............................................18
      6.1. Certificate issuance.....................................11
      5.2. issuance.....................................18
      6.2. ROA management...........................................12
         5.2.1. management...........................................19
         6.2.1. Single-homed subscribers (without portable allocations)
         ...........................................................12
         5.2.2. Multi-homing........................................13
         5.2.3.
         ...........................................................20
         6.2.2. Multi-homed subscribers.............................20
         6.2.3. Portable allocations................................13
      5.3. allocations................................21
      6.3. Route filter construction................................13
   6. Security Considerations.......................................14 construction................................21

   7. IANA Considerations...........................................14 Security Considerations.......................................22
   8. Acknowledgments...............................................14 IANA Considerations...........................................23
   9. References....................................................15
      9.1. Acknowledgments...............................................23
   10. References...................................................24
      10.1. Normative References.....................................15
      9.2. References....................................24
      10.2. Informative References...................................15 References..................................24
   Author's Addresses...............................................15 Addresses...............................................25
   Intellectual Property Statement..................................16 Statement..................................25
   Disclaimer of Validity...........................................16 Validity...........................................26

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 supports, at a minimum,
   two
   types aspects of routing security: It security; it enables an entity to verifiably
   assert that it is the legitimate holder of a set IP addresses or a
   set of Autonomous System (AS) numbers, and it allows the holder of IP
   address space to explicitly and verifiably authorize an AS one or more ASes
   to originate routes to that address space.  In addition to these
   initial applications, however, the infrastructure defined by this architecture could
   also support, without
   extension, more advanced is intended to be able to support security protocols such as S-BGP [7] S-
   BGP [8] or soBGP [8]. [9].  This architecture is applicable to routing of
   both IPv4 and IPv6 datagrams.

   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, so that structure. Thus management of this architecture 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.  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 [4].

   The architecture [5]. Also CMS [4] is
   used as the syntax for the newly-defined signed objects required by
   this infrastructure.

   As noted above, the infrastructure is comprised of three main
   components: An an X.509
   public-key infrastructure (PKI) where PKI in which certificates attest to holdings of
   IP address space and AS numbers; non-certificate/CRL signed objects called Route
   (Route Origination Authorizations (ROAs) that enable an address space holder
   to explicitly authorize an AS to originate routes to portions of and manifests) used by the
   IP address space;
   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.

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 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 address is hierarchic: 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" (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 of IP addresses may sub-allocate
   portions of that set, either to itself (e.g., to a particular unit of
   the same organization), or to another organization. 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 signing 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 or national registries. 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 Certificate, Certificates, and
   conform to the certificate profile for such certificates [5]. [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. 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 assigned to certificate
   issuers and subjects used in
   certificates are not intended to be meaningful; "descriptive." That is, this PKI
   is intended to provide authorization, but not authentication. This is
   in contrast to most PKIs where considerable effort is expended to ensure 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. This PKI is different because it is an
   authorization PKI, not an authentication PKI. 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. Only the basic PKI requirement, that a CA not
   associate

   Most of the same name with two distinct subjects to whom it issues
   certificates, is imposed.

   The certificates in the PKI assert the basic facts on which
   the rest of the infrastructure operates.  Certificates  CA certificates within the CA hierarchy
   PKI attest to IP address space and AS number holdings.  End-entity
   (EE) certificates are issued by resource holders holder CAs to delegate the
   authority attested by their allocation certificates, the certificates. The primary use
   for this
   being EE certificates is the signing validation of ROAs.  These certificates and corresponding
   certificate revocation lists Route Origination
   Authorizations (ROAs). Additionally, signed objects called manifests
   will comprise a significant portion of be used to help ensure the data stored in integrity of the repository system. system,
   and the signature on each manifest will be verified via an EE
   certificate.

2.2. CA Certificates

   Any holder of Internet Number Resources resources who is authorized to sub-
   allocate sub-allocate
   them must be able to issue Resource Certificates to correspond to
   these sub-allocations.  Thus, for example, CA certificates will be
   associated with each of the Regional Internet
   Registries, National Internet Registries, RIRs, NIRs, and Local Internet
   Registries, as well as with all ISPs. LIRs/ISPs.  A CA
   certificate is also
   necessary for is required to enable a resource holder to issue ROAs (because
   ROAs, because it must also issue the corresponding end-entity certificates certificate
   used to validate
   ROAs), so many each ROA. Thus some subscribers also will need to
   have CA certificates for their allocations (in particular, multi-homed subscribers, and allocations, e.g., subscribers with
   portable allocations). allocations, 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)

   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, 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, (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 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 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 holder, so entities that have allocations from multiple sources
   will have multiple CA certificates. (A A CA also may issue distinct
   certificates for each distinct allocation to the same entity, if the
   issuer
   CA and the resource holder agree that such an arrangement will
   facilitate management and use of the certificates.) 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

   Although the

   The private key corresponding to public key contained in an
   end-entity EE
   certificate is not used to sign other certificates in the
   PKI, the 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. ROAs and manifests.
   For this
   purpose, ROAs and manifests there is 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
   itself to be used to revoke these signed objects.
   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 only the public portions of end-entity certificates
   will need there is no requirement to be retained protect these private
   keys for any significant length an extended period of time.

   Although this document defines only one use 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 indicated specified resources.  This could facilitate authentication of
   inter-ISP interactions, or authentication of interactions with the
   repository system.  These additional uses for end-entity
   certificates, however, 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, ROAs and manifests, as
   described above.

2.4. Trust Anchors

   In any PKI, each relying party (RP) is free to choose its own set of
   trust anchors. In this case, the hierarchy This general property of this PKI PKIs applies here as well.
   There is structured
   according to the an extant IP address space and AS number allocation hierarchy,
   so since administrative control of
   hierarchy. IANA is the IP address space (the root of obvious candidate to be the allocation hierarchy) rests with TA, but
   operational considerations may argue for a multi-TA PKI, e.g., one in
   which both IANA and the RIRs , these
   entities form a natural default set of default trust anchors for this PKI. anchors.
   Nonetheless, every relying party is free to choose a different set of
   trust anchors to use for certificate validation operations.

   For example, an RP (e.g., an LIR/ISP) could create one or more a self-signed certificates
   certificate 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 these this trust anchors anchor to
   whatever entities in the PKI it wishes, with the result that the
   certificate paths terminating at these this locally-installed trust anchors anchor
   will satisfy the RFC 3779 validation requirements.

   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.

2.5. Default Trust Anchor Considerations

   IANA forms the root of the extant IP address space and AS number
   allocation hierarchy. Therefore, it is natural to consider a model in
   which most relying parties have as their single trust anchor a self-
   signed IANA certificate whose RFC 3779 extensions specify the
   entirety of the AS number and IP address and spaces. However, IANA
   has not traditionally acted in an operational capacity as the root of
   the resource allocation hierarchy, much less managed certificates and
   their associated private keys. Therefore it is unclear whether IANA
   is willing to undertake this role as the default trust anchor for the
   PKI. This has prompted the consideration of alternative approaches
   for recommending trust anchors to potential relying parties.

   Essentially all allocated IP address and AS number resources are sub-
   allocated by IANA to one of the five RIRs. Therefore, one could
   consider a model in which the default trust anchors are a set of five
   self-signed certificates, one for each RIR. There are two
   difficulties that such an approach must overcome.

   The first difficulty is that IANA retains authority for 44 /8
   prefixes in IPv4 and a /26 prefix in IPv6. Therefore, any approach
   that recommends the RIRs as default trust anchors will also require
   as a default trust anchor an IANA certificate who's RFC 3779
   extensions correspond to this address space. Additionally, there are
   about 49 /8 prefixes containing legacy 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.

   The second difficulty is that the resource allocations of the RIRs
   may change several times a year. Typically in a PKI, trust anchors
   are quite long-lived and distributed to relying parties via some out-
   of-band mechanism. However, such out-of-band distribution of new
   trust anchors is not feasible if the allocations change every few
   months. Therefore, any approach that recommends the RIRs as default
   trust anchors must provide an in-band mechanism for managing the
   changes that will occur in the RIR allocations (as expressed via RFC
   3779 extensions).

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 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" 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" 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" certificate (see Figure 1).

3. Route Origination Authorizations

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

3.1. Role in the overall architecture

   A ROA is an attestation that the holder of a set of IP addresses prefixes has
   authorized an autonomous system to originate routes for that set of
   IP addresses. those
   prefixes.  A ROA is structured according to the format described in
   [6].
   [7].  The validity of this authorization depends on the issuer signer of the
   ROA being the owner holder of the set of IP addresses 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.  The

   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 ROAs as inputs to route filter construction for use by its
   BGP routers. These filters would prevent importation of any route in
   which the origin AS of the AS-PATH attribute is not an AS that is
   authorized (via a valid ROA) to originate the route. (See Section 6.3
   for more details.)

   Initially, the repository system will be the primary mechanism for
   disseminating ROAs, since
   the operators of these repositories already provide other types routing
   information. will hold the
   certificates and CRLs needed to verify ROAs.  In addition, ROAs could also
   could be distributed in BGP UPDATE messages or via other
   communication paths, since route
   filtering is their primary application. 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  Syntactically, a ROA thus have three essential components:

   1. An AS number

   2. One or more IP address prefixes

   3. A digital signature

   In addition, is a CMS signed-data object
   whose content is defined as follows:

      RouteOriginAttestation ::= SEQUENCE {
         version [0] INTEGER DEFAULT 0,
         asID   ASID,
         exactMatch BOOLEAN,
         ipAddrBlocks ROAIPAddrBlocks }

      ASID ::= INTEGER

      ROAIPAddrBlocks ::= SEQUENCE of ROAIPAddressFamily

      ROAIPAddressFamily ::= SEQUENCE {
         addressFamily OCTET STRING (SIZE (2..3)),
         addresses SEQUENCE OF IPAddress }
       -- Only two address families are allowed: IPv4 and IPv6

      IPAddress ::= BIT STRING

   That is, the signed data within the ROA has consists of a version number, to accommodate changes in
   syntax (or semantics) over time. The
   the AS number contained in a ROA is that is being authorized, and a list of an IP prefixes to
   which the AS is authorized to originate routes. If the exactMatch
   flag is set to TRUE, then the AS is authorized to originate only
   routes for the exact prefix(es) indicated IP
   address prefixes.  Only one in the ROA. Otherwise, if
   the exactMatch flag is set to FALSE, the AS number is contained in a ROA in order authorized to simplify ROA management, e.g.,
   originate routes to avoid the complexity prefix(es) in the ROA as well as any longer
   (more specific) prefixes.

   Note that might
   arise is AS numbers for multiple ISPs were referenced from a ROA contains only a single
   ROA. If AS number. Thus, in cases
   where an ISP serving a subscriber has multiple AS numbers, and
   wants 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 advertisement of the same
   set of prefixes by any of these ASes, the ISP should request the
   subscriber to issue multiple ROAs, each specifying a distinct AS
   number. Similarly, a multi-homed address space holder must generate
   multiple ROAs, one for each ISP that will
   originate routes for it. from any of these ASes.

   A ROA is signed using the private key whose corresponding to the public key is contained
   in an end-entity certificate in the PKI, from which the ROA inherits
   two properties.  First, The IP prefixes listed in the ROA are the
   ones that the indicated AS is authorized to originate; in PKI. In order for
   this authorization (i.e., the ROA) a ROA to be
   valid, its corresponding end-entity (EE) certificate must be valid
   and the IP address prefixes
   contained in a of the ROA must be exactly match the same as the set of IP
   addresses
   address prefix(es) specified in the IP Address Delegation Extension of the end-entity
   certificate used to sign EE certificate's RFC 3779
   extension. Therefore, the ROA.  Second, validity interval of the ROA is valid only as
   long as implicitly
   the certificate used to sign it is valid; a validity interval of its corresponding certificate. A ROA is
   invalidated
   revoked by revoking the end-entity certificate 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 key internet are generally quite long lived. Therefore, as
   long as the EE certificates used to verify it, and the validity interval of the sign a ROA is implicitly that of the are given a validity
   interval of several months, the corresponding
   certificate.

   Address holders likelihood that have many ROAs would need
   to revoked within time that 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 multiple two
   sources must
   issue multiple ROAs.  If (and RIR and an address holder has allocations from
   multiple sources, then these allocations will be described by
   multiple NIR). It needs two CA certificates in the PKI, each issued by the provider of
   the respective allocation; the sets of IP addresses contained in end-
   entity certificates issued by this address holder are required due to be
   subsets of these allocations. RFC
   3779 rules.

   Because end-entity certificates are in
   one-to-one correspondence each ROA is associated with ROAs, this means that a single end-entity certificate,
   the set of IP
   addresses prefixes contained in a ROA must be drawn from an
   allocation by a single source; hence ROAs source, i.e., a ROA cannot combine allocations
   from multiple sources.

3.3. Revocation

   If an address holder decides that Address space holders who have allocations
   from multiple sources, and who wish to authorize an AS should no longer to originate
   routes for addresses that it holds (e.g., if the address holder
   transfers from one ISP these allocations, must issue multiple ROAs to another), then it the AS.

4. Repositories and Manifests

   Initially, an LIR/ISP will be necessary to
   invalidate make use of the ROAs that attest resource PKI by acquiring
   and validating every ROA, to any such authorization.  Since
   ROAs are in one-to-one correspondence with end-entity certificates,
   the standard method for revoking create a ROA is to revoke the corresponding
   end-entity certificate in table of the PKI.  There is no independent
   revocation mechanism for ROAs.

4. Repository system

   In order prefixes for ROAs (and other objects which
   each AS is authorized to be verified using
   certificates from the PKI) originate routes. To validate all ROAs, an
   LIR/ISP needs to be validated, acquire all the objects necessary to
   validate them must be universally accessible. 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. download by
   LIRs/ISPs. 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 (described below) 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. This requirement exists to prevent The use access controls prevents denial of
   service attacks based on deletion of or tampering with to repository
   objects. Although
   any unauthorized modification is detectable by Indeed, although relying parties,
   because all the parties can detect tampering with
   objects are digitally signed, in the repository, it is preferable that the repository
   system prevent such unauthorized modifications. modifications to the greatest extent
   possible.

4.1. Role in the overall architecture

   The repository system is the central clearing-house for the objects
   required for validation of all signed
   objects like ROAs. 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.  In
   addition, signed objects that require universal distribution can also
   be made accessible through the repository system; parties (primarily
   LIRs/ISPs). ROAs and manifests are the only additional examples of such objects defined by this document,
   objects, but other types of signed objects may be added to this
   architecture in the future.  The
   repository system also must ensure the integrity of the data it
   contains by enforcing appropriate controls on access to the
   repository and on modifications to entries in it. This document briefly describes the controls necessary for PKI way
   signed objects (certificates, CRLs, ROAs and ROAs, but does
   not assume that they manifests) are applicable to other types of objects; if managed
   in the repository system. As other types of signed objects are added
   to the repository system it will be included in necessary to modify the
   description, but it is anticipated that most of the design principles
   will still apply. The repository system is described in
   the future, any necessary controls on them must be defined. detail in
   [??].

4.2. Contents and structure

   The primary function of the

   Although there is a single repository system that is to provide universal
   distribution of objects necessary for the function accessed by
   relying parties, it is comprised of this
   architecture.  First multiple databases. These
   databases will be distributed among these are registries (RIRs, NIRs,
   LIRs/ISPs). At a minimum, the objects that comprise database operated by each registry will
   contain all CA and EE certificates, CRLs, and manifests signed by the
   PKI, namely Resource Certificates
   CA(s) associated with that registry. Repositories operated by
   LIRs/ISPs also will contain ROAs. Registries are encouraged 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 CRLs; these
   objects require universal distribution so file
   system directory in the repository that is the authoritative
   publication point for all relying parties
   have access 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 PKI components required AIA extension of certificate B points to validate signed objects
   used by this architecture.
   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 addition, 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 may should
   not be necessary to make
   other types 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. Manifests

   A manifest is a signed object listing of all of the signed objects available through
   issued by a particular authority that are present in the repository
   system.  ROAs are For each certificate, CRL, or ROA issued by the authority,
   the manifest contains both the name of the file containing the
   object, and a prime example hash of the file content.

   As with ROAs, a manifest is signed by a private key whose
   corresponding public key appears in an end-entity certificate signed
   by the CA in question. Each such end-entity certificate is used to
   sign a type, since routes single manifest and the private key corresponding to such an
   end-entity certificate may be deleted after it is used to sign that
   manifest. To avoid needless CRL growth, the EE certificate used to
   validate a manifest SHOULD expire at the same time that the manifest
   expires, i.e., the notAfter value in the EE certificate should be the
   same as the nextUpdate value in the manifest.

   Syntactically, a manifest is a CMS signed-data object whose
   origination content
   is authorized defined as follows:

     Manifest ::=    SEQUENCE {
         version         INTEGER DEFAULT 0,
         manifestNumber  INTEGER,
         thisUpdate      GeneralizedTime,
         nextUpdate      GeneralizedTime,
         fileHashAlg     OBJECT IDENTIFIER,
         fileList        SEQUENCE OF FileAndHash
                 }

     FileAndHash ::=    SEQUENCE {
         file        IA5String
         hash        BIT STRING
                 }

   The manifestNumber field is a sequence number that is incremented
   each time a manifest is issued by a ROA are distributed through authority. The thisUpdate field
   contains the entire
   routing infrastructure, time when the manifest was created and the nextUpdate
   field contains the time at which the next scheduled manifest will be
   issued. If the authority alters any component of its items in the repository,
   then it MUST issue a new manifest before nextUpdate. In such a case,
   when the authority issues the new manifest, it MUST also issue a new
   CRL which may, by local policy,
   examine includes the route origin for consistency with EE certificate corresponding to the ROA.

   Although there old
   manifest. A manifest is thus valid until the time specified in
   nextUpdate or until a single repository system that manifest is accessed by
   relying parties, it is comprised of multiple databases. These
   databases issued with a greater manifest
   number, whichever comes first. The revoked EE certificate for the old
   manifest will be distributed among RIRs and ISPs removed from the CRL when it expires, thus this
   procedure ought not yield large CRLs.

   The fileHashAlg field contains the OID of the hash algorithm used to
   hash the files that participate in the architecture.  At a minimum, authority has placed into the database operated by repository. The
   mandatory to implement hash algorithm is SHA-256 and its OID is
   2.16.840.1.101.3.4.2.1. [RFC 4055]

   The fileList field contains a sequence of FileAndHash pairs, one for
   each RIR
   will contain certificates currently valid certificate, CRL and CRLs issued by ROA that RIR; it may also
   contain repository objects submitted has been issued by holders
   the authority. Each of addresses that
   fall within the FileAndHash pairs contains the name of the
   file in the repository that RIR's scope or copies contains the object in question, and a
   hash of data from other RIRs,
   according to local policy.

4.3. the file's contents.

4.4. 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 [9] [10] as
   the single access protocol.  RSYNC, as used in this implementation,
   provides all of the above functionality.

4.4. A document specifying the
   conventions for use of RSYNC in the PKI will be prepared.

4.5. 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 is suggested in Section 2.3
   above.

5. Local Cache Maintenance

   In order to utilize signed objects issued under this PKI (e.g. for
   route filter construction, see Section 6.3), 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 registry 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. If the hash values do not match, use
        an out-of-band mechanism to 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 [6]
        for more details.)

   Note that when a relying party performs 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. 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.

6. Common Operations

   Creating and maintaining the infrastructure described above will
   entail the addition of security additional operations to as "side effects" of normal resource
   allocation and routing authorization procedures.  For example, a
   multi-homed
   subscriber entering with "portable" address space who entes a relationship
   with a new an ISP will need to issue one or more ROAs to 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 first- hop first-hop AS to
   originate an advertised route.

5.1.

6.1. Certificate issuance

   In order to participate in this infrastructure, resource holders will
   require certificates in the PKI that attest to their allocations.
   Each such certificate will show the issuer of the allocation as the
   certificate issuer, the recipient of the allocation as subject, and a
   description of the allocated resources in the appropriate RFC 3779
   extensions.  The two operations defined in this architecture that
   require a resource holder to have resource certificates for his
   allocations are (1) issuance of certificates for sub-allocations and
   (2) management of ROAs (and corresponding end-entity certificates).

   In particular, there

   There are several operational scenarios that require certificates to
   be issued.  Any allocation that may be sub-allocated requires a CA certificate
   certificate, e.g., so that certificates can be issued as necessary
   for the sub-allocations. Multi-homed subscribers require
   certificates for their allocations so that they can issue ROAs to
   their ISPs. Holders of "portable" address 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 allocation (since the
   allocation does not come from any ISP.

   As ISP). Additionally, multi-homed
   subscribers may require certificates for their allocations if they
   intend to issue the ROAs for their allocations (see Section 6.2.2).
   Other holders of resources 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 will may
   accrue a collection of resource certificates to attest to them.  It
   may be the case that multiple of  If a
   resource holder's holder receives multiple allocations are from the same source.  A source,
   the set of resource certificates that are all
   issued by the same CA could may be combined into a single
   resource
   certificate certificate, if both the issuer and the resource holder
   agree. This is effected by consolidating their the IP Address Delegation
   and AS Identifier Delegation Extensions into a single extension of (of
   each
   type. type) in a new certificate.  However, if the certificates for
   these allocations contain different validity intervals, creating a
   certificate that combines them might create problems, and 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 a resource holder, any
   certificates attesting to such an allocation must MUST be revoked. A
   resource holder MAY choose SHOULD NOT to use the same public key in multiple CA
   certificates that are issued by the same or differing authorities,
   although such as
   reuse of a key pair does complicate complicates path construction.

5.2. 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.

6.2. ROA management

   Whenever a holder of IP address space wants to authorize an AS to
   originate routes for a prefix within his holdings, he must MUST issue an
   end-entity certificate containing that prefix and use in an IP Address
   Delegation extension. He then uses the corresponding private key to
   sign a ROA containing the designated prefix and an the AS number identifying for the designated
   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 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 prefixes prefix(es) to be
        authorized in the ROA ROA.

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

     3. Sign the ROA using the private key corresponding to the end-entity end-
        entity certificate (the ROA is comprised of the payload
        encapsulated in a CMS signed message [ROA format I-D]) [7]).

     4. Upload the end-entity certificate and the ROA to the repository
      system
        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.

5.2.1.

6.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 (or prefixes)
   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 its own allocation. Thus, a single-homed subscribers subscriber with
   a non-portable allocations do allocation is not need to included in the RPKI, i.e., it does
   not receive a CA certificate, nor issue (or otherwise manage) EE certificates or ROAs.

5.2.2. Multi-homing

   If a multi-homed subscriber wants

6.2.2. Multi-homed subscribers

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

   One option is for the multi-homed subscriber to do so by issuing obtain a CA
   certificate from the ISP who allocated the prefixes to the
   subscriber. The multi-homed subscriber can then create a ROA (and
   associated end-entity certificate) that authorizes a second ISP to
   originate routes to the subscriber prefix(es). The ROA for each AS the second
   ISP generally SHOULD be set to require an exact match, if the intent
   is to enable backup paths for the prefix. Note that the first ISP,
   who allocated the prefixes, will want to advertise the more specific
   prefix for this subscriber (vs. the encompassing prefix). Either the
   subscriber or the first ISP will need to issue an EE certificate and
   ROA for the (more specific) prefix, authorizing this ISP to advertise
   this more specific prefix.

   A second option is that the multi-homed subscriber can request that
   the ISP that allocated the prefixes create a ROA that authorizes the
   second ISP to originate routes to the subscriber's prefixes. (The ISP
   also creates an EE certificate and ROA for its own advertisement of
   the subscriber prefix, as above.) This option does not require that
   the subscriber be issued a certificate or participate in question.

5.2.3. ROA
   management. Therefore, this option is simpler for the subscriber, and
   is preferred if the option is supported by the ISP performing the
   allocation.

6.2.3. Portable allocations

   A resource holder is said to have a portable (provider independent)
   allocation if the resource holder received its allocation from a
   regional or national registry.  Because
   these the prefixes represented in
   such allocations are not taken from any larger allocations an allocation held by an ISP,
   there is no ISP that holds and advertises a more general prefix.  If the A
   holder of a portable allocation wants to MUST authorize an
   ISP one or more ASes to
   originate routes to its allocation, then it must issue a ROA these prefixes. Thus the resource holder MUST
   generate one or more EE certificates and associated ROAs to this ISP; 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.

5.3.

6.3. Route filter construction

   The goal of this architecture is to support improved routing
   security.  One way to do this is to use ROAs to construct route
   filters that reject routes that conflict with the origination
   authorizations asserted by current ROAs, which can be accomplished
   with the following procedure:

     1. Obtain current a local copy of all currently valid EE certificates, CRLs, and ROAs from as
        specified in Section 5.

     2. Query the repository system (e.g., update to obtain a previous download)

   2. local copy of all ROAs
        issued under the PKI.

     3. Verify that the each end-entity ROA matches the hash value contained in the
        manifest of the CA certificate by constructing and verifying
      a certification path for used to verify the EE certificate (including checking
      relevant CRLs).

   3. Verify
        that issued the ROA and that no ROAs are missing. (ROAs are
        contained in files with a ".roa" suffix, so missing ROAs are
        readily detected.)

     4. Validate each ROA by verifying that it it's signature is signed verifiable
        by a valid end-
      entity end-entity certificate that matches the address
        allocation in the ROA.

   4. (See [7] for more details.)

     5. Based on the validated ROAs, construct a table of prefixes and
        corresponding authorized origin ASes (or vice versa).

   In addition to this basic route-filtering technique,

   A BGP speaker that applies such a filter is thus guaranteed that for
   a given IP address prefix, all routes that the
   infrastructure can be used BGP speaker accepts
   for that prefix were originated by an AS that is authorized by the
   owner of the prefix to support more advanced routing-security
   systems, such as S-BGP [7] and soBGP [8]. authorize routes to that prefix.

   The first three steps in the above procedure would might incur a
   prohibitive amount of
   substantial overhead if all objects in the repository system were
   downloaded and validated every time a route filter was constructed.
   Instead, it will be more efficient for users of the infrastructure to
   initially download all of the signed objects
   (certificates, CRLs, and ROAs), perform necessary validations, then the
   validation algorithm described above. Subsequently, a relying party
   need only perform incremental downloads and validations on a regular
   basis.  A typical ISP using the infrastructure might have a daily
   schedule to download updates from the repository, upload any
   modifications it has made, and construct route filters.

6.

   It should be noted that the transition to 4-byte AS numbers (see RFC
   4893 [10]) weakens the security guarantees achieved by BGP speakers
   who do not support 4-byte AS numbers (referred 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 to the
   reserved value 23456 before being sent to a BGP speaker who does not
   understand 4-byte AS numbers. Therefore, when an ISP creates a route
   filter for use by an OLD BGP speaker, it must allow any 4-byte AS
   number to advertise routes for an IP address prefix if there exists a
   ROA that authorizes any 4-byte AS number to advertise routes to that
   prefix. This means that if an OLD BGP speaker accepts a route that
   was originated by an AS with a 4-byte AS number, there is no
   guarantee that it was originated by an authorized 4-byte AS number
   (unless the route was propagated by an intermediate NEW BGP speaker
   who performed route filtering as described above).

7. 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

7.

8. IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC

8.

9. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

9.

10. References

9.1.

10.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]   Housley, R., et al., "Internet X.509 Public Key Infrastructure
         Certificate and Certificate Revocation List (CRL) Profile", RFC
         3280, April 2002.

   [4]   Housley, R., "Cryptographic Message 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.

   [5]

   [6]   Huston, G., Michaelson, G., and Loomans, R., "A Profile for
         X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-
         03, February 2007.

   [6]   Kong, D., and draft-ietf-sidr-res-certs,
         July 2007 (work in progress).

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

9.2. draft-ietf-sidr-roa-format,
         July 2008 (work in progress).

10.2. Informative References

   [7]   [S-BGP]

   [8]   [soBGP]   [S-BGP]

   [9]   [soBGP]

   [10]  [rsync]

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

Author's Addresses

   Richard Barnes

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

   Email: rbarnes@bbn.com mlepinski@bbn.com

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

   Email: kent@bbn.com

   Richard Barnes
   BBN Technologies
   10 Moulton St.
   Cambridge, MA 02138

   Email: rbarnes@bbn.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of 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 may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and 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 (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.