Internet Engineering Task Force (IETF) M. Lepinski Request for Comments: 6480 S. Kent Category: Informational BBN Technologies ISSN: 2070-1721 February 2012 An Infrastructure to Support Secure Internet Routing
AbstractThis document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6480.
Copyright Notice Copyright (c) 2012 IETF Trust 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction ....................................................3 1.1. Terminology ................................................4 2. Public Key Infrastructure for Internet Number Resources .........4 2.1. Role in the Overall Architecture ...........................5 2.2. CA Certificates ............................................6 2.3. End-Entity (EE) Certificates ...............................7 2.4. Trust Anchors ..............................................8 3. Route Origination Authorizations ................................9 3.1. Role in the Overall Architecture ...........................9 3.2. Syntax and Semantics ......................................10 4. Repositories ...................................................11 4.1. Role in the Overall Architecture ..........................12 4.2. Contents and Structure ....................................12 4.3. Access Protocols ..........................................14 4.4. Access Control ............................................15 5. Manifests ......................................................15 5.1. Syntax and Semantics ......................................15 6. Local Cache Maintenance ........................................16 7. Common Operations ..............................................17 7.1. Certificate Issuance ......................................17 7.2. CA Key Rollover ...........................................18 7.3. ROA Management ............................................19 7.3.1. Single-Homed Subscribers ...........................20 7.3.2. Multi-Homed Subscribers ............................20 7.3.3. Provider-Independent Address Space .................21 8. Security Considerations ........................................21 9. IANA Considerations ............................................21 10. Acknowledgments ...............................................22 11. References ....................................................22 11.1. Normative References .....................................22 11.2. Informative References ...................................23
RFC4271] for the Internet. The architecture encompasses three principle elements: o Resource Public Key Infrastructure (RPKI) o digitally signed routing objects to support routing security o a distributed repository system to hold the PKI objects and the signed routing objects The architecture described by this document enables an entity to verifiably assert that it is the legitimate holder of a set of IP addresses or a set of Autonomous System (AS) numbers. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. In addition to this initial application, the infrastructure defined by this architecture also is intended to provide future support for security protocols such as Secure BGP [S-BGP] or Secure Origin BGP [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 the Public Key Infrastructure using X.509 (PKIX) [RFC5280] working group and the extensions for IP addresses and AS numbers representation defined in RFC 3779 [RFC3779]. Also, Cryptographic Message Syntax (CMS) [RFC5652] is used as the syntax
for the newly defined signed objects [RFC6488] required by this infrastructure. As noted above, the architecture is comprised of three main components: an X.509 PKI in which certificates attest to holdings of IP address space and AS numbers; non-certificate signed objects (including route origination authorizations and manifests) used by the infrastructure; and a distributed repository system that makes all of these signed objects available for use by ISPs in making routing decisions. These three basic components enable several security functions; most notably the cryptographic validation that an autonomous system is authorized to originate routes to a given prefix [RFC6483]. RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779]. Throughout this document, we use the terms "address space holder" or "holder of IP address space" interchangeably to refer to a legitimate holder of IP address space who has received this address space through the standard IP address allocation hierarchy. That is, the address space holder has either directly received the address space as an allocation from a Regional Internet Registry (RIR) or IANA; or else the address space holder has received the address space as a sub-allocation from a National Internet Registry (NIR) or Local Internet Registry (LIR). We use the term "resource holder" to refer to a legitimate holder of either IP address or AS number resources. Throughout this document, we use the terms "registry" and "ISP" to refer to an entity that has an IP address space and/or AS number allocation that it is permitted to sub-allocate. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
cryptographically verifiable attestations as to these allocations. In current practice, the allocation of IP addresses is hierarchical. The root of the hierarchy is IANA. Below IANA are five Regional Internet Registries (RIRs), each of which manages address and AS number allocation within a defined geopolitical region. In some regions, the third tier of the hierarchy includes National Internet Registries (NIRs) as well as Local Internet Registries (LIRs) and subscribers with so-called provider-independent ("portable") allocations. (The term "LIR" is used in some regions to refer to what other regions define as an ISP. Throughout the rest of this document, we will use the term "LIR/ISP" to simplify references to these entities.) In other regions, the third tier consists only of LIRs/ISPs and subscribers with provider-independent allocations. In general, the holder of a block of IP address space may sub- allocate portions of that block, either to itself (e.g., to a particular unit of the same organization), or to another organization, subject to contractual constraints established by the registries. Because of this structure, IP address allocations can be described naturally by a hierarchic public key infrastructure, in which each certificate attests to an allocation of IP addresses, and issuance of subordinate certificates corresponds to sub-allocation of IP addresses. The above reasoning holds true for AS number resources as well, with the difference that, by convention, AS numbers may not be sub-allocated except by RIRs or NIRs. Thus, allocations of both IP addresses and AS numbers can be expressed by the same PKI. Such a PKI, which is henceforth referred to as the "Resource Public Key Infrastructure (RPKI)", is a central component of this architecture. RFC6487]. 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 [RFC3779]. An important property of this PKI is that certificates do not attest to the identity of the subject. Therefore, the subject names used in certificates are not intended to be "descriptive". That is, the resource PKI is intended to provide authorization, but not authentication. This is in contrast to most PKIs where the issuer ensures that the descriptive subject name in a certificate is properly associated with the entity that holds the private key corresponding to the public key in the certificate. Because issuers
need not verify the right of an entity to use a subject name in a certificate, they avoid the costs and liabilities of such verification. This makes it easier for these entities to take on the additional role of Certification Authority (CA). Most of the certificates in the PKI assert the basic facts on which the rest of the infrastructure operates. CA certificates within the PKI attest to IP address space and AS number holdings. End-entity (EE) certificates are issued by resource holder CAs to delegate the authority attested by their allocation certificates. The primary use for EE certificates is the validation of Route Origination Authorizations (ROAs), signed objects which provide an explicit authorization by an address holder that a given AS is permitted to originate routes to a set of addresses (see Section 3). End-entity certificates are also used to verify other signed objects, such as manifests, which will be used to help ensure the integrity of the repository system (see Section 5). Section 7.3.2). Unlike in most PKIs, the distinguished name of the subject in a CA certificate is chosen by the certificate issuer. The subject's distinguished name must not attempt to convey the identity of the subject in a descriptive fashion. The subject's distinguished name must include the CommonName attribute and may additionally include the serial attribute. In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP, is not in the business of verifying the legal right of the subject to assert a particular identity. Therefore, selecting a distinguished name that does not convey the identity of the subject in a descriptive fashion minimizes the opportunity for the subject to
misuse the certificate to assert an identity, and thus minimizes the legal liability of the issuer. Since all CA certificates are issued to subjects with whom the issuer has an existing relationship, it is recommended that the issuer select a subject name that enables the issuer to easily link the certificate to existing database records associated with the subject. For example, an authority may use internal database keys or subscriber IDs as the subject's common name in issued certificates. Although the subject's common name in a certificate does not convey identity, it is still the case that the common name must be unique among all subjects to whom a certification authority issues certificates. That is, a CA must not issue certificates to two different entities that use the same common name for the subject. Each resource certificate attests to an allocation of resources to a resource holder, so entities that have allocations from multiple sources will have multiple CA certificates. Note that when an entity receives multiple certificates from different issuers, the subject names in these certificates will generally be different. A CA also may issue distinct certificates for each distinct allocation to the same entity, if the CA and the resource holder agree that such an arrangement will facilitate management and use of the certificates. For example, an LIR/ISP may have several certificates issued to it by one registry, each describing a distinct set of address blocks, because the LIR/ISP desires to treat the allocations as separate.
exactly once in its lifetime, and thus can be destroyed after it has been used to sign its one object. This fact should simplify key management, since there is no requirement to protect these private keys for an extended period of time. The EE certificate used to verify a signed object appears in the Cryptographic Message Syntax (CMS) wrapper (see [RFC6488]) of the signed object. Therefore, it is not necessary to transmit the EE certificate separately from the signed object. Likewise, it is not necessary for the EE certificate to appear in the RPKI repository system except as part of the corresponding signed object. Although this document describes only two uses for end-entity certificates, additional uses will likely be defined in the future. For example, end-entity certificates could be used as a more general authorization for their subjects to act on behalf of the specified resource holder. This could facilitate authentication of inter-ISP interactions, or authentication of interactions with the repository system. These additional uses for end-entity certificates may require retention of the corresponding private keys, even though such retention is not required for keys used to sign ROAs and manifests. RFC 3779. A large ISP that uses private IP address space (i.e., RFC 1918) and runs BGP internally will need to create this sort of trust anchor to accommodate a CA to which all private address space is assigned. The RP could then issue certificates under this CA that correspond to the RP's internal use of private address space. Note that an RP who elects to create and manage its own set of trust anchors may fail to detect allocation errors that arise under such circumstances, but the resulting vulnerability is local to the RP.
It is expected that some parties within the extant IP address space and AS number allocation hierarchy may wish to publish trust anchor material for possible use by relying parties. A standard profile for the publication of trust anchor material for this public key infrastructure can be found in [RFC6490]. RFC6482]. The validity of this authorization depends on the signer of the ROA being the holder of the prefix(es) in the ROA; this fact is asserted by an end-entity certificate from the PKI, whose corresponding private key is used to sign the ROA. ROAs may be used by relying parties to verify that the AS that originates a route for a given IP address prefix is authorized by the holder of that prefix to originate such a route. For example, an ISP might use validated ROAs as inputs to route filter construction for use by its BGP routers. (See [RFC6483] for information on the use of ROAs to validate the origination of BGP routes.) Initially, the repository system will be the primary mechanism for disseminating ROAs, since these repositories will hold the certificates and CRLs needed to verify ROAs. In addition, ROAs also could be distributed in BGP UPDATE messages or via other communication paths, if needed to meet timeliness requirements.
[RFC6488] and an encapsulated content specific to the ROA that expresses the authorization [RFC6482]. At a high level, the ROA's content contains (1) an AS number; (2) a list of IP address prefixes; and, optionally, (3) for each prefix, the maximum length of more specific (longer) prefixes that the AS is also authorized to advertise. (This last element facilitates a compact authorization to advertise, for example, any prefixes of length 20 to 24 bits contained within a given length 20 prefix.) Note that a ROA contains only a single AS number. Thus, if an ISP has multiple AS numbers that will be authorized to originate routes to the prefix(es) in the ROA, an address space holder will need to issue multiple ROAs to authorize the ISP to originate routes from any of these ASes. A ROA is signed using the private key corresponding to the public key in an end-entity (EE) certificate in the PKI. In order for a ROA to be valid, its corresponding end-entity certificate must be valid, and the IP address prefixes of the ROA must exactly match the IP address prefix(es) specified in the EE certificate's 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 revoking a ROA. One might worry that this revocation model could lead to long CRLs for the CA certification that is signing the EE certificates. However, routing announcements on the public Internet are generally quite long lived. Therefore, as long as the EE certificates used to verify a ROA are given a validity interval of several months, the likelihood that many ROAs would need to be revoked within that time is quite low.
--------- --------- | RIR | | NIR | | CA | | CA | --------- --------- | | | | | | --------- --------- | ISP | | ISP | | CA 1 | | CA 2 | --------- --------- | \ | | ----- | | \ | ---------- ---------- ---------- | ISP | | ISP | | ISP | | EE 1a | | EE 1b | | EE 2 | ---------- ---------- ---------- | | | | | | | | | ---------- ---------- ---------- | ROA 1a | | ROA 1b | | ROA 2 | ---------- ---------- ---------- Figure 1: This figure illustrates an ISP with allocations from two sources (an RIR and an NIR). It needs two CA certificates due to the rules defined in RFC 3779. 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.
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 with repository objects. Indeed, although relying parties can detect tampering with objects in the repository, it is preferable that the repository system prevent such unauthorized modifications to the greatest extent possible. RFC6481].
For every certificate in the PKI, there will be a corresponding file system directory in the repository that is the authoritative publication point for all objects (certificates, CRLs, ROAs, and manifests) verifiable via this certificate. A certificate's Subject Information Access (SIA) extension [RFC5280] contains a URI that references this directory. Additionally, a certificate's Authority Information Access (AIA) extension [RFC5280] 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 | | | +--------- SIA | | | | +--------+ | | | | | | | | | | | | +-------------------|------------------+ | | | | | | +->| +--------+ | +--------+ | | | | Cert B | | | Cert C | | | | | CRLDP ----+ | | CRLDP -+-+ | +----------- AIA | | +----- AIA | | | | | SIA | | | SIA | | | | +--------+ | +--------+ | | | V | | | +---------+ | | | | A's CRL |<-----------+ | | +---------+ | | A's Repository Publication Directory | +--------------------------------------+ Figure 2: Use of SIA and AIA extensions in the RPKI In Figure 2, certificates B and C are issued by CA A. Therefore, the AIA extensions of certificates B and C point to (certificate) A, and the SIA extension of certificate A points to the repository publication point of CA A's subordinate products, which includes certificates B and C, as well as the CRL issued by A. The CRL Distribution Points (CRLDP) extension in certificates B and C both point to the CRL issued by A.
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. Section 4.4). To ensure all relying parties are able to acquire all RPKI signed objects, all publication points MUST be accessible via rsync (see [RFC5781] and [RSYNC]), although other download protocols MAY also be supported. A repository publication point may provide update/change/delete functionality via (set of) access protocols that it desires, provided that the supported protocols are clearly communicated to all certification authorities publishing data at a given publication point.
Section 2.3. Section 6) to mitigate the risk of an attacker who deletes files from a repository or replaces current signed objects with stale versions of the same object. Such protection is needed because, although all objects in the repository system are signed, the repository system itself is untrusted. RFC6486] but, at a high level, a manifest consists of (1) a manifest number; (2) the time the manifest was issued; (3) the time of the next planned update; and (4) a list of filename and hash value pairs.
The manifest number is a sequence number that is incremented each time a manifest is issued by the authority. An authority is REQUIRED to issue a new manifest any time it alters any of its items in the repository, or when the specified time of the next update is reached. A manifest is thus valid until the specified time of the next update or until a manifest is issued with a greater manifest number, whichever comes first. (Note that when an EE certificate is used to sign only a single manifest, whenever the authority issues the new manifest, the CA MUST also issue a new CRL that includes the EE certificate corresponding to the old manifest. The revoked EE certificate for the old manifest will be removed from the CRL when it expires; thus, this procedure ought not to result in significant CRL growth.) RFC6487] for more details.) Note that since relying parties will perform these operations regularly, it is more efficient for the relying party to request from the repository system only those objects that have changed since the relying party last updated its local cache.
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. Section 7.3.2). Other resource holders need not be issued CA certificates within the PKI. In the long run, a resource holder will not request resource certificates, but rather receive a certificate as a side effect of the allocation process for the resource. However, initial deployment of the RPKI will entail issuance of certificates to existing resource holders as an explicit event. Note that in all cases, the authority issuing a CA certificate will be the entity who allocates resources to the subject. This differs from most PKIs in which a subject can request a certificate from any certification authority. If a resource holder receives multiple allocations over time, it may accrue a collection of resource certificates to attest to them. If a resource holder receives multiple allocations from the same source, the set of resource certificates may be combined into a single resource certificate, if both the issuer and the resource holder agree. This is accomplished by consolidating the IP Address Delegation and AS Identifier Delegation extensions into a single
extension (of each type) in a new certificate. However, if these certificates attest to allocations that are valid for different periods of time, creating a certificate that combines them might create problems, as the combined certificate can express only a single validity interval. If a resource holder's allocations come from different sources, they will be signed by different CAs and cannot be combined. When a set of resources is no longer allocated to a resource holder, any certificates attesting to such an allocation MUST be revoked. A resource holder SHOULD NOT use the same public key in multiple CA certificates that are issued by the same or differing authorities, as reuse of a key pair complicates path construction. Note that since the subject's distinguished name is chosen by the issuer, a subject who receives allocations from two sources generally will receive certificates with different subject names. RFC6489] specifies a conservative key rollover procedure that should be used by a certification authority when it changes the public (and private) keys associated with its RPKI CA certificate. At a high level, the two key properties of the rollover procedure are as follows. First, as data from RPKI signed objects may be used in routing operations, the procedure ensures that at any point in the rollover procedure, a relying party will never reach incorrect conclusions about the validity of a signed object. Note in particular, that the CA cannot assume that a relying party will use any particular algorithm for constructing a certificate path from an EE certificate to (one of) the relying party's trust anchor(s); therefore, the key rollover procedure is designed to preserve the
integrity of the SIA and AIA points within the RPKI hierarchy to the greatest extent possible. Second, the key rollover procedure is designed so that the reissuance of all certificates below the CA in the RPKI hierarchy is not required. Of course, it is necessary to re-sign all certificates issued directly under the CA whose key is changing. However, the SIA and AIA pointers within the certificates are populated so that no further reissuance is required. RFC5652]). 4. Upload the end-entity certificate and the ROA to the repository system. The standard procedure for revoking a ROA is to revoke the corresponding end-entity certificate by creating an appropriate CRL and uploading it to the repository system. The revoked ROA and end- entity certificate SHOULD be removed from the repository system. Care must be taken when revoking ROAs in that revoking a ROA may cause a relying party to treat routing advertisements corresponding to the prefixes and origin AS number in the ROA as unauthorized (and potentially even change routing behavior to no longer forward packets based on those advertisements). In particular, resource holders should adhere to the principle of "make before break" as follows. Before revoking a ROA corresponding to a prefix that the resource holder wishes to be routable on the Internet, it is very important for the resource holder to ensure that there exists another valid
alternative ROA that lists the same prefix (possibly indicating a different AS number). Additionally, the resource holder should ensure that the AS indicated in the valid alternative ROA is actually originating routing advertisements to the prefixes in question. Furthermore, a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation.
subscriber's prefixes and not an encompassing aggregate. Note that this approach results in inconsistent origin AS numbers for the subscriber's prefixes that are considered undesirable on the public Internet; thus, this approach is NOT RECOMMENDED. 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. RFC6491].
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC5280] 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. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010. [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012. [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6486] Austein, R., Huston., G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure", RFC 6486, February 2012. [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012. [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure", RFC 6488, February 2012. [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, February 2012. [RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012. [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012. [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012. [RSYNC] rsync web pages, <http://rsync.samba.org/>. [S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000. [soBGP] White, R., "soBGP", May 2005, <ftp://ftp-eng.cisco.com/sobgp/index.html>