< draft-ietf-sidr-arch-01.txt   draft-ietf-sidr-arch-02.txt >
Secure Inter-Domain Routing M. Lepinski Secure Inter-Domain Routing M. Lepinski
Working Group S. Kent Working Group S. Kent
Internet Draft R. Barnes Internet Draft R. Barnes
Intended status: Informational BBN Technologies Intended status: Informational BBN Technologies
Expires: January 2008 July 8, 2007 Expires: May 2008 November 18, 2007
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-01.txt draft-ietf-sidr-arch-02.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 January 8, 2007. This Internet-Draft will expire on May 18, 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 15 skipping to change at page 2, line 15
authorize autonomous systems to originate routes for specified IP authorize autonomous systems to originate routes for specified IP
address prefixes. The data objects that comprise the PKI, as well as address prefixes. The data objects that comprise the PKI, as well as
other signed objects necessary for secure routing, are stored and other signed objects necessary for secure routing, are stored and
disseminated through a distributed repository system. This document disseminated through a distributed repository system. This document
also describes at a high level how this architecture can be used to also describes at a high level how this architecture can be used to
add security features to common operations such as IP address space add security features to common operations such as IP address space
allocation and route filter construction. allocation and route filter construction.
Conventions used in this document Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
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..........................5 2.1. Role in the overall architecture..........................5
2.2. CA Certificates...........................................5 2.2. CA Certificates...........................................5
2.3. End-Entity (EE) Certificates..............................7 2.3. End-Entity (EE) Certificates..............................7
2.4. Trust Anchors.............................................7 2.4. Trust Anchors.............................................8
2.5. Default Trust Anchor Considerations.......................8 2.5. Default Trust Anchor Considerations.......................8
2.6. Representing Early-Registration Transfers (ERX)...........9 2.6. Representing Early-Registration Transfers (ERX)...........9
3. Route Origination Authorizations..............................10 3. Route Origination Authorizations..............................10
3.1. Role in the overall architecture.........................10 3.1. Role in the overall architecture.........................11
3.2. Syntax and semantics.....................................11 3.2. Syntax and semantics.....................................11
4. Repositories and Manifests....................................13 4. Repositories..................................................13
4.1. Role in the overall architecture.........................13 4.1. Role in the overall architecture.........................14
4.2. Contents and structure...................................13 4.2. Contents and structure...................................14
4.3. Manifests................................................15 4.3. Access protocols.........................................16
4.4. Access protocols.........................................16 4.4. Access control...........................................16
4.5. Access control...........................................17 5. Manifests.....................................................17
5. Local Cache Maintenance.......................................17 5.1. Manifest Syntax..........................................17
6. Common Operations.............................................18 5.2. Certificate Requests.....................................18
6.1. Certificate issuance.....................................18 5.3. Publication Repositories.................................19
6.2. ROA management...........................................19 5.4. Relying Party processing of a Manifest...................19
6.2.1. Single-homed subscribers (without portable allocations) 5.4.1. The nominal good case:..............................20
...........................................................20 5.4.2. The bad cases:......................................20
6.2.2. Multi-homed subscribers.............................20 5.4.3. Warning List........................................21
6.2.3. Portable allocations................................21 6. Local Cache Maintenance.......................................22
6.3. Route filter construction................................21 7. Common Operations.............................................23
7.1. Certificate issuance.....................................23
7. Security Considerations.......................................22 7.2. ROA management...........................................24
8. IANA Considerations...........................................23 7.2.1. Single-homed subscribers (without portable allocations)
9. Acknowledgments...............................................23 ...........................................................25
10. References...................................................24 7.2.2. Multi-homed subscribers.............................25
10.1. Normative References....................................24 7.2.3. Portable allocations................................26
10.2. Informative References..................................24 7.3. Route filter construction................................26
Author's Addresses...............................................25 8. Security Considerations.......................................27
Intellectual Property Statement..................................25 9. IANA Considerations...........................................27
Disclaimer of Validity...........................................26 10. Acknowledgments..............................................28
11. References...................................................29
11.1. Normative References....................................29
11.2. Informative References..................................29
Author's Addresses...............................................30
Intellectual Property Statement..................................30
Disclaimer of Validity...........................................31
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 encompasses three principle elements: architecture encompasses three principle elements:
. a public key infrastructure (PKI) . a public key infrastructure (PKI)
. digitally-signed routing objects to support routing security . digitally-signed routing objects to support routing security
. a distributed repository system to hold the PKI objects and the . a distributed repository system to hold the PKI objects and the
signed routing objects signed routing objects
The architecture described by this document supports, at a minimum, The architecture described by this document supports, at a minimum,
two aspects of routing security; it enables an entity to verifiably 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 assert that it is the legitimate holder of a set of IP addresses or a
set of Autonomous System (AS) numbers, and it allows the holder of IP set of Autonomous System (AS) numbers, and it allows the holder of IP
address space to explicitly and verifiably authorize one or more ASes address space to explicitly and verifiably authorize one or more ASes
to originate routes to that address space. In addition to these to originate routes to that address space. In addition to these
initial applications, the infrastructure defined by this architecture initial applications, the infrastructure defined by this architecture
also is intended to be able to support security protocols such as S- 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 BGP [8] or soBGP [9]. This architecture is applicable to the routing
both IPv4 and IPv6 datagrams. of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only
address families supported by this architecture. Thus, for example,
use of this architecture with MPLS labels is beyond the scope of this
document.
In order to facilitate deployment, the architecture takes advantage In order to facilitate deployment, the architecture takes advantage
of existing technologies and practices. The structure of the PKI of existing technologies and practices. The structure of the PKI
element of the architecture corresponds to the existing resource element of the architecture corresponds to the existing resource
allocation structure. Thus management of this PKI is a natural allocation structure. Thus management of this PKI is a natural
extension of the resource-management functions of the organizations extension of the resource-management functions of the organizations
that are already responsible for IP address and AS number resource that are already responsible for IP address and AS number resource
allocation. Likewise, existing resource allocation and revocation allocation. Likewise, existing resource allocation and revocation
practices have well-defined correspondents in this architecture. 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
skipping to change at page 8, line 26 skipping to change at page 8, line 34
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 2.5. Default Trust Anchor Considerations
IANA forms the root of the extant IP address space and AS number IANA forms the root of the extant IP address space and AS number
allocation hierarchy. Therefore, it is natural to consider a model in allocation hierarchy. Therefore, it is natural to consider a model in
which most relying parties have as their single trust anchor a self- which most relying parties have as their single trust anchor a self-
signed IANA certificate whose RFC 3779 extensions specify the signed IANA certificate whose RFC 3779 extensions specify the
entirety of the AS number and IP address and spaces. However, IANA entirety of the AS number and IP address spaces.
has not traditionally acted in an operational capacity as the root of
the resource allocation hierarchy, much less managed certificates and As an example of such model, consider the use of private IP address
their associated private keys. Therefore it is unclear whether IANA space (i.e., 10/8, 172.16/12, and 192.168/16 in IPv4 and FC00::/7 in
is willing to undertake this role as the default trust anchor for the IPv6). IANA could issue a CA certificate for these blocks of private
PKI. This has prompted the consideration of alternative approaches address space and then destroy the private key corresponding to the
for recommending trust anchors to potential relying parties. public key in the certificate. In this way, any relying party who
configured IANA as their sole trust anchor would automatically reject
any ROA containing private addresses, appropriate behavior with
regard to routing in the public Internet. On the other hand, such an
approach would not interfere with an organization that wishes to use
private address space in conjunction with BGP and this PKI
technology. Such an organization could configure its relying parties
with an additional, local trust anchor that issues certificates for
private addresses used within the organization. In this manner, BGP
advertisements for these private addresses would be accepted within
the organization but would be rejected if mistakenly sent outside the
private address space context in question.
In the DNSSEC context, IANA (as the root of the DNS) is already
experimenting with the operational procedures needed to digitally
sign the root zone. This is very much analogous to the role it would
play if it were to act as the default trust anchor for the RPKI, even
though DNSSEC does not make use of X.509 certificates. Nonetheless,
it is appropriate consider alternative default trust anchor models,
if IANA does not act in this capacity. This motivates the
consideration of alternative default trust anchor options for RPKI
relying parties.
Essentially all allocated IP address and AS number resources are sub- Essentially all allocated IP address and AS number resources are sub-
allocated by IANA to one of the five RIRs. Therefore, one could 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 consider a model in which the default trust anchors are a set of five
self-signed certificates, one for each RIR. There are two self-signed certificates, one for each RIR. There are two
difficulties that such an approach must overcome. difficulties that such an approach must overcome.
The first difficulty is that IANA retains authority for 44 /8 The first difficulty is that IANA retains authority for 44 /8
prefixes in IPv4 and a /26 prefix in IPv6. Therefore, any approach prefixes in IPv4 and a /26 prefix in IPv6. Therefore, any approach
that recommends the RIRs as default trust anchors will also require that recommends the RIRs as default trust anchors will also require
skipping to change at page 11, line 34 skipping to change at page 12, line 25
ROAIPAddressFamily ::= SEQUENCE { ROAIPAddressFamily ::= SEQUENCE {
addressFamily OCTET STRING (SIZE (2..3)), addressFamily OCTET STRING (SIZE (2..3)),
addresses SEQUENCE OF IPAddress } addresses SEQUENCE OF IPAddress }
-- Only two address families are allowed: IPv4 and IPv6 -- Only two address families are allowed: IPv4 and IPv6
IPAddress ::= BIT STRING IPAddress ::= BIT STRING
That is, the signed data within the ROA consists of a version number, That is, the signed data within the ROA consists of a version number,
the AS number that is being authorized, and a list of IP prefixes to the AS number that is being authorized, and a list of IP prefixes to
which the AS is authorized to originate routes. If the exactMatch which the AS is authorized to originate routes. If the exactMatch
flag is set to TRUE, then the AS is authorized to originate only flag is set to TRUE, then the AS is authorized to originate routes
routes for the exact prefix(es) indicated in the ROA. Otherwise, if only for the specific prefix(es) listed in the ROA. If the exactMatch
the exactMatch flag is set to FALSE, the AS is authorized to flag is set to FALSE, the AS is authorized to originate routes to the
originate routes to the prefix(es) in the ROA as well as any longer prefix(es) in the ROA as well as any longer (more specific) prefixes.
(more specific) prefixes.
Note that a ROA contains only a single AS number. Thus, in cases Note that a ROA contains only a single AS number. Thus, if an ISP has
where an ISP has multiple AS numbers that will be authorized to multiple AS numbers that will be authorized to originate routes to
originate routes to the prefix(es) in the ROA, an address space the prefix(es) in the ROA, an address space holder will need to issue
holder will need to issue multiple ROAs to authorize the ISP to multiple ROAs to authorize the ISP to originate routes from any of
originate routes from any of these ASes. these ASes.
A ROA is signed using the private key corresponding to the public key A ROA is signed using the private key corresponding to the public key
in an end-entity certificate in the PKI. In order for a ROA to be in an end-entity certificate in the PKI. In order for a ROA to be
valid, its corresponding end-entity (EE) certificate must be valid valid, its corresponding end-entity (EE) certificate must be valid
and the IP address prefixes of the ROA must exactly match the IP and the IP address prefixes of the ROA must exactly match the IP
address prefix(es) specified in the EE certificate's RFC 3779 address prefix(es) specified in the EE certificate's RFC 3779
extension. Therefore, the validity interval of the ROA is implicitly extension. Therefore, the validity interval of the ROA is implicitly
the validity interval of its corresponding certificate. A ROA is the validity interval of its corresponding certificate. A ROA is
revoked by revoking the corresponding EE certificate. There is no revoked by revoking the corresponding EE certificate. There is no
independent method of invoking a ROA. One might worry that this independent method of invoking a ROA. One might worry that this
revocation model could lead to long CRLs for the CA certification revocation model could lead to long CRLs for the CA certification
that is signing the EE certificates. However, routing announcements that is signing the EE certificates. However, routing announcements
on the public internet are generally quite long lived. Therefore, as on the public internet are generally quite long lived. Therefore, as
long as the EE certificates used to sign a ROA are given a validity long as the EE certificates used to verify a ROA are given a validity
interval of several months, the likelihood that many ROAs would need interval of several months, the likelihood that many ROAs would need
to revoked within time that is quite low. to revoked within time that is quite low.
--------- --------- --------- ---------
| RIR | | NIR | | RIR | | NIR |
| CA | | CA | | CA | | CA |
--------- --------- --------- ---------
| | | |
| | | |
| | | |
skipping to change at page 13, line 5 skipping to change at page 13, line 41
sources (and RIR and an NIR). It needs two CA certificates due to RFC sources (and RIR and an NIR). It needs two CA certificates due to RFC
3779 rules. 3779 rules.
Because each ROA is associated with a single end-entity certificate, Because each ROA is associated with a single end-entity certificate,
the set of IP prefixes contained in a ROA must be drawn from an the set of IP prefixes contained in a ROA must be drawn from an
allocation by a single source, i.e., a ROA cannot combine allocations allocation by a single source, i.e., a ROA cannot combine allocations
from multiple sources. Address space holders who have allocations from multiple sources. Address space holders who have allocations
from multiple sources, and who wish to authorize an AS to originate from multiple sources, and who wish to authorize an AS to originate
routes for these allocations, must issue multiple ROAs to the AS. routes for these allocations, must issue multiple ROAs to the AS.
4. Repositories and Manifests 4. Repositories
Initially, an LIR/ISP will make use of the resource PKI by acquiring 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 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 each AS is authorized to originate routes. To validate all ROAs, an
LIR/ISP needs to acquire all the certificates and CRLs. The primary LIR/ISP needs to acquire all the certificates and CRLs. The primary
function of the distributed repository system described here is to function of the distributed repository system described here is to
store these signed objects and to make them available for download by store these signed objects and to make them available for download by
LIRs/ISPs. The digital signatures on all objects in the repository LIRs/ISPs. The digital signatures on all objects in the repository
ensure that unauthorized modification of valid objects is detectable ensure that unauthorized modification of valid objects is detectable
by relying parties. Additionally, the repository system uses by relying parties. Additionally, the repository system uses
manifests (described below) to ensure that relying parties can detect manifests (see Section 5) to ensure that relying parties can detect
the deletion of valid objects and the insertion of out of date, valid the deletion of valid objects and the insertion of out of date, valid
signed objects. signed objects.
The repository system is also a point of enforcement for access The repository system is also a point of enforcement for access
controls for the signed objects stored in it, e.g., ensuring that controls for the signed objects stored in it, e.g., ensuring that
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 access controls prevents denial of by authorized parties. The use 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
skipping to change at page 15, line 13 skipping to change at page 16, line 5
directory containing certificates B and C. directory containing certificates B and C.
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. Manifests 4.3. Access protocols
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 17, line 12 skipping to change at page 16, line 39
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 [10] as Current efforts to implement a repository system use RSYNC [10] 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.5. Access control 4.4. Access control
In order to maintain the integrity of information in the repository, In order to maintain the integrity of information in the repository,
controls must be put in place to prevent addition, deletion, or controls must be put in place to prevent addition, deletion, or
modification of objects in the repository by unauthorized parties. modification of objects in the repository by unauthorized parties.
The identities of parties attempting to make such changes can be The identities of parties attempting to make such changes can be
authenticated through the relevant access protocols. Although authenticated through the relevant access protocols. Although
specific access control policies are subject to the local control of specific access control policies are subject to the local control of
repository operators, it is recommended that repositories allow only repository operators, it is recommended that repositories allow only
the issuers of signed objects to add, delete, or modify them. the issuers of signed objects to add, delete, or modify them.
Alternatively, it may be advantageous in the future to define a Alternatively, it may be advantageous in the future to define a
formal delegation mechanism to allow resource holders to authorize formal delegation mechanism to allow resource holders to authorize
other parties to act on their behalf, as suggested in Section 2.3 other parties to act on their behalf, as suggested in Section 2.3
above. above.
5. Local Cache Maintenance 5. Manifests
A manifest is a signed object listing of all of the signed objects
issued by an authority responsible for a publication 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, for which the
corresponding public key appears in an end-entity certificate. This
EE certificate, in turn, is signed by the CA in question. The EE
certificate private key may be used to sign one for more manifests.
If the private key is used to sign only a single manifest, then the
manifest can be revoked by revoking 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 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. If a private key
corresponding to a the public key in an EE certificate is used to
sign multiple (sequential) manifests for the CA in question, then
there is no revocation mechanism for these manifests. In such a case
a relying party will treat a manifest as valid until either (a) he
obtains a new manifest for the same CA having a higher
manifestNumber; or (b) the nextUpdate time is reached.
This EE certificate has an SIA extension access description field
with an accessMethod OID value of id-ad-signedobjectrepository where
the associated accessLocation references the publication point of the
manifest as an object URL.
5.1. Manifest Syntax
Syntactically, a manifest is a CMS signed-data object. As it is
intended that the manifest will be used in the context of assembling
a local copy of the entire RPKI repository, then the necessary
information to validate the certificate path for the manifest's
signature will be at hand for the relying party, thus duplication of
superior certificates and of CRLs in the CMS SignedData of the
manifest is not required. Only the EE certificate needed to directly
verify the signature on the manifest MUST be included in the CMS
SignedData; other certificates MUST NOT be included and CRLs MUST NOT
be included.
The CMS timestamp field MUST be included in the CMS SignedData.
The content of the CMS signed-data object is defined as follows:
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER,
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE OF (SIZE 0..MAX) 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. A manifest is
valid until the time specified in nextUpdate or until a manifest is
issued with a greater manifest number, whichever comes first. (Note
that when an EE certificate is used to sign only a single manifest,
whenever the authority issues the new manifest, the CA MUST also
issue a new CRL which includes the EE certificate corresponding to
the old manifest. The revoked EE certificate for the old manifest
will be removed from the CRL when it expires, thus this procedure
ought not result in significant CRLs growth.)
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. [12]
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.
5.2. Certificate Requests
A request for a CA certificate MUST include in the SIA of the request
an accessMethod OID of id-ad-manifest, where the associated
accessLocation refers to the subject's published manifest object as
an object URL. The manifest refers to the list of all products of
this CA certificate (except of course the manifest itself) that are
published at the publication point referred to by the SIA repository
pointer. This implies that the name of the manifest object is known
in advance, requiring the manifest object name to be a PURL, i.e., a
URL that is unchanged across manifest generation cycles.
Certificate requests for EE certificates MUST include in the SIA of
the request an access method OID of id-ad-manifest, where the
associated access location refers to the publication point of the
object verified using this EE certificate.
This implies that all certificate issuance requests where there is an
SIA extension present should include the id-ad-manifest access method
and the associated access location in the request, and the issuer
should honour these values in the issued certificate.
5.3. Publication Repositories
The RPKI publication directory model requires that every publication
point be associated with a CA, and be non-empty. Upon creation of the
publication repository, the CA MUST create an manifest. The manifest
will contain at least one entry, the CRL issued by the CA.
For a CA-issuer who is digitally signing documents and publishing
these signed objects, the EE certifate used to verify the signing of
an object would use the id-ad-manifest SIA access method to refer to
the signed object itself. If the signing format is CMS and the EE
certificate is attached to the signed document, then there is no
requirement to publish the EE cert in the publication repository of
the CA. On the other hand, of the CA wants to ensure that relying
parties can assure themselves that they have the complete collection
of signed objects then publishing the EE cert in the CA's publication
repository would be sufficient.
5.4. Relying Party processing of a Manifest
In this section, we describe the recommended behavior of a relying
party when processing a manifest. We begin by describing the
scenario where the relying party is able to successfully validate a
manifest the corresponds to the contents of the repository. We then
describe the recommended behavior in the various cases where the
relying party is unable to validate such a manifest.
5.4.1. The nominal good case:
A manifest is present in the repository, is current (i.e., the
current time is bounded by the manifest validity interval), and its
signature can be verified. All files listed in the manifest are found
in the repository and the hashes match. Any files in the repository
that are NOT listed in the manifest but that validate anyway SHOUD be
ignored (since they could be older instances of objects covered by
the manifest).
5.4.2. The bad cases:
1. No manifest is found in the repository at the publication point.
In this case, the relying party cannot use the manifest in question.
a. If the relying party has a prior manifest for this publication
point, he should use most recent, verified manifest for the
publication point in question and generate warning A.
b. If no prior manifest for this publication point is available,
there is no basis for detecting missing files, so just process
certificate, CRL, and ROA files and generate warning B.
2. The Signature on manifest fetched from the repository cannot be
verified (or the format is bad). In this case, the relying party
cannot use the manifest in question.
a. If the relying party has a prior manifest for this publication
point, he should use most recent, verified manifest for the
publication point in question and generate warning A.
b. If no prior manifest for this publication point is available,
there is no basis for detecting missing files, so he should just
process certificate, CRL, and ROA files and generate warning B.
3. The manifest is present and current and its signature can be
verified using a matching EE certificate
a. If the EE certificate is valid (current and not revoked) and
all files listed in the manifest are found in the repository and the
hashes match, then the relying party should use the manifest as in
Section 5.
b. If the EE certificate is valid and one or more files listed in
the manifest have hashes that do not match the files in the
repository with the indicates names, then the corresponding files are
likely to be old and intended to be replaced, and thus SHOULD NOT be
used. The relying party should generate Warning C.
c. If the EE certificate is valid and one or more files listed in
the manifest are missing, the relying party should Generate Warning
D.
d. If the EE certificate is expired. (this says the issuer of the
manifest screwed up!), the relying party should generate warning E,
but proceed with processing.
e. If the EE certificate is revoked but not expired, then the
manifest SHOULD be ignored. The relying party should generate warning
F and proceed with processing as if no manifest is available (since
the CA explicitly revoked the certificate for the manifest.)
4. The manifest is present but expired. If the signature cannot be
verified, treat as case 1/2. If the manifest signature can be
verified using a matching EE certificate:
a. If the EE certificate is valid (current and not revoked), then
generate warning A and proceed.
b. If the EE certificate is expired. (this says the issuer of the
manifest screwed up!), then generate warning G and proceed.
c. If EE certificate is revoked but not expired, the manifest
SHOULD be ignored. Generate warning F and proceed with processing as
if no manifest is available (since the CA explicitly revoked the
certificate for the manifest.)
5.4.3. Warning List
Warning A: A current manifest is not available for <pub point name>.
A older manifest for this publication point will be used, but there
may be undetected deletions from the publication point.
Warning B: No manifest is available for <pub point name>, and thus
there may have been undetected deletions from the publication point.
Warning C: The following files at <pub point name> appear to be
SUPERCEDED and are NOT being processed.
Warning D: The following files that should have been present in the
repository at <pub point name>, are missing <file list>. This
indicates an attack against this publication point, or the
repository, or an error by the publisher.
Warning E: EE certificate for manifest verification for <pub point
name> is expired. This indicates an error by the publisher, but
processing for this publication point will proceed using the current
manifest.
Warning F: The EE certificate for <pub point name> has been revoked.
The manifest will be ignored and all files found at this publication
point will be processed.
Warning G: EE certificate for manifest verification for <pub point
name> is expired. This indicates an error by the publisher, but
processing for this publication point will proceed using the most
recent (but expired) manifest.
6. Local Cache Maintenance
In order to utilize signed objects issued under this PKI (e.g. for In order to utilize signed objects issued under this PKI (e.g. for
route filter construction, see Section 6.3), a relying party must route filter construction, see Section 6.3), a relying party must
first obtain a local copy of the valid EE certificates for the PKI. first obtain a local copy of the valid EE certificates for the PKI.
To do so, the relying party performs the following steps: 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 registry system to obtain a copy of all certificates,
manifests and CRLs issued under the PKI. 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
skipping to change at page 18, line 18 skipping to change at page 23, line 7
for more details.) for more details.)
Note that when a relying party performs these operations regularly, Note that when a relying party performs these operations regularly,
it is more efficient for the relying party to request from the it is more efficient for the relying party to request from the
repository system only those objects that have changed since the repository system only those objects that have changed since the
relying party last updated its local cache. Note also that by relying party last updated its local cache. Note also that by
checking all issued objects against the appropriate manifest, the checking all issued objects against the appropriate manifest, the
relying party can be certain that it is not missing an updated relying party can be certain that it is not missing an updated
version of any object. version of any object.
6. 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 "portable" address space who entes a relationship subscriber with "portable" address space who entes a relationship
with an ISP will need to issue one or more ROAs identifying that ISP, with an ISP will need to issue one or more ROAs identifying that ISP,
in addition to conducting any other necessary technical or business in addition to conducting any other necessary technical or business
procedures. The current primary use of this infrastructure is for procedures. The current primary use of this infrastructure is for
route filter construction; using ROAs, route filters can be route filter construction; using ROAs, route filters can be
constructed in an automated fashion with high assurance that the constructed in an automated fashion with high assurance that the
holder of the advertised prefix has authorized the first-hop AS to holder of the advertised prefix has authorized the first-hop AS to
originate an advertised route. originate an advertised route.
6.1. Certificate issuance 7.1. Certificate issuance
There are several operational scenarios that require certificates to There are several operational scenarios that require certificates to
be issued. Any allocation that may be sub-allocated requires a CA be issued. Any allocation that may be sub-allocated requires a CA
certificate, e.g., so that certificates can be issued as necessary certificate, e.g., so that certificates can be issued as necessary
for the sub-allocations. Holders of "portable" address allocations for the sub-allocations. Holders of "portable" address allocations
also must have certificates, so that a ROA can be issued to each ISP also must have certificates, so that a ROA can be issued to each ISP
that is authorized to originate a route to the allocation (since the that is authorized to originate a route to the allocation (since the
allocation does not come from any ISP). Additionally, multi-homed allocation does not come from any ISP). Additionally, multi-homed
subscribers may require certificates for their allocations if they subscribers may require certificates for their allocations if they
intend to issue the ROAs for their allocations (see Section 6.2.2). intend to issue the ROAs for their allocations (see Section 6.2.2).
skipping to change at page 19, line 30 skipping to change at page 24, line 20
will be signed by different CAs, and cannot be combined. When a set will be signed by different CAs, and cannot be combined. When a set
of resources is no longer allocated to a resource holder, any of resources is no longer allocated to a resource holder, any
certificates attesting to such an allocation MUST be revoked. A certificates attesting to such an allocation MUST be revoked. A
resource holder SHOULD NOT to use the same public key in multiple CA resource holder SHOULD NOT to use the same public key in multiple CA
certificates that are issued by the same or differing authorities, as certificates that are issued by the same or differing authorities, as
reuse of a key pair complicates path construction. Note that since reuse of a key pair complicates path construction. Note that since
the subject's distinguished name is chosen by the issuer, a subject the subject's distinguished name is chosen by the issuer, a subject
who receives allocations from two sources generally will receive who receives allocations from two sources generally will receive
certificates with different subject names. certificates with different subject names.
6.2. ROA management 7.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 in an IP Address end-entity certificate containing that prefix in an IP Address
Delegation extension. He then uses the corresponding private key to Delegation extension. He then uses the corresponding private key to
sign a ROA containing the designated prefix and the AS number for the sign a ROA containing the designated prefix and the AS number for the
AS. The resource holder MAY include more than one prefix in the EE AS. The resource holder MAY include more than one prefix in the EE
certificate and corresponding ROA if desired. As a prerequisite, certificate and corresponding ROA if desired. As a prerequisite,
then, any address holder that issues ROAs for a prefix must have a then, any address holder that issues ROAs for a prefix must have a
resource certificate for an allocation containing that prefix. The resource certificate for an allocation containing that prefix. The
skipping to change at page 20, line 17 skipping to change at page 25, line 5
encapsulated in a CMS signed message [7]). 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.
6.2.1. Single-homed subscribers (without portable allocations) 7.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(es) it is using, since its ISP will already advertise a more prefix(es) it is using, since its ISP will already advertise a more
general prefix and route traffic for the subscriber's prefix as an general prefix and route traffic for the subscriber's prefix as an
internal function. Since no routes are originated specifically for internal function. Since no routes are originated specifically for
prefixes held by these subscribers, no ROAs need to be issued under prefixes held by these subscribers, no ROAs need to be issued under
their allocations; rather, the subscriber's ISP will issue any their allocations; rather, the subscriber's ISP will issue any
necessary ROAs for its more general prefixes under resource necessary ROAs for its more general prefixes under resource
certificates its own allocation. Thus, a single-homed subscriber with certificates its own allocation. Thus, a single-homed subscriber with
a non-portable allocation is not included in the RPKI, i.e., it does a non-portable allocation is not included in the RPKI, i.e., it does
not receive a CA certificate, nor issue EE certificates or ROAs. not receive a CA certificate, nor issue EE certificates or ROAs.
6.2.2. Multi-homed subscribers 7.2.2. Multi-homed subscribers
In order for multiple ASes to originate routers for prefixes held by In order for multiple ASes to originate routers for prefixes held by
a multi-homed subscriber, each AS must have a ROA that explicitly a multi-homed subscriber, each AS must have a ROA that explicitly
authorizes such route origination. There are two ways that this can authorizes such route origination. There are two ways that this can
be accomplished. be accomplished.
One option is for the multi-homed subscriber to obtain a CA One option is for the multi-homed subscriber to obtain a CA
certificate from the ISP who allocated the prefixes to the certificate from the ISP who allocated the prefixes to the
subscriber. The multi-homed subscriber can then create a ROA (and subscriber. The multi-homed subscriber can then create a ROA (and
associated end-entity certificate) that authorizes a second ISP to associated end-entity certificate) that authorizes a second ISP to
skipping to change at page 21, line 15 skipping to change at page 26, line 5
A second option is that the multi-homed subscriber can request that A second option is that the multi-homed subscriber can request that
the ISP that allocated the prefixes create a ROA that authorizes the the ISP that allocated the prefixes create a ROA that authorizes the
second ISP to originate routes to the subscriber's prefixes. (The ISP second ISP to originate routes to the subscriber's prefixes. (The ISP
also creates an EE certificate and ROA for its own advertisement of also creates an EE certificate and ROA for its own advertisement of
the subscriber prefix, as above.) This option does not require that the subscriber prefix, as above.) This option does not require that
the subscriber be issued a certificate or participate in ROA the subscriber be issued a certificate or participate in ROA
management. Therefore, this option is simpler for the subscriber, and management. Therefore, this option is simpler for the subscriber, and
is preferred if the option is supported by the ISP performing the is preferred if the option is supported by the ISP performing the
allocation. allocation.
6.2.3. Portable allocations 7.2.3. Portable allocations
A resource holder is said to have a portable (provider independent) A resource holder is said to have a portable (provider independent)
allocation if the resource holder received its allocation from a allocation if the resource holder received its allocation from a
regional or national registry. Because the prefixes represented in regional or national registry. Because the prefixes represented in
such allocations are not taken from an allocation held by an ISP, 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 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 holder of a portable allocation MUST authorize one or more ASes to
originate routes to these prefixes. Thus the resource holder MUST originate routes to these prefixes. Thus the resource holder MUST
generate one or more EE certificates and associated ROAs to enable generate one or more EE certificates and associated ROAs to enable
the AS(es) to originate routes for the prefix(es) in question. This the AS(es) to originate routes for the prefix(es) in question. This
ROA is required because none of the ISP's existing ROAs authorize it ROA is required because none of the ISP's existing ROAs authorize it
to originate routes to that portable allocation. to originate routes to that portable allocation.
6.3. Route filter construction 7.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 a local copy of all currently valid EE certificates, as 1. Obtain a local copy of all currently valid EE certificates, as
specified in Section 5. specified in Section 5.
skipping to change at page 22, line 25 skipping to change at page 27, line 17
downloaded and validated every time a route filter was constructed. downloaded and validated every time a route filter was constructed.
Instead, it will be more efficient for users of the infrastructure to Instead, it will be more efficient for users of the infrastructure to
initially download all of the signed objects and perform the initially download all of the signed objects and perform the
validation algorithm described above. Subsequently, a relying party validation algorithm described above. Subsequently, a relying party
need only perform incremental downloads and validations on a regular need only perform incremental downloads and validations on a regular
basis. A typical ISP using the infrastructure might have a daily basis. A typical ISP using the infrastructure might have a daily
schedule to download updates from the repository, upload any schedule to download updates from the repository, upload any
modifications it has made, and construct route filters. modifications it has made, and construct route filters.
It should be noted that the transition to 4-byte AS numbers (see RFC It should be noted that the transition to 4-byte AS numbers (see RFC
4893 [10]) weakens the security guarantees achieved by BGP speakers 4893 [11]) weakens the security guarantees achieved by BGP speakers
who do not support 4-byte AS numbers (referred to as OLD BGP who do not support 4-byte AS numbers (referred to as OLD BGP
speakers). RFC 4893 specifies that all 4-byte AS numbers (except speakers). RFC 4893 specifies that all 4-byte AS numbers (except
those whose first two bytes are entirely zero) be mapped to the 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 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 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 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 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 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 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 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 guarantee that it was originated by an authorized 4-byte AS number
(unless the route was propagated by an intermediate NEW BGP speaker (unless the route was propagated by an intermediate NEW BGP speaker
who performed route filtering as described above). who performed route filtering as described above).
7. Security Considerations 8. 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
8. IANA Considerations 9. 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
9. Acknowledgments 10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. The architecture described in this draft is derived from the
collective ideas and work of a large group of individuals. This work
would not have been possible without the intellectual contributions
of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of
APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Time
Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy
Bush of IIJ.
10. References Although we are indebted to everyone who has contributed to this
architecture, we would like to especially thank Rob Austein for the
concept of a manifest, and Geoff Huston for the concept of managing
object validity through single-use EE certificate key pairs.
10.1. Normative References 11. References
11.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] 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-
July 2007 (work in progress). 09, November 2007.
[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, Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-01,
July 2008 (work in progress). July 2008.
10.2. Informative References 11.2. Informative References
[8] [S-BGP] [8] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway
Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
Communications Vol. 18, No. 4, April 2000.
[9] [soBGP] [9] White, R., "soBGP", May 2005, <ftp://ftp-
eng.cisco.com/sobgp/index.html>
[10] [rsync] [10] Tridgell, A., "rsync", April 2006,
<http://samba.anu.edu.au/rsync/>
[11] Vohra, Q., and Chen, E., "BGP Support for Four-octet AS Number [11] Vohra, Q., and Chen, E., "BGP Support for Four-octet AS Number
Space", RFC 4893, May 2007. Space", RFC 4893, May 2007.
[12] Schaad, J., Kaliski, B., Housley, R., "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure for use in the Internet X.509
Public Key Infrastructure", RFC 4055, June 2005.
Author's Addresses Author's Addresses
Matt Lepinski Matt Lepinski
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
Email: mlepinski@bbn.com Email: mlepinski@bbn.com
Stephen Kent Stephen Kent
 End of changes. 39 change blocks. 
141 lines changed or deleted 371 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/