RFC 6480
An Infrastructure to Support Secure Internet Routing
RFC 6480: An Infrastructure to Support Secure Internet Routing 🎀
okay bestie, this is part 1 of 6 of RFC 6480 💖 so grab a snack, we're going in ✨
The title block gives us the basics. It's an Informational RFC, so it's not a Standards Track spec. It's published for info and vibes 🦋 It came out in February 2012, and its ISSN is 2070-1721. The authors are M. Lepinski and S. Kent, both at BBN Technologies. The title block doesn't list anything it obsoletes or updates, so it's standing completely on its own 💅
Abstract
okay so the big idea is this 🌸 It describes an architecture for an infrastructure that makes Internet routing more secure. The foundation is a Resource Public Key Infrastructure (RPKI) that mirrors the allocation hierarchy of IP address space and Autonomous System (AS) numbers. On top of that sits a distributed repository system that stores and shares the RPKI data objects, plus other signed objects needed for better routing security 🔐
The first real application is about letting the legitimate holder of IP address space explicitly and verifiably authorize one or more ASes to originate routes to that space. Those verifiable authorizations could be used, for example, to build BGP route filters more securely 🧚
Status of This Memo
this is not an Internet Standards Track specification 💅 it's published for informational purposes.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 👑
For the current status, any errata, and how to give feedback, check 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. please actually read these, they spell out your rights and restrictions 🙈 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.
Table of Contents
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 ...................................231. Introduction ✨
okay this is the intro where the architecture gets its whole personality 🦋 It's built to support better security for BGP routing [RFC4271] across the Internet. It has three principal elements:
- Resource Public Key Infrastructure (RPKI)
- digitally signed routing objects to support routing security
- a distributed repository system to hold the PKI objects and the signed routing objects
With this architecture, an entity can verifiably prove that it's the legitimate holder of a set of IP addresses or a set of Autonomous System (AS) numbers 💅 The first real application is the same as in the abstract: the legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that space, and those authorizations could help build BGP route filters more securely 🔐 The infrastructure is also meant to support future security protocols like Secure BGP [S-BGP] or Secure Origin BGP [soBGP] 🌈 It applies to routing both IPv4 and IPv6 datagrams. Right now, IPv4 and IPv6 are the only address families it supports, so using it with MPLS labels is out of scope for this document 🙈
To make deployment easier, the architecture reuses existing technologies and practices 🌸 The PKI part matches the existing resource allocation structure, so running it is basically a natural extension of what the organizations already responsible for IP address and AS number allocation already do. Existing allocation and revocation practices also have clear counterparts in this architecture 🧚 Note that even though routing security is the initial focus, the PKI could also support other applications that rely on attestations of IP address or AS number resource holdings ✨
To keep implementation simple, existing IETF standards get used wherever possible 💖 For example, it leans heavily on the X.509 certificate profile from the Public Key Infrastructure using X.509 (PKIX) [RFC5280] working group, plus the extensions for representing IP addresses and AS numbers defined in RFC 3779 [RFC3779]. Cryptographic Message Syntax (CMS) [RFC5652] is the syntax for the newly defined signed objects [RFC6488] that this infrastructure needs 🎀
So the architecture has three main components 🫶 First, an X.509 PKI where certificates attest to holdings of IP address space and AS numbers. Second, non-certificate signed objects (including route origination authorizations and manifests) used by the infrastructure. Third, a distributed repository system that makes all these signed objects available for ISPs to use when making routing decisions. Together, these three pieces enable several security functions, most notably the cryptographic validation that an autonomous system is authorized to originate routes to a given prefix [RFC6483] 👑
1.1. Terminology 📚
okay so you need to be familiar with the terms and concepts in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779] before this makes full sense 🧚
The terms "address space holder" and "holder of IP address space" get used interchangeably to mean a legitimate holder of IP address space who got it through the standard IP address allocation hierarchy 🌸 That means the holder either got the space directly as an allocation from a Regional Internet Registry (RIR) or IANA, or got it as a sub-allocation from a National Internet Registry (NIR) or Local Internet Registry (LIR). We use "resource holder" for a legitimate holder of either IP address or AS number resources 💅
The terms "registry" and "ISP" refer to an entity that has an IP address space and/or AS number allocation it's 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] 🫶
2. Public Key Infrastructure for Internet Number Resources ✨
okay bestie, this is the heart of the whole thing 💖. Whoever holds a block of IP address space gets to decide the topological destination of IP datagrams whose destinations fall inside that block 🦋. So inter-domain routing decisions are basically built on knowing who was allocated what, and a core job of this architecture is giving cryptographically verifiable attestations about those allocations 🔐. Right now IP address allocation is hierarchical 🌈. The root is IANA. Under IANA sit five Regional Internet Registries (RIRs), and each one manages address and AS number allocation within a defined geopolitical region 🌸.
In some regions the third tier also has National Internet Registries (NIRs), plus Local Internet Registries (LIRs) and subscribers with so-called provider-independent ("portable") allocations 💅. Quick aside: in some regions "LIR" means what other regions call an ISP, so for the rest of this doc we're just saying "LIR/ISP" to keep things simple 🫶. In other regions the third tier is only LIRs/ISPs and subscribers with provider-independent allocations ✨.
The holder of a block can sub-allocate portions of it, either to itself (like a particular unit of the same organization) or to another organization, subject to contractual constraints set by the registries 💼. Because of this structure, IP address allocations can be described naturally by a hierarchic public key infrastructure 🧚. Each certificate attests to an allocation of IP addresses, and issuing a subordinate certificate corresponds to sub-allocating IP addresses. The same reasoning holds for AS number resources, with one difference: by convention, AS numbers may not be sub-allocated except by RIRs or NIRs. So allocations of both IP addresses and AS numbers can be expressed by the same PKI 👑. This PKI is henceforth referred to as the "Resource Public Key Infrastructure (RPKI)", and it is a central component of this architecture 💜.
2.1. Role in the Overall Architecture
Certificates in this PKI are called resource certificates, and they conform to the certificate profile for such certificates [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 in the resource certificate to the IP addresses or AS numbers in the certificate's IP Address Delegation or AS Identifier Delegation extensions, respectively, as defined in RFC 3779 [RFC3779] ✨.
An important property here is that certificates do not attest to the identity of the subject 🙈. So the subject names in certificates are not meant to be "descriptive". The resource PKI is intended to provide authorization, but not authentication. This is different from most PKIs, where the issuer makes sure the descriptive subject name is properly tied to the entity holding the private key. Because issuers don't need to verify an entity's right to use a subject name, they dodge the costs and liabilities of that verification, which 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 the rest of the infrastructure runs on 🧠. CA certificates 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 validating Route Origination Authorizations (ROAs), which are signed objects giving an explicit authorization by an address holder that a given AS is permitted to originate routes to a set of addresses (see Section 3) 🔥. EE certificates are also used to verify other signed objects, like manifests, which help ensure the integrity of the repository system (see Section 5) 🫶.
2.2. CA Certificates
Any resource holder who is authorized to sub-allocate these resources must be able to issue resource certificates for those sub-allocations 🌷. So, for example, CA certificates are associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. A CA certificate is also required to let a resource holder issue ROAs, because the holder must issue the corresponding end-entity certificate used to validate each ROA 🎀. That means some entities that don't sub-allocate their resources will still need CA certificates for their allocations. A multi-homed subscriber with a provider-independent allocation is a good example, since it needs one to issue ROAs 🦋.
(Side note, bestie: 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 😌. A multi-homed subscriber with an allocation from an LIR/ISP may or may not need to be explicitly represented, as discussed in Section 7.3.2.)
Unlike 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. It must include the CommonName attribute, and it may additionally include the serial attribute 🍓.
The issuer here is an RIR, NIR, or LIR/ISP, and it is not in the business of verifying the legal right of the subject to assert a particular identity 💼. So picking a distinguished name that doesn't convey identity descriptively minimizes the chance the subject can misuse the certificate to assert an identity, and it minimizes the issuer's legal liability 🛡️. Since every CA certificate goes to a subject the issuer already has a relationship with, it is recommended that the issuer pick a subject name that makes it easy to link the certificate to existing database records 🗂️. For example, an authority may use internal database keys or subscriber IDs as the subject's common name in issued certificates 🧚.
Even though the common name doesn't convey identity, it still must be unique among all subjects to whom a certification authority issues certificates 💜. In other words, 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 with allocations from multiple sources will have multiple CA certificates 🌈. When an entity receives multiple certificates from different issuers, the subject names in those certificates will generally be different 🌸. A CA may also issue distinct certificates for each distinct allocation to the same entity, if the CA and the resource holder agree that this arrangement will make management and use of the certificates easier 🫶. 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 wants to treat the allocations as separate ✨.
2.3. End-Entity (EE) Certificates
The private key corresponding to a public key in an EE certificate is not used to sign other certificates in a PKI 🔑. The primary function of end-entity certificates here is verifying signed objects that relate to the usage of the resources described in the certificate, like ROAs and manifests 💅.
For ROAs and manifests, there is a one-to-one correspondence between end-entity certificates and signed objects 🦋. The private key for each end-entity certificate is used to sign exactly one object, and each object is signed with only one key. This property lets the PKI revoke these signed objects, rather than inventing 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) is considered invalid. So a signed object can be effectively revoked just by revoking the end-entity certificate used to sign it 💀.
There's also a secondary advantage. The private key for a public key in a certificate is used exactly once in its lifetime, so it can be destroyed after it has signed its one object 🧹. This 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 of that signed object (see [RFC6488]) 🎁. So 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. That could facilitate authentication of inter-ISP interactions, or authentication of interactions with the repository system 👑. These additional uses may require retention of the corresponding private keys, even though such retention is not required for keys used to sign ROAs and manifests 🌷.
2.4. Trust Anchors 🔐✨
Okay so bestie, in any PKI every relying party (RP) gets to pick its own set of trust anchors (TAs). Main character energy, literally 👑. This is just how PKIs work, and it applies here too. There's already an existing IP address space and AS number allocation hierarchy, so IANA and/or the five RIRs are the obvious candidates to be default TAs. Still, each RP makes the final call on which trust anchors it uses for certificate validation. 💅
For example, an RP (like an LIR/ISP) could create a trust anchor that all address space and/or all AS numbers get assigned to, and it knows the private key for it. 🗝️ The RP can then issue certificates under that trust anchor to whoever in the PKI it wants. So certification paths ending at this locally installed trust anchor will meet the validation requirements in RFC 3779. It's giving custom-made 🎀. A big ISP that uses private IP address space (that's RFC 1918) and runs BGP internally will need to make this kind of trust anchor, so it can have a CA that all the private address space is assigned to. The RP can then issue certificates under that CA that match how it uses private address space internally. 🧚
Note that an RP who decides to create and manage its own trust anchors might miss allocation errors that come up in that situation. But the vulnerability stays local to that RP, so it's not everyone's problem 🙈.
It's expected that some parties in the existing IP address space and AS number allocation hierarchy may want to publish trust anchor material so relying parties can use it. A standard profile for publishing trust anchor material for this PKI is in [RFC6490] 🌸.
3. Route Origination Authorizations 🦋
Okay, so the info about IP address allocation that the PKI gives you isn't enough by itself to guide routing decisions 🙃. BGP assumes that the AS originating routes for a particular prefix is authorized to do that by the holder of the prefix (or of an address block that contains the prefix). But the PKI has no info about those authorizations at all. That's the gap! A Route Origination Authorization (ROA) fills it. It makes that authorization explicit, so a holder of IP address space can create an object that clearly and verifiably says an AS is allowed to originate routes to a given set of prefixes. Iconic 🔥.
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 ✨. It's structured according to the format in [RFC6482]. The validity of this authorization depends on the signer of the ROA being the holder of the prefix(es) in the ROA. An end-entity certificate from the PKI asserts that fact, and its matching private key is what signs the ROA 🔏.
Relying parties can use ROAs to check that the AS originating a route for a given IP address prefix is authorized by the prefix holder to originate that route. For example, an ISP might use validated ROAs as inputs when it builds route filters for its BGP routers 🛡️. (See [RFC6483] for info on using ROAs to validate BGP route origination.)
At the start, the repository system will be the main way ROAs get shared, since the repositories hold the certificates and CRLs needed to verify ROAs 📦. ROAs could also be distributed in BGP UPDATE messages or through other communication paths, if timeliness requirements call for it ⏰.
3.2. Syntax and Semantics 📜
A ROA is an explicit authorization for a single AS to originate routes to one or more prefixes, and it's signed by the holder of those prefixes 💖. Conceptually, the ROA syntax has two parts: a general CMS template that all RPKI signed objects share ([RFC6488]), and encapsulated content specific to the ROA that expresses the authorization ([RFC6482]). Two layers, very organized 🎀.
At a high level, the ROA's content has (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. That last bit makes a compact authorization possible, like allowing any prefixes of length 20 to 24 bits inside a given length 20 prefix 🍓.
Note that a ROA only contains a single AS number. So if an ISP has multiple AS numbers that should be allowed to originate routes to the prefix(es) in the ROA, the address space holder will need to issue multiple ROAs to authorize the ISP to originate routes from any of those ASes 🙈.
A ROA is signed using the private key that matches the public key in an end-entity (EE) certificate in the PKI. For a ROA to be valid, its end-entity certificate must be valid, and the IP address prefixes in the ROA must exactly match the IP address prefix(es) in the EE certificate's RFC 3779 extension. So the ROA's validity interval is implicitly the validity interval of its certificate ⏳. A ROA gets revoked by revoking its EE certificate, and there's no separate way to revoke a ROA 🚫. Someone might worry this revocation model leads to long CRLs for the CA certifying the EE certificates. But routing announcements on the public Internet are generally long lived 🌈. So as long as the EE certificates used to verify a ROA have a validity interval of several months, it's pretty unlikely that lots of ROAs would need revoking in that window 😌.
--------- ---------
| 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. 🗺️
Since each ROA is tied to a single end-entity certificate, the set of IP prefixes in a ROA must come from an allocation by a single source. In other words, a ROA can't mix allocations from multiple sources 🙅♀️. Address space holders with allocations from multiple sources, who want to authorize an AS to originate routes for those allocations, must issue multiple ROAs to that AS 💜.
4. Repositories 🗄️
To start, an LIR/ISP will use the resource PKI by acquiring and validating every ROA, so it can build a table of the prefixes each AS is authorized to originate routes for 📋. To validate all ROAs, an LIR/ISP needs to acquire all the certificates and CRLs. The main job of the distributed repository system described here is to store these signed objects and make them available for LIRs/ISPs to download 📥. This repository system lets relying parties pull fresh data at whatever frequency they think is right. However, it doesn't give them a way to have fresh data pushed to them (for example, by putting resource PKI objects in BGP or other protocol messages). That kind of mechanism is beyond the scope of this document, so we're skipping it for now 🚀.
The digital signatures on all objects in the repository make sure that unauthorized changes to valid objects are detectable by relying parties 🔍. The repository system also uses manifests (see Section 5) so relying parties can detect when valid objects get deleted or when out-of-date, valid signed objects get inserted 🕵️♀️.
The repository system is also where access controls for the signed objects stored in it get enforced. For example, records related to an allocation of resources can only be changed by authorized parties 🔐. Access controls help prevent denial-of-service attacks based on deleting or tampering with repository objects. Even though relying parties can detect tampering, it's preferable that the repository system prevents unauthorized modifications as much as possible 💯.
4.1. Role in the Overall Architecture 🏗️
The repository system is the untrusted clearing-house for all signed objects that need to be globally accessible to relying parties 📬. When certificates and CRLs are created, they're uploaded to this repository, and then downloaded for use by relying parties (mainly LIRs/ISPs) 💌. ROAs and manifests are more examples of such objects, but other types of signed objects may be added to this architecture in the future ✨. This document gives a brief description of how signed objects (certificates, CRLs, ROAs, and manifests) are managed in the repository system. As other types of signed objects get added, the description will need to be modified, but most of the design principles are expected to still apply 🌷. The repository system is described in detail in [RFC6481] 🎀.
4.2. Contents and Structure ✨
okay so there's technically ONE repository system that relying parties access, but it's actually made up of multiple databases 🗂️ spread across registries (RIRs, NIRs, LIRs/ISPs). At a minimum, the database each registry runs holds all CA and EE certificates, CRLs, and manifests signed by the CA(s) tied to that registry. Repositories run by LIRs/ISPs also hold ROAs. Registries are encouraged to keep copies of repo data from their customers, and their customers' customers (etc.), so relying parties can grab the whole repo contents without drama 🫶. Ideally, each RIR holds PKI data from all entities in its geopolitical scope 🌍.
For every certificate in the PKI, there's a matching file system directory in the repo, and that directory is the authoritative publication point for all objects (certificates, CRLs, ROAs, and manifests) that can be verified through that certificate 📂. A certificate's Subject Information Access (SIA) extension [RFC5280] holds a URI that points to this directory. A certificate's Authority Information Access (AIA) extension [RFC5280] holds a URI that points to the authoritative location of the CA certificate it was issued under. So if certificate A is used to verify certificate B, then B's AIA points to A, and A's SIA points to a directory containing 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 🧾. So 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. That includes certificates B and C, plus 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 gets reissued with the same public key, it should not be necessary to reissue (with an updated AIA URI) every certificate signed by the reissued certificate 🙅♀️. That's why a certification authority SHOULD use a persistent URI naming scheme for issued certificates 🔁. Reissued certificates should use the same publication point as the previously issued certificates that have the same subject and public key, and they should overwrite those certificates.
4.3. Access Protocols 🦋
Repository operators will choose one or more access protocols that relying parties can use to get into the repository system 🔑. These protocols get used by a bunch of participants in the infrastructure (e.g., all registries, ISPs, and multi-homed subscribers) to keep their own parts of it up to date. To support all that, the suite of access protocols needs certain basic functionality, which is described below. No single access protocol has to implement all of these functions (although it might!), but each function MUST be implemented by at least one access protocol deployed by a repository operator 💪.
Download: Access protocols must support bulk download of repository contents, plus downloading the changes to what was already downloaded, since this is the most common way relying parties will interact with the repo system 📥. Other download interactions (e.g., downloading 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 remove them 🗑️. Mechanisms for modifying objects in the repository may also be provided. All access protocols that allow changes to the repository (through addition, deletion, or modification of its contents) must support verification of the authorization of the entity making the change, so that appropriate access controls can be applied (see Section 4.4) 🛡️.
To make sure all relying parties can 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 can offer whatever update/change/delete functionality it wants via (a set of) access protocols, as long as the supported protocols are clearly communicated to all certification authorities publishing data at that publication point 📣.
4.4. Access Control 🔐
To keep the repository's info legit, controls have to be put in place to stop unauthorized parties from adding, deleting, or modifying objects in the repository 🚫. The identities of parties trying to make those changes can be authenticated through the relevant access protocols. Specific access control policies are up to the local control of repository operators, but 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, so resource holders can authorize other parties to act on their behalf, as suggested in Section 2.3 👑.
5. Manifests 📜
A manifest is a signed object listing all of the signed objects (except for the manifest itself) issued by an authority responsible for a publication in the repository system 📋. For each unexpired certificate, CRL, or ROA the authority issued, the manifest contains both the name of the file holding the object and a hash of the file content.
Just like ROAs, a manifest is signed by a private key, and the matching public key shows up in an end-entity certificate 🔏. That EE certificate is then signed by the CA in question. Since the private key in an EE certificate is only used to sign a single manifest, the manifest can be revoked by revoking the EE certificate. In that case, to avoid needless CRL growth, the EE certificate used to validate a manifest SHOULD expire at the same time the manifest expires ⏰.
Relying parties may use manifests when building a local cache (see Section 6) to lower the risk of an attacker who deletes files from a repository or swaps current signed objects for stale versions of the same object 🕵️♀️. That protection is needed because, even though all objects in the repository system are signed, the repository system itself is untrusted 🚨.
5.1. Syntax and Semantics 💅
A manifest is basically a list of (the hashes of) all the files in a repository publication point at a particular moment in time 🕰️. The detailed specification of the manifest's content is in [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 goes up by one each time the authority issues a manifest 🔢. An authority is REQUIRED to issue a new manifest any time it changes any of its items in the repository, or when the specified time of the next update is reached. A manifest is valid until the specified time of the next update, or until a manifest with a greater manifest number is issued, 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, so this procedure ought not to result in significant CRL growth 🧹.)
6. Local Cache Maintenance 🧁
To use signed objects issued under this PKI, a relying party must first obtain a local copy of the valid EE certificates for the PKI 🍰. To do that, the relying party performs the following steps:
- Query the repository system to obtain a copy of all certificates, manifests, and CRLs issued under the PKI.
- For each CA certificate in the PKI, verify the signature on the corresponding manifest. Additionally, verify that the current time is earlier than the time indicated in the nextUpdate field of the manifest.
- For each manifest, verify that certificates and CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that no certificate or manifest listed on the manifest is missing from the repository. If the hash values don't match, or if any certificate or CRL is missing, notify the appropriate repository administrator that the repository data has been corrupted 🚩.
- Validate each EE certificate by constructing and verifying a certification path for the certificate (including checking relevant CRLs) to the locally configured set of TAs. (See [RFC6487] for more details.) 🔍
Since relying parties do these operations regularly, it's way more efficient for the relying party to request from the repository system only the objects that have changed since it last updated its local cache ⚡. Also, by checking all issued objects against the appropriate manifest, the relying party can be certain it isn't missing an updated version of any object 💯.
7. Common Operations 🎀
Creating and maintaining the infrastructure described above will involve extra operations as "side effects" of normal resource allocation and routing authorization procedures 🧩. For example, a subscriber with provider-independent ("portable") address space who enters a relationship with an ISP will need to issue one or more ROAs identifying that ISP, in addition to doing any other necessary technical or business procedures 🤝. The current main use of this infrastructure is route filter construction. Using ROAs, route filters can be built in an automated way with high assurance that the holder of the advertised prefix has authorized the origin AS to originate an advertised route 🌸✨.
7.1. Certificate Issuance 🎀
okay so there are a bunch of situations where certificates need to get issued 💅 Any allocation that might get sub-allocated needs a CA certificate, so certificates can be issued for those sub-allocations whenever they're needed 🌸 Holders of provider-independent IP address space need certificates too, so a ROA can be issued to each ISP that's allowed to originate a route to the allocation, since the allocation doesn't come from any ISP 🦋 Multi-homed subscribers might also need certificates for their allocations if they plan on issuing the ROAs for those allocations themselves (see Section 7.3.2) ✨ Other resource holders don't need CA certificates in the PKI, so no stress for them 🫶
in the long run, a resource holder won't have to request resource certificates. they'll just get one automatically as a side effect of the allocation process for the resource 🧚 the initial rollout of the RPKI is different though, since it means handing certificates out to existing resource holders as an explicit event 🍓 and in every case, the authority that issues a CA certificate is the entity that allocates the resources to the subject. this is different from most PKIs, where a subject can ask any certification authority for a certificate 👑
if a resource holder gets multiple allocations over time, they might end up with a bunch of resource certificates attesting to them 💜 if the allocations all come from the same source, the certificates can be merged into one resource certificate, but only if both the issuer and the resource holder agree 🔥 this happens by combining the IP Address Delegation and AS Identifier Delegation extensions into a single extension (of each type) in a new certificate. BUT, ngl, if the certificates cover allocations that are valid for different periods of time, merging them can cause problems, because the combined certificate can only express a single validity interval 😭
if a resource holder's allocations come from different sources, they'll be signed by different CAs and can't be merged 🙈 when a set of resources is no longer allocated to a resource holder, any certificates attesting to that allocation MUST be revoked 🚫 a resource holder SHOULD NOT use the same public key in multiple CA certificates issued by the same or different authorities, because reusing a key pair makes path construction more complicated 🌈 also, since the issuer picks the subject's distinguished name, a subject who gets allocations from two sources will usually end up with certificates that have different subject names 🎀
7.2. CA Key Rollover 🔄
whenever a certification authority wants to change the public key (and the matching private key) tied to its RPKI CA certificate, it MUST perform a key rollover procedure 🌸 rollovers usually happen on a periodic schedule, and how often is written down in the certification practice statement of that CA ⭐ unscheduled rollovers might also be needed if a key is suspected to be compromised 😳
rollover is only required when the CA's key actually changes. it's NOT needed when a new CA certificate gets issued with the same key as the previous one 🦋 for example, a new CA certificate has to be issued if the CA gains or gives up a resource, or if the validity period of the resource allocation gets extended. in those cases the new certificate will usually reuse the same public (and private) key as the old one, so no key rollover is needed 💖
the document [RFC6489] lays out a conservative key rollover procedure that should be used by a certification authority when it changes the public (and private) keys tied to its RPKI CA certificate 🧚 the two big properties of that procedure are these. first, data from RPKI signed objects might get used in routing operations, so the procedure makes sure that at every point during the rollover, a relying party never reaches incorrect conclusions about whether a signed object is valid. the CA can't assume a relying party will use any specific algorithm to build a certificate path from an EE certificate to (one of) the relying party's trust anchor(s), so the procedure is designed to keep the SIA and AIA points inside the RPKI hierarchy intact as much as possible 🫶 second, the procedure is designed so that certificates further down the RPKI hierarchy below the CA don't all have to be reissued. the certificates issued directly under the CA whose key is changing do have to be re-signed, obviously 🍓 but the SIA and AIA pointers in those certificates are filled in so that no further reissuance is needed 🌈
7.3. ROA Management 📜
whenever a holder of IP address space wants to authorize an AS to originate routes for a prefix inside their holdings, they MUST issue an end-entity certificate that contains that prefix in an IP Address Delegation extension 👑 then they use the matching private key to sign a ROA containing the designated prefix and the AS number for that AS ✨ the resource holder MAY include more than one prefix in the EE certificate and the corresponding ROA if they want to 💅 so, as a prerequisite, any address space holder that issues ROAs for a prefix must have a resource certificate for an allocation containing that prefix 🔥 the standard procedure for issuing a ROA goes like this:
- Create an end-entity certificate containing the prefix(es) to be authorized in the ROA.
- Construct the payload of the ROA, including the prefixes in the end-entity certificate and the AS number to be authorized.
- Sign the ROA using the private key corresponding to the end-entity certificate (the ROA is comprised of the payload encapsulated in a CMS signed message [RFC5652]).
- Upload the end-entity certificate and the ROA to the repository system.
the standard way to revoke a ROA is to revoke the matching end-entity certificate by making an appropriate CRL and uploading it to the repository system 🌸 the revoked ROA and end-entity certificate SHOULD be removed from the repository system 🧹
⚠️ be careful when revoking ROAs! revoking one can make a relying party treat the routing advertisements matching the prefixes and origin AS number in that ROA as unauthorized, and it could even change routing behavior so packets stop being forwarded based on those advertisements 😱 so resource holders should follow the principle of "make before break" 🫶 before revoking a ROA for a prefix the resource holder wants to stay routable on the Internet, it's super important to make sure there's another valid alternative ROA listing that same prefix (it could have a different AS number, tho) 💀 the resource holder should also make sure the AS in that valid alternative ROA is actually originating routing advertisements to those prefixes. and finally, a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation 🙌
7.3.1. Single-Homed Subscribers 🏠
in BGP, a single-homed subscriber with Provider Aggregatable (PA) address space doesn't need to explicitly authorize routes to be originated for the prefix(es) it's using 💁♀️ that's because its ISP already advertises a more general prefix and routes traffic for the subscriber's prefix as an internal function. since no routes are originated specifically for prefixes held by these subscribers, no ROAs need to be issued under their allocations 🌷 instead, the subscriber's ISP issues any necessary ROAs for its more general prefixes under resource certificates from its own allocation. so a single-homed subscriber with an IP address allocation from their service provider isn't part of the RPKI at all: no CA certificate, no EE certificates, no ROAs 🧚
7.3.2. Multi-Homed Subscribers 🌐
now let's talk about a subscriber who gets Provider Aggregatable (PA) IP address space from a primary ISP (so the IP addresses they use are a subset of ISP A's IP address space allocation) and also gets redundant upstream connectivity from one or more secondary ISPs, on top of the primary ISP 🦋 the preferred option for this kind of multi-homed subscriber is to get an AS number and run BGP with each of their upstream providers 👑 in that case there are two RECOMMENDED ways to handle ROA management. the first is that the primary ISP issues a CA certificate to the subscriber, and the subscriber issues a ROA containing the subscriber's AS number and the subscriber's IP address prefixes 💖 the second is that the primary ISP doesn't issue a CA certificate to the subscriber, and instead issues a ROA on the subscriber's behalf that contains the subscriber's AS number and the subscriber's IP address prefixes 🍓
if the subscriber can't or won't get an AS number and run BGP, another option is for the multi-homed subscriber to ask the primary ISP to create a ROA for each secondary ISP, authorizing that secondary ISP to originate routes to the subscriber's prefixes 🫶 the primary ISP will also create a ROA containing its own AS number and the subscriber's prefixes, because in that case the primary ISP probably wants to advertise exactly the subscriber's prefixes and not some encompassing aggregate 🌈 but heads up, this approach gives inconsistent origin AS numbers for the subscriber's prefixes, which are considered undesirable on the public Internet 😬 so this approach is NOT RECOMMENDED 🙅♀️
7.3.3. Provider-Independent Address Space 🌍
a resource holder has provider-independent (portable) address space if they got their allocation directly from a RIR or NIR 💜 since the prefixes in these allocations aren't taken from an allocation held by an ISP, there's no ISP holding and advertising a more general prefix for them 😤 a holder of a portable IP address space allocation MUST authorize one or more ASes to originate routes to these prefixes. so the resource holder MUST generate one or more EE certificates and associated ROAs to let the AS(es) 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 for the subscriber's provider-independent allocation 🙃
8. Security Considerations 🔐
the focus of this document is security, so security considerations are basically everywhere in this spec 🚨
the security mechanisms this architecture provides and enables 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 🔒 and because the repository system is structured as a distributed database, it should be inherently resistant to denial-of-service attacks 🛡️ still, appropriate precautions should also be taken, both through replication and backup of the constituent databases and through the physical security of database servers 💅✨
9. IANA Considerations 🎀
okay so for IANA stuff, the instructions for how IANA gets involved with the RPKI live in [RFC6491] 🌸✨. go read that one, bestie 💅
10. Acknowledgments 🫶
ngl this architecture didn't come from one genius 🧠 it's built on the collective ideas of a LOT of people 💖. the intellectual contributions of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim Christensen and Cathy Murphy of ARIN, Rob Austein of ISC, and Randy Bush of IIJ are literally the foundation 🏗️🦋. we are so grateful 🥹
okay but also, a few people get special shoutouts 📣: Rob Austein for the concept of a manifest 📜, Geoff Huston for the idea of managing object validity through single-use EE certificate key pairs 🔑✨, and Richard Barnes for helping with an early version of this document 🎀. iconic contributors, all of them 👑
11. References 📚
11.1. Normative References 💜
- [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.
11.2. Informative References 🌈
- [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>
Authors' Addresses 🧚
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138
EMail: mlepinski@bbn.com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138
EMail: kent@bbn.com
📦 where this page comes from
- ietf: rfc6480 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms