draft-ietf-sidr-arch-06.txt   draft-ietf-sidr-arch-07.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 March 9, 2009 Intended status: Informational July 13, 2009
Expires: September 9, 2009 Expires: January 13, 2010
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-06.txt draft-ietf-sidr-arch-07.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 September 9, 2009. This Internet-Draft will expire on September 13, 2009.
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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
support improved security of Internet routing. The foundation of this support improved security of Internet routing. The foundation of this
architecture is a public key infrastructure (PKI) that represents the architecture is a public key infrastructure (PKI) that represents the
allocation hierarchy of IP address space and Autonomous System allocation hierarchy of IP address space and Autonomous System
Numbers; and a distributed repository system for storing and Numbers; and a distributed repository system for storing and
disseminating the data objects that comprise the PKI, as well as disseminating the data objects that comprise the PKI, as well as
other signed objects necessary for improved routing security. As an other signed objects necessary for improved routing security. As an
initial application of this architecture, the document describes how initial application of this architecture, the document describes how
a legitimate holder of IP address space can explicitly and verifiably a legitimate holder of IP address space can explicitly and verifiably
authorize one or more ASes to originate routes to that address space. authorize one or more ASes to originate routes to that address space.
skipping to change at page 2, line 24 skipping to change at page 2, line 22
Such verifiable authorizations could be used, for example, to more Such verifiable authorizations could be used, for example, to more
securely construct BGP route filters. securely construct BGP route filters.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology...............................................4 1.1. Terminology...............................................4
2. PKI for Internet Number Resources..............................5 2. PKI for Internet Number Resources..............................5
2.1. Role in the overall architecture..........................5 2.1. Role in the overall architecture..........................5
2.2. CA Certificates...........................................6 2.2. CA Certificates...........................................6
2.3. End-Entity (EE) Certificates..............................8 2.3. End-Entity (EE) Certificates..............................7
2.4. Trust Anchors.............................................8 2.4. Trust Anchors.............................................8
2.5. Representing Early-Registration Transfers (ERX)...........9 3. Route Origination Authorizations...............................9
3. Route Origination Authorizations..............................10 3.1. Role in the overall architecture..........................9
3.1. Role in the overall architecture.........................11 3.2. Syntax and semantics......................................9
3.2. Syntax and semantics.....................................11 4. Repositories..................................................11
4. Repositories..................................................13 4.1. Role in the overall architecture.........................12
4.1. Role in the overall architecture.........................13 4.2. Contents and structure...................................12
4.2. Contents and structure...................................14 4.3. Access protocols.........................................14
4.3. Access protocols.........................................15 4.4. Access control...........................................14
4.4. Access control...........................................16 5. Manifests.....................................................15
5. Manifests.....................................................16 5.1. Syntax and semantics.....................................15
5.1. Syntax and semantics.....................................16 6. Local Cache Maintenance.......................................16
6. Local Cache Maintenance.......................................17 7. Common Operations.............................................17
7. Common Operations.............................................18 7.1. Certificate issuance.....................................17
7.1. Certificate issuance.....................................18 7.2. ROA management...........................................18
7.2. ROA management...........................................19 7.2.1. Single-homed subscribers (without provider independent
7.2.1. Single-homed subscribers (without portable allocations) addresses).................................................19
...........................................................20 7.2.2. Multi-homed subscribers (without provider independent
7.2.2. Multi-homed subscribers (without portable allocations)20 addresses).................................................19
7.2.3. Portable allocations................................21 7.2.3. Provider-Independent Address Space..................20
8. Security Considerations.......................................21 8. Security Considerations.......................................20
9. IANA Considerations...........................................21 9. IANA Considerations...........................................20
10. Acknowledgments..............................................22 10. Acknowledgments..............................................20
11. References...................................................23 11. References...................................................22
11.1. Normative References....................................23 11.1. Normative References....................................22
11.2. Informative References..................................23 11.2. Informative References..................................22
Authors' Addresses...............................................24 Authors' Addresses...............................................23
Pre-5378 Material Disclaimer.....................................24 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
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
skipping to change at page 5, line 19 skipping to change at page 5, line 19
within that block, decisions about inter-domain routing are within that block, decisions about inter-domain routing are
inherently based on knowledge of the allocation of the IP address inherently based on knowledge of the allocation of the IP address
space. Thus, a basic function of this architecture is to provide space. Thus, a basic function of this architecture is to provide
cryptographically verifiable attestations as to these allocations. In cryptographically verifiable attestations as to these allocations. In
current practice, the allocation of IP addresses is hierarchic. The current practice, the allocation of IP addresses is hierarchic. The
root of the hierarchy is IANA. Below IANA are five Regional Internet root of the hierarchy is IANA. Below IANA are five Regional Internet
Registries (RIRs), each of which manages address and AS number Registries (RIRs), each of which manages address and AS number
allocation within a defined geopolitical region. In some regions the allocation within a defined geopolitical region. In some regions the
third tier of the hierarchy includes National Internet Registries third tier of the hierarchy includes National Internet Registries
(NIRs) as well as Local Internet Registries (LIRs) and subscribers (NIRs) as well as Local Internet Registries (LIRs) and subscribers
with so-called "portable" (provider-independent) allocations. (The with so-called provider-independent ("portable") allocations. (The
term LIR is used in some regions to refer to what other regions term LIR is used in some regions to refer to what other regions
define as an ISP. Throughout the rest of this document we will use define as an ISP. Throughout the rest of this document we will use
the term LIR/ISP to simplify references to these entities.) In other the term LIR/ISP to simplify references to these entities.) In other
regions the third tier consists only of LIRs/ISPs and subscribers regions the third tier consists only of LIRs/ISPs and subscribers
with portable allocations. with provider-independent allocations.
In general, the holder of a block of IP address space may sub- In general, the holder of a block of IP address space may sub-
allocate portions of that block, either to itself (e.g., to a allocate portions of that block, either to itself (e.g., to a
particular unit of the same organization), or to another particular unit of the same organization), or to another
organization, subject to contractual constraints established by the organization, subject to contractual constraints established by the
registries. Because of this structure, IP address allocations can be registries. Because of this structure, IP address allocations can be
described naturally by a hierarchic public-key infrastructure, in described naturally by a hierarchic public-key infrastructure, in
which each certificate attests to an allocation of IP addresses, and which each certificate attests to an allocation of IP addresses, and
issuance of subordinate certificates corresponds to sub-allocation of issuance of subordinate certificates corresponds to sub-allocation of
IP addresses. The above reasoning holds true for AS number resources IP addresses. The above reasoning holds true for AS number resources
skipping to change at page 6, line 39 skipping to change at page 6, line 39
2.2. CA Certificates 2.2. CA Certificates
Any resource holder who is authorized to sub-allocate these resources Any resource holder who is authorized to sub-allocate these resources
must be able to issue Resource Certificates to correspond to these must be able to issue Resource Certificates to correspond to these
sub-allocations. Thus, for example, CA certificates will be sub-allocations. Thus, for example, CA certificates will be
associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. A CA associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. A CA
certificate also is required to enable a resource holder to issue certificate also is required to enable a resource holder to issue
ROAs, because it must issue the corresponding end-entity certificate ROAs, because it must issue the corresponding end-entity certificate
used to validate each ROA. Thus some entities that do not sub- used to validate each ROA. Thus some entities that do not sub-
allocate their resources also will need to have CA certificates for allocate their resources also will need to have CA certificates for
their allocations, e.g., a multi-homed subscriber with a portable their allocations, e.g., a multi-homed subscriber with a provider-
allocation, to enable them to issue ROAs. (A subscriber who is not independent allocation, to enable them to issue ROAs. (A subscriber
multi-homed, whose allocation comes from an LIR/ISP, and who has not who is not multi-homed, whose allocation comes from an LIR/ISP, and
moved to a different LIR/ISP, need not be represented in the PKI. who has not moved to a different LIR/ISP, need not be represented in
Moreover, a multi-homed subscriber with an allocation from an LIR/ISP the PKI. Moreover, a multi-homed subscriber with an allocation from
may or may not need to be explicitly represented, as discussed in an LIR/ISP may or may not need to be explicitly represented, as
Section 7.2.2) discussed in Section 7.2.2)
Unlike in most PKIs, the distinguished name of the subject in a CA Unlike in most PKIs, the distinguished name of the subject in a CA
certificate is chosen by the certificate issuer. If the subject of a certificate is chosen by the certificate issuer. The subject's
certificate is an RIR or IANA, then the distinguished name of the distinguished name must not attempt to convey the identity of the
subject will be chosen to convey the identity of the registry and subject in a descriptive fashion, and must be unique among all
should consist of (a subset of) the following attributes: country, certificates issued by a given authority. The subject's distinguished
organization, organizational unit, and common name. For example, an name must include the common name attribute and may additionally
appropriate subject name for the APNIC RIR might be: include the serial attribute.
. Country: AU
. Organization: Asia Pacific Network Information Centre
. Common Name: APNIC Resource Certification Authority
If the subject of a certificate is not an RIR or IANA, (e.g.,
the subject is a NIR, or LIR/ISP) the distinguished name must not
attempt to convey the identity of the subject in a descriptive
fashion. The subject's distinguished name must be unique among all
certificates issued by a given authority. It is RECOMMENDED that the
distinguished name consist of two attributes: common name and serial.
The common name should be a string that is consistent among all
certificates issued by a given authority to a given subject (this
allows an authority to correlate certificates issued to the same
subject). The serial attribute should be a string that changes each
time the certificate is re-issued (e.g. key roll-over), which
facilitates the uniqueness of distinguished names across all
certificates issued by a given authority.
In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP, In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP,
is not in the business of verifying the legal right of the subject to is not in the business of verifying the legal right of the subject to
assert a particular identity. Therefore, selecting a distinguished assert a particular identity. Therefore, selecting a distinguished
name that does not convey the identity of the subject in a name that does not convey the identity of the subject in a
descriptive fashion minimizes the opportunity for the subject to descriptive fashion minimizes the opportunity for the subject to
misuse the certificate to assert an identity, and thus minimizes the misuse the certificate to assert an identity, and thus minimizes the
legal liability of the issuer. Since all CA certificates are issued legal liability of the issuer. Since all CA certificates are issued
to subjects with whom the issuer has an existing relationship, it is to subjects with whom the issuer has an existing relationship, it is
recommended that the issuer select a subject name that enables the recommended that the issuer select a subject name that enables the
skipping to change at page 9, line 28 skipping to change at page 9, line 7
Note that a RP who elects to create and manage its own set of trust Note that a RP who elects to create and manage its own set of trust
anchors may fail to detect allocation errors that arise under such anchors may fail to detect allocation errors that arise under such
circumstances, but the resulting vulnerability is local to the RP. circumstances, but the resulting vulnerability is local to the RP.
It is expected that some parties within the extant IP address space It is expected that some parties within the extant IP address space
and AS number allocation hierarchy may wish to publish trust anchor and AS number allocation hierarchy may wish to publish trust anchor
material for possible use by relying parties. A standard profile for material for possible use by relying parties. A standard profile for
the publication of trust anchor material for this public key the publication of trust anchor material for this public key
infrastructure can be found in [9]. infrastructure can be found in [9].
2.5. Representing Early-Registration Transfers (ERX)
Currently, IANA allocates IPv4 address space to the RIRs at the level
of /8 prefixes. However, there exist allocations that cross these RIR
boundaries. For example, A LACNIC customer may have an allocation
that falls within a /8 prefix administered by ARIN. Therefore, the
resource PKI must be able to represent such transfers from one RIR to
another in a manner that permits the validation of certificates with
RFC 3779 extensions.
+-------------------------------+
| |
| LACNIC Administrative |
| Boundary |
| |
+--------+ | +--------+ | +--------+
| ARIN | | | LACNIC | | | RIPE |
| ROOT | | | ROOT | | | ROOT |
+--------+ | +--------+ | +--------+
\ | | /
------------ ------------
| \ / |
| +--------+ +--------+ |
| | LACNIC | | LACNIC | |
| | CA | | CA | |
| +--------+ +--------+ |
| |
+-------------------------------+
FIGURE 1: Representing EXR
To represent such transfers, RIRs will need to manage multiple CA
certificates, each with distinct public (and corresponding private)
keys. Each RIR will have a single "root" certificate (e.g., a self-
signed certificate or a certificate signed by IANA, see Section 2.5),
plus one additional CA certificate for each RIR from which it
receives a transfer. Each of these additional CA certificates will be
issued under the "root" certificate of the RIR from which the
transfer is received. This means that although the certificate is
bound to the RIR that receives the transfer, for the purposes of
certificate path construction and validation, it does not appear
under that RIR's "root" certificate (see Figure 1).
3. Route Origination Authorizations 3. Route Origination Authorizations
The information on IP address allocation provided by the PKI is not, The information on IP address allocation provided by the PKI is not,
in itself, sufficient to guide routing decisions. In particular, BGP in itself, sufficient to guide routing decisions. In particular, BGP
is based on the assumption that the AS that originates routes for a is based on the assumption that the AS that originates routes for a
particular prefix is authorized to do so by the holder of that prefix particular prefix is authorized to do so by the holder of that prefix
(or an address block encompassing the prefix); the PKI contains no (or an address block encompassing the prefix); the PKI contains no
information about these authorizations. A Route Origination information about these authorizations. A Route Origination
Authorization (ROA) makes such authorization explicit, allowing a Authorization (ROA) makes such authorization explicit, allowing a
holder of IP address space to create an object that explicitly and holder of IP address space to create an object that explicitly and
skipping to change at page 18, line 18 skipping to change at page 17, line 10
choose to perform these operations on a daily schedule. Note also choose to perform these operations on a daily schedule. Note also
that by checking all issued objects against the appropriate manifest, that by checking all issued objects against the appropriate manifest,
the relying party can be certain that it is not missing an updated the relying party can be certain that it is not missing an updated
version of any object. 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 "portable" address space who enters a relationship subscriber with provider-independent ("portable") address space who
with an ISP will need to issue one or more ROAs identifying that ISP, enters a relationship with an ISP will need to issue one or more ROAs
in addition to conducting any other necessary technical or business identifying that ISP, in addition to conducting any other necessary
procedures. The current primary use of this infrastructure is for technical or business procedures. The current primary use of this
route filter construction; using ROAs, route filters can be infrastructure is for route filter construction; using ROAs, route
constructed in an automated fashion with high assurance that the filters can be constructed in an automated fashion with high
holder of the advertised prefix has authorized the origin AS to assurance that the holder of the advertised prefix has authorized the
originate an advertised route. origin AS to originate an advertised route.
7.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" IP address space for the sub-allocations. Holders of provider-independent IP address
allocations also must have certificates, so that a ROA can be issued space allocations also must have certificates, so that a ROA can be
to each ISP that is authorized to originate a route to the allocation issued to each ISP that is authorized to originate a route to the
(since the allocation does not come from any ISP). Additionally, allocation (since the allocation does not come from any ISP).
multi-homed subscribers may require certificates for their Additionally, multi-homed subscribers may require certificates for
allocations if they intend to issue the ROAs for their allocations their allocations if they intend to issue the ROAs for their
(see Section 7.2.2). Other resource holders need not be issued CA allocations (see Section 7.2.2). Other resource holders need not be
certificates within the PKI. issued CA certificates within the PKI.
In the long run, a resource holder will not request resource In the long run, a resource holder will not request resource
certificates, but rather receive a certificate as a side effect of certificates, but rather receive a certificate as a side effect of
the allocation process for the resource. However, initial deployment the allocation process for the resource. However, initial deployment
of the RPKI will entail issuance of certificates to existing resource of the RPKI will entail issuance of certificates to existing resource
holders as an explicit event. Note that in all cases, the authority holders as an explicit event. Note that in all cases, the authority
issuing a CA certificate will be the entity who allocates resources issuing a CA certificate will be the entity who allocates resources
to the subject. This differs from most PKIs in which a subject can to the subject. This differs from most PKIs in which a subject can
request a certificate from any certification authority. request a certificate from any certification authority.
skipping to change at page 20, line 13 skipping to change at page 19, 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.
7.2.1. Single-homed subscribers (without portable allocations) 7.2.1. Single-homed subscribers (without provider independent addresses)
In BGP, a single-homed subscriber with a non-portable allocation does In BGP, a single-homed subscriber with provider allocated (non-
not need to explicitly authorize routes to be originated for the portable) address space does not need to explicitly authorize routes
prefix(es) it is using, since its ISP will already advertise a more to be originated for the prefix(es) it is using, since its ISP will
general prefix and route traffic for the subscriber's prefix as an already advertise a more general prefix and route traffic for the
internal function. Since no routes are originated specifically for subscriber's prefix as an internal function. Since no routes are
prefixes held by these subscribers, no ROAs need to be issued under originated specifically for prefixes held by these subscribers, no
their allocations; rather, the subscriber's ISP will issue any ROAs need to be issued under their allocations; rather, the
necessary ROAs for its more general prefixes under resource subscriber's ISP will issue any necessary ROAs for its more general
certificates from its own allocation. Thus, a single-homed subscriber prefixes under resource certificates from its own allocation. Thus, a
with a non-portable allocation is not included in the RPKI, i.e., it single-homed subscriber with an IP address allocation from his
does not receive a CA certificate, nor issue EE certificates or ROAs. service provider is not included in the RPKI, i.e., it does not
receive a CA certificate, nor issue EE certificates or ROAs.
7.2.2. Multi-homed subscribers (without portable allocations) 7.2.2. Multi-homed subscribers (without provider independent addresses)
Here we consider a subscriber who receives IP address space from a Here we consider a subscriber who receives IP address space from a
primary ISP (i.e., the IP addresses used by the subscriber are a primary ISP (i.e., the IP addresses used by the subscriber are a
subset of ISP A's IP address space allocation) and receives redundant subset of ISP A's IP address space allocation) and receives redundant
upstream connectivity from the primary ISP, as well as one or more upstream connectivity from the primary ISP, as well as one or more
secondary ISPs. The preferred option for such a multi-homed secondary ISPs. The preferred option for such a multi-homed
subscribers is for the subscriber to obtain an AS number (from an RIR subscribers is for the subscriber to obtain an AS number (from an RIR
or NIR) and run BGP with each of its upstream providers. In such a or NIR) and run BGP with each of its upstream providers. In such a
case, there are two ways for ROA management to be handled. The first case, there are two ways for ROA management to be handled. The first
is that the primary ISP issues a CA certificate to the subscriber, is that the primary ISP issues a CA certificate to the subscriber,
skipping to change at page 21, line 9 skipping to change at page 20, line 5
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 subscribers 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. Portable allocations 7.2.3. Provider-Independent Address Space
A resource holder is said to have a portable (provider independent) A resource holder is said to have provider-independent (portable)
allocation if the resource holder received its allocation from a RIR address space if the resource holder received its allocation directly
or NIR. Because the prefixes represented in such allocations are not from a RIR or NIR. Because the prefixes represented in such
taken from an allocation held by an ISP, there is no ISP that holds allocations are not taken from an allocation held by an ISP, there is
and advertises a more general prefix. A holder of a portable IP no ISP that holds and advertises a more general prefix. A holder of a
address space allocation MUST authorize one or more ASes to originate portable IP address space allocation MUST authorize one or more ASes
routes to these prefixes. Thus the resource holder MUST generate one to originate routes to these prefixes. Thus the resource holder MUST
or more EE certificates and associated ROAs to enable the AS(es) to generate one or more EE certificates and associated ROAs to enable
originate routes for the prefix(es) in question. This ROA is required the AS(es) to originate routes for the prefix(es) in question. This
because none of the ISP's existing ROAs authorize it to originate ROA is required because none of the ISP's existing ROAs authorize it
routes to that portable allocation. to originate routes to the subscriber's provider-idependent
allocation.
8. 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
 End of changes. 19 change blocks. 
156 lines changed or deleted 95 lines changed or added

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