Secure Inter-Domain Routing M. Lepinski Working Group S. Kent Internet Draft BBN Technologies Intended status: Informational
November 3, 2008March 9, 2009 Expires: May 3,September 9, 2009 An Infrastructure to Support Secure Internet Routing draft-ietf-sidr-arch-04.txtdraft-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 sheThis 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 accordancefull conformance with Section 6the 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.txthttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.htmlhttp://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..............................4Resources..............................5 2.1. Role in the overall architecture..........................5 2.2. CA Certificates...........................................5Certificates...........................................6 2.3. End-Entity (EE) Certificates..............................7 2.4. Trust Anchors.............................................8 2.5. Default Trust Anchor Considerations.......................8Considerations.....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.........................11architecture.........................10 3.2. Syntax and semantics.....................................11 4. Repositories..................................................13Repositories..................................................12 4.1. Role in the overall architecture.........................14architecture.........................13 4.2. Contents and structure...................................14structure...................................13 4.3. Access protocols.........................................16protocols.........................................15 4.4. Access control...........................................16control...........................................15 5. Manifests.....................................................17Manifests.....................................................16 5.1. Syntax and semantics.....................................17semantics.....................................16 6. Local Cache Maintenance.......................................18Maintenance.......................................17 7. Common Operations.............................................18 7.1. Certificate issuance.....................................19issuance.....................................18 7.2. ROA management...........................................20management...........................................19 7.2.1. Single-homed subscribers (without portable allocations) ...........................................................20 7.2.2. Multi-homed subscribers.............................21subscribers.............................20 7.2.3. Portable allocations................................21 7.3. Route filter construction................................22construction......Error! Bookmark not defined. 8. Security Considerations.......................................23Considerations.......................................21 9. IANA Considerations...........................................24Considerations...........................................21 10. Acknowledgments..............................................24Acknowledgments..............................................21 11. References...................................................25References...................................................23 11.1. Normative References....................................25References....................................23 11.2. Informative References..................................25References..................................23 Authors' Addresses...............................................26Addresses...............................................24 Intellectual Property Statement..................................26Statement..................................24 Disclaimer of Validity...........................................27Validity.................Error! Bookmark not defined. 1. Introduction This document describes an architecture for an infrastructure to support improved security for BGP routing  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 S- BGP  or soBGP .. 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  and the extensions for IP Addresses and AS numbers representation defined in RFC 3779 . Also CMS  is used as the syntax for the newly-defined signed objects required by this infrastructure. As noted above, the infrastructurearchitecture 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" , and "X.509 Extensions for IP Addresses and AS Identifiers" . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" inThroughout this document are to be interpreted as described in RFC-2119 . 2. PKI for Internet Number Resources Becausewe use the holderterms "address space holder" or "holder of a blockIP address space is entitledspace" interchangeably to define the topological destinationrefer to a legitimate holder of IP datagrams whose destinations fall within that block, decisions about inter-domain routing are inherently based on knowledgeaddress space who has received this address space through the standard IP address allocation ofhierarchy. That is, the IPaddress 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 IPfrom 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 . 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 setblock of IP addressesaddress space may sub-allocatesub- 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 regionalRIRs 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 . 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 . 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 resourceswho is authorized to sub-allocate themthese 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 subscribersentities that do not sub- allocate their resources also will need to have CA certificates for their allocations, e.g., subscribersa 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 andmust not attempt to convey the identity of the subject in a descriptive fashion. Additionally, theThe subject's distinguished name must be unique among all certificates issued by a given authority. In this PKI, the certificate issuer, being an internet registryRIR, 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 itsa 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 thespecified 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 choosechooses 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 andand/or the five RIRs form aare obvious candidates to be default set of trust anchors.TAs here. Nonetheless, every relying party is free to choose a differenteach RP ultimately chooses the set of trust anchors toit will use for certificate validation operations.validation. For example, ana 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 certificatecertification paths terminating at this locally-installed trust anchor will satisfy the RFC 3779 validation requirements. AnA 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  specifies a format for a putative trust anchor to distribute to relyingIt 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). Givenwithin the extant IP address space and AS number allocation hierarchy, it is envisioned that IANA and the five RIRs will providehierarchy may wish to publish trust anchor information to relying parties and thatmaterial for possible use by relying parties will generally acceptparties. A standard profile for the publication of trust anchors fromanchor material for this set.public key infrastructure can be found in . 2.5. Representing Early-Registration Transfers (ERX) Currently, IANA forms the root of the extant IPallocates 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 eitherto the entirety of IP address space, or alternatively that portionRIRs 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. Ascross 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 issueallocation 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 regardresource 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 wishestransfers from one RIR to use private address spaceanother in conjunction with BGP and this PKI technology. Such an organization could configure its relying parties with an additional, local trust anchora 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 (aspermits the rootvalidation 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 certificatescertificates 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 . 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  for information on the origin ASuse of the AS-PATH attribute is not an AS that is authorized (via a valid ROA)ROAs to originatevalidate 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  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 timethat 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 .. 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  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 bothAIA extensions of certificates B and C point to A, and the nameSIA extension of certificate A points to the filedirectory containing the object,certificates B and C. If a hash of the file content. As with ROAs, a manifestCA certificate is signed by a private key, for whichreissued with the correspondingsame public key appears inkey, it should not be necessary to reissue (with an end-entity certificate. This EE certificate, in turn, isupdated AIA URI) all certificates signed by the CA in question. The EEcertificate private key may be used to issue one for more manifests. If the private key is used to sign onlybeing reissued. Therefore, a single manifest, then the manifest can be revoked by revoking the EE certificate. In suchcertification 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 atsame publication point as previously issued certificates having the same timesubject 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 usedrelying parties can use to issue multiple (sequential) manifests foraccess the CA in question, then there is no revocation mechanism for these individual manifests. Manifests mayrepository system. These protocols will be used by relying parties when constructing a local cache (see Section 6) to mitigatenumerous participants in the riskinfrastructure (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 versionsit. In order to support these activities, certain basic functionality is required of the same object. Such protection is needed because althoughsuite of access protocols, as described below. No single access protocol need implement all objects inof 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. Syntaxcontents and semantics A manifest constitutes a listsubsequent download of (the hashes of) allchanges to the filesdownloaded contents, since this will be the most common way in awhich relying parties interact with the repository point at a particular point in time. A detailed specificationsystem. Other types of manifest syntax is provided in  but, at a high level, a manifest consistsdownload interactions (e.g., download of (1)a manifest number; (2) the time the manifest was issued; (3) the time ofsingle object) MAY also be supported. Upload/change/delete: Access protocols MUST also support mechanisms for the next planned update; and (4) a listissuers of filenamecertificates, CRLs, and hash value pairs. The manifest number is a sequence number that is incremented each time a manifest is issued byother signed objects to add them to the authority. An authority is requiredrepository, and to issue a new manifest any time it alters any of its itemsremove 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 timemodification of its contents) MUST support verification of the next update is reached. A manifest is thus valid until the specified timeauthorization of the next update or until a manifest is issued with a greater manifest number, whichever comes first. (Noteentity performing the modification, so that when an EE certificate is usedappropriate access controls can be applied (see Section 4.4). Current efforts to sign onlyimplement a single manifest, whenever the authority issues the new manifest,repository system use RSYNC  as the CA MUST also issue a new CRL which includessingle access protocol. RSYNC, as used in this implementation, provides all of the EE certificate corresponding toabove functionality. A document specifying the old manifest. The revoked EE certificateconventions for use of RSYNC in the old manifestPKI will be removed from the CRL when it expires, thus this procedure ought not result in significant CRLs growth.) 6. Local Cache Maintenanceprepared. 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 partymaintain the integrity of information in the repository, controls must first obtain a local copybe put in place to prevent addition, deletion, or modification of objects in the valid EE certificates forrepository 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 performslocal control of repository operators, it is recommended that repositories allow only the following steps: 1. Queryissuers of signed objects to add, delete, or modify them. Alternatively, it may be advantageous in the registry systemfuture to obtaindefine a copyformal 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 CRLsof the signed objects issued underby an authority responsible for a publication in the PKI. 2.repository system. For each CA certificate in the PKI, verifycertificate, CRL, or ROA issued by the signature onauthority, the corresponding manifest. Additionally, verify thatmanifest contains both the current time is earlier thanname of the time indicated infile containing the nextUpdate fieldobject, and a hash of the manifest. 3. For each manifest, verify that certificates and CRLs issued underfile content. As with ROAs, a manifest is signed by a private key, for which the corresponding CA certificate match the hash values containedpublic 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 mechanismprivate key is used to notifysign only a single manifest, then the appropriate repository administrator thatmanifest can be revoked by revoking the repository data has been corrupted. 4. Validate eachEE certificate by constructing and verifyingcertificate. In such a certification path forcase, to avoid needless CRL growth, the EE certificate (including checking relevant CRLs)used to the locally configured set of TAs. (See  for more details.) Notevalidate a manifest SHOULD expire at the same time that when a relying party performs these operations regularly, itthe manifest expires. If an EE certificate is more efficientused 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 partyparties when constructing a local cache (see Section 6) to request frommitigate the risk of an attacker who deletes files from a repository system only thoseor replaces current signed objects that have changed sincewith stale versions of the relying party last updated its local cache. Note also that by checkingsame object. Such protection is needed because although all issuedobjects againstin the appropriate manifest,repository system are signed, the relying party can be certain that itrepository system itself is not missing an updated version of any object. 7. Common Operations Creatinguntrusted. 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 entesrepository 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 usetime. A detailed specification of this infrastructuremanifest syntax is for route filter construction; using ROAs, route filters can be constructedprovided in an automated fashion with but, at a high assurance thatlevel, a manifest consists of (1) a manifest number; (2) the time the manifest was issued; (3) the holdertime 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 requiresnext planned update; and (4) a CA certificate, e.g., so that certificates can be issued as necessary for the sub-allocations. Holderslist of ''portable'' address allocations also must have certificates, so thatfilename and hash value pairs. The manifest number is a ROA can be issued to each ISPsequence number that is authorized to originateincremented each time a route to the allocation (sincemanifest is issued by the allocation does not come from any ISP). Additionally, multi-homed subscribers may require certificates for their allocations if they intendauthority. 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 holdersrepository, or when the specified time of resources need not be issued CA certificates withinthe PKI. Innext 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 receivemanifest is issued with a greater manifest number, whichever comes first. (Note that when an EE certificate asis used to sign only a side effect ofsingle manifest, whenever the allocation process forauthority issues the resource. However, initial deployment ofnew manifest, the RPKI will entail issuance of certificatesCA 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 CAold manifest. The revoked EE certificate for the old manifest will be removed from the entity who allocates resourcesCRL when it expires, thus this procedure ought not to the subject. This differs from most PKIsresult in which a subject can request a certificate from any certification authority. Ifsignificant 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 accruerelying party must first obtain a collectionlocal copy of resourcethe 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. Ifobtain a resource holder receives multiple allocations fromcopy 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 bothPKI, verify the issuer andsignature on the resource holder agree. Thiscorresponding manifest. Additionally, verify that the current time is effected by consolidatingearlier than the IP Address Delegation and AS Identifier Delegation Extensions into a single extension (of each type)time indicated in a new certificate. However, ifthe nextUpdate field of the manifest. 3. For each manifest, verify that certificates for these allocations contain different validity intervals, creating aand CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that combines them might create problems, and thusno 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 signedmissing, 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. Whenverifying a certification path for the certificate (including checking relevant CRLs) to the locally configured set of resources is no longer allocated toTAs. (See  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 userelying party performs these operations regularly, it is more efficient for the same public key in multiple CA certificates that are issued byrelying party to request from the same or differing authorities, as reuse of a key pair complicates path construction. Noterepository system only those objects that have changed since the subject's distinguished name is chosen by the issuer, a subject who receives allocationsrelying 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 Wheneverthe repository. However, a holder of IP address space wants to authorize an AStypical ISP might reasonably choose to originate routes forperform these operations on a prefix within his holdings, he MUST issue an end-entity certificate containingdaily schedule. Note also that prefix in an IP Address Delegation extension. He then uses the corresponding private key to sign a ROA containingby checking all issued objects against the designated prefix andappropriate manifest, the AS number forrelying party can be certain that it is not missing an updated version of any object. 7. Common Operations Creating and maintaining the AS. Theinfrastructure described above will entail additional operations as "side effects" of normal resource holder MAY include more than one prefix in the EE certificateallocation and corresponding ROA if desired. Asrouting authorization procedures. For example, a prerequisite, then, anysubscriber with "portable" address holder that issues ROAs for a prefix must havespace who enters a resource certificate forrelationship with an allocation containingISP 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 ROAcurrent primary use of this infrastructure is as follows: 1. Create an end-entity certificate containing the prefix(es) tofor route filter construction; using ROAs, route filters can be authorizedconstructed in an automated fashion with high assurance that the ROA. 2. Construct the payloadholder of the ROA, including the prefixes in the end-entity certificate andadvertised prefix has authorized the origin AS numberto be authorized. 3. Sign the ROA using the private key correspondingoriginate 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 inbe issued. Any allocation that may be sub-allocated requires a CMS signed message ). 4. Upload the end-entity certificate and the ROA to the repository system. The standard procedureCA certificate, e.g., so that certificates can be issued as necessary for revokingthe 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 itoriginate a route to the repository system. The revoked ROA and end- entity certificate SHOULD BE removed fromallocation (since the repository system. 7.2.1. Single-homed subscribers (without portable allocations) In BGP, a single-homed subscriber with a non-portableallocation 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 trafficcome 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, noROAs for their allocations (see Section 7.2.2). Other resource holders need tonot be issued under their allocations; rather,CA certificates within the subscriber's ISPPKI. In the long run, a resource holder will issue any necessary ROAs for its more general prefixes undernot request resource certificates its own allocation. Thus,certificates, but rather receive a single-homed subscriber withcertificate as a non-portableside effect of the allocation is not included inprocess for the RPKI, i.e., it does not receive a CA certificate, nor issue EEresource. However, initial deployment of the RPKI will entail issuance of certificates or ROAs. 7.2.2. Multi-homed subscribers In order for multiple ASesto 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 forexisting resource holders as an explicit event. Note that in all cases, the multi-homed subscriber to obtainauthority issuing a CA certificate fromwill be the ISPentity who allocated the prefixesallocates resources to the subscriber. The multi-homed subscribersubject. This differs from most PKIs in which a subject can then createrequest a ROA (and associated end-entity certificate) that authorizescertificate from any certification authority. If a second ISPresource holder receives multiple allocations over time, it may accrue a collection of resource certificates to originate routesattest to them. If a resource holder receives multiple allocations from the subscriber prefix(es). The ROA forsame source, the second ISP generally SHOULD beset 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 thatissuer and the first ISP, who allocatedresource holder agree. This is accomplished by consolidating the prefixes, will want to advertiseIP Address Delegation and AS Identifier Delegation Extensions into a single extension (of each type) in a new certificate. However, if the more specific prefixcertificates for this subscriber (vs. the encompassing prefix). Either the subscriber or the first ISP will need to issue an EEthese allocations contain different validity intervals, creating a certificate that combines them might create problems, and ROA for the (more specific) prefix, authorizing this ISPthus 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 isresource holder SHOULD NOT use the same public key in multiple CA certificates that are issued by the multi-homed subscriber can requestsame or differing authorities, as reuse of a key pair complicates path construction. Note that since the ISP that allocatedsubject's distinguished name is chosen by the prefixes createissuer, a subject who receives allocations from two sources generally will receive certificates with different subject names. 7.2. ROA that authorizes the second ISPmanagement Whenever a holder of IP address space wants to authorize an AS to originate routes to the subscriber's prefixes. (The ISP also createsfor a prefix within his holdings, he MUST issue an EEend-entity certificate and ROA for its own advertisement of the subscriber prefix, as above.) This option does not requirecontaining that prefix in an IP Address Delegation extension. He then uses the subscriber be issuedcorresponding private key to sign a certificate or participate inROA management. Therefore, this option is simpler forcontaining the subscriber,designated prefix and is preferred if the option is supported bythe ISP performingAS number for the allocation. 7.2.3. Portable allocations AAS. The resource holder is said to have a portable (provider independent) allocation ifMAY include more than one prefix in the resourceEE certificate and corresponding ROA if desired. As a prerequisite, then, any address space holder received its allocation fromthat issues ROAs for a regional or national registry. Because the prefixes represented in such allocations are not taken fromprefix must have a resource certificate for an allocation held by an ISP, there is no ISPcontaining that holds and advertises a more generalprefix. A holder ofThe standard procedure for issuing a portable allocation MUST authorize one or more ASes to originate routesROA is as follows: 1. Create an end-entity certificate containing the prefix(es) to these prefixes. Thusbe authorized in the resource holder MUST generate one or more EE certificatesROA. 2. Construct the payload of the ROA, including the prefixes in the end-entity certificate and associated ROAsthe AS number to enablebe authorized. 3. Sign the AS(es)ROA using the private key corresponding to originate routes forthe prefix(es) in question. Thisend- entity certificate (the ROA is required because nonecomprised 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 ROAspayload encapsulated in a CMS signed message ). 4. Upload the end-entity certificate and the ROA to construct route filters that reject routes that conflict withthe origination authorizations asserted by current ROAs.repository system. The following is intended to providestandard procedure for revoking a high-level description of how the architecture might be usedROA is to construct a route filter. Additional guidance onrevoke the use of ROAscorresponding end-entity certificate by creating an appropriate CRL and uploading it to derive inferences aboutthe validity of BGP UPDATE messages is provided in .repository system. The guidance in  is particularly important duringrevoked 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 wheresingle-homed subscriber with a non-portable allocation does not all ISPs implement this architecture (and thusneed to explicitly authorize routes to be originated for the filter described below which naively rejects all UPDATES withoutprefix(es) it is using, since its ISP will already advertise a corresponding ROA would incorrectly reject validmore 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 allthese subscribers, no ROAs need to be issued under their allocations; rather, the PKI. 3. Verify that the each ROA matches the hash value containedsubscriber'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 theRPKI, i.e., it does not receive a CA certificate used to verify thecertificate, 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 bycertificates or ROAs. 7.2.2. Multi-homed subscribers (without portable allocations) Here we consider a valid end-entity certificate that matches thesubscriber who receives IP address allocation inspace from a primary ISP (i.e., the ROA. (See  for more details.) 5. Based onIP addresses used by the validated ROAs, constructsubscriber are a tablesubset of prefixesISP A's IP address space allocation) and corresponding authorized origin ASes (or vice versa). A BGP speaker that appliesreceives redundant upstream connectivity from the primary ISP, as well as one or more secondary ISPs. The preferred option for such a filtermulti-homed subscribers is thus guaranteed thatfor a given IP address prefix, all routes thatthe BGP speaker accepts for that prefix were originated bysubscriber to obtain an AS that is authorized by the owner of the prefix to authorize routesnumber (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 inis that the above procedure might incurprimary ISP issues a substantial overhead if all objects inCA certificate to the repository system were downloadedsubscriber, and validated every time a route filter was constructed. Instead, it will be more efficient for users ofthe infrastructuresubscriber issues a ROA to initially download all ofcontaining the signed objectssubscriber's AS number and performthe 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 downloadsROA to the subscriber, and validations oninstead issues a regular basis. A typical ISP usingROA on the infrastructure may choose any frequency it desires for downloading updates fromsubscriber'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 oncreate a daily schedule. It should be notedROA for each secondary ISP that authorizes the transition to 4-byte AS numbers (see RFC 4893 ) weakens the security guarantees achieved by BGP speakers who do not support 4-byte AS numbers (referredsecondary 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 mappedoriginate routes to the reserved value 23456 before being sent to a BGP speaker who does not understand 4-byte AS numbers. Therefore, when ansubscriber's prefixes. The primary ISP createswill also create a route filter for use by an OLD BGP speaker, it must allow any 4-byteROA 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 forprecisely the subscriber's prefixes and not an IP address prefix if there exists a ROAencompassing aggregate. Note that authorizes any 4-bytethis approach results in inconsistent origin AS number to advertise routesnumbers 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 thathave a portable (provider independent) allocation if an OLD BGP speaker acceptsthe resource holder received its allocation from a route that was originatedRIR 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 guaranteeISP that it was originated by an authorized 4-byte AS number (unlessholds 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 serversservers. 9. IANA Considerations This document makes no request of IANA. Noterequests 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 RFCthe RIRs. IANA SHOULD make available trust anchor material in the format defined in  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, TimeTim 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  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006  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.  Housley, R., ''Cryptographic"Cryptographic Message Syntax'',Syntax", RFC 3852, July 2004.  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.  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.  Lepinski, M., Kent, S., and Kong, D., "A Profile for Route Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-04, November 2008.  Austein, R., et al., ''Manifests"Manifests for the Resource Public Key Infrastructure'',Infrastructure", draft-ietf-sidr-rpki-manifests-04, October 2008.  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  Huston, G., Michaelson, G., and Loomans, R., ''A"A Profile for Resource Certificate Repository Structure'',Structure", draft-ietf-sidr- repos-struct-01, October 2008.  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.  White, R., "soBGP", May 2005, <ftp://ftp- eng.cisco.com/sobgp/index.html>  Tridgell, A., "rsync", April 2006, <http://samba.anu.edu.au/rsync/>  Vohra, Q., and Chen, E., ''BGP Support for Four-octet AS Number Space'', RFC 4893, May 2007. 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: firstname.lastname@example.org Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 Email: email@example.com Intellectual Property Statement ThePre-5378 Material Disclaimer This document may contain material from IETF takes no position regarding the validity or scope of any Intellectual Property RightsDocuments or other rights that might be claimed to pertain to the implementationIETF Contributions published or use ofmade publicly available before November 10, 2008. The person(s) controlling the technology describedcopyright in some of this document or the extent to which any license under such rights might or mightmaterial may not be available; nor does it represent that it has made any independent effort to identify any such rights. Information onhave granted the procedures with respectIETF Trust the right to rights in RFC documents can be found in BCP 78 and BCP 79. Copiesallow modifications of IPR disclosures made tosuch material outside the IETF Secretariat and any assurances of licenses to be made available, or the result ofStandards Process. Without obtaining an attempt made to obtain a generaladequate license or permission forfrom the use ofperson(s) controlling the copyright in such proprietary rights by implementers or users ofmaterials, 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 thatdocument may not be required to implement this standard. Please address the information tomodified outside the IETF at firstname.lastname@example.org. Disclaimer of Validity This documentStandards 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) TheIETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, andStandards 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.