< draft-ietf-sidr-arch-00.txt   draft-ietf-sidr-arch-01.txt >
Secure Inter-Domain Routing R. Barnes Secure Inter-Domain Routing M. Lepinski
Working Group S. Kent Working Group S. Kent
Internet Draft BBN Technologies Internet Draft R. Barnes
Intended status: Informational February 23, 2007 Intended status: Informational BBN Technologies
Expires: August 2007 Expires: January 2008 July 8, 2007
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-00.txt draft-ietf-sidr-arch-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 August 23, 2007. This Internet-Draft will expire on January 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
support secure Internet routing. The foundation of this architecture support secure Internet routing. The foundation of this architecture
is a public key infrastructure (PKI) that represents the allocation is a public key infrastructure (PKI) that represents the allocation
skipping to change at page 2, line 26 skipping to change at page 2, line 26
server respectively. server respectively.
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 [1].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. PKI for Internet Number Resources..............................4 2. PKI for Internet Number Resources..............................4
2.1. Role in the overall architecture..........................4 2.1. Role in the overall architecture..........................5
2.2. CA Certificates...........................................5 2.2. CA Certificates...........................................5
2.3. End-Entity Certificates...................................5 2.3. End-Entity (EE) Certificates..............................7
2.4. Trust Anchors.............................................6 2.4. Trust Anchors.............................................7
3. Route Origination Authorizations...............................6 2.5. Default Trust Anchor Considerations.......................8
3.1. Role in the overall architecture..........................7 2.6. Representing Early-Registration Transfers (ERX)...........9
3.2. Syntax and semantics......................................7 3. Route Origination Authorizations..............................10
3.3. Revocation................................................8 3.1. Role in the overall architecture.........................10
4. Repository system..............................................8 3.2. Syntax and semantics.....................................11
4.1. Role in the overall architecture..........................9 4. Repositories and Manifests....................................13
4.2. Contents and structure....................................9 4.1. Role in the overall architecture.........................13
4.3. Access protocols.........................................10 4.2. Contents and structure...................................13
4.4. Access control...........................................10 4.3. Manifests................................................15
5. Common Operations.............................................11 4.4. Access protocols.........................................16
5.1. Certificate issuance.....................................11 4.5. Access control...........................................17
5.2. ROA management...........................................12 5. Local Cache Maintenance.......................................17
5.2.1. Single-homed subscribers (without portable allocations) 6. Common Operations.............................................18
...........................................................12 6.1. Certificate issuance.....................................18
5.2.2. Multi-homing........................................13 6.2. ROA management...........................................19
5.2.3. Portable allocations................................13 6.2.1. Single-homed subscribers (without portable allocations)
5.3. Route filter construction................................13 ...........................................................20
6. Security Considerations.......................................14 6.2.2. Multi-homed subscribers.............................20
7. IANA Considerations...........................................14 6.2.3. Portable allocations................................21
8. Acknowledgments...............................................14 6.3. Route filter construction................................21
9. References....................................................15
9.1. Normative References.....................................15 7. Security Considerations.......................................22
9.2. Informative References...................................15 8. IANA Considerations...........................................23
Author's Addresses...............................................15 9. Acknowledgments...............................................23
Intellectual Property Statement..................................16 10. References...................................................24
Disclaimer of Validity...........................................16 10.1. Normative References....................................24
10.2. Informative References..................................24
Author's Addresses...............................................25
Intellectual Property Statement..................................25
Disclaimer of Validity...........................................26
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 [2] for the Internet. The
architecture described by this document supports, at a minimum, two architecture encompasses three principle elements:
types of routing security: It enables an entity to verifiably assert
that it is the legitimate holder of a set IP addresses or a set of . a public key infrastructure (PKI)
Autonomous System (AS) numbers, and it allows the holder of IP
address space to explicitly and verifiably authorize an AS to . digitally-signed routing objects to support routing security
originate routes to that address space. In addition to these initial
applications, however, this architecture could also support, without . a distributed repository system to hold the PKI objects and the
extension, more advanced security protocols such as S-BGP [7] or signed routing objects
soBGP [8]. This architecture is applicable to routing of both IPv4
and IPv6 datagrams. The architecture described by this document supports, at a minimum,
two aspects of routing security; it enables an entity to verifiably
assert that it is the legitimate holder of a set IP addresses or a
set of Autonomous System (AS) numbers, and it allows the holder of IP
address space to explicitly and verifiably authorize one or more ASes
to originate routes to that address space. In addition to these
initial applications, the infrastructure defined by this architecture
also is intended to be able to support security protocols such as S-
BGP [8] or soBGP [9]. This architecture is applicable to routing of
both IPv4 and IPv6 datagrams.
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 of existing technologies and practices. The structure of the PKI
architecture corresponds to the existing resource allocation element of the architecture corresponds to the existing resource
structure, so that management of this architecture is a natural allocation structure. Thus management of this PKI is a natural
extension of the resource-management functions of organizations that extension of the resource-management functions of the organizations
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. To practices have well-defined correspondents in this architecture. To
ease implementation, existing IETF standards are used wherever 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 PKIX [3] and the extensions for IP Addresses and
AS numbers defined in RFC 3779 [4]. AS numbers representation defined in RFC 3779 [5]. Also CMS [4] is
used as the syntax for the newly-defined signed objects required by
this infrastructure.
The architecture is comprised of three main components: An X.509 As noted above, the infrastructure is comprised of three main
public-key infrastructure (PKI) where certificates attest to holdings components: an X.509 PKI in which certificates attest to holdings of
of IP address space and AS numbers; signed objects called Route IP address space and AS numbers; non-certificate/CRL signed objects
Origination Authorizations (ROAs) that enable an address space holder (Route Origination Authorizations and manifests) used by the
to explicitly authorize an AS to originate routes to portions of the infrastructure; and a distributed repository system that makes all of
IP address space; and a distributed repository system that makes these signed objects available for use by ISPs in making routing
these objects available for use by ISPs in making routing decisions. decisions. These three basic components enable several security
These three basic components enable several security functions; this functions; this document describes how they can be used to improve
document describes how they can be used to improve route filter route filter generation, and to perform several other common
generation, and to perform several other common operations in such a operations in such a way as to make them cryptographically
way as to make them cryptographically verifiable. verifiable.
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 IP address space is entitled to define
the topological destination of IP datagrams whose destinations fall the topological destination of IP datagrams whose destinations fall
within that block, decisions about inter-domain routing are within that block, decisions about inter-domain routing are
inherently based on knowledge the allocation of the IP address space. inherently based on knowledge the allocation of the IP address space.
Thus, a basic function of this architecture is to provide 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 address is hierarchic: The current practice, the allocation of IP address is hierarchic. The
holder of a set of IP addresses may sub-allocate portions of that root of the hierarchy is IANA. Below IANA are five Regional Internet
set, either to itself (e.g., to a particular unit of the same Registries (RIRs), each of which manages address and AS number
organization), or to another organization. Because of this allocation within a defined geopolitical region. In some regions the
structure, IP address allocations can be described naturally by a third tier of the hierarchy includes National Internet Registries and
hierarchic public-key infrastructure, in which each certificate (NIRs) as well as Local Internet Registries (LIRs) and subscribers
attests to an allocation of IP addresses, and signing of subordinate with so-called "portable" (provider-independent) allocations. (The
term LIR is used in some regions to refer to what other regions
define as an ISP. Throughout the rest of this document we will use
the term LIR/ISP to simplify references to these entities.) In other
regions the third tier consists only of LIRs/ISPs and subscribers
with portable allocations.
In general, the holder of a set of IP addresses may sub-allocate
portions of that set, either to itself (e.g., to a particular unit of
the same organization), or to another organization, subject to
contractual constraints established by the registries. Because of
this structure, IP address allocations can be described naturally by
a hierarchic public-key infrastructure, in which each certificate
attests to an allocation of IP addresses, and issuance of subordinate
certificates corresponds to sub-allocation of IP addresses. The certificates corresponds to sub-allocation of IP addresses. The
above reasoning holds true for AS number resources as well, with the above reasoning holds true for AS number resources as well, with the
difference that, by convention, AS numbers may not be sub-allocated difference that, by convention, AS numbers may not be sub-allocated
except by registries. Thus allocations of both IP addresses and AS except by regional or national registries. Thus allocations of both
numbers can be expressed by the same PKI. Such a PKI is a central IP addresses and AS numbers can be expressed by the same PKI. Such a
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 Certificate, and conform Certificates in this PKI are called Resource Certificates, and
to the certificate profile for such certificates [5]. Resource conform to the certificate profile for such certificates [6].
certificates attest to the allocation by the (certificate) issuer of Resource certificates attest to the allocation by the (certificate)
IP addresses or AS numbers to the subject. They do this by binding issuer of IP addresses or AS numbers to the subject. They do this by
the public key contained in the Resource Certificate to the IP binding the public key contained in the Resource Certificate to the
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. An important Delegation or AS Identifier Delegation Extensions, respectively, as
property of this PKI is that the names assigned to certificate defined in RFC 3779 [5].
issuers and subjects are not intended to be meaningful; this is in
contrast to most PKIs where considerable effort is expended to ensure An important property of this PKI is that certificates do not attest
that the subject name in a certificate is properly associated with to the identity of the subject. Therefore, the subject names used in
certificates are not intended to be "descriptive." That is, this PKI
is intended to provide authorization, but not authentication. This is
in contrast to most PKIs where the issuer ensures that the
descriptive subject name in a certificate is properly associated with
the entity that holds the private key corresponding to the public key the entity that holds the private key corresponding to the public key
in the certificate. This PKI is different because it is an in the certificate. Because issuers need not verify the right of an
authorization PKI, not an authentication PKI. Because issuers need entity to use a subject name in a certificate, they avoid the costs
not verify the right of an entity to use a subject name in a and liabilities of such verification. This makes it easier for these
certificate, they avoid the costs and liabilities of such entities to take on the additional role of CA.
verification. This makes it easier for these entities to take on the
additional role of CA. Only the basic PKI requirement, that a CA not
associate the same name with two distinct subjects to whom it issues
certificates, is imposed.
The certificates in the PKI assert the basic facts on which the rest Most of the certificates in the PKI assert the basic facts on which
of the infrastructure operates. Certificates within the CA hierarchy the rest of the infrastructure operates. CA certificates within the
attest to IP address space and AS number holdings. End-entity PKI attest to IP address space and AS number holdings. End-entity
certificates are issued by resource holders to delegate the authority (EE) certificates are issued by resource holder CAs to delegate the
attested by their allocation certificates, the primary use for this authority attested by their allocation certificates. The primary use
being the signing of ROAs. These certificates and corresponding for EE certificates is the validation of Route Origination
certificate revocation lists will comprise a significant portion of Authorizations (ROAs). Additionally, signed objects called manifests
the data stored in the repository system. will be used to help ensure the integrity of the repository system,
and the signature on each manifest will be verified via an EE
certificate.
2.2. CA Certificates 2.2. CA Certificates
Any holder of Internet Number Resources who is authorized to sub- Any holder of Internet resources who is authorized to sub-allocate
allocate them must be able to issue Resource Certificates to them must be able to issue Resource Certificates to correspond to
correspond to these sub-allocations. Thus, for example, CA these sub-allocations. Thus, for example, CA certificates will be
certificates will be associated with each of the Regional Internet associated with each of the RIRs, NIRs, and LIRs/ISPs. A CA
Registries, National Internet Registries, and Local Internet certificate also is required to enable a resource holder to issue
Registries, as well as with all ISPs. A CA certificate is also ROAs, because it must issue the corresponding end-entity certificate
necessary for a resource holder to issue ROAs (because it must also used to validate each ROA. Thus some subscribers also will need to
issue the corresponding end-entity certificates used to validate have CA certificates for their allocations, e.g., subscribers with
ROAs), so many subscribers also will need to have CA certificates for portable allocations, to enable them to issue ROAs. (A subscriber who
their allocations (in particular, multi-homed subscribers, and is not multi-homed, whose allocation comes from an LIR/ISP, and who
subscribers with portable allocations). has not moved to a different LIR/ISP, need not be represented in the
PKI. Moreover, a multi-homed subscriber with an allocation from an
LIR/ISP may or may not need to be explicitly represented, as
discussed in Section 6.2.2)
Unlike in most PKIs, the distinguished name of the subject in a CA
certificate is chosen by the certificate issuer. If the subject of a
certificate is an RIR, then the distinguished name of the subject
will be chosen to convey the identity of the registry and should
consist of (a subset of) the following attributes: country,
organization, organizational unit, and common name. For example, an
appropriate subject name for the APNIC RIR might be:
. Country: AU
. Organization: Asia Pacific Network Information Centre
. Common Name: APNIC Resource Certification Authority
If the subject of a certificate is not an RIR, (e.g., the subject is
a NIR, or LIR/ISP) the distinguished name MUST consist only of the
common name attribute and must not attempt to convey the identity of
the subject in a descriptive fashion. Additionally, the subject's
distinguished name must be unique among all certificates issued by a
given authority. In this PKI, the certificate issuer, being an
internet registry or LIR/ISP, is not in the business of verifying the
legal right of the subject to assert a particular identity.
Therefore, selecting a distinguished name that does not convey the
identity of the subject in a descriptive fashion minimizes the
opportunity for the subject to misuse the certificate to assert an
identity, and thus minimizes the legal liability of the issuer. Since
all CA certificates are issued to subjects with whom the issuer has
an existing relationship, it is recommended that the issuer select a
subject name that enables the issuer to easily link the certificate
to existing database records associated with the subject. For
example, an authority may use internal database keys or subscriber
IDs as the subject common name in issued certificates.
Each Resource Certificate attests to an allocation of resources to Each Resource Certificate attests to an allocation of resources to
its holder, so entities that have allocations from multiple sources its holder, so entities that have allocations from multiple sources
will have multiple CA certificates. (A CA also may issue distinct will have multiple CA certificates. A CA also may issue distinct
certificates for each distinct allocation to the same entity, if the certificates for each distinct allocation to the same entity, if the
issuer and the resource holder agree that such an arrangement will CA and the resource holder agree that such an arrangement will
facilitate management and use of the certificates.) facilitate management and use of the certificates. For example, an
LIR/ISP may have several certificates issued to it by one registry,
each describing a distinct set of address blocks, because the LIR/ISP
desires to treat the allocations as separate.
2.3. End-Entity Certificates 2.3. End-Entity (EE) Certificates
Although the private key corresponding to public key contained in an The private key corresponding to public key contained in an EE
end-entity certificate is not used to sign other certificates in the certificate is not used to sign other certificates in a PKI. The
PKI, the primary function of end-entity certificates in this PKI is primary function of end-entity certificates in this PKI is the
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. For this resources described in the certificate, e.g., ROAs and manifests.
purpose, there is a one-to-one correspondence between end-entity For ROAs and manifests there will be a one-to-one correspondence
certificates and signed objects, i.e., the private key corresponding between end-entity certificates and signed objects, i.e., the private
to each end-entity certificate is used to sign exactly one object, key corresponding to each end-entity certificate is used to sign
and each object is signed with one key. This property allows the PKI exactly one object, and each object is signed with only one key.
itself to be used to revoke these signed objects. When the end-entity This property allows the PKI to be used to revoke these signed
certificate used to sign an object has been revoked, the signature on objects, rather than creating a new revocation mechanism. When the
that object (and any corresponding assertions) will be considered end-entity certificate used to sign an object has been revoked, the
invalid, so a signed object can be effectively revoked by revoking signature on that object (and any corresponding assertions) will be
the end-entity certificate used to sign it. considered invalid, so a signed object can be effectively revoked by
revoking the end-entity certificate used to sign it.
A secondary advantage to this one-to-one correspondence is that the 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 only the public portions of end-entity certificates management, since there is no requirement to protect these private
will need to be retained for any significant length of time. keys for an extended period of time.
Although this document defines only one use for end-entity Although this document defines 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 holder of authorization for their subjects to act on behalf of the holder of
the indicated resources. This could facilitate authentication of the specified resources. This could facilitate authentication of
inter-ISP interactions, or authentication of interactions with the inter-ISP interactions, or authentication of interactions with the
repository system. These additional uses for end-entity repository system. These additional uses for end-entity certificates
certificates, however, may require retention of the corresponding may require retention of the corresponding private keys, even though
private keys, even though this is not required for the private keys this is not required for the private keys associated with end-entity
associated with end-entity certificates keys used for verification of certificates keys used for verification of ROAs and manifests, as
ROAs, as described above. described above.
2.4. Trust Anchors 2.4. Trust Anchors
In any PKI, each relying party (RP) is free to choose its own set of In any PKI, each relying party (RP) is free to choose its own set of
trust anchors. In this case, the hierarchy of this PKI is structured trust anchors. This general property of PKIs applies here as well.
according to the IP address space and AS number allocation hierarchy, There is an extant IP address space and AS number allocation
so since administrative control of the IP address space (the root of hierarchy. IANA is the obvious candidate to be the TA, but
the allocation hierarchy) rests with IANA and the RIRs , these operational considerations may argue for a multi-TA PKI, e.g., one in
entities form a natural set of default trust anchors for this PKI. which both IANA and the RIRs form a default set of trust anchors.
Nonetheless, every relying party is free to choose a different set of Nonetheless, every relying party is free to choose a different set of
trust anchors to use for certificate validation operations. trust anchors to use for certificate validation operations.
For example, an RP could create one or more self-signed certificates For example, an RP (e.g., an LIR/ISP) could create a self-signed
to which all address space and/or all AS numbers are assigned, and certificate to which all address space and/or all AS numbers are
for which the RP knows the corresponding private key. The RP could assigned, and for which the RP knows the corresponding private key.
then issue certificates under these trust anchors to whatever The RP could then issue certificates under this trust anchor to
entities in the PKI it wishes, with the result that the certificate whatever entities in the PKI it wishes, with the result that the
paths terminating at these locally-installed trust anchors will certificate paths terminating at this locally-installed trust anchor
satisfy the RFC 3779 validation requirements. will satisfy the RFC 3779 validation requirements.
An RP who elects to create and manage its own set of trust anchors An RP who elects to create and manage its own set of trust anchors
may fail to detect allocation errors that arise under such 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.
2.5. Default Trust Anchor Considerations
IANA forms the root of the extant IP address space and AS number
allocation hierarchy. Therefore, it is natural to consider a model in
which most relying parties have as their single trust anchor a self-
signed IANA certificate whose RFC 3779 extensions specify the
entirety of the AS number and IP address and spaces. However, IANA
has not traditionally acted in an operational capacity as the root of
the resource allocation hierarchy, much less managed certificates and
their associated private keys. Therefore it is unclear whether IANA
is willing to undertake this role as the default trust anchor for the
PKI. This has prompted the consideration of alternative approaches
for recommending trust anchors to potential relying parties.
Essentially all allocated IP address and AS number resources are sub-
allocated by IANA to one of the five RIRs. Therefore, one could
consider a model in which the default trust anchors are a set of five
self-signed certificates, one for each RIR. There are two
difficulties that such an approach must overcome.
The first difficulty is that IANA retains authority for 44 /8
prefixes in IPv4 and a /26 prefix in IPv6. Therefore, any approach
that recommends the RIRs as default trust anchors will also require
as a default trust anchor an IANA certificate who's RFC 3779
extensions correspond to this address space. Additionally, there are
about 49 /8 prefixes containing legacy allocations that are not each
allocated to a single RIR. Currently, for the purpose of
administering reverse DNS zones, each of these prefixes is
administered by a single RIR who delegates authority for allocations
within the prefix as appropriate. This existing arrangement could be
used as the template for the assignment of administrative
responsibility for the certification of these address blocks in the
RPKI. Such an arrangement would in no way alter the administrative
arrangements and the associated policies that apply to the individual
legacy allocations that have been made from these address blocks.
The second difficulty is that the resource allocations of the RIRs
may change several times a year. Typically in a PKI, trust anchors
are quite long-lived and distributed to relying parties via some out-
of-band mechanism. However, such out-of-band distribution of new
trust anchors is not feasible if the allocations change every few
months. Therefore, any approach that recommends the RIRs as default
trust anchors must provide an in-band mechanism for managing the
changes that will occur in the RIR allocations (as expressed via RFC
3779 extensions).
2.6. Representing Early-Registration Transfers (ERX)
Currently, IANA allocates IPv4 address space to the RIRs at the level
of /8 prefixes. However, there exist allocations that cross these RIR
boundaries. For example, A LACNIC customer may have an allocation
that falls within a /8 prefix administered by ARIN. Therefore, the
resource PKI must be able to represent such transfers from one RIR to
another in a manner that permits the validation of certificates with
RFC 3779 extensions.
---------------------------------
| |
| LACNIC Administrative |
| Boundary |
| |
---------- | ---------- | ----------
| ARIN | | | LACNIC | | | RIPE |
| ROOT | | | ROOT | | | ROOT |
---------- | ---------- | ----------
\ | | /
------------ ------------
| \ / |
| ---------- ---------- |
| | LACNIC | | LACNIC | |
| | CA | | CA | |
| ---------- ---------- |
| |
---------------------------------
FIGURE 1: Representing EXR
To represent such transfers, RIRs will need to manage multiple CA
certificates, each with distinct public (and corresponding private)
keys. Each RIR will have a single "root" certificate (e.g., a self-
signed certificate or a certificate signed by IANA, see Section 2.5),
plus one additional CA certificate for each RIR from which it
receives a transfer. Each of these additional CA certificates will be
issued under the "root" certificate of the RIR from which the
transfer is received. This means that although the certificate is
bound to the RIR that receives the transfer, for the purposes of
certificate path construction and validation, it does not appear
under that RIR's "root" certificate (see Figure 1).
3. Route Origination Authorizations 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 block of IP address space is authorized to do so by the particular prefix is authorized to do so by the holder of that prefix
holder of that block; the PKI contains no information about these (or an address block encompassing the prefix); the PKI contains no
authorizations. A Route Origination Authorization (ROA) make such information about these authorizations. A Route Origination
authorization explicit, allowing a holder of address space to create Authorization (ROA) makes such authorization explicit, allowing a
an object that explicitly and verifiably asserts that an AS is holder of address space to create an object that explicitly and
authorized originate routes to that address space. verifiably asserts that an AS is authorized originate routes to
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 IP addresses has A ROA is an attestation that the holder of a set of prefixes has
authorized an autonomous system to originate routes for that set of authorized an autonomous system to originate routes for those
IP addresses. A ROA is structured according to format described in prefixes. A ROA is structured according to the format described in
[6]. The validity of this authorization depends on the issuer of the [7]. The validity of this authorization depends on the signer of the
ROA being the owner of the set of IP addresses in the ROA; this fact ROA being the holder of the prefix(es) in the ROA; this fact is
is asserted by an end-entity certificate from the PKI, whose asserted by an end-entity certificate from the PKI, whose
corresponding private key is used to sign the ROA. The repository corresponding private key is used to sign the ROA.
system will be the primary mechanism for disseminating ROAs, since
the operators of repositories already provide other types routing ROAs may be used by relying parties to verify that the AS that
information. In addition, ROAs could also be distributed in BGP originates a route for a given IP address prefix is authorized by the
UPDATE messages or via other communication paths, since route holder of that prefix to originate such a route. For example, an ISP
filtering is their primary application. might use ROAs as inputs to route filter construction for use by its
BGP routers. These filters would prevent importation of any route in
which the origin AS of the AS-PATH attribute is not an AS that is
authorized (via a valid ROA) to originate the route. (See Section 6.3
for more details.)
Initially, the repository system will be the primary mechanism for
disseminating ROAs, since these repositories will hold the
certificates and CRLs needed to verify ROAs. In addition, ROAs also
could be distributed in BGP UPDATE messages or via other
communication paths, if needed to meet timeliness requirements.
3.2. Syntax and semantics 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 ROA thus have three essential components: of those prefixes. Syntactically, a ROA is a CMS signed-data object
whose content is defined as follows:
1. An AS number RouteOriginAttestation ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
asID ASID,
exactMatch BOOLEAN,
ipAddrBlocks ROAIPAddrBlocks }
2. One or more IP address prefixes ASID ::= INTEGER
3. A digital signature ROAIPAddrBlocks ::= SEQUENCE of ROAIPAddressFamily
In addition, a ROA has a version number, to accommodate changes in ROAIPAddressFamily ::= SEQUENCE {
syntax (or semantics) over time. The AS number contained in a ROA is addressFamily OCTET STRING (SIZE (2..3)),
that of an AS authorized to originate routes for the indicated IP addresses SEQUENCE OF IPAddress }
address prefixes. Only one AS number is contained in a ROA in order -- Only two address families are allowed: IPv4 and IPv6
to simplify ROA management, e.g., to avoid the complexity that might
arise is AS numbers for multiple ISPs were referenced from a single
ROA. If an ISP serving a subscriber has multiple AS numbers, and
wants the address space holder to authorize advertisement of the same
set of prefixes by any of these ASes, the ISP should request the
subscriber to issue multiple ROAs, each specifying a distinct AS
number. Similarly, a multi-homed address space holder must generate
multiple ROAs, one for each ISP that will originate routes for it.
A ROA is signed using the private key whose public key is contained IPAddress ::= BIT STRING
in an end-entity certificate in the PKI, from which the ROA inherits
two properties. First, The IP prefixes listed in the ROA are the
ones that the indicated AS is authorized to originate; in order for
this authorization (i.e., the ROA) to be valid, the prefixes
contained in a ROA must be exactly the same as the set of IP
addresses in the IP Address Delegation Extension of the end-entity
certificate used to sign the ROA. Second, the ROA is valid only as
long as the certificate used to sign it is valid; a ROA is
invalidated by revoking the end-entity certificate corresponding to
the public key used to verify it, and the validity interval of the
ROA is implicitly that of the validity interval of the corresponding
certificate.
Address holders that have allocations from multiple sources must That is, the signed data within the ROA consists of a version number,
issue multiple ROAs. If an address holder has allocations from the AS number that is being authorized, and a list of IP prefixes to
multiple sources, then these allocations will be described by which the AS is authorized to originate routes. If the exactMatch
multiple CA certificates in the PKI, each issued by the provider of flag is set to TRUE, then the AS is authorized to originate only
the respective allocation; the sets of IP addresses contained in end- routes for the exact prefix(es) indicated in the ROA. Otherwise, if
entity certificates issued by this address holder are required to be the exactMatch flag is set to FALSE, the AS is authorized to
subsets of these allocations. Because end-entity certificates are in originate routes to the prefix(es) in the ROA as well as any longer
one-to-one correspondence with ROAs, this means that the set of IP (more specific) prefixes.
addresses contained in a ROA must be drawn from an allocation by a
single source; hence ROAs cannot combine allocations from multiple
sources.
3.3. Revocation Note that a ROA contains only a single AS number. Thus, in cases
where an ISP has multiple AS numbers that will be authorized to
originate routes to the prefix(es) in the ROA, an address space
holder will need to issue multiple ROAs to authorize the ISP to
originate routes from any of these ASes.
If an address holder decides that an AS should no longer originate A ROA is signed using the private key corresponding to the public key
routes for addresses that it holds (e.g., if the address holder in an end-entity certificate in the PKI. In order for a ROA to be
transfers from one ISP to another), then it will be necessary to valid, its corresponding end-entity (EE) certificate must be valid
invalidate the ROAs that attest to any such authorization. Since and the IP address prefixes of the ROA must exactly match the IP
ROAs are in one-to-one correspondence with end-entity certificates, address prefix(es) specified in the EE certificate's RFC 3779
the standard method for revoking a ROA is to revoke the corresponding extension. Therefore, the validity interval of the ROA is implicitly
end-entity certificate in the PKI. There is no independent the validity interval of its corresponding certificate. A ROA is
revocation mechanism for ROAs. revoked by revoking the corresponding EE certificate. There is no
independent method of invoking a ROA. One might worry that this
revocation model could lead to long CRLs for the CA certification
that is signing the EE certificates. However, routing announcements
on the public internet are generally quite long lived. Therefore, as
long as the EE certificates used to sign a ROA are given a validity
interval of several months, the likelihood that many ROAs would need
to revoked within time that is quite low.
4. Repository system --------- ---------
| 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 |
---------- ---------- ----------
In order for ROAs (and other objects to be verified using FIGURE 2: This figure illustrates an ISP with allocations from two
certificates from the PKI) to be validated, the objects necessary to sources (and RIR and an NIR). It needs two CA certificates due to RFC
validate them must be universally accessible. The primary function 3779 rules.
of the distributed repository system described here is to store these
objects and to make them available for download. The repository Because each ROA is associated with a single end-entity certificate,
system is also a point of enforcement for access controls for the the set of IP prefixes contained in a ROA must be drawn from an
signed objects stored in it, e.g., ensuring that records related to allocation by a single source, i.e., a ROA cannot combine allocations
an allocation of resources can be manipulated only by authorized from multiple sources. Address space holders who have allocations
parties. This requirement exists to prevent denial of service attacks from multiple sources, and who wish to authorize an AS to originate
based on deletion of or tampering with repository objects. Although routes for these allocations, must issue multiple ROAs to the AS.
any unauthorized modification is detectable by relying parties,
because all the objects are digitally signed, it is preferable that 4. Repositories and Manifests
the repository system prevent unauthorized modifications.
Initially, an LIR/ISP will make use of the resource PKI by acquiring
and validating every ROA, to create a table of the prefixes for which
each AS is authorized to originate routes. To validate all ROAs, an
LIR/ISP needs to acquire all the certificates and CRLs. The primary
function of the distributed repository system described here is to
store these signed objects and to make them available for download by
LIRs/ISPs. The digital signatures on all objects in the repository
ensure that unauthorized modification of valid objects is detectable
by relying parties. Additionally, the repository system uses
manifests (described below) to ensure that relying parties can detect
the deletion of valid objects and the insertion of out of date, valid
signed objects.
The repository system is also a point of enforcement for access
controls for the signed objects stored in it, e.g., ensuring that
records related to an allocation of resources can be manipulated only
by authorized parties. The use access controls prevents denial of
service attacks based on deletion of or tampering to repository
objects. Indeed, although relying parties can detect tampering with
objects in the repository, it is preferable that the repository
system prevent such unauthorized modifications to the greatest extent
possible.
4.1. Role in the overall architecture 4.1. Role in the overall architecture
The repository system is the central clearing-house for the objects The repository system is the central clearing-house for all signed
required for validation of signed objects like ROAs. When objects that must be globally accessible to relying parties. When
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. In repository, and then downloaded for use by relying parties (primarily
addition, signed objects that require universal distribution can also LIRs/ISPs). ROAs and manifests are additional examples of such
be made accessible through the repository system; ROAs are the only objects, but other types of signed objects may be added to this
such objects defined by this document, but other types of signed architecture in the future. This document briefly describes the way
objects may be added to this architecture in the future. The signed objects (certificates, CRLs, ROAs and manifests) are managed
repository system also must ensure the integrity of the data it in the repository system. As other types of signed objects are added
contains by enforcing appropriate controls on access to the to the repository system it will be necessary to modify the
repository and on modifications to entries in it. This document description, but it is anticipated that most of the design principles
describes the controls necessary for PKI objects and ROAs, but does will still apply. The repository system is described in detail in
not assume that they are applicable to other types of objects; if [??].
other types of objects are to be included in the repository system in
the future, any necessary controls on them must be defined.
4.2. Contents and structure 4.2. Contents and structure
The primary function of the repository system is to provide universal
distribution of objects necessary for the function of this
architecture. First among these are the objects that comprise the
PKI, namely Resource Certificates and their corresponding CRLs; these
objects require universal distribution so that all relying parties
have access to the PKI components required to validate signed objects
used by this architecture. In addition, it may be necessary to make
other types of signed objects available through the repository
system. ROAs are a prime example of such a type, since routes whose
origination is authorized by a ROA are distributed through the entire
routing infrastructure, any component of which may, by local policy,
examine the route origin for consistency with the ROA.
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 RIRs and ISPs that participate in databases will be distributed among registries (RIRs, NIRs,
the architecture. At a minimum, the database operated by each RIR LIRs/ISPs). At a minimum, the database operated by each registry will
will contain certificates and CRLs issued by that RIR; it may also contain all CA and EE certificates, CRLs, and manifests signed by the
contain repository objects submitted by holders of addresses that CA(s) associated with that registry. Repositories operated by
fall within that RIR's scope or copies of data from other RIRs, LIRs/ISPs also will contain ROAs. Registries are encouraged maintain
according to local policy. copies of repository data from their customers, and their customer's
customers (etc.), to facilitate retrieval of the whole repository
contents by relying parties. Ideally, each RIR will hold PKI data
from all entities within its geopolitical scope.
4.3. Access protocols For every certificate in the PKI, there will be a corresponding file
system directory in the repository that is the authoritative
publication point for all objects (certificates, CRLs, ROAs and
manifests) verifiable via this certificate. A certificate's Subject
Information Authority (SIA) extension provides a URI that references
this directory. Additionally, a certificate's Authority Information
Authority (AIA) extension contains a URI that references the
authoritative location for the CA certificate under which the given
certificate was issued. That is, if certificate A is used to verify
certificate B, then the AIA extension of certificate B points to
certificate A, and the SIA extension of certificate A points to a
directory containing certificate B (see Figure 2).
----------
---------->| Cert A |<-----
| | CRLDP | | -----------
| | AIA | | --->| A's CRL |<--
| --------+- SIA | | | ----------- |
| | ---------- | | |
| | | | |
| | ----+----- |
| | | | |
| | ----------------|---|------------------ |
| | | | | | |
| -->| ---------- | | ---------- | |
| | | Cert B | | | | Cert C | | |
| | | CRLDP -+--- | | CRLDP -+----|----
----------+- AIA | ----+- AIA | |
| | SIA | | SIA | |
| ---------- ---------- |
| |
---------------------------------------
FIGURE 3: In this example, certificates B and C are issued under
certificate A. Therefore, the AIA extensions of certificates B and C
point to A, and the SIA extension of certificate A points to the
directory containing certificates B and C.
If a CA certificate is reissued with the same public key, it should
not be necessary to reissue (with an updated AIA URI) all
certificates signed by the certificate being reissued. Therefore, a
certification authority SHOULD use a persistent URI naming scheme for
issued certificates. That is, reissued certificates should use the
same publication point as previously issued certificates having the
same subject and public key, and should overwrite such certificates.
4.3. Manifests
A manifest is a signed object listing of all of the signed objects
issued by a particular authority that are present in the repository
system. For each certificate, CRL, or ROA issued by the authority,
the manifest contains both the name of the file containing the
object, and a hash of the file content.
As with ROAs, a manifest is signed by a private key whose
corresponding public key appears in an end-entity certificate signed
by the CA in question. Each such end-entity certificate is used to
sign a single manifest and the private key corresponding to such an
end-entity certificate may be deleted after it is used to sign that
manifest. To avoid needless CRL growth, the EE certificate used to
validate a manifest SHOULD expire at the same time that the manifest
expires, i.e., the notAfter value in the EE certificate should be the
same as the nextUpdate value in the manifest.
Syntactically, a manifest is a CMS signed-data object whose content
is defined as follows:
Manifest ::= SEQUENCE {
version INTEGER DEFAULT 0,
manifestNumber INTEGER,
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String
hash BIT STRING
}
The manifestNumber field is a sequence number that is incremented
each time a manifest is issued by a authority. The thisUpdate field
contains the time when the manifest was created and the nextUpdate
field contains the time at which the next scheduled manifest will be
issued. If the authority alters any of its items in the repository,
then it MUST issue a new manifest before nextUpdate. In such a case,
when the authority issues the new manifest, it MUST also issue a new
CRL which includes the EE certificate corresponding to the old
manifest. A manifest is thus valid until the time specified in
nextUpdate or until a manifest is issued with a greater manifest
number, whichever comes first. The revoked EE certificate for the old
manifest will be removed from the CRL when it expires, thus this
procedure ought not yield large CRLs.
The fileHashAlg field contains the OID of the hash algorithm used to
hash the files that the authority has placed into the repository. The
mandatory to implement hash algorithm is SHA-256 and its OID is
2.16.840.1.101.3.4.2.1. [RFC 4055]
The fileList field contains a sequence of FileAndHash pairs, one for
each currently valid certificate, CRL and ROA that has been issued by
the authority. Each of the FileAndHash pairs contains the name of the
file in the repository that contains the object in question, and a
hash of the file's contents.
4.4. Access protocols
Repository operators will choose one or more access protocols that Repository operators will choose one or more access protocols that
relying parties can use to access the repository system. These relying parties can use to access the repository system. These
protocols will be used by numerous participants in the infrastructure protocols will be used by numerous participants in the infrastructure
(e.g., all registries, ISPs, and multi-homed subscribers) to maintain (e.g., all registries, ISPs, and multi-homed subscribers) to maintain
their respective portions of it. In order to support these their respective portions of it. In order to support these
activities, certain basic functionality is required of the suite of activities, certain basic functionality is required of the suite of
access protocols, as described below. No single access protocol need access protocols, as described below. No single access protocol need
implement all of these functions (although this may be the case), but implement all of these functions (although this may be the case), but
each function must be implemented by at least one access protocol. each function must be implemented by at least one access protocol.
skipping to change at page 10, line 34 skipping to change at page 17, line 7
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 [9] as the Current efforts to implement a repository system use RSYNC [10] as
single access protocol. RSYNC, as used in this implementation, the single access protocol. RSYNC, as used in this implementation,
provides all of the above functionality. provides all of the above functionality. A document specifying the
conventions for use of RSYNC in the PKI will be prepared.
4.4. Access control 4.5. 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 is suggested in Section 2.3 other parties to act on their behalf, as suggested in Section 2.3
above. above.
5. Common Operations 5. Local Cache Maintenance
In order to utilize signed objects issued under this PKI (e.g. for
route filter construction, see Section 6.3), a relying party must
first obtain a local copy of the valid EE certificates for the PKI.
To do so, the relying party performs the following steps:
1. Query the registry system to obtain a copy of all certificates,
manifests and CRLs issued under the PKI.
2. For each CA certificate in the PKI, verify the signature on the
corresponding manifest. Additionally, verify that the current
time is earlier than the time indicated in the nextUpdate field
of the manifest.
3. For each manifest, verify that certificates and CRLs issued
under the corresponding CA certificate match the hash values
contained in the manifest. If the hash values do not match, use
an out-of-band mechanism to notify the appropriate repository
administrator that the repository data has been corrupted.
4. Validate each EE certificate by constructing and verifying a
certification path for the certificate (including checking
relevant CRLs) to the locally configured set of TAs. (See [6]
for more details.)
Note that when a relying party performs these operations regularly,
it is more efficient for the relying party to request from the
repository system only those objects that have changed since the
relying party last updated its local cache. Note also that by
checking all issued objects against the appropriate manifest, the
relying party can be certain that it is not missing an updated
version of any object.
6. Common Operations
Creating and maintaining the infrastructure described above will Creating and maintaining the infrastructure described above will
entail the addition of security operations to normal resource entail additional operations as "side effects" of normal resource
allocation and routing authorization procedures. For example, a allocation and routing authorization procedures. For example, a
multi-homed subscriber entering a relationship with a new ISP will subscriber with "portable" address space who entes a relationship
need to issue one or more ROAs to that ISP, in addition to conducting with an ISP will need to issue one or more ROAs identifying that ISP,
any other necessary technical or business procedures. The current in addition to conducting any other necessary technical or business
primary use of this infrastructure is for route filter construction; procedures. The current primary use of this infrastructure is for
using ROAs, route filters can be constructed in an automated fashion route filter construction; using ROAs, route filters can be
with high assurance that the holder of the advertised prefix has constructed in an automated fashion with high assurance that the
authorized the first- hop AS to originate an advertised route. holder of the advertised prefix has authorized the first-hop AS to
originate an advertised route.
5.1. Certificate issuance 6.1. Certificate issuance
In order to participate in this infrastructure, resource holders will There are several operational scenarios that require certificates to
require certificates in the PKI that attest to their allocations. be issued. Any allocation that may be sub-allocated requires a CA
Each such certificate will show the issuer of the allocation as the certificate, e.g., so that certificates can be issued as necessary
certificate issuer, the recipient of the allocation as subject, and a for the sub-allocations. Holders of "portable" address allocations
description of the allocated resources in the appropriate RFC 3779 also must have certificates, so that a ROA can be issued to each ISP
extensions. The two operations defined in this architecture that that is authorized to originate a route to the allocation (since the
require a resource holder to have resource certificates for his allocation does not come from any ISP). Additionally, multi-homed
allocations are (1) issuance of certificates for sub-allocations and subscribers may require certificates for their allocations if they
(2) management of ROAs (and corresponding end-entity certificates). intend to issue the ROAs for their allocations (see Section 6.2.2).
Other holders of resources need not be issued CA certificates within
the PKI.
In particular, there are several operational scenarios that require In the long run, a resource holder will not request resource
certificates to be issued. Any allocation that may be sub-allocated certificates, but rather receive a certificate as a side effect of
requires a CA certificate so that certificates can be issued as the allocation process for the resource. However, initial deployment
necessary for sub-allocations. Multi-homed subscribers require of the RPKI will entail issuance of certificates to existing resource
certificates for their allocations so that they can issue ROAs to holders as an explicit event. Note that in all cases, the authority
their ISPs. Holders of "portable" address allocations must have issuing a CA certificate will be the entity who allocates resources
certificates, so that a ROA can be issued to each ISP that is to the subject. This differs from most PKIs in which a subject can
authorized to originate a route to the allocation, since the request a certificate from any certification authority.
allocation does not come from any ISP.
As a resource holder receives multiple allocations over time, it will If a resource holder receives multiple allocations over time, it may
accrue a collection of resource certificates to attest to them. It accrue a collection of resource certificates to attest to them. If a
may be the case that multiple of a resource holder's allocations are resource holder receives multiple allocations from the same source,
from the same source. A set of resource certificates that are all the set of resource certificates may be combined into a single
issued by the same CA could be combined into a single resource resource certificate, if both the issuer and the resource holder
certificate by consolidating their IP Address Delegation and AS agree. This is effected by consolidating the IP Address Delegation
Identifier Delegation Extensions into a single extension of each and AS Identifier Delegation Extensions into a single extension (of
type. However, if the certificates for these allocations contain each type) in a new certificate. However, if the certificates for
different validity intervals, creating a certificate that combines these allocations contain different validity intervals, creating a
them might create problems, and thus is NOT RECOMMENDED. If a certificate that combines them might create problems, and thus is NOT
resource holder's allocations come from different sources, they will RECOMMENDED.
be signed by different CAs, and cannot be combined. When a set of
resources is no longer allocated to a resource holder, any
certificates attesting to such an allocation must be revoked. A
resource holder MAY choose to use the same public key in multiple CA
certificates that issued by the same or differing authorities,
although such reuse of a key pair does complicate path construction.
5.2. ROA management If a resource holder's allocations come from different sources, they
will be signed by different CAs, and cannot be combined. When a set
of resources is no longer allocated to a resource holder, any
certificates attesting to such an allocation MUST be revoked. A
resource holder SHOULD NOT to use the same public key in multiple CA
certificates that are issued by the same or differing authorities, as
reuse of a key pair complicates path construction. Note that since
the subject's distinguished name is chosen by the issuer, a subject
who receives allocations from two sources generally will receive
certificates with different subject names.
6.2. 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 and use the end-entity certificate containing that prefix in an IP Address
corresponding private key to sign a ROA containing the designated Delegation extension. He then uses the corresponding private key to
prefix and an AS number identifying the designated AS. As a sign a ROA containing the designated prefix and the AS number for the
prerequisite, then, any address holder that issues ROAs for a prefix AS. The resource holder MAY include more than one prefix in the EE
must have a resource certificate for an allocation containing that certificate and corresponding ROA if desired. As a prerequisite,
prefix. The standard procedure for issuing a ROA is as follows: then, any address holder that issues ROAs for a prefix must have a
resource certificate for an allocation containing that prefix. The
standard procedure for issuing a ROA is as follows:
1. Create an end-entity certificate containing the prefixes 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-entity 3. Sign the ROA using the private key corresponding to the end-
certificate (the ROA is comprised of the payload encapsulated in a entity certificate (the ROA is comprised of the payload
CMS signed message [ROA format I-D]) encapsulated in a CMS signed message [7]).
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.
5.2.1. Single-homed subscribers (without portable allocations) 6.2.1. Single-homed subscribers (without portable allocations)
In BGP, a single-homed subscriber with a non-portable allocation does In BGP, a single-homed subscriber with a non-portable allocation does
not need to explicitly authorize routes to be originated for the not need to explicitly authorize routes to be originated for the
prefix (or prefixes) it is using, since its ISP will already prefix(es) it is using, since its ISP will already advertise a more
advertise a more general prefix and route traffic for the general prefix and route traffic for the subscriber's prefix as an
subscriber's prefix as an internal function. Since no routes are internal function. Since no routes are originated specifically for
originated specifically for prefixes held by these subscribers, no prefixes held by these subscribers, no ROAs need to be issued under
ROAs need to be issued under their allocations; rather, the their allocations; rather, the subscriber's ISP will issue any
subscriber's ISP will issue any necessary ROAs for its more general necessary ROAs for its more general prefixes under resource
prefixes under resource certificates its own allocation. Thus, certificates its own allocation. Thus, a single-homed subscriber with
single-homed subscribers with non-portable allocations do not need to a non-portable allocation is not included in the RPKI, i.e., it does
issue (or otherwise manage) ROAs. not receive a CA certificate, nor issue EE certificates or ROAs.
5.2.2. Multi-homing 6.2.2. Multi-homed subscribers
If a multi-homed subscriber wants multiple ASes to originate routes In order for multiple ASes to originate routers for prefixes held by
for prefixes that it holds, then it must explicitly authorize each of a multi-homed subscriber, each AS must have a ROA that explicitly
them to do so by issuing a ROA for each AS in question. authorizes such route origination. There are two ways that this can
be accomplished.
5.2.3. Portable allocations One option is for the multi-homed subscriber to obtain a CA
certificate from the ISP who allocated the prefixes to the
subscriber. The multi-homed subscriber can then create a ROA (and
associated end-entity certificate) that authorizes a second ISP to
originate routes to the subscriber prefix(es). The ROA for the second
ISP generally SHOULD be set to require an exact match, if the intent
is to enable backup paths for the prefix. Note that the first ISP,
who allocated the prefixes, will want to advertise the more specific
prefix for this subscriber (vs. the encompassing prefix). Either the
subscriber or the first ISP will need to issue an EE certificate and
ROA for the (more specific) prefix, authorizing this ISP to advertise
this more specific prefix.
A resource holder is said to have a portable allocation if the A second option is that the multi-homed subscriber can request that
resource holder received its allocation from a registry. Because the ISP that allocated the prefixes create a ROA that authorizes the
these allocations are not taken from any larger allocations held by second ISP to originate routes to the subscriber's prefixes. (The ISP
an ISP, there is no ISP that holds and advertises a more general also creates an EE certificate and ROA for its own advertisement of
prefix. If the holder of a portable allocation wants to authorize an the subscriber prefix, as above.) This option does not require that
ISP to originate routes to its allocation, then it must issue a ROA the subscriber be issued a certificate or participate in ROA
to this ISP; none of the ISP's existing ROAs authorize it to management. Therefore, this option is simpler for the subscriber, and
originate routes to that portable allocation. is preferred if the option is supported by the ISP performing the
allocation.
5.3. Route filter construction 6.2.3. Portable allocations
A resource holder is said to have a portable (provider independent)
allocation if the resource holder received its allocation from a
regional or national registry. Because the prefixes represented in
such 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 portable allocation MUST authorize one or more ASes to
originate routes to these prefixes. Thus the resource holder MUST
generate one or more EE certificates and associated ROAs to enable
the AS(es) to originate routes for the prefix(es) in question. This
ROA is required because none of the ISP's existing ROAs authorize it
to originate routes to that portable allocation.
6.3. Route filter construction
The goal of this architecture is to support improved routing The goal of this architecture is to support improved routing
security. One way to do this is to use ROAs to construct route security. One way to do this is to use ROAs to construct route
filters that reject routes that conflict with the origination filters that reject routes that conflict with the origination
authorizations asserted by current ROAs, which can be accomplished authorizations asserted by current ROAs, which can be accomplished
with the following procedure: with the following procedure:
1. Obtain current certificates, CRLs, and ROAs from the repository 1. Obtain a local copy of all currently valid EE certificates, as
system (e.g., update a previous download) specified in Section 5.
2. Verify each end-entity certificate by constructing and verifying 2. Query the repository system to obtain a local copy of all ROAs
a certification path for the certificate (including checking issued under the PKI.
relevant CRLs).
3. Verify each ROA by verifying that it is signed by a valid end- 3. Verify that the each ROA matches the hash value contained in the
entity certificate that matches the address allocation in the ROA. manifest of the CA certificate used to verify the EE certificate
that issued the ROA and that no ROAs are missing. (ROAs are
contained in files with a ".roa" suffix, so missing ROAs are
readily detected.)
4. Based on validated ROAs, construct a table of prefixes and 4. Validate each ROA by verifying that it's signature is verifiable
corresponding authorized origin ASes (or vice versa). by a valid end-entity certificate that matches the address
allocation in the ROA. (See [7] for more details.)
In addition to this basic route-filtering technique, the 5. Based on the validated ROAs, construct a table of prefixes and
infrastructure can be used to support more advanced routing-security corresponding authorized origin ASes (or vice versa).
systems, such as S-BGP [7] and soBGP [8].
The first three steps in the above procedure would incur a A BGP speaker that applies such a filter is thus guaranteed that for
prohibitive amount of overhead if all objects in the repository a given IP address prefix, all routes that the BGP speaker accepts
system were downloaded and validated every time a route filter was for that prefix were originated by an AS that is authorized by the
constructed. Instead, it will be more efficient for users of the owner of the prefix to authorize routes to that prefix.
infrastructure to initially download all of the objects
(certificates, CRLs, and ROAs), perform necessary validations, then
perform incremental downloads and validations on a regular basis. A
typical ISP using the infrastructure might have a daily schedule to
download updates from the repository, upload any modifications it has
made, and construct route filters.
6. Security Considerations The first three steps in the above procedure might incur a
substantial overhead if all objects in the repository system were
downloaded and validated every time a route filter was constructed.
Instead, it will be more efficient for users of the infrastructure to
initially download all of the signed objects and perform the
validation algorithm described above. Subsequently, a relying party
need only perform incremental downloads and validations on a regular
basis. A typical ISP using the infrastructure might have a daily
schedule to download updates from the repository, upload any
modifications it has made, and construct route filters.
It should be noted that the transition to 4-byte AS numbers (see RFC
4893 [10]) weakens the security guarantees achieved by BGP speakers
who do not support 4-byte AS numbers (referred to as OLD BGP
speakers). RFC 4893 specifies that all 4-byte AS numbers (except
those whose first two bytes are entirely zero) be mapped to the
reserved value 23456 before being sent to a BGP speaker who does not
understand 4-byte AS numbers. Therefore, when an ISP creates a route
filter for use by an OLD BGP speaker, it must allow any 4-byte AS
number to advertise routes for an IP address prefix if there exists a
ROA that authorizes any 4-byte AS number to advertise routes to that
prefix. This means that if an OLD BGP speaker accepts a route that
was originated by an AS with a 4-byte AS number, there is no
guarantee that it was originated by an authorized 4-byte AS number
(unless the route was propagated by an intermediate NEW BGP speaker
who performed route filtering as described above).
7. Security Considerations
The focus of this document is security; hence security considerations The focus of this document is security; hence security considerations
permeate this specification. permeate this specification.
The security mechanisms provided by and enabled by this architecture The security mechanisms provided by and enabled by this architecture
depend on the integrity and availability of the infrastructure it depend on the integrity and availability of the infrastructure it
describes. The integrity of objects within the infrastructure is describes. The integrity of objects within the infrastructure is
ensured by appropriate controls on the repository system, as ensured by appropriate controls on the repository system, as
described in Section 4.4. Likewise, because the repository system is described in Section 4.4. Likewise, because the repository system is
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
7. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC RFC
8. Acknowledgments 9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
9. References 10. References
9.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006 (BGP-4)", RFC 4271, January 2006
[3] Housley, R., et al., "Internet X.509 Public Key Infrastructure [3] Housley, R., et al., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC Certificate and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002. 3280, April 2002.
[4] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [4] Housley, R., "Cryptographic Message Syntax", RFC 3852, July
2004.
[5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[5] Huston, G., Michaelson, G., and Loomans, R., "A Profile for [6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for
X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs- X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs,
03, February 2007. July 2007 (work in progress).
[6] Kong, D., and Kent, S., " A Profile for Route Origin [7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route
Authorizations (ROA)", draft-ietf-sidr-roa-format-00, February Origin Authorizations (ROA)", draft-ietf-sidr-roa-format,
2007. July 2008 (work in progress).
9.2. Informative References 10.2. Informative References
[7] [S-BGP] [8] [S-BGP]
[8] [soBGP] [9] [soBGP]
[9] [rsync] [10] [rsync]
[11] Vohra, Q., and Chen, E., "BGP Support for Four-octet AS Number
Space", RFC 4893, May 2007.
Author's Addresses Author's Addresses
Richard Barnes Matt Lepinski
BBN Technologies BBN Technologies
10 Moulton St.
Cambridge, MA 02138
Email: rbarnes@bbn.com Email: mlepinski@bbn.com
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St.
Cambridge, MA 02138
Email: kent@bbn.com Email: kent@bbn.com
Richard Barnes
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
Email: rbarnes@bbn.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 92 change blocks. 
398 lines changed or deleted 811 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/