draft-ietf-sidr-arch-12.txt   draft-ietf-sidr-arch-13.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 February 16, 2011 Intended status: Informational May 23, 2011
Expires: August 16, 2011 Expires: November 23, 2011
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-12.txt draft-ietf-sidr-arch-13.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 16, 2011. This Internet-Draft will expire on November 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. 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 resource public key infrastructure (RPKI) that
allocation hierarchy of IP address space and Autonomous System (AS) represents the allocation hierarchy of IP address space and
Numbers; and a distributed repository system for storing and Autonomous System (AS) Numbers; and a distributed repository system
disseminating the data objects that comprise the PKI, as well as for storing and disseminating the data objects that comprise the
other signed objects necessary for improved routing security. As an RPKI, as well as other signed objects necessary for improved routing
initial application of this architecture, the document describes how security. As an initial application of this architecture, the
a legitimate holder of IP address space can explicitly and verifiably document describes how a legitimate holder of IP address space can
authorize one or more ASes to originate routes to that address space. explicitly and verifiably authorize one or more ASes to originate
Such verifiable authorizations could be used, for example, to more routes to that address space. Such verifiable authorizations could be
securely construct BGP route filters. used, for example, to more 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 ...................................... 15 4.4. Access control...........................................15
5. Manifests ................................................ 15 5. Manifests.....................................................15
5.1. Syntax and semantics ................................ 15 5.1. Syntax and semantics.....................................16
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. CA Key Rollover ..................................... 18 7.2. CA Key Rollover..........................................18
7.3. ROA management ...................................... 19 7.3. ROA management...........................................19
7.3.1. Single-homed subscribers ....................... 20 7.3.1. Single-homed subscribers............................20
7.3.2. Multi-homed subscribers ........................ 20 7.3.2. Multi-homed subscribers.............................20
7.3.3. Provider-Independent Address Space ............. 21 7.3.3. Provider-Independent Address Space..................21
8. Security Considerations .................................. 21 8. Security Considerations.......................................21
9. IANA Considerations ...................................... 21 9. IANA Considerations...........................................22
10. Acknowledgments ......................................... 22 10. Acknowledgments..............................................22
11. References .............................................. 23 11. References...................................................23
11.1. Normative References ............................... 23 11.1. Normative References....................................23
11.2. Informative References ............................ 23 11.2. Informative References..................................24
Authors' Addresses ......................................... 24 Authors' Addresses...............................................24
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 [RFC 4271] for the support improved security for BGP routing [RFC 4271] for the
Internet. The architecture encompasses three principle elements: Internet. The architecture encompasses three principle elements:
. a public key infrastructure (PKI) . a resource public key infrastructure (RPKI)
. 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
skipping to change at page 4, line 16 skipping to change at page 4, line 16
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 the Public Key Infrastructure using X.509 (PKIX) profile defined by the Public Key Infrastructure using X.509 (PKIX)
working group [RFC 5280] and the extensions for IP Addresses and AS working group [RFC 5280] and the extensions for IP Addresses and AS
numbers representation defined in RFC 3779 [RFC 3779]. Also numbers representation defined in RFC 3779 [RFC 3779]. Also
Cryptographic Message Syntax (CMS) [RFC 5652] is used as the syntax Cryptographic Message Syntax (CMS) [RFC 5652] is used as the syntax
for the newly-defined signed objects [SIGN-OBJ] required by this for the newly-defined signed objects [SIGN-OBJ] required by this
infrastructure. 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 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; most notably the cryptographic validation that an
improve route filter generation, and to perform several other common autonomous system is authorized to originate routes to a given prefix
operations in such a way as to make them cryptographically [ROA-VALID].
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" [RFC 5280], and "X.509 and Certificate Revocation List (CRL) Profile" [RFC 5280], and "X.509
Extensions for IP Addresses and AS Identifiers" [RFC 3779]. Extensions for IP Addresses and AS Identifiers" [RFC 3779].
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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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. that it is permitted to sub-allocate.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC 2119]. 2119 [RFC 2119].
2. PKI for Internet Number Resources 2. Public Key Infrastructure for Internet Number Resources
Because the holder of a block of IP address space is entitled to Because the holder of a block of IP address space is entitled to
define the topological destination of IP datagrams whose destinations define the topological destination of IP datagrams whose destinations
fall 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 hierarchical. 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
skipping to change at page 5, line 38 skipping to change at page 5, line 38
particular unit of the same organization), or to another particular unit of the same organization), or to another
organization, subject to contractual constraints established by the organization, subject to contractual constraints established by the
registries. Because of this structure, IP address allocations can be registries. Because of this structure, IP address allocations can be
described naturally by a hierarchic public-key infrastructure, in described naturally by a hierarchic public-key infrastructure, in
which each certificate attests to an allocation of IP addresses, and which each certificate attests to an allocation of IP addresses, and
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, which is henceforth referred to as the Resource Public Key
Infrastructure (RPKI), 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 [RES-CERT]. 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
skipping to change at page 11, line 30 skipping to change at page 11, line 30
| ISP | | ISP | | ISP | | ISP | | ISP | | ISP |
| 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 1: This figure illustrates an ISP with allocations from two
sources (an 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.
skipping to change at page 12, line 26 skipping to change at page 12, line 26
records related to an allocation of resources can be manipulated only records related to an allocation of resources can be manipulated only
by authorized parties. The use of access controls prevents denial of by authorized parties. The use of access controls prevents denial of
service attacks based on deletion of or tampering to repository service attacks based on deletion of or tampering to repository
objects. Indeed, although relying parties can detect tampering with objects. Indeed, although relying parties can detect tampering with
objects in the repository, it is preferable that the repository objects in the repository, it is preferable that the repository
system prevent such unauthorized modifications to the greatest extent system prevent such unauthorized modifications to the greatest extent
possible. possible.
4.1. Role in the overall architecture 4.1. Role in the overall architecture
The repository system is the central clearing-house for all signed The repository system is the untrusted clearing-house for all signed
objects that must be globally accessible to relying parties. 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 (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
skipping to change at page 13, line 11 skipping to change at page 13, line 11
LIRs/ISPs also will contain ROAs. Registries are encouraged to LIRs/ISPs also will contain ROAs. Registries are encouraged to
maintain copies of repository data from their customers, and their maintain copies of repository data from their customers, and their
customer's customers (etc.), to facilitate retrieval of the whole customer's customers (etc.), to facilitate retrieval of the whole
repository contents by relying parties. Ideally, each RIR will hold repository contents by relying parties. Ideally, each RIR will hold
PKI data from all entities within its geopolitical scope. PKI data from all entities within its geopolitical scope.
For every certificate in the PKI, there will be a corresponding file For every certificate in the PKI, there will be a corresponding file
system directory in the repository that is the authoritative system directory in the repository that is the authoritative
publication point for all objects (certificates, CRLs, ROAs and publication point for all objects (certificates, CRLs, ROAs and
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 [RFC 5280] contains a URI that
this directory. Additionally, a certificate's Authority Information references this directory. Additionally, a certificate's Authority
Authority (AIA) extension contains a URI that references the Information Authority (AIA) extension [RFC 5280] contains a URI that
authoritative location for the CA certificate under which the given references the authoritative location for the CA certificate under
certificate was issued. That is, if certificate A is used to verify which the given certificate was issued. That is, if certificate A is
certificate B, then the AIA extension of certificate B points to used to verify certificate B, then the AIA extension of certificate B
certificate A, and the SIA extension of certificate A points to a points to certificate A, and the SIA extension of certificate A
directory containing certificate B (see Figure 2). points to a directory containing certificate B (see Figure 2).
+--------+ +--------+
+--------->| Cert A |<----+ +--------->| Cert A |<----+
| | CRLDP | | | | CRLDP | |
| | AIA | | | | AIA | |
| +--------- SIA | | | +--------- SIA | |
| | +--------+ | | | +--------+ |
| | | | | |
| | | | | |
| | | | | |
skipping to change at page 13, line 44 skipping to change at page 13, line 44
+----------- AIA | | +----- AIA | | | +----------- AIA | | +----- AIA | | |
| | SIA | | | SIA | | | | | SIA | | | SIA | | |
| +--------+ | +--------+ | | | +--------+ | +--------+ | |
| V | | | V | |
| +---------+ | | | +---------+ | |
| | A's CRL |<-----------+ | | | A's CRL |<-----------+ |
| +---------+ | | +---------+ |
| A's Repository Publication Directory | | A's Repository Publication Directory |
+--------------------------------------+ +--------------------------------------+
FIGURE 3: In this example, certificates B and C are issued by FIGURE 2: Use of SIA and AIA extensions in the RPKI
certification authority A. Therefore, the AIA extensions of
certificates B and C point to the publication point where Certificate In Figure 2, certificates B and C are issued by (CA) A. Therefore,
A is published, and the SIA extension of certificate A points to the the AIA extensions of certificates B and C point to (certificate) A,
repository publication point where the objects issued under authority and the SIA extension of certificate A points to the repository
A, including certificates B and C and A's CRL, are published. publication point of CA A's subordinate products, which includes
certificates B and C, as well as the CRL issued by A. The CRL
Distribution Points (CRLDP) extension in certificates B and C both
point to the Certificate Revocation List (CRL) issued by A.
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
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
deployed by a repository operator.
Download: Access protocols MUST support the bulk download of Download: Access protocols must support the bulk download of
repository contents and subsequent download of changes to the repository contents and subsequent download of changes to the
downloaded contents, since this will be the most common way in which downloaded contents, since this will be the most common way in which
relying parties interact with the repository system. Other types of relying parties interact with the repository system. Other types of
download interactions (e.g., download of a single object) MAY also be download interactions (e.g., download of a single object) may also be
supported. supported.
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).
To ensure all relying parties are able to acquire all RPKI signed To ensure all relying parties are able to acquire all RPKI signed
objects, all publication points MUST be accessible via RSYNC (see objects, all publication points MUST be accessible via RSYNC (see
[RFC 5781] and [RSYNC]), although other download protocols also be [RFC 5781] and [RSYNC]), although other download protocols MAY also
supported. A repository publication point may provide be supported. A repository publication point may provide
update/change/delete functionality via (set of) access protocols that update/change/delete functionality via (set of) access protocols that
it desires, provided that the supported protocols are clearly it desires, provided that the supported protocols are clearly
communicated to all certification authorities publishing data at a communicated to all certification authorities publishing data at a
given publication point. 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.
skipping to change at page 15, line 23 skipping to change at page 15, line 26
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 (except for the manifest itself) issued by an authority responsible
repository system. For each unexpired certificate, CRL, or ROA issued for a publication in the repository system. For each unexpired
by the authority, the manifest contains both the name of the file certificate, CRL, or ROA issued by the authority, the manifest
containing the object, and a hash of the file content. 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, 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. Since the EE certificate, in turn, is signed by the CA in question. Since the
private key in an EE certificate is used to sign only a single private key in an EE certificate is used to sign only a single
manifest, then the manifest can be revoked by revoking the EE manifest, then the manifest can be revoked by revoking the EE
certificate. In such a case, to avoid needless CRL growth, the EE certificate. In such a case, to avoid needless CRL growth, the EE
certificate used to validate a manifest SHOULD expire at the same certificate used to validate a manifest SHOULD expire at the same
time that the manifest expires. time that the manifest expires.
skipping to change at page 16, line 6 skipping to change at page 16, line 15
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 the manifest's content is provided in [MANIFEST] specification of the manifest's content is provided in [MANIFEST]
but, at a high level, a manifest consists of (1) a manifest number; but, at a high level, a manifest consists of (1) a manifest number;
(2) the time the manifest was issued; (3) the time of the next (2) the time the manifest was issued; (3) the time of the next
planned update; and (4) a list of filename and hash value pairs. 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
certificate corresponding to the old manifest. The revoked EE certificate corresponding to the old manifest. The revoked EE
certificate for the old manifest will be removed from the CRL when it certificate for the old manifest will be removed from the CRL when it
expires, thus this procedure ought not to result in significant CRLs expires, thus this procedure ought not to result in significant CRLs
growth.) growth.)
6. Local Cache Maintenance 6. Local Cache Maintenance
In order to utilize signed objects issued under this PKI, a relying In order to utilize signed objects issued under this PKI, a relying
party must first obtain a local copy of the valid EE certificates for 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: the PKI. To do so, the relying party performs the following steps:
1. Query the registry system to obtain a copy of all certificates, 1. Query the repository system to obtain a copy of all
manifests and CRLs issued under the PKI. certificates, manifests and CRLs issued under the PKI.
2. For each CA certificate in the PKI, verify the signature on the 2. For each CA certificate in the PKI, verify the signature on the
corresponding manifest. Additionally, verify that the current corresponding manifest. Additionally, verify that the current
time is earlier than the time indicated in the nextUpdate field time is earlier than the time indicated in the nextUpdate field
of the manifest. of the manifest.
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
skipping to change at page 18, line 26 skipping to change at page 18, line 36
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. CA Key Rollover 7.2. CA Key Rollover
Whenever a certification authority wishes to change the public key Whenever a certification authority wishes to change the public key
(and corresponding private key) associated with its RPKI CA (and corresponding private key) associated with its RPKI CA
certificate, it must perform a key rollover procedure. Key rollover certificate, it MUST perform a key rollover procedure. Key rollover
is typically performed on a periodic basis, where the frequency of is typically performed on a periodic basis, where the frequency of
key rollovers is specified in the certification practice statement of key rollovers is specified in the certification practice statement of
the given CA. Additionally, unscheduled rollovers may be required in the given CA. Additionally, unscheduled rollovers may be required in
the event of suspected key compromises. the event of suspected key compromises.
Note that rollover is only required when the CA's key actually 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 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 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 example, a new CA certificate must be issued if the CA gains or
relinquishes resource, or if the validity period of the resource relinquishes resource, or if the validity period of the resource
skipping to change at page 21, line 46 skipping to change at page 22, line 10
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.
9. IANA Considerations 9. IANA Considerations
This document requests that the IANA issue RPKI Certificates for the Instructions for IANA's participation in the RPKI are provided in
resources for which it is authoritative, i.e., reserved IPv4 [IANA-OBJ].
addresses, IPv6 Unique Local Addresses (ULAs), and address space not
yet allocated by IANA to the RIRs. IANA SHOULD make available trust
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 23, line 26 skipping to change at page 23, line 26
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008. List (CRL) Profile", RFC 5280, May 2008.
[RFC 5652] Housley, R., "Cryptographic Message Syntax", RFC 5652, [RFC 5652] Housley, R., "Cryptographic Message Syntax", RFC 5652,
September 2009. September 2009.
[RFC 3779] 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.
[RES-CERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI
Scheme", RFC 5781, February 2010.
[RES-CERT] Huston, G., Michaelson, G., and R. Loomans, "A Profile
for X.509 PKIX Resource Certificates", draft-ietf-sidr- for X.509 PKIX Resource Certificates", draft-ietf-sidr-
res-certs, December 2010. res-certs, May 2011.
[ROA-FORM] Lepinski, M., Kent, S., and Kong, D., "A Profile for [ROA-FORM] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Route Origin Authorizations (ROA)", draft-ietf-sidr-roa- Origin Authorizations (ROA)", draft-ietf-sidr-roa-format,
format, February 2011. February 2011.
[SIGN-OBJ] Chi, A., Kent, S., and Lepinski, M., "Signed Object [SIGN-OBJ] Chi, A., Kent, S., and M. Lepinski, "Signed Object
Template for the Resource Public Key Infrastructure", Template for the Resource Public Key Infrastructure",
draft-ietf-sidr-signed-object, February 2010. draft-ietf-sidr-signed-object, May 2011.
[MANIFEST] Austein, R., et al., "Manifests for the Resource Public [MANIFEST] Austein, R., et al., "Manifests for the Resource Public
Key Infrastructure", draft-ietf-sidr-rpki-manifests, Key Infrastructure", draft-ietf-sidr-rpki-manifests, May
November 2010. 2011.
[REPOS] Huston, G., Michaelson, G., and Loomans, R., "A Profile [REPOS] Huston, G., Michaelson, G., and R. Loomans, "A Profile
for Resource Certificate Repository Structure", draft- for Resource Certificate Repository Structure", draft-
ietf-sidr-repos-struct, November 2010. ietf-sidr-repos-struct, February 2011.
11.2. Informative References [IANA-OBJ] Manderson, T., Vegoda, L. and S. Kent, "RPKI Objects
issued by IANA", draft-ietf-sidr-iana-objects, May 2011.
[KEY-ROLL] Huston, G., Michaelson, G., and Kent, K., "CA Key 11.2. Informative References
Rollover in the RPKI", draft-huston-sidr-keyroll,
December 2010.
[ROA-VALID] Huston, G., Michaelson, G., "Validation of Route [KEY-ROLL] Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
Origination in BGP using the Resource Certificate PKI", in the RPKI", draft-huston-sidr-keyroll, February 2011.
draft-ietf-sidr-roa-validation, November 2010.
[RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI [ROA-VALID] Huston, G., et al., "Validation of Route Origination in
Scheme", RFC 5781, February 2010. BGP using the Resource Certificate PKI", draft-ietf-sidr-
roa-validation, April 2011.
[SIDR-TA] Michaelson, G., Kent, S., and Huston, G., "A Profile for [SIDR-TA] Michaelson, G., Kent, S., and Huston, G., "A Profile for
Trust Anchor Material for the Resource Certificate PKI", Trust Anchor Material for the Resource Certificate PKI",
draft-ietf-sidr-ta, May 2010. draft-ietf-sidr-ta, April 2011.
[S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway [S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway
Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
Communications Vol. 18, No. 4, April 2000. Communications Vol. 18, No. 4, April 2000.
[soBGP] White, R., "soBGP", May 2005, <ftp://ftp- [soBGP] White, R., "soBGP", May 2005, <ftp://ftp-
eng.cisco.com/sobgp/index.html> eng.cisco.com/sobgp/index.html>
[RSYNC] Tridgell, A., "rsync", March 2008, < [RSYNC] Tridgell, A., "rsync", March 2008,
http://rsync.samba.org/> <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
 End of changes. 40 change blocks. 
115 lines changed or deleted 118 lines changed or added

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