draft-ietf-sidr-arch-08.txt   draft-ietf-sidr-arch-09.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 July 29, 2009 Intended status: Informational October 26, 2009
Expires: January 29, 2010 Expires: April 26, 2010
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-08.txt draft-ietf-sidr-arch-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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 January 29, 20010. This Internet-Draft will expire on April 26, 20010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4.1. Role in the overall architecture.........................12 4.1. Role in the overall architecture.........................12
4.2. Contents and structure...................................12 4.2. Contents and structure...................................12
4.3. Access protocols.........................................14 4.3. Access protocols.........................................14
4.4. Access control...........................................14 4.4. Access control...........................................14
5. Manifests.....................................................15 5. Manifests.....................................................15
5.1. Syntax and semantics.....................................15 5.1. Syntax and semantics.....................................15
6. Local Cache Maintenance.......................................16 6. Local Cache Maintenance.......................................16
7. Common Operations.............................................17 7. Common Operations.............................................17
7.1. Certificate issuance.....................................17 7.1. Certificate issuance.....................................17
7.2. ROA management...........................................18 7.2. ROA management...........................................18
7.2.1. Single-homed subscribers (without provider independent 7.2.1. Single-homed subscribers (with PA address space)....19
addresses).................................................19 7.2.2. Multi-homed subscribers (with PA address space).....19
7.2.2. Multi-homed subscribers (without provider independent
addresses).................................................19
7.2.3. Provider-Independent Address Space..................20 7.2.3. Provider-Independent Address Space..................20
8. Security Considerations.......................................20 8. Security Considerations.......................................20
9. IANA Considerations...........................................20 9. IANA Considerations...........................................21
10. Acknowledgments..............................................21 10. Acknowledgments..............................................21
11. References...................................................22 11. References...................................................22
11.1. Normative References....................................22 11.1. Normative References....................................22
11.2. Informative References..................................22 11.2. Informative References..................................22
Authors' Addresses...............................................23 Authors' Addresses...............................................23
Pre-5378 Material Disclaimer.....................................23 Pre-5378 Material Disclaimer.....................................23
1. Introduction 1. Introduction
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
skipping to change at page 3, line 28 skipping to change at page 3, line 28
The architecture described by this document enables an entity to The architecture described by this document enables an entity to
verifiably assert that it is the legitimate holder of a set of IP verifiably assert that it is the legitimate holder of a set of IP
addresses or a set of Autonomous System (AS) numbers. As an initial addresses or a set of Autonomous System (AS) numbers. As an initial
application of this architecture, the document describes how a application of this architecture, the document describes how a
legitimate holder of IP address space can explicitly and verifiably legitimate holder of IP address space can explicitly and verifiably
authorize one or more ASes to originate routes to that address space. authorize one or more ASes to originate routes to that address space.
Such verifiable authorizations could be used, for example, to more Such verifiable authorizations could be used, for example, to more
securely construct BGP route filters. In addition to this initial securely construct BGP route filters. In addition to this initial
application, the infrastructure defined by this architecture also is application, the infrastructure defined by this architecture also is
intended to provide future support for security protocols such as S- intended to provide future support for security protocols such as S-
BGP [11] or soBGP [12]. This architecture is applicable to the BGP [12] or soBGP [13]. This architecture is applicable to the
routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently
the only address families supported by this architecture. Thus, for the only address families supported by this architecture. Thus, for
example, use of this architecture with MPLS labels is beyond the example, use of this architecture with MPLS labels is beyond the
scope of this document. scope of this document.
In order to facilitate deployment, the architecture takes advantage In order to facilitate deployment, the architecture takes advantage
of existing technologies and practices. The structure of the PKI of existing technologies and practices. The structure of the PKI
element of the architecture corresponds to the existing resource element of the architecture corresponds to the existing resource
allocation structure. Thus management of this PKI is a natural allocation structure. Thus management of this PKI is a natural
extension of the resource-management functions of the organizations extension of the resource-management functions of the organizations
skipping to change at page 4, line 40 skipping to change at page 4, line 39
through the standard IP address allocation hierarchy. That is, the through the standard IP address allocation hierarchy. That is, the
address space holder has either directly received the address space address space holder has either directly received the address space
as an allocation from a Regional Internet Registry (RIR) or IANA; or as an allocation from a Regional Internet Registry (RIR) or IANA; or
else the address space holder has received the address space as a else the address space holder has received the address space as a
sub-allocation from a National Internet Registry (NIR) or Local sub-allocation from a National Internet Registry (NIR) or Local
Internet Registry (LIR). We use the term "resource holder" to refer Internet Registry (LIR). We use the term "resource holder" to refer
to a legitimate holder of either IP address or AS number resources. to a legitimate holder of either IP address or AS number resources.
Throughout this document we use the terms "registry" and ISP to refer Throughout this document we use the terms "registry" and ISP to refer
to an entity that has an IP address space and/or AS number allocation to an entity that has an IP address space and/or AS number allocation
that it is permitted to sub-allocate. We use the term "subscriber" to that it is permitted to sub-allocate its resources. We use the term
refer to an entity (e.g., an enterprise) that receives an IP address "subscriber" to refer to an entity (e.g., an enterprise) that
space and/or AS number allocation, but does not sub-allocate its receives an IP address space and/or AS number assignment, and does
resources. not sub-allocate its resources.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
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
skipping to change at page 9, line 42 skipping to change at page 9, line 42
prefixes. A ROA is structured according to the format described in prefixes. A ROA is structured according to the format described in
[7]. The validity of this authorization depends on the signer of the [7]. The validity of this authorization depends on the signer of the
ROA being the holder of the prefix(es) in the ROA; this fact is ROA being the holder of the prefix(es) in the ROA; this fact 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. corresponding private key is used to sign the ROA.
ROAs may be used by relying parties to verify that the AS that ROAs may be used by relying parties to verify that the AS that
originates a route for a given IP address prefix is authorized by the originates a route for a given IP address prefix is authorized by the
holder of that prefix to originate such a route. For example, an ISP holder of that prefix to originate such a route. For example, an ISP
might use validated ROAs as inputs to route filter construction for might use validated ROAs as inputs to route filter construction for
use by its BGP routers. (See [14] for information on the use of ROAs use by its BGP routers. (See [15] for information on the use of ROAs
to validate the origination of BGP routes.) to validate the origination of BGP routes.)
Initially, the repository system will be the primary mechanism for Initially, the repository system will be the primary mechanism for
disseminating ROAs, since these repositories will hold the disseminating ROAs, since these repositories will hold the
certificates and CRLs needed to verify ROAs. In addition, ROAs also certificates and CRLs needed to verify ROAs. In addition, ROAs also
could be distributed in BGP UPDATE messages or via other could be distributed in BGP UPDATE messages or via other
communication paths, if needed to meet timeliness requirements. communication paths, if needed to meet timeliness requirements.
3.2. Syntax and semantics 3.2. Syntax and semantics
skipping to change at page 12, line 38 skipping to change at page 12, line 38
certificates and CRLs are created, they are uploaded to this certificates and CRLs are created, they are uploaded to this
repository, and then downloaded for use by relying parties (primarily repository, and then downloaded for use by relying parties (primarily
LIRs/ISPs). ROAs and manifests are additional examples of such LIRs/ISPs). ROAs and manifests are additional examples of such
objects, but other types of signed objects may be added to this objects, but other types of signed objects may be added to this
architecture in the future. This document briefly describes the way architecture in the future. This document briefly describes the way
signed objects (certificates, CRLs, ROAs and manifests) are managed signed objects (certificates, CRLs, ROAs and manifests) are managed
in the repository system. As other types of signed objects are added in the repository system. As other types of signed objects are added
to the repository system it will be necessary to modify the to the repository system it will be necessary to modify the
description, but it is anticipated that most of the design principles description, but it is anticipated that most of the design principles
will still apply. The repository system is described in detail in will still apply. The repository system is described in detail in
[10]. [11].
4.2. Contents and structure 4.2. Contents and structure
Although there is a single repository system that is accessed by Although there is a single repository system that is accessed by
relying parties, it is comprised of multiple databases. These relying parties, it is comprised of multiple databases. These
databases will be distributed among registries (RIRs, NIRs, databases will be distributed among registries (RIRs, NIRs,
LIRs/ISPs). At a minimum, the database operated by each registry will LIRs/ISPs). At a minimum, the database operated by each registry will
contain all CA and EE certificates, CRLs, and manifests signed by the contain all CA and EE certificates, CRLs, and manifests signed by the
CA(s) associated with that registry. Repositories operated by CA(s) associated with that registry. Repositories operated by
LIRs/ISPs also will contain ROAs. Registries are encouraged to LIRs/ISPs also will contain ROAs. Registries are encouraged to
skipping to change at page 14, line 36 skipping to change at page 14, line 36
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 [13] as Current efforts to implement a repository system use RSYNC [14] as
the 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. A document specifying the provides all of the above functionality. A document specifying the
conventions for use of RSYNC in the PKI will be prepared. conventions for use of RSYNC in the PKI will be prepared.
4.4. Access control 4.4. Access control
In order to maintain the integrity of information in the repository, In order to maintain the integrity of information in the repository,
controls must be put in place to prevent addition, deletion, or controls must be put in place to prevent addition, deletion, or
modification of objects in the repository by unauthorized parties. modification of objects in the repository by unauthorized parties.
The identities of parties attempting to make such changes can be The identities of parties attempting to make such changes can be
skipping to change at page 16, line 39 skipping to change at page 16, line 39
certificate or manifest listed on the manifest is missing from certificate or manifest listed on the manifest is missing from
the repository. If the hash values do not match, or if any the repository. If the hash values do not match, or if any
certificate or CRL is missing, notify the appropriate repository certificate or CRL is missing, notify the appropriate repository
administrator that the repository data has been corrupted. administrator that the repository data has been corrupted.
4. Validate each EE certificate by constructing and verifying a 4. Validate each EE certificate by constructing and verifying a
certification path for the certificate (including checking certification path for the certificate (including checking
relevant CRLs) to the locally configured set of TAs. (See [6] relevant CRLs) to the locally configured set of TAs. (See [6]
for more details.) for more details.)
Note that when a relying party performs these operations regularly, Note that since relying parties will perform these operations
it is more efficient for the relying party to request from the regularly, it is more efficient for the relying party to request from
repository system only those objects that have changed since the the repository system only those objects that have changed since the
relying party last updated its local cache. A relying party may relying party last updated its local cache. A relying party may
choose any frequency it desires for downloading and validating choose any frequency it desires for downloading and validating
updates from the repository. However, a typical ISP might reasonably updates from the repository. However, any relying party that uses
choose to perform these operations on a daily schedule. Note also RPKI data as an input to operational routing decisions (e.g., ISPs,
that by checking all issued objects against the appropriate manifest, RIRs, NIRs) SHOULD download and validate updates at least once every
the relying party can be certain that it is not missing an updated three hours.
version of any object.
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.
7. Common Operations 7. Common Operations
Creating and maintaining the infrastructure described above will Creating and maintaining the infrastructure described above will
entail additional operations as "side effects" of 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
subscriber with provider-independent ("portable") address space who subscriber with provider-independent ("portable") address space who
enters a relationship with an ISP will need to issue one or more ROAs enters a relationship with an ISP will need to issue one or more ROAs
identifying that ISP, in addition to conducting any other necessary identifying that ISP, in addition to conducting any other necessary
technical or business procedures. The current primary use of this technical or business procedures. The current primary use of this
skipping to change at page 19, line 19 skipping to change at page 19, line 22
holder wishes to be routable on the Internet, it is very important holder wishes to be routable on the Internet, it is very important
for the resource holder to ensure that there exists another valid for the resource holder to ensure that there exists another valid
alternative ROA that lists the same prefix (possibly indicating a alternative ROA that lists the same prefix (possibly indicating a
different AS number). Additionally, the resource holder should ensure different AS number). Additionally, the resource holder should ensure
that the AS indicated in the valid alternative ROA is actually that the AS indicated in the valid alternative ROA is actually
originating routing advertisements to the prefixes in question. originating routing advertisements to the prefixes in question.
Furthermore, a relying party must fetch new ROAs from the repository Furthermore, a relying party must fetch new ROAs from the repository
system before taking any routing action in response to a ROA system before taking any routing action in response to a ROA
revocation. revocation.
7.2.1. Single-homed subscribers (without provider independent addresses) 7.2.1. Single-homed subscribers (with PA address space)
In BGP, a single-homed subscriber with provider allocated (non- In BGP, a single-homed subscriber with provider aggregatable (non-
portable) address space does not need to explicitly authorize routes portable) address space does not need to explicitly authorize routes
to be originated for the prefix(es) it is using, since its ISP will to be originated for the prefix(es) it is using, since its ISP will
already advertise a more general prefix and route traffic for the already advertise a more general prefix and route traffic for the
subscriber's prefix as an internal function. Since no routes are subscriber's prefix as an internal function. Since no routes are
originated specifically for prefixes held by these subscribers, no originated specifically for prefixes held by these subscribers, no
ROAs need to be issued under their allocations; rather, the ROAs need to be issued under their allocations; rather, the
subscriber's ISP will issue any necessary ROAs for its more general subscriber's ISP will issue any necessary ROAs for its more general
prefixes under resource certificates from its own allocation. Thus, a prefixes under resource certificates from its own allocation. Thus, a
single-homed subscriber with an IP address allocation from his single-homed subscriber with an IP address allocation from his
service provider is not included in the RPKI, i.e., it does not service provider is not included in the RPKI, i.e., it does not
receive a CA certificate, nor issue EE certificates or ROAs. receive a CA certificate, nor issue EE certificates or ROAs.
7.2.2. Multi-homed subscribers (without provider independent addresses) 7.2.2. Multi-homed subscribers (with PA address space)
Here we consider a subscriber who receives IP address space from a Here we consider a subscriber who receives provider aggregatable IP
primary ISP (i.e., the IP addresses used by the subscriber are a address space from a primary ISP (i.e., the IP addresses used by the
subset of ISP A's IP address space allocation) and receives redundant subscriber are a subset of ISP A's IP address space allocation) and
upstream connectivity from the primary ISP, as well as one or more receives redundant upstream connectivity from one or more secondary
secondary ISPs. The preferred option for such a multi-homed ISPs, in addition to the primary ISP. The preferred option for such a
subscribers is for the subscriber to obtain an AS number (from an RIR multi-homed subscriber is for the subscriber to obtain an AS number
or NIR) and run BGP with each of its upstream providers. In such a (from an RIR or NIR) and run BGP with each of its upstream providers.
case, there are two ways for ROA management to be handled. The first In such a case, there are two ways for ROA management to be handled.
is that the primary ISP issues a CA certificate to the subscriber, The first is that the primary ISP issues a CA certificate to the
and the subscriber issues a ROA to containing the subscriber's AS subscriber, and the subscriber issues a ROA to containing the
number and the subscriber's IP address prefixes. The second subscriber's AS number and the subscriber's IP address prefixes. The
possibility is that the primary ISP does not issue a ROA to the second possibility is that the primary ISP does not issue a CA
subscriber, and instead issues a ROA on the subscriber's behalf that certificate to the subscriber, and instead issues a ROA on the
contains the subscriber's AS number and the subscriber's IP address subscriber's behalf that contains the subscriber's AS number and the
prefixes. subscriber's IP address prefixes.
If the subscriber is unable or unwilling to obtain an AS number and If the subscriber is unable or unwilling to obtain an AS number and
run BGP, the other option is that the multi-homed subscriber can run BGP, the other option is that the multi-homed subscriber can
request that the primary ISP create a ROA for each secondary ISP that request that the primary ISP create a ROA for each secondary ISP that
authorizes the secondary ISP to originate routes to the subscriber's authorizes the secondary ISP to originate routes to the subscriber's
prefixes. The primary ISP will also create a ROA containing its own prefixes. The primary ISP will also create a ROA containing its own
AS number and the subscriber's prefixes, as it is likely in such a AS number and the subscriber's prefixes, as it is likely in such a
case that the primary ISP wishes to advertise precisely the case that the primary ISP wishes to advertise precisely the
subscriber's prefixes and not an encompassing aggregate. Note that subscriber's prefixes and not an encompassing aggregate. Note that
this approach results in inconsistent origin AS numbers for the this approach results in inconsistent origin AS numbers for the
subscribers prefixes which are considered undesirable on the public subscriber's prefixes which are considered undesirable on the public
Internet; thus this approach is NOT RECOMMENDED. Internet; thus this approach is NOT RECOMMENDED.
7.2.3. Provider-Independent Address Space 7.2.3. Provider-Independent Address Space
A resource holder is said to have provider-independent (portable) A resource holder is said to have provider-independent (portable)
address space if the resource holder received its allocation directly address space if the resource holder received its allocation directly
from a RIR or NIR. Because the prefixes represented in such from a RIR or NIR. Because the prefixes represented in such
allocations are not taken from an allocation held by an ISP, there is allocations are not taken from an allocation held by an ISP, there is
no ISP that holds and advertises a more general prefix. A holder of a no ISP that holds and advertises a more general prefix. A holder of a
portable IP address space allocation MUST authorize one or more ASes portable IP address space allocation MUST authorize one or more ASes
skipping to change at page 21, line 6 skipping to change at page 21, line 11
precautions should also be taken, both through replication and backup precautions should also be taken, both through replication and backup
of the constituent databases and through the physical security of of the constituent databases and through the physical security of
database servers. database servers.
9. IANA Considerations 9. IANA Considerations
This document requests that the IANA issue RPKI Certificates for the This document requests that the IANA issue RPKI Certificates for the
resources for which it is authoritative, i.e., reserved IPv4 resources for which it is authoritative, i.e., reserved IPv4
addresses, IPv6 ULAs, and address space not yet allocated by IANA to addresses, IPv6 ULAs, and address space not yet allocated by IANA to
the RIRs. IANA SHOULD make available trust anchor material in the the RIRs. IANA SHOULD make available trust anchor material in the
format defined in [10] in support of these functions. format defined in [9] in support of these functions.
10. Acknowledgments 10. Acknowledgments
The architecture described in this draft is derived from the The architecture described in this draft is derived from the
collective ideas and work of a large group of individuals. This work collective ideas and work of a large group of individuals. This work
would not have been possible without the intellectual contributions would not have been possible without the intellectual contributions
of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of
APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim
Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy
Bush of IIJ. Bush of IIJ.
skipping to change at page 22, line 28 skipping to change at page 22, line 28
5280, May 2008. 5280, May 2008.
[4] Housley, R., "Cryptographic Message Syntax", RFC 3852, July [4] Housley, R., "Cryptographic Message Syntax", RFC 3852, July
2004. 2004.
[5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [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.
[6] 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-
16, February 2009. 17, September 2009.
[7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route [7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route
Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-04, Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-06,
November 2008. October 2009.
[8] Austein, R., et al., "Manifests for the Resource Public Key [8] Austein, R., et al., "Manifests for the Resource Public Key
Infrastructure", draft-ietf-sidr-rpki-manifests-04, October Infrastructure", draft-ietf-sidr-rpki-manifests-05, August
2008. 2009.
[9] Michaelson, G., Kent, S., and Huston, G., "A Profile for Trust [9] Michaelson, G., Kent, S., and Huston, G., "A Profile for Trust
Anchor Material for the Resource Certificate PKI", draft-ietf- Anchor Material for the Resource Certificate PKI", draft-ietf-
sidr-ta-00, February 2009. sidr-ta-02, September 2009.
[10] Huston, G., "A Profile for Algorithms and Key Sizes for use in
the Resource Public Key Infrastructure", draft-ietf-sidr-rpki-
algs-00, August 2009.
11.2. Informative References 11.2. Informative References
[10] Huston, G., Michaelson, G., and Loomans, R., "A Profile for [11] Huston, G., Michaelson, G., and Loomans, R., "A Profile for
Resource Certificate Repository Structure", draft-ietf-sidr- Resource Certificate Repository Structure", draft-ietf-sidr-
repos-struct-01, October 2008. repos-struct-03, August 2009.
[11] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway [12] 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.
[12] White, R., "soBGP", May 2005, <ftp://ftp- [13] White, R., "soBGP", May 2005, <ftp://ftp-
eng.cisco.com/sobgp/index.html> eng.cisco.com/sobgp/index.html>
[13] Tridgell, A., "rsync", April 2006, [14] Tridgell, A., "rsync", April 2006,
<http://samba.anu.edu.au/rsync/> <http://samba.anu.edu.au/rsync/>
[14] Huston, G., Michaelson, G., "Validation of Route Origination in [15] Huston, G., Michaelson, G., "Validation of Route Origination in
BGP using the Resource Certificate PKI", draft-ietf-sidr-roa- BGP using the Resource Certificate PKI", draft-ietf-sidr-roa-
validation-01, October 2008. validation-03, August 2009.
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. 29 change blocks. 
58 lines changed or deleted 63 lines changed or added

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