< draft-ietf-sidr-arch-09.txt   draft-ietf-sidr-arch-10.txt >
Secure Inter-Domain Routing M. Lepinski Secure Inter-Domain Routing M. Lepinski
Working Group S. Kent Working Group S. Kent
Internet Draft BBN Technologies Internet Draft BBN Technologies
Intended status: Informational October 26, 2009 Intended status: Informational September 21, 2010
Expires: April 26, 2010 Expires: March 21, 2011
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-09.txt draft-ietf-sidr-arch-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 20010. This Internet-Draft will expire on April 21, 20010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. 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.
Abstract Abstract
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
support improved security of Internet routing. The foundation of this support improved security of Internet routing. The foundation of this
architecture is a public key infrastructure (PKI) that represents the architecture is a public key infrastructure (PKI) that represents the
allocation hierarchy of IP address space and Autonomous System allocation hierarchy of IP address space and Autonomous System (AS)
Numbers; and a distributed repository system for storing and Numbers; and a distributed repository system for storing and
disseminating the data objects that comprise the PKI, as well as disseminating the data objects that comprise the PKI, as well as
other signed objects necessary for improved routing security. As an other signed objects necessary for improved routing security. As an
initial application of this architecture, the document describes how initial application of this architecture, the document describes how
a legitimate holder of IP address space can explicitly and verifiably a legitimate holder of IP address space can explicitly and verifiably
authorize one or more ASes to originate routes to that address space. authorize one or more ASes to originate routes to that address space.
Such verifiable authorizations could be used, for example, to more Such verifiable authorizations could be used, for example, to more
securely construct BGP route filters. securely construct BGP route filters.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ............................................... 3
1.1. Terminology...............................................4 1.1. Terminology ........................................... 4
2. PKI for Internet Number Resources..............................5 2. PKI for Internet Number Resources .......................... 5
2.1. Role in the overall architecture..........................5 2.1. Role in the overall architecture ...................... 5
2.2. CA Certificates...........................................6 2.2. CA Certificates ....................................... 6
2.3. End-Entity (EE) Certificates..............................7 2.3. End-Entity (EE) Certificates .......................... 7
2.4. Trust Anchors.............................................8 2.4. Trust Anchors ......................................... 8
3. Route Origination Authorizations...............................9 3. Route Origination Authorizations ........................... 9
3.1. Role in the overall architecture..........................9 3.1. Role in the overall architecture ...................... 9
3.2. Syntax and semantics.....................................10 3.2. Syntax and semantics .................................. 10
4. Repositories..................................................11 4. Repositories ............................................... 11
4.1. Role in the overall architecture.........................12 4.1. Role in the overall architecture ...................... 12
4.2. Contents and structure...................................12 4.2. Contents and structure ................................ 12
4.3. Access protocols.........................................14 4.3. Access protocols ...................................... 14
4.4. Access control...........................................14 4.4. Access control ........................................ 15
5. Manifests.....................................................15 5. Manifests .................................................. 15
5.1. Syntax and semantics.....................................15 5.1. Syntax and semantics .................................. 15
6. Local Cache Maintenance.......................................16 6. Local Cache Maintenance .................................... 16
7. Common Operations.............................................17 7. Common Operations .......................................... 17
7.1. Certificate issuance.....................................17 7.1. Certificate issuance .................................. 17
7.2. ROA management...........................................18 7.2. CA Key Rollover ....................................... 18
7.2.1. Single-homed subscribers (with PA address space)....19 7.3. ROA management ........................................ 19
7.2.2. Multi-homed subscribers (with PA address space).....19 7.3.1. Single-homed subscribers (with PA address space) . 20
7.2.3. Provider-Independent Address Space..................20 7.3.2. Multi-homed subscribers (with PA address space) .. 20
8. Security Considerations.......................................20 7.3.3. Provider-Independent Address Space ............... 21
9. IANA Considerations...........................................21 8. Security Considerations .................................... 21
10. Acknowledgments..............................................21 9. IANA Considerations ........................................ 21
11. References...................................................22 10. Acknowledgments ........................................... 22
11.1. Normative References....................................22 11. References ................................................ 23
11.2. Informative References..................................22 11.1. Normative References ................................. 23
Authors' Addresses...............................................23 11.2. Informative References ............................... 24
Pre-5378 Material Disclaimer.....................................23 Authors' Addresses ............................................ 25
1. Introduction 1. Introduction
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
support improved security for BGP routing [2] for the Internet. The support improved security for BGP routing [RFC 4271] for the
architecture encompasses three principle elements: Internet. The architecture encompasses three principle elements:
. a public key infrastructure (PKI) . a public key infrastructure (PKI)
. digitally-signed routing objects to support routing security . digitally-signed routing objects to support routing security
. a distributed repository system to hold the PKI objects and the . a distributed repository system to hold the PKI objects and the
signed routing objects signed routing objects
The architecture described by this document enables an entity to The architecture described by this document enables an entity to
verifiably assert that it is the legitimate holder of a set of IP 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 addresses or a set of Autonomous System (AS) numbers. As an initial
application of this architecture, the document describes how a application of this architecture, the document describes how a
legitimate holder of IP address space can explicitly and verifiably legitimate holder of IP address space can explicitly and verifiably
authorize one or more ASes to originate routes to that address space. authorize one or more ASes to originate routes to that address space.
Such verifiable authorizations could be used, for example, to more Such verifiable authorizations could be used, for example, to more
securely construct BGP route filters. In addition to this initial securely construct BGP route filters. In addition to this initial
application, the infrastructure defined by this architecture also is application, the infrastructure defined by this architecture also is
intended to provide future support for security protocols such as S- intended to provide future support for security protocols such as S-
BGP [12] or soBGP [13]. This architecture is applicable to the BGP [S-BGP] or soBGP [soBGP]. This architecture is applicable to the
routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently
the only address families supported by this architecture. Thus, for the only address families supported by this architecture. Thus, for
example, use of this architecture with MPLS labels is beyond the example, use of this architecture with MPLS labels is beyond the
scope of this document. scope of this document.
In order to facilitate deployment, the architecture takes advantage In order to facilitate deployment, the architecture takes advantage
of existing technologies and practices. The structure of the PKI of existing technologies and practices. The structure of the PKI
element of the architecture corresponds to the existing resource element of the architecture corresponds to the existing resource
allocation structure. Thus management of this PKI is a natural allocation structure. Thus management of this PKI is a natural
extension of the resource-management functions of the organizations extension of the resource-management functions of the organizations
that are already responsible for IP address and AS number resource that are already responsible for IP address and AS number resource
allocation. Likewise, existing resource allocation and revocation allocation. Likewise, existing resource allocation and revocation
practices have well-defined correspondents in this architecture. Note practices have well-defined correspondents in this architecture. Note
that while the initial focus of this architecture is routing security that while the initial focus of this architecture is routing security
applications, the PKI described in this document could be used to applications, the PKI described in this document could be used to
support other applications that make use of attestations of IP support other applications that make use of attestations of IP
address or AS number resource holdings. address or AS number resource holdings.
To ease implementation, existing IETF standards are used wherever To ease implementation, existing IETF standards are used wherever
possible; for example, extensive use is made of the X.509 certificate possible; for example, extensive use is made of the X.509 certificate
profile defined by PKIX [3] and the extensions for IP Addresses and profile defined by the Public Key Infrastructure using X.509 (PKIX)
AS numbers representation defined in RFC 3779 [5]. Also CMS [4] is working group [RFC 5280] and the extensions for IP Addresses and AS
used as the syntax for the newly-defined signed objects required by numbers representation defined in RFC 3779 [RFC 3779]. Also
this infrastructure. Cryptographic Message Syntax (CMS) [RFC 5652] is used as the syntax
for the newly-defined signed objects [SIGN-OBJ] required by this
infrastructure.
As noted above, the architecture is comprised of three main As noted above, the architecture is comprised of three main
components: an X.509 PKI in which certificates attest to holdings of components: an X.509 PKI in which certificates attest to holdings of
IP address space and AS numbers; non-certificate/CRL signed objects IP address space and AS numbers; non-certificate/CRL signed objects
(including route origination authorizations and manifests) used by (including route origination authorizations and manifests) used by
the infrastructure; and a distributed repository system that makes the infrastructure; and a distributed repository system that makes
all of these signed objects available for use by ISPs in making all of these signed objects available for use by ISPs in making
routing decisions. These three basic components enable several routing decisions. These three basic components enable several
security functions; this document describes how they can be used to security functions; this document describes how they can be used to
improve route filter generation, and to perform several other common improve route filter generation, and to perform several other common
operations in such a way as to make them cryptographically operations in such a way as to make them cryptographically
verifiable. verifiable.
1.1. Terminology 1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [3], and "X.509 and Certificate Revocation List (CRL) Profile" [RFC 5280], and "X.509
Extensions for IP Addresses and AS Identifiers" [5]. Extensions for IP Addresses and AS Identifiers" [RFC3 779].
Throughout this document we use the terms "address space holder" or 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" interchangeably to refer to a legitimate
holder of IP address space who has received this address space holder of IP address space who has received this address space
through the standard IP address allocation hierarchy. That is, the through the standard IP address allocation hierarchy. That is, the
address space holder has either directly received the address space address space holder has either directly received the address space
as an allocation from a Regional Internet Registry (RIR) or IANA; or as an allocation from a Regional Internet Registry (RIR) or IANA; or
else the address space holder has received the address space as a else the address space holder has received the address space as a
sub-allocation from a National Internet Registry (NIR) or Local sub-allocation from a National Internet Registry (NIR) or Local
Internet Registry (LIR). We use the term "resource holder" to refer Internet Registry (LIR). We use the term "resource holder" to refer
to a legitimate holder of either IP address or AS number resources. to a legitimate holder of either IP address or AS number resources.
Throughout this document we use the terms "registry" and ISP to refer 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 to an entity that has an IP address space and/or AS number allocation
that it is permitted to sub-allocate its resources. We use the term that it is permitted to sub-allocate.
"subscriber" to refer to an entity (e.g., an enterprise) that
receives an IP address space and/or AS number assignment, and does
not sub-allocate its resources.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC 2119 [RFC 2119].
2. PKI for Internet Number Resources 2. PKI for Internet Number Resources
Because the holder of a block IP address space is entitled to define Because the holder of a block of IP address space is entitled to
the topological destination of IP datagrams whose destinations fall define the topological destination of IP datagrams whose destinations
within that block, decisions about inter-domain routing are fall within that block, decisions about inter-domain routing are
inherently based on knowledge of the allocation of the IP address inherently based on knowledge of the allocation of the IP address
space. Thus, a basic function of this architecture is to provide space. Thus, a basic function of this architecture is to provide
cryptographically verifiable attestations as to these allocations. In cryptographically verifiable attestations as to these allocations. In
current practice, the allocation of IP addresses is hierarchic. The current practice, the allocation of IP addresses is hierarchical. The
root of the hierarchy is IANA. Below IANA are five Regional Internet root of the hierarchy is IANA. Below IANA are five Regional Internet
Registries (RIRs), each of which manages address and AS number Registries (RIRs), each of which manages address and AS number
allocation within a defined geopolitical region. In some regions the allocation within a defined geopolitical region. In some regions the
third tier of the hierarchy includes National Internet Registries third tier of the hierarchy includes National Internet Registries
(NIRs) as well as Local Internet Registries (LIRs) and subscribers (NIRs) as well as Local Internet Registries (LIRs) and subscribers
with so-called provider-independent ("portable") allocations. (The with so-called provider-independent ("portable") allocations. (The
term LIR is used in some regions to refer to what other regions 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 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 the term LIR/ISP to simplify references to these entities.) In other
regions the third tier consists only of LIRs/ISPs and subscribers regions the third tier consists only of LIRs/ISPs and subscribers
skipping to change at page 5, line 43 skipping to change at page 5, line 43
issuance of subordinate certificates corresponds to sub-allocation of issuance of subordinate certificates corresponds to sub-allocation of
IP addresses. The above reasoning holds true for AS number resources IP addresses. The above reasoning holds true for AS number resources
as well, with the difference that, by convention, AS numbers may not 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 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 addresses and AS numbers can be expressed by the same PKI. Such a
PKI is a central component of this architecture. PKI is a central component of this architecture.
2.1. Role in the overall architecture 2.1. Role in the overall architecture
Certificates in this PKI are called Resource Certificates, and Certificates in this PKI are called Resource Certificates, and
conform to the certificate profile for such certificates [6]. conform to the certificate profile for such certificates [RES-CERT].
Resource certificates attest to the allocation by the (certificate) Resource certificates attest to the allocation by the (certificate)
issuer of IP addresses or AS numbers to the subject. They do this by 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 binding the public key contained in the Resource Certificate to the
IP addresses or AS numbers included in the certificate's IP Address IP addresses or AS numbers included in the certificate's IP Address
Delegation or AS Identifier Delegation Extensions, respectively, as Delegation or AS Identifier Delegation Extensions, respectively, as
defined in RFC 3779 [5]. defined in RFC 3779 [RFC 3779].
An important property of this PKI is that certificates do not attest An important property of this PKI is that certificates do not attest
to the identity of the subject. Therefore, the subject names used in to the identity of the subject. Therefore, the subject names used in
certificates are not intended to be "descriptive." That is, the certificates are not intended to be "descriptive." That is, the
resource PKI is intended to provide authorization, but not resource PKI is intended to provide authorization, but not
authentication. This is in contrast to most PKIs where the issuer authentication. This is in contrast to most PKIs where the issuer
ensures that the descriptive subject name in a certificate is ensures that the descriptive subject name in a certificate is
properly associated with the entity that holds the private key properly associated with the entity that holds the private key
corresponding to the public key in the certificate. Because issuers 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 need not verify the right of an entity to use a subject name in a
certificate, they avoid the costs and liabilities of such certificate, they avoid the costs and liabilities of such
verification. This makes it easier for these entities to take on the verification. This makes it easier for these entities to take on the
additional role of Certificate Authority (CA). additional role of Certificate Authority (CA).
Most of the certificates in the PKI assert the basic facts on which Most of the certificates in the PKI assert the basic facts on which
the rest of the infrastructure operates. CA certificates within the the rest of the infrastructure operates. CA certificates within the
PKI attest to IP address space and AS number holdings. End-entity PKI attest to IP address space and AS number holdings. End-entity
(EE) certificates are issued by resource holder CAs to delegate the (EE) certificates are issued by resource holder CAs to delegate the
authority attested by their allocation certificates. The primary use authority attested by their allocation certificates. The primary use
for EE certificates is the validation of Route Origination for EE certificates is the validation of Route Origination
Authorizations (ROAs). Additionally, signed objects called manifests Authorizations (ROAs), signed objects which provide an explicit
will be used to help ensure the integrity of the repository system, authorization by an address holder that a given AS is permitted to
and the signature on each manifest will be verified via an EE originate routes to a set of addresses (see Section 3). End Entity
certificate. 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).
2.2. CA Certificates 2.2. CA Certificates
Any resource holder who is authorized to sub-allocate these resources Any resource holder who is authorized to sub-allocate these resources
must be able to issue Resource Certificates to correspond to these must be able to issue Resource Certificates to correspond to these
sub-allocations. Thus, for example, CA certificates will be sub-allocations. Thus, for example, CA certificates will be
associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. A CA 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 certificate also is required to enable a resource holder to issue
ROAs, because it must issue the corresponding end-entity certificate ROAs, because it must issue the corresponding end-entity certificate
used to validate each ROA. Thus some entities that do not sub- used to validate each ROA. Thus some entities that do not sub-
skipping to change at page 7, line 41 skipping to change at page 7, line 42
subject names in these certificates will generally be different. A CA subject names in these certificates will generally be different. A CA
also may issue distinct certificates for each distinct allocation to also may issue distinct certificates for each distinct allocation to
the same entity, if the CA and the resource holder agree that such an the same entity, if the CA and the resource holder agree that such an
arrangement will facilitate management and use of the certificates. arrangement will facilitate management and use of the certificates.
For example, an LIR/ISP may have several certificates issued to it by For example, an LIR/ISP may have several certificates issued to it by
one registry, each describing a distinct set of address blocks, one registry, each describing a distinct set of address blocks,
because the LIR/ISP desires to treat the allocations as separate. because the LIR/ISP desires to treat the allocations as separate.
2.3. End-Entity (EE) Certificates 2.3. End-Entity (EE) Certificates
The private key corresponding to public key contained in an EE The private key corresponding to a public key contained in an EE
certificate is not used to sign other certificates in a PKI. The certificate is not used to sign other certificates in a PKI. The
primary function of end-entity certificates in this PKI is the primary function of end-entity certificates in this PKI is the
verification of signed objects that relate to the usage of the verification of signed objects that relate to the usage of the
resources described in the certificate, e.g., ROAs and manifests. resources described in the certificate, e.g., ROAs and manifests.
For ROAs and manifests there will be a one-to-one correspondence For ROAs and manifests there will be a one-to-one correspondence
between end-entity certificates and signed objects, i.e., the private between end-entity certificates and signed objects, i.e., the private
key corresponding to each end-entity certificate is used to sign key corresponding to each end-entity certificate is used to sign
exactly one object, and each object is signed with only one key. exactly one object, and each object is signed with only one key.
This property allows the PKI to be used to revoke these signed This property allows the PKI to be used to revoke these signed
objects, rather than creating a new revocation mechanism. When the objects, rather than creating a new revocation mechanism. When the
end-entity certificate used to sign an object has been revoked, the end-entity certificate used to sign an object has been revoked, the
signature on that object (and any corresponding assertions) will be signature on that object (and any corresponding assertions) will be
considered invalid, so a signed object can be effectively revoked by considered invalid, so a signed object can be effectively revoked by
revoking the end-entity certificate used to sign it. revoking the end-entity certificate used to sign it.
A secondary advantage to this one-to-one correspondence is that the A secondary advantage to this one-to-one correspondence is that the
private key corresponding to the public key in a certificate is used 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 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 been used to sign its one object. This fact should simplify key
management, since there is no requirement to protect these private management, since there is no requirement to protect these private
keys for an extended period of time. 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 [SIGN-OBJ]) 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 Although this document describes only two uses for end-entity
certificates, additional uses will likely be defined in the future. certificates, additional uses will likely be defined in the future.
For example, end-entity certificates could be used as a more general For example, end-entity certificates could be used as a more general
authorization for their subjects to act on behalf of the specified authorization for their subjects to act on behalf of the specified
resource holder. This could facilitate authentication of inter-ISP resource holder. This could facilitate authentication of inter-ISP
interactions, or authentication of interactions with the repository interactions, or authentication of interactions with the repository
system. These additional uses for end-entity certificates may system. These additional uses for end-entity certificates may
require retention of the corresponding private keys, even though this require retention of the corresponding private keys, even though this
is not required for the private keys associated with end-entity is not required for the private keys associated with end-entity
certificates keys used for verification of ROAs and manifests, as certificates keys used for verification of ROAs and manifests, as
skipping to change at page 9, line 13 skipping to change at page 9, line 21
of private address space. of private address space.
Note that a RP who elects to create and manage its own set of trust 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 anchors may fail to detect allocation errors that arise under such
circumstances, but the resulting vulnerability is local to the RP. circumstances, but the resulting vulnerability is local to the RP.
It is expected that some parties within the extant IP address space It is expected that some parties within the extant IP address space
and AS number allocation hierarchy may wish to publish trust anchor and AS number allocation hierarchy may wish to publish trust anchor
material for possible use by relying parties. A standard profile for material for possible use by relying parties. A standard profile for
the publication of trust anchor material for this public key the publication of trust anchor material for this public key
infrastructure can be found in [9]. infrastructure can be found in [SIDR-TA].
3. Route Origination Authorizations 3. Route Origination Authorizations
The information on IP address allocation provided by the PKI is not, The information on IP address allocation provided by the PKI is not,
in itself, sufficient to guide routing decisions. In particular, BGP in itself, sufficient to guide routing decisions. In particular, BGP
is based on the assumption that the AS that originates routes for a 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 particular prefix is authorized to do so by the holder of that prefix
(or an address block encompassing the prefix); the PKI contains no (or an address block encompassing the prefix); the PKI contains no
information about these authorizations. A Route Origination information about these authorizations. A Route Origination
Authorization (ROA) makes such authorization explicit, allowing a Authorization (ROA) makes such authorization explicit, allowing a
holder of IP address space to create an object that explicitly and holder of IP address space to create an object that explicitly and
verifiably asserts that an AS is authorized originate routes to a verifiably asserts that an AS is authorized originate routes to a
given set of prefixes. given set of prefixes.
3.1. Role in the overall architecture 3.1. Role in the overall architecture
A ROA is an attestation that the holder of a set of prefixes has A ROA is an attestation that the holder of a set of prefixes has
authorized an autonomous system to originate routes for those authorized an autonomous system to originate routes for those
prefixes. A ROA is structured according to the format described in prefixes. A ROA is structured according to the format described in
[7]. The validity of this authorization depends on the signer of the [ROA-FORM]. The validity of this authorization depends on the signer
ROA being the holder of the prefix(es) in the ROA; this fact is of the ROA being the holder of the prefix(es) in the ROA; this fact
asserted by an end-entity certificate from the PKI, whose is asserted by an end-entity certificate from the PKI, whose
corresponding private key is used to sign the ROA. corresponding private key is used to sign the ROA.
ROAs may be used by relying parties to verify that the AS that 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 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 holder of that prefix to originate such a route. For example, an ISP
might use validated ROAs as inputs to route filter construction for might use validated ROAs as inputs to route filter construction for
use by its BGP routers. (See [15] for information on the use of ROAs use by its BGP routers. (See [ROA-VALID] for information on the use
to validate the origination of BGP routes.) of ROAs to validate the origination of BGP routes.)
Initially, the repository system will be the primary mechanism for Initially, the repository system will be the primary mechanism for
disseminating ROAs, since these repositories will hold the disseminating ROAs, since these repositories will hold the
certificates and CRLs needed to verify ROAs. In addition, ROAs also certificates and CRLs needed to verify ROAs. In addition, ROAs also
could be distributed in BGP UPDATE messages or via other could be distributed in BGP UPDATE messages or via other
communication paths, if needed to meet timeliness requirements. communication paths, if needed to meet timeliness requirements.
3.2. Syntax and semantics 3.2. Syntax and semantics
A ROA constitutes an explicit authorization for a single AS to A ROA constitutes an explicit authorization for a single AS to
originate routes to one or more prefixes, and is signed by the holder 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 of those prefixes. Conceptually, the ROA syntax consists of two
found in [7] but, at a high level, a ROA consists of (1) an AS parts, a general CMS template common to all RPKI signed objects
number; (2) a list of IP address prefixes; and, optionally, (3) for [SIGN-OBJ] and an encapsulated content specific to the ROA which
each prefix, the maximum length of more specific (longer) prefixes expresses the authorization [ROA-FORM].
that the AS is also authorized to advertise. (This last element
facilitates a compact authorization to advertise, for example, any At a high level, the ROA's content contains (1) an AS number; (2) a
prefixes of length 20 to 24 contained within a given length 20 list of IP address prefixes; and, optionally, (3) for each prefix,
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 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 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 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 multiple ROAs to authorize the ISP to originate routes from any of
these ASes. these ASes.
A ROA is signed using the private key corresponding to the public key 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 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 valid, its corresponding end-entity (EE) certificate must be valid
and the IP address prefixes of the ROA must exactly match the IP and the IP address prefixes of the ROA must exactly match the IP
address prefix(es) specified in the EE certificate's RFC 3779 address prefix(es) specified in the EE certificate's RFC 3779
extension. Therefore, the validity interval of the ROA is implicitly extension. Therefore, the validity interval of the ROA is implicitly
the validity interval of its corresponding certificate. A ROA is the validity interval of its corresponding certificate. A ROA is
revoked by revoking the corresponding EE certificate. There is no revoked by revoking the corresponding EE certificate. There is no
independent method of invoking a ROA. One might worry that this independent method of revoking a ROA. One might worry that this
revocation model could lead to long CRLs for the CA certification revocation model could lead to long CRLs for the CA certification
that is signing the EE certificates. However, routing announcements that is signing the EE certificates. However, routing announcements
on the public internet are generally quite long lived. Therefore, as 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 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 interval of several months, the likelihood that many ROAs would need
to revoked within that time is quite low. to revoked within that time is quite low.
--------- --------- --------- ---------
| RIR | | NIR | | RIR | | NIR |
| CA | | CA | | CA | | CA |
skipping to change at page 11, line 31 skipping to change at page 11, line 31
| EE 1a | | EE 1b | | EE 2 | | EE 1a | | EE 1b | | EE 2 |
---------- ---------- ---------- ---------- ---------- ----------
| | | | | |
| | | | | |
| | | | | |
---------- ---------- ---------- ---------- ---------- ----------
| ROA 1a | | ROA 1b | | ROA 2 | | ROA 1a | | ROA 1b | | ROA 2 |
---------- ---------- ---------- ---------- ---------- ----------
FIGURE 2: This figure illustrates an ISP with allocations from two 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 sources (an RIR and an NIR). It needs two CA certificates due to RFC
3779 rules. 3779 rules.
Because each ROA is associated with a single end-entity certificate, 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 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 allocation by a single source, i.e., a ROA cannot combine allocations
from multiple sources. Address space holders who have allocations from multiple sources. Address space holders who have allocations
from multiple sources, and who wish to authorize an AS to originate from multiple sources, and who wish to authorize an AS to originate
routes for these allocations, must issue multiple ROAs to the AS. routes for these allocations, must issue multiple ROAs to the AS.
4. Repositories 4. Repositories
skipping to change at page 12, line 38 skipping to change at page 12, line 38
certificates and CRLs are created, they are uploaded to this certificates and CRLs are created, they are uploaded to this
repository, and then downloaded for use by relying parties (primarily repository, and then downloaded for use by relying parties (primarily
LIRs/ISPs). ROAs and manifests are additional examples of such LIRs/ISPs). ROAs and manifests are additional examples of such
objects, but other types of signed objects may be added to this objects, but other types of signed objects may be added to this
architecture in the future. This document briefly describes the way architecture in the future. This document briefly describes the way
signed objects (certificates, CRLs, ROAs and manifests) are managed signed objects (certificates, CRLs, ROAs and manifests) are managed
in the repository system. As other types of signed objects are added in the repository system. As other types of signed objects are added
to the repository system it will be necessary to modify the to the repository system it will be necessary to modify the
description, but it is anticipated that most of the design principles description, but it is anticipated that most of the design principles
will still apply. The repository system is described in detail in will still apply. The repository system is described in detail in
[11]. [REPOS].
4.2. Contents and structure 4.2. Contents and structure
Although there is a single repository system that is accessed by Although there is a single repository system that is accessed by
relying parties, it is comprised of multiple databases. These relying parties, it is comprised of multiple databases. These
databases will be distributed among registries (RIRs, NIRs, databases will be distributed among registries (RIRs, NIRs,
LIRs/ISPs). At a minimum, the database operated by each registry will LIRs/ISPs). At a minimum, the database operated by each registry will
contain all CA and EE certificates, CRLs, and manifests signed by the contain all CA and EE certificates, CRLs, and manifests signed by the
CA(s) associated with that registry. Repositories operated by CA(s) associated with that registry. Repositories operated by
LIRs/ISPs also will contain ROAs. Registries are encouraged to LIRs/ISPs also will contain ROAs. Registries are encouraged to
skipping to change at page 13, line 20 skipping to change at page 13, line 20
manifests) verifiable via this certificate. A certificate's Subject manifests) verifiable via this certificate. A certificate's Subject
Information Authority (SIA) extension provides a URI that references Information Authority (SIA) extension provides a URI that references
this directory. Additionally, a certificate's Authority Information this directory. Additionally, a certificate's Authority Information
Authority (AIA) extension contains a URI that references the Authority (AIA) extension contains a URI that references the
authoritative location for the CA certificate under which the given authoritative location for the CA certificate under which the given
certificate was issued. That is, if certificate A is used to verify certificate was issued. That is, if certificate A is used to verify
certificate B, then the AIA extension of certificate B points to certificate B, then the AIA extension of certificate B points to
certificate A, and the SIA extension of certificate A points to a certificate A, and the SIA extension of certificate A points to a
directory containing certificate B (see Figure 2). directory containing certificate B (see Figure 2).
+--------+ +--------+
+--------->| Cert A |<----+ +--------->| Cert A |<----+
| | CRLDP | | +---------+ | | CRLDP | |
| | AIA | | +-->| A's CRL |<-+ | | AIA | |
| +--------- SIA | | | +---------+ | | +--------- SIA | |
| | +--------+ | | | | | +--------+ |
| | | | | | | |
| | +---+----+ | | | |
| | | | | | | |
| | +---------------|---|-----------------+ | | | +-------------------|------------------+
| | | | | | | | | | | |
| +->| +--------+ | | +--------+ | | | +->| +--------+ | +--------+ |
| | | Cert B | | | | Cert C | | | | | | Cert B | | | Cert C | |
| | | CRLDP ----+ | | CRLDP -+--------+ | | | CRLDP ----+ | | CRLDP -+-+ |
+----------- AIA | +----- AIA | | +----------- AIA | | +----- AIA | | |
| | SIA | | SIA | | | | SIA | | | SIA | | |
| +--------+ +--------+ | | +--------+ | +--------+ | |
| | | V | |
+-------------------------------------+ | +---------+ | |
| | A's CRL |<-----------+ |
| +---------+ |
| A's Repository Publication Directory |
+--------------------------------------+
FIGURE 3: In this example, certificates B and C are issued under FIGURE 3: In this example, certificates B and C are issued by
certificate A. Therefore, the AIA extensions of certificates B and C certification authority A. Therefore, the AIA extensions of
point to A, and the SIA extension of certificate A points to the certificates B and C point to the publication point where Certificate
directory containing certificates B and C. A is published, and the SIA extension of certificate A points to the
repository publication point where the objects issued under authority
A, including certificates B and C and A's CRL, are published.
If a CA certificate is reissued with the same public key, it should If a CA certificate is reissued with the same public key, it should
not be necessary to reissue (with an updated AIA URI) all not be necessary to reissue (with an updated AIA URI) all
certificates signed by the certificate being reissued. Therefore, a certificates signed by the certificate being reissued. Therefore, a
certification authority SHOULD use a persistent URI naming scheme for certification authority SHOULD use a persistent URI naming scheme for
issued certificates. That is, reissued certificates should use the issued certificates. That is, reissued certificates should use the
same publication point as previously issued certificates having the same publication point as previously issued certificates having the
same subject and public key, and should overwrite such certificates. same subject and public key, and should overwrite such certificates.
4.3. Access protocols 4.3. Access protocols
skipping to change at page 14, line 36 skipping to change at page 14, line 42
Upload/change/delete: Access protocols MUST also support mechanisms Upload/change/delete: Access protocols MUST also support mechanisms
for the issuers of certificates, CRLs, and other signed objects to for the issuers of certificates, CRLs, and other signed objects to
add them to the repository, and to remove them. Mechanisms for add them to the repository, and to remove them. Mechanisms for
modifying objects in the repository MAY also be provided. All access modifying objects in the repository MAY also be provided. All access
protocols that allow modification to the repository (through protocols that allow modification to the repository (through
addition, deletion, or modification of its contents) MUST support addition, deletion, or modification of its contents) MUST support
verification of the authorization of the entity performing the verification of the authorization of the entity performing the
modification, so that appropriate access controls can be applied (see modification, so that appropriate access controls can be applied (see
Section 4.4). Section 4.4).
Current efforts to implement a repository system use RSYNC [14] as To ensure all relying parties are able to acquire all RPKI signed
the single access protocol. RSYNC, as used in this implementation, objects, all publication points MUST be accessible via RSYNC (see
provides all of the above functionality. A document specifying the [RFC 5871] and [RSYNC]), although other download protocols also be
conventions for use of RSYNC in the PKI will be prepared. 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.
4.4. Access control 4.4. Access control
In order to maintain the integrity of information in the repository, In order to maintain the integrity of information in the repository,
controls must be put in place to prevent addition, deletion, or controls must be put in place to prevent addition, deletion, or
modification of objects in the repository by unauthorized parties. modification of objects in the repository by unauthorized parties.
The identities of parties attempting to make such changes can be The identities of parties attempting to make such changes can be
authenticated through the relevant access protocols. Although authenticated through the relevant access protocols. Although
specific access control policies are subject to the local control of specific access control policies are subject to the local control of
repository operators, it is recommended that repositories allow only repository operators, it is RECOMMENDED that repositories allow only
the issuers of signed objects to add, delete, or modify them. the issuers of signed objects to add, delete, or modify them.
Alternatively, it may be advantageous in the future to define a Alternatively, it may be advantageous in the future to define a
formal delegation mechanism to allow resource holders to authorize formal delegation mechanism to allow resource holders to authorize
other parties to act on their behalf, as suggested in Section 2.3 other parties to act on their behalf, as suggested in Section 2.3
above. above.
5. Manifests 5. Manifests
A manifest is a signed object listing of all of the signed objects A manifest is a signed object listing of all of the signed objects
issued by an authority responsible for a publication in the issued by an authority responsible for a publication in the
repository system. For each certificate, CRL, or ROA issued by the repository system. For each unexpired certificate, CRL, or ROA issued
authority, the manifest contains both the name of the file containing by the authority, the manifest contains both the name of the file
the object, and a hash of the file content. containing the object, and a hash of the file content.
As with ROAs, a manifest is signed by a private key, for which the As with ROAs, a manifest is signed by a private key, for which the
corresponding public key appears in an end-entity certificate. This corresponding public key appears in an end-entity certificate. This
EE certificate, in turn, is signed by the CA in question. The EE EE certificate, in turn, is signed by the CA in question. Since the
certificate private key may be used to issue one for more manifests. private key in an EE certificate is used to sign only a single
If the private key is used to sign only a single manifest, then the manifest, then the manifest can be revoked by revoking the EE
manifest can be revoked by revoking the EE certificate. In such a certificate. In such a case, to avoid needless CRL growth, the EE
case, to avoid needless CRL growth, the EE certificate used to certificate used to validate a manifest SHOULD expire at the same
validate a manifest SHOULD expire at the same time that the manifest time that the manifest expires.
expires. If an EE certificate is used to issue multiple (sequential)
manifests for the CA in question, then there is no revocation
mechanism for these individual manifests.
Manifests may be used by relying parties when constructing a local Manifests may be used by relying parties when constructing a local
cache (see Section 6) to mitigate the risk of an attacker who deletes cache (see Section 6) to mitigate the risk of an attacker who deletes
files from a repository or replaces current signed objects with stale files from a repository or replaces current signed objects with stale
versions of the same object. Such protection is needed because versions of the same object. Such protection is needed because
although all objects in the repository system are signed, the although all objects in the repository system are signed, the
repository system itself is untrusted. repository system itself is untrusted.
5.1. Syntax and semantics 5.1. Syntax and semantics
A manifest constitutes a list of (the hashes of) all the files in a A manifest constitutes a list of (the hashes of) all the files in a
repository point at a particular point in time. A detailed repository point at a particular point in time. A detailed
specification of manifest syntax is provided in [8] but, at a high specification of the manifest's content is provided in [MANIFEST]
level, a manifest consists of (1) a manifest number; (2) the time the but, at a high level, a manifest consists of (1) a manifest number;
manifest was issued; (3) the time of the next planned update; and (4) (2) the time the manifest was issued; (3) the time of the next
a list of filename and hash value pairs. planned update; and (4) a list of filename and hash value pairs.
The manifest number is a sequence number that is incremented each The manifest number is a sequence number that is incremented each
time a manifest is issued by the authority. An authority is required 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 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. 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 A manifest is thus valid until the specified time of the next update
or until a manifest is issued with a greater manifest number, or until a manifest is issued with a greater manifest number,
whichever comes first. (Note that when an EE certificate is used to whichever comes first. (Note that when an EE certificate is used to
sign only a single manifest, whenever the authority issues the new sign only a single manifest, whenever the authority issues the new
manifest, the CA MUST also issue a new CRL which includes the EE manifest, the CA MUST also issue a new CRL which includes the EE
skipping to change at page 16, line 36 skipping to change at page 16, line 43
3. For each manifest, verify that certificates and CRLs issued 3. For each manifest, verify that certificates and CRLs issued
under the corresponding CA certificate match the hash values under the corresponding CA certificate match the hash values
contained in the manifest. Additionally, verify that no contained in the manifest. Additionally, verify that no
certificate or manifest listed on the manifest is missing from certificate or manifest listed on the manifest is missing from
the repository. If the hash values do not match, or if any the repository. If the hash values do not match, or if any
certificate or CRL is missing, notify the appropriate repository certificate or CRL is missing, notify the appropriate repository
administrator that the repository data has been corrupted. administrator that the repository data has been corrupted.
4. Validate each EE certificate by constructing and verifying a 4. Validate each EE certificate by constructing and verifying a
certification path for the certificate (including checking certification path for the certificate (including checking
relevant CRLs) to the locally configured set of TAs. (See [6] relevant CRLs) to the locally configured set of TAs. (See [RES-
for more details.) CERT] for more details.)
Note that since relying parties will perform these operations Note that since relying parties will perform these operations
regularly, it is more efficient for the relying party to request from regularly, it is more efficient for the relying party to request from
the repository system only those objects that have changed since the the repository system only those objects that have changed since the
relying party last updated its local cache. A relying party may relying party last updated its local cache. A relying party may
choose any frequency it desires for downloading and validating choose any frequency it desires for downloading and validating
updates from the repository. However, any relying party that uses updates from the repository. However, any relying party that uses
RPKI data as an input to operational routing decisions (e.g., ISPs, RPKI data as an input to operational routing decisions (e.g., ISPs,
RIRs, NIRs) SHOULD download and validate updates at least once every RIRs, NIRs) SHOULD download and validate updates at least once every
three hours. three hours.
skipping to change at page 18, line 5 skipping to change at page 18, line 9
to the subject. This differs from most PKIs in which a subject can to the subject. This differs from most PKIs in which a subject can
request a certificate from any certification authority. request a certificate from any certification authority.
If a resource holder receives multiple allocations over time, it may If a resource holder receives multiple allocations over time, it may
accrue a collection of resource certificates to attest to them. If a accrue a collection of resource certificates to attest to them. If a
resource holder receives multiple allocations from the same source, resource holder receives multiple allocations from the same source,
the set of resource certificates may be combined into a single the set of resource certificates may be combined into a single
resource certificate, if both the issuer and the resource holder resource certificate, if both the issuer and the resource holder
agree. This is accomplished by consolidating the IP Address agree. This is accomplished by consolidating the IP Address
Delegation and AS Identifier Delegation Extensions into a single Delegation and AS Identifier Delegation Extensions into a single
extension (of each type) in a new certificate. However, if the extension (of each type) in a new certificate. However, if these
certificates for these allocations contain different validity certificates attest to allocations which are valid for different
intervals, creating a certificate that combines them might create periods of time, creating a certificate that combines them might
problems, and thus is NOT RECOMMENDED. create problems as the combined certificate can only express a single
validity interval.
If a resource holder's allocations come from different sources, they If a resource holder's allocations come from different sources, they
will be signed by different CAs, and cannot be combined. When a set will be signed by different CAs, and cannot be combined. When a set
of resources is no longer allocated to a resource holder, any of resources is no longer allocated to a resource holder, any
certificates attesting to such an allocation MUST be revoked. A certificates attesting to such an allocation MUST be revoked. A
resource holder SHOULD NOT use the same public key in multiple CA resource holder SHOULD NOT use the same public key in multiple CA
certificates that are issued by the same or differing authorities, as certificates that are issued by the same or differing authorities, as
reuse of a key pair complicates path construction. Note that since reuse of a key pair complicates path construction. Note that since
the subject's distinguished name is chosen by the issuer, a subject the subject's distinguished name is chosen by the issuer, a subject
who receives allocations from two sources generally will receive who receives allocations from two sources generally will receive
certificates with different subject names. certificates with different subject names.
7.2. ROA management 7.2. CA Key Rollover
Whenever a certification authority wishes to change the public key
(and corresponding private key) associated with its RPKI CA
certificate, it must perform a key rollover procedure. Key rollover
is typically performed on a periodic basis, where the frequency of
key rollovers is specified in the certification practice statement of
the given CA. Additionally, unscheduled rollovers may be required in
the event of suspected key compromises.
Note that rollover is only required when the CA's key actually
changes, it is not required in cases where a new CA certificate is
issued with the same key as the previous certificate for this CA. For
example, a new CA certificate must be issued if the CA gains or
relinquishes resource, or if the validity period of the resource
allocation is extended. However, in such a cases the new certificate
will generally use the same public (and private) key as the previous
certificate and thus key rollover is not required.
The document [KEY-ROLL] 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
design 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 re-issuance is required.
7.3. ROA management
Whenever a holder of IP address space wants to authorize an AS to Whenever a holder of IP address space wants to authorize an AS to
originate routes for a prefix within his holdings, he MUST issue an originate routes for a prefix within his holdings, he MUST issue an
end-entity certificate containing that prefix in an IP Address end-entity certificate containing that prefix in an IP Address
Delegation extension. He then uses the corresponding private key to Delegation extension. He then uses the corresponding private key to
sign a ROA containing the designated prefix and the AS number for the sign a ROA containing the designated prefix and the AS number for the
AS. The resource holder MAY include more than one prefix in the EE AS. The resource holder MAY include more than one prefix in the EE
certificate and corresponding ROA if desired. As a prerequisite, certificate and corresponding ROA if desired. As a prerequisite,
then, any address space holder that issues ROAs for a prefix must then, any address space holder that issues ROAs for a prefix must
have a resource certificate for an allocation containing that prefix. have a resource certificate for an allocation containing that prefix.
The standard procedure for issuing a ROA is as follows: The standard procedure for issuing a ROA is as follows:
1. Create an end-entity certificate containing the prefix(es) to be 1. Create an end-entity certificate containing the prefix(es) to be
authorized in the ROA. authorized in the ROA.
2. Construct the payload of the ROA, including the prefixes in the 2. Construct the payload of the ROA, including the prefixes in the
end-entity certificate and the AS number to be authorized. end-entity certificate and the AS number to be authorized.
3. Sign the ROA using the private key corresponding to the end- 3. Sign the ROA using the private key corresponding to the end-
entity certificate (the ROA is comprised of the payload entity certificate (the ROA is comprised of the payload
encapsulated in a CMS signed message [7]). encapsulated in a CMS signed message [RFC 5652]).
4. Upload the end-entity certificate and the ROA to the repository 4. Upload the end-entity certificate and the ROA to the repository
system. system.
The standard procedure for revoking a ROA is to revoke the The standard procedure for revoking a ROA is to revoke the
corresponding end-entity certificate by creating an appropriate CRL corresponding end-entity certificate by creating an appropriate CRL
and uploading it to the repository system. The revoked ROA and end- and uploading it to the repository system. The revoked ROA and end-
entity certificate SHOULD BE removed from the repository system. entity certificate SHOULD be removed from the repository system.
Care must be taken when revoking ROAs in that revoking a ROA may Care must be taken when revoking ROAs in that revoking a ROA may
cause a relying party to treat routing advertisements corresponding cause a relying party to treat routing advertisements corresponding
to the prefixes and origin AS number in the ROA as unauthorized (and to the prefixes and origin AS number in the ROA as unauthorized (and
potentially even change routing behavior to no longer forward packets potentially even change routing behavior to no longer forward packets
based on those advertisements). In particular, resource holders based on those advertisements). In particular, resource holders
should adhere to the principle of "make before break" as follows. should adhere to the principle of "make before break" as follows.
Before revoking a ROA corresponding to a prefix which the resource Before revoking a ROA corresponding to a prefix which the resource
holder wishes to be routable on the Internet, it is very important holder wishes to be routable on the Internet, it is very important
for the resource holder to ensure that there exists another valid for the resource holder to ensure that there exists another valid
alternative ROA that lists the same prefix (possibly indicating a alternative ROA that lists the same prefix (possibly indicating a
different AS number). Additionally, the resource holder should ensure different AS number). Additionally, the resource holder should ensure
that the AS indicated in the valid alternative ROA is actually that the AS indicated in the valid alternative ROA is actually
originating routing advertisements to the prefixes in question. originating routing advertisements to the prefixes in question.
Furthermore, a relying party must fetch new ROAs from the repository Furthermore, a relying party must fetch new ROAs from the repository
system before taking any routing action in response to a ROA system before taking any routing action in response to a ROA
revocation. revocation.
7.2.1. Single-homed subscribers (with PA address space) 7.3.1. Single-homed subscribers (with PA address space)
In BGP, a single-homed subscriber with provider aggregatable (non- In BGP, a single-homed subscriber with Provider Aggregatable (PA)
portable) address space does not need to explicitly authorize routes address space does not need to explicitly authorize routes to be
to be originated for the prefix(es) it is using, since its ISP will originated for the prefix(es) it is using, since its ISP will already
already advertise a more general prefix and route traffic for the advertise a more general prefix and route traffic for the
subscriber's prefix as an internal function. Since no routes are subscriber's prefix as an internal function. Since no routes are
originated specifically for prefixes held by these subscribers, no originated specifically for prefixes held by these subscribers, no
ROAs need to be issued under their allocations; rather, the ROAs need to be issued under their allocations; rather, the
subscriber's ISP will issue any necessary ROAs for its more general subscriber's ISP will issue any necessary ROAs for its more general
prefixes under resource certificates from its own allocation. Thus, a prefixes under resource certificates from its own allocation. Thus, a
single-homed subscriber with an IP address allocation from his single-homed subscriber with an IP address allocation from his
service provider is not included in the RPKI, i.e., it does not service provider is not included in the RPKI, i.e., it does not
receive a CA certificate, nor issue EE certificates or ROAs. receive a CA certificate, nor issue EE certificates or ROAs.
7.2.2. Multi-homed subscribers (with PA address space) 7.3.2. Multi-homed subscribers (with PA address space)
Here we consider a subscriber who receives provider aggregatable IP Here we consider a subscriber who receives Provider Aggregatable (PA)
address space from a primary ISP (i.e., the IP addresses used by the IP address space from a primary ISP (i.e., the IP addresses used by
subscriber are a subset of ISP A's IP address space allocation) and the subscriber are a subset of ISP A's IP address space allocation)
receives redundant upstream connectivity from one or more secondary and receives redundant upstream connectivity from one or more
ISPs, in addition to the primary ISP. The preferred option for such a secondary ISPs, in addition to the primary ISP. The preferred option
multi-homed subscriber is for the subscriber to obtain an AS number for such a multi-homed subscriber is for the subscriber to obtain an
(from an RIR or NIR) and run BGP with each of its upstream providers. AS number (from an RIR or NIR) and run BGP with each of its upstream
In such a case, there are two ways for ROA management to be handled. providers. In such a case, there are two ways for ROA management to
The first is that the primary ISP issues a CA certificate to the be handled. The first is that the primary ISP issues a CA certificate
subscriber, and the subscriber issues a ROA to containing the to the subscriber, and the subscriber issues a ROA to containing the
subscriber's AS number and the subscriber's IP address prefixes. The subscriber's AS number and the subscriber's IP address prefixes. The
second possibility is that the primary ISP does not issue a CA second possibility is that the primary ISP does not issue a CA
certificate to the subscriber, and instead issues a ROA on the 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 behalf that contains the subscriber's AS number and the
subscriber's IP address prefixes. subscriber's IP address prefixes.
If the subscriber is unable or unwilling to obtain an AS number and 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 run BGP, the other option is that the multi-homed subscriber can
request that the primary ISP create a ROA for each secondary ISP that request that the primary ISP create a ROA for each secondary ISP that
authorizes the secondary ISP to originate routes to the subscriber's authorizes the secondary ISP to originate routes to the subscriber's
prefixes. The primary ISP will also create a ROA containing its own prefixes. The primary ISP will also create a ROA containing its own
AS number and the subscriber's prefixes, as it is likely in such a AS number and the subscriber's prefixes, as it is likely in such a
case that the primary ISP wishes to advertise precisely the case that the primary ISP wishes to advertise precisely the
subscriber's prefixes and not an encompassing aggregate. Note that subscriber's prefixes and not an encompassing aggregate. Note that
this approach results in inconsistent origin AS numbers for the this approach results in inconsistent origin AS numbers for the
subscriber's prefixes which are considered undesirable on the public subscriber's prefixes which are considered undesirable on the public
Internet; thus this approach is NOT RECOMMENDED. Internet; thus this approach is NOT RECOMMENDED.
7.2.3. Provider-Independent Address Space 7.3.3. Provider-Independent Address Space
A resource holder is said to have provider-independent (portable) A resource holder is said to have provider-independent (portable)
address space if the resource holder received its allocation directly address space if the resource holder received its allocation directly
from a RIR or NIR. Because the prefixes represented in such from a RIR or NIR. Because the prefixes represented in such
allocations are not taken from an allocation held by an ISP, there is allocations are not taken from an allocation held by an ISP, there is
no ISP that holds and advertises a more general prefix. A holder of a no ISP that holds and advertises a more general prefix. A holder of a
portable IP address space allocation MUST authorize one or more ASes portable IP address space allocation MUST authorize one or more ASes
to originate routes to these prefixes. Thus the resource holder MUST to originate routes to these prefixes. Thus the resource holder MUST
generate one or more EE certificates and associated ROAs to enable generate one or more EE certificates and associated ROAs to enable
the AS(es) to originate routes for the prefix(es) in question. This the AS(es) to originate routes for the prefix(es) in question. This
skipping to change at page 21, line 9 skipping to change at page 22, line 4
structured as a distributed database, it should be inherently structured as a distributed database, it should be inherently
resistant to denial of service attacks; nonetheless, appropriate resistant to denial of service attacks; nonetheless, appropriate
precautions should also be taken, both through replication and backup precautions should also be taken, both through replication and backup
of the constituent databases and through the physical security of of the constituent databases and through the physical security of
database servers. database servers.
9. IANA Considerations 9. IANA Considerations
This document requests that the IANA issue RPKI Certificates for the This document requests that the IANA issue RPKI Certificates for the
resources for which it is authoritative, i.e., reserved IPv4 resources for which it is authoritative, i.e., reserved IPv4
addresses, IPv6 ULAs, and address space not yet allocated by IANA to addresses, IPv6 Unique Local Addresses (ULAs), and address space not
the RIRs. IANA SHOULD make available trust anchor material in the yet allocated by IANA to the RIRs. IANA SHOULD make available trust
format defined in [9] in support of these functions. anchor material in the format defined in [SIDR-TA] in support of
these functions.
10. Acknowledgments 10. Acknowledgments
The architecture described in this draft is derived from the The architecture described in this draft is derived from the
collective ideas and work of a large group of individuals. This work collective ideas and work of a large group of individuals. This work
would not have been possible without the intellectual contributions would not have been possible without the intellectual contributions
of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of
APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim
Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy
Bush of IIJ. Bush of IIJ.
skipping to change at page 22, line 9 skipping to change at page 23, line 9
architecture, we would like to especially thank Rob Austein for the architecture, we would like to especially thank Rob Austein for the
concept of a manifest, Geoff Huston for the concept of managing concept of a manifest, Geoff Huston for the concept of managing
object validity through single-use EE certificate key pairs, and object validity through single-use EE certificate key pairs, and
Richard Barnes for help in preparing an early version of this Richard Barnes for help in preparing an early version of this
document. document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 [RFC 4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
(BGP-4)", RFC 4271, January 2006 Protocol 4 (BGP-4)", RFC 4271, January 2006
[3] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, [RFC 5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
R., and W. Polk, "Internet X.509 Public Key Infrastructure Housley, R., and W. Polk, "Internet X.509 Public Key
Certificate and Certificate Revocation List (CRL) Profile", RFC Infrastructure Certificate and Certificate Revocation
5280, May 2008. List (CRL) Profile", RFC 5280, May 2008.
[4] Housley, R., "Cryptographic Message Syntax", RFC 3852, July [RFC 5652] Housley, R., "Cryptographic Message Syntax", RFC 5652,
2004. September 2009.
[5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC 3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for [RES-CERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile
X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs- for X.509 PKIX Resource Certificates", draft-ietf-sidr-
17, September 2009. res-certs, May 2010.
[7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route [ROA-FORM] Lepinski, M., Kent, S., and Kong, D., "A Profile for
Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-06, Route Origin Authorizations (ROA)", draft-ietf-sidr-roa-
October 2009. format, September 2010.
[8] Austein, R., et al., "Manifests for the Resource Public Key [SIGN-OBJ] Chi, A., Kent, S., and Lepinski, M., "Signed Object
Infrastructure", draft-ietf-sidr-rpki-manifests-05, August Template for the Resource Public Key Infrastructure",
2009. draft-ietf-sidr-rpki-signed-object, September 2010.
[9] Michaelson, G., Kent, S., and Huston, G., "A Profile for Trust [MANIFEST] Austein, R., et al., "Manifests for the Resource Public
Anchor Material for the Resource Certificate PKI", draft-ietf- Key Infrastructure", draft-ietf-sidr-rpki-manifests, May
sidr-ta-02, September 2009. 2010.
[10] Huston, G., "A Profile for Algorithms and Key Sizes for use in [SIDR-ALG] Huston, G., "A Profile for Algorithms and Key Sizes for
the Resource Public Key Infrastructure", draft-ietf-sidr-rpki- use in the Resource Public Key Infrastructure", draft-
algs-00, August 2009. ietf-sidr-rpki-algs, May 2010.
[REPOS] Huston, G., Michaelson, G., and Loomans, R., "A Profile
for Resource Certificate Repository Structure", draft-
ietf-sidr-repos-struct, May 2010.
11.2. Informative References 11.2. Informative References
[11] Huston, G., Michaelson, G., and Loomans, R., "A Profile for [KEY-ROLL] Huston, G., Michaelson, G., and Kent, K., "CA Key
Resource Certificate Repository Structure", draft-ietf-sidr- Rollover in the RPKI", draft-huston-sidr-keyroll, July
repos-struct-03, August 2009. 2010.
[12] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway [ROA-VALID] Huston, G., Michaelson, G., "Validation of Route
Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Origination in BGP using the Resource Certificate PKI",
Communications Vol. 18, No. 4, April 2000. draft-ietf-sidr-roa-validation, May 2010.
[13] White, R., "soBGP", May 2005, <ftp://ftp- [PROVISION] Huston, G., Michaelson, G., Ellacott, B., and Austein,
eng.cisco.com/sobgp/index.html> R., "A Protocol for Provisioning Resource Certificates",
draft-ietf-sidr-rescert-provisioning, May 2010.
[14] Tridgell, A., "rsync", April 2006, [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI
<http://samba.anu.edu.au/rsync/> Scheme", RFC 5781, February 2010.
[15] Huston, G., Michaelson, G., "Validation of Route Origination in [SIDR-TA] Michaelson, G., Kent, S., and Huston, G., "A Profile for
BGP using the Resource Certificate PKI", draft-ietf-sidr-roa- Trust Anchor Material for the Resource Certificate PKI",
validation-03, August 2009. draft-ietf-sidr-ta, May 2010.
[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>
[RSYNC] Tridgell, A., "rsync", March 2008, <
http://rsync.samba.org/>
Authors' Addresses Authors' Addresses
Matt Lepinski Matt Lepinski
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
Email: mlepinski@bbn.com Email: mlepinski@bbn.com
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
Email: kent@bbn.com Email: kent@bbn.com
Pre-5378 Material Disclaimer
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
 End of changes. 64 change blocks. 
200 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/