< draft-ietf-sidr-arch-04.txt   draft-ietf-sidr-arch-05.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 November 3, 2008 Intended status: Informational March 9, 2009
Expires: May 3, 2009 Expires: September 9, 2009
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-04.txt draft-ietf-sidr-arch-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with the
any applicable patent or other IPR claims of which he or she is provisions of BCP 78 and BCP 79.
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
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 3, 2008. This Internet-Draft will expire on September 9, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 holder of IP address space can explicitly and verifiably authorize a legitimate holder of IP address space can explicitly and verifiably
one or more ASes to originate routes to that address space. Such authorize one or more ASes to originate routes to that address space.
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
2. PKI for Internet Number Resources..............................4 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...........................................5 2.2. CA Certificates...........................................6
2.3. End-Entity (EE) Certificates..............................7 2.3. End-Entity (EE) Certificates..............................7
2.4. Trust Anchors.............................................8 2.4. Trust Anchors.............................................8
2.5. Default Trust Anchor Considerations.......................8 2.5. Default Trust Anchor Considerations.....Error! Bookmark not
2.6. Representing Early-Registration Transfers (ERX)..........10 defined.
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.........................11 3.1. Role in the overall architecture.........................10
3.2. Syntax and semantics.....................................11 3.2. Syntax and semantics.....................................11
4. Repositories..................................................13 4. Repositories..................................................12
4.1. Role in the overall architecture.........................14 4.1. Role in the overall architecture.........................13
4.2. Contents and structure...................................14 4.2. Contents and structure...................................13
4.3. Access protocols.........................................16 4.3. Access protocols.........................................15
4.4. Access control...........................................16 4.4. Access control...........................................15
5. Manifests.....................................................17 5. Manifests.....................................................16
5.1. Syntax and semantics.....................................17 5.1. Syntax and semantics.....................................16
6. Local Cache Maintenance.......................................18 6. Local Cache Maintenance.......................................17
7. Common Operations.............................................18 7. Common Operations.............................................18
7.1. Certificate issuance.....................................19 7.1. Certificate issuance.....................................18
7.2. ROA management...........................................20 7.2. ROA management...........................................19
7.2.1. Single-homed subscribers (without portable allocations) 7.2.1. Single-homed subscribers (without portable allocations)
...........................................................20 ...........................................................20
7.2.2. Multi-homed subscribers.............................21 7.2.2. Multi-homed subscribers.............................20
7.2.3. Portable allocations................................21 7.2.3. Portable allocations................................21
7.3. Route filter construction................................22 7.3. Route filter construction......Error! Bookmark not defined.
8. Security Considerations.......................................23 8. Security Considerations.......................................21
9. IANA Considerations...........................................24 9. IANA Considerations...........................................21
10. Acknowledgments..............................................24 10. Acknowledgments..............................................21
11. References...................................................25 11. References...................................................23
11.1. Normative References....................................25 11.1. Normative References....................................23
11.2. Informative References..................................25 11.2. Informative References..................................23
Authors' Addresses...............................................26 Authors' Addresses...............................................24
Intellectual Property Statement..................................26 Intellectual Property Statement..................................24
Disclaimer of Validity...........................................27 Disclaimer of Validity.................Error! Bookmark not defined.
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 enables an entity to The architecture described by this document enables an entity to
verifiably assert that it is the legitimate holder of a set of IP verifiably assert that it is the legitimate holder of a set of IP
addresses or a set of Autonomous System (AS) numbers. As an initial addresses or a set of Autonomous System (AS) numbers. As an initial
application of this architecture, the document describes how a holder application of this architecture, the document describes how a
of IP address space can explicitly and verifiably authorize one or legitimate holder of IP address space can explicitly and verifiably
more ASes to originate routes to that address space. Such verifiable authorize one or more ASes to originate routes to that address space.
authorizations could be used, for example, to more securely construct Such verifiable authorizations could be used, for example, to more
BGP route filters. In addition to this initial application, the securely construct BGP route filters. In addition to this initial
infrastructure defined by this architecture also is intended to application, the infrastructure defined by this architecture also is
provide future support for security protocols such as S-BGP [10] or intended to provide future support for security protocols such as S-
soBGP [11]. This architecture is applicable to the routing of both BGP [11] or soBGP [12]. This architecture is applicable to the
IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only address routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently
families supported by this architecture. Thus, for example, use of the only address families supported by this architecture. Thus, for
this architecture with MPLS labels is beyond the scope of this example, use of this architecture with MPLS labels is beyond the
document. scope of this document.
In order to facilitate deployment, the architecture takes advantage In order to facilitate deployment, the architecture takes advantage
of existing technologies and practices. The structure of the PKI of existing technologies and practices. The structure of the PKI
element of the architecture corresponds to the existing resource element of the architecture corresponds to the existing resource
allocation structure. Thus management of this PKI is a natural allocation structure. Thus management of this PKI is a natural
extension of the resource-management functions of the organizations extension of the resource-management functions of the organizations
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. Note
ease implementation, existing IETF standards are used wherever that while the initial focus of this architecture is routing security
applications, the PKI described in this document could be used to
support other applications that make use of attestations of IP
address or AS number resource holdings.
To ease implementation, existing IETF standards are used wherever
possible; for example, extensive use is made of the X.509 certificate possible; for example, extensive use is made of the X.509 certificate
profile defined by PKIX [3] and the extensions for IP Addresses and profile defined by PKIX [3] and the extensions for IP Addresses and
AS numbers representation defined in RFC 3779 [5]. Also CMS [4] is AS numbers representation defined in RFC 3779 [5]. Also CMS [4] is
used as the syntax for the newly-defined signed objects required by used as the syntax for the newly-defined signed objects required by
this infrastructure. this infrastructure.
As noted above, the infrastructure is comprised of three main As noted above, the architecture is comprised of three main
components: an X.509 PKI in which certificates attest to holdings of components: an X.509 PKI in which certificates attest to holdings of
IP address space and AS numbers; non-certificate/CRL signed objects IP address space and AS numbers; non-certificate/CRL signed objects
(including route origination authorizations and manifests) used by (including route origination authorizations and manifests) used by
the infrastructure; and a distributed repository system that makes the infrastructure; and a distributed repository system that makes
all of these signed objects available for use by ISPs in making all of these signed objects available for use by ISPs in making
routing decisions. These three basic components enable several routing decisions. These three basic components enable several
security functions; this document describes how they can be used to security functions; this document describes how they can be used to
improve route filter generation, and to perform several other common improve route filter generation, and to perform several other common
operations in such a way as to make them cryptographically operations in such a way as to make them cryptographically
verifiable. verifiable.
1.1. Terminology 1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [3], and "X.509 and Certificate Revocation List (CRL) Profile" [3], and "X.509
Extensions for IP Addresses and AS Identifiers" [5]. Extensions for IP Addresses and AS Identifiers" [5].
Throughout this document we use the terms "address space holder" or
"holder of IP address space" interchangeably to refer to a legitimate
holder of IP address space who has received this address space
through the standard IP address allocation hierarchy. That is, the
address space holder has either directly received the address space
as an allocation from a Regional Internet Registry (RIR) or IANA; or
else the address space holder has received the address space as a
sub-allocation from a National Internet Registry (NIR) or Local
Internet Registry (LIR). We use the term "resource holder" to refer
to a legitimate holder of either IP address or AS number resources.
Throughout this document we use the terms "registry" and ISP to refer
to an entity that has an IP address space and/or AS number allocation
that it is permitted to sub-allocate. We use the term "subscriber" to
refer to an entity (e.g., an enterprise) that receives an IP address
space and/or AS number allocation, but does not sub-allocate its
resources.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
2. PKI for Internet Number Resources 2. PKI for Internet Number Resources
Because the holder of a block IP address space is entitled to define Because the holder of a block IP address space is entitled to define
the topological destination of IP datagrams whose destinations fall the topological destination of IP datagrams whose destinations fall
within that block, decisions about inter-domain routing are within that block, decisions about inter-domain routing are
inherently based on knowledge the allocation of the IP address space. inherently based on knowledge of the allocation of the IP address
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 address 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 and 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 "portable" (provider-independent) 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 portable allocations.
In general, the holder of a set of IP addresses may sub-allocate In general, the holder of a block of IP address space may sub-
portions of that set, either to itself (e.g., to a particular unit of allocate portions of that block, either to itself (e.g., to a
the same organization), or to another organization, subject to particular unit of the same organization), or to another
contractual constraints established by the registries. Because of organization, subject to contractual constraints established by the
this structure, IP address allocations can be described naturally by registries. Because of this structure, IP address allocations can be
a hierarchic public-key infrastructure, in which each certificate described naturally by a hierarchic public-key infrastructure, in
attests to an allocation of IP addresses, and issuance of subordinate which each certificate attests to an allocation of IP addresses, and
certificates corresponds to sub-allocation of IP addresses. The issuance of subordinate certificates corresponds to sub-allocation of
above reasoning holds true for AS number resources as well, with the IP addresses. The above reasoning holds true for AS number resources
difference that, by convention, AS numbers may not be sub-allocated as well, with the difference that, by convention, AS numbers may not
except by regional or national registries. Thus allocations of both be sub-allocated except by RIRs or NIRs. Thus allocations of both IP
IP addresses and AS numbers can be expressed by the same PKI. Such a addresses and AS numbers can be expressed by the same PKI. Such a
PKI is a central component of this architecture. PKI is a central component of this architecture.
2.1. Role in the overall architecture 2.1. Role in the overall architecture
Certificates in this PKI are called Resource Certificates, and Certificates in this PKI are called Resource Certificates, and
conform to the certificate profile for such certificates [6]. conform to the certificate profile for such certificates [6].
Resource certificates attest to the allocation by the (certificate) Resource certificates attest to the allocation by the (certificate)
issuer of IP addresses or AS numbers to the subject. They do this by issuer of IP addresses or AS numbers to the subject. They do this by
binding the public key contained in the Resource Certificate to the binding the public key contained in the Resource Certificate to the
IP addresses or AS numbers included in the certificate's IP Address IP addresses or AS numbers included in the certificate's IP Address
Delegation or AS Identifier Delegation Extensions, respectively, as Delegation or AS Identifier Delegation Extensions, respectively, as
defined in RFC 3779 [5]. defined in RFC 3779 [5].
An important property of this PKI is that certificates do not attest An important property of this PKI is that certificates do not attest
to the identity of the subject. Therefore, the subject names used in to the identity of the subject. Therefore, the subject names used in
certificates are not intended to be ''descriptive.'' That is, this certificates are not intended to be "descriptive." That is, this PKI
PKI is intended to provide authorization, but not authentication. is intended to provide authorization, but not authentication. This is
This is in contrast to most PKIs where the issuer ensures that the in contrast to most PKIs where the issuer ensures that the
descriptive subject name in a certificate is properly associated with descriptive subject name in a certificate is properly associated with
the entity that holds the private key corresponding to the public key the entity that holds the private key corresponding to the public key
in the certificate. Because issuers need not verify the right of an in the certificate. Because issuers need not verify the right of an
entity to use a subject name in a certificate, they avoid the costs entity to use a subject name in a certificate, they avoid the costs
and liabilities of such verification. This makes it easier for these and liabilities of such verification. This makes it easier for these
entities to take on the additional role of CA. entities to take on the additional role of Certificate Authority
(CA).
Most of the certificates in the PKI assert the basic facts on which Most of the certificates in the PKI assert the basic facts on which
the rest of the infrastructure operates. CA certificates within the the rest of the infrastructure operates. CA certificates within the
PKI attest to IP address space and AS number holdings. End-entity PKI attest to IP address space and AS number holdings. End-entity
(EE) certificates are issued by resource holder CAs to delegate the (EE) certificates are issued by resource holder CAs to delegate the
authority attested by their allocation certificates. The primary use authority attested by their allocation certificates. The primary use
for EE certificates is the validation of Route Origination for EE certificates is the validation of Route Origination
Authorizations (ROAs). Additionally, signed objects called manifests Authorizations (ROAs). Additionally, signed objects called manifests
will be used to help ensure the integrity of the repository system, will be used to help ensure the integrity of the repository system,
and the signature on each manifest will be verified via an EE and the signature on each manifest will be verified via an EE
certificate. certificate.
2.2. CA Certificates 2.2. CA Certificates
Any holder of Internet resources who is authorized to sub-allocate Any resource holder who is authorized to sub-allocate these resources
them must be able to issue Resource Certificates to correspond to must be able to issue Resource Certificates to correspond to these
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 subscribers also will need to used to validate each ROA. Thus some entities that do not sub-
have CA certificates for their allocations, e.g., subscribers with allocate their resources also will need to have CA certificates for
portable allocations, to enable them to issue ROAs. (A subscriber who their allocations, e.g., a multi-homed subscriber with a portable
is not multi-homed, whose allocation comes from an LIR/ISP, and who allocation, to enable them to issue ROAs. (A subscriber who is not
has not moved to a different LIR/ISP, need not be represented in the multi-homed, whose allocation comes from an LIR/ISP, and who has not
PKI. Moreover, a multi-homed subscriber with an allocation from an moved to a different LIR/ISP, need not be represented in the PKI.
LIR/ISP may or may not need to be explicitly represented, as Moreover, a multi-homed subscriber with an allocation from an LIR/ISP
discussed in Section 6.2.2) may or may not need to be explicitly represented, as 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. If the subject of a
certificate is an RIR or IANA, then the distinguished name of the certificate is an RIR or IANA, then the distinguished name of the
subject will be chosen to convey the identity of the registry and subject will be chosen to convey the identity of the registry and
should consist of (a subset of) the following attributes: country, should consist of (a subset of) the following attributes: country,
organization, organizational unit, and common name. For example, an organization, organizational unit, and common name. For example, an
appropriate subject name for the APNIC RIR might be: appropriate subject name for the APNIC RIR might be:
. Country: AU . Country: AU
. Organization: Asia Pacific Network Information Centre . Organization: Asia Pacific Network Information Centre
. Common Name: APNIC Resource Certification Authority . Common Name: APNIC Resource Certification Authority
If the subject of a certificate is not an RIR or IANA, (e.g., the If the subject of a certificate is not an RIR or IANA, (e.g.,
subject is a NIR, or LIR/ISP) the distinguished name MUST consist the subject is a NIR, or LIR/ISP) the distinguished name must not
only of the common name attribute and must not attempt to convey the attempt to convey the identity of the subject in a descriptive
identity of the subject in a descriptive fashion. Additionally, the fashion. The subject's distinguished name must be unique among all
subject's distinguished name must be unique among all certificates certificates issued by a given authority. In this PKI, the
issued by a given authority. In this PKI, the certificate issuer, certificate issuer, being an RIR, NIR, or LIR/ISP, is not in the
being an internet registry or LIR/ISP, is not in the business of business of verifying the legal right of the subject to assert a
verifying the legal right of the subject to assert a particular particular identity. Therefore, selecting a distinguished name that
identity. Therefore, selecting a distinguished name that does not does not convey the identity of the subject in a descriptive fashion
convey the identity of the subject in a descriptive fashion minimizes minimizes the opportunity for the subject to misuse the certificate
the opportunity for the subject to misuse the certificate to assert to assert an identity, and thus minimizes the legal liability of the
an identity, and thus minimizes the legal liability of the issuer. issuer. Since all CA certificates are issued to subjects with whom
Since all CA certificates are issued to subjects with whom the issuer the issuer has an existing relationship, it is recommended that the
has an existing relationship, it is recommended that the issuer issuer select a subject name that enables the issuer to easily link
select a subject name that enables the issuer to easily link the the certificate to existing database records associated with the
certificate to existing database records associated with the subject. subject. For example, an authority may use internal database keys or
For example, an authority may use internal database keys or
subscriber IDs as the subject common name in issued certificates. subscriber IDs as the subject common name in issued certificates.
Each Resource Certificate attests to an allocation of resources to Each Resource Certificate attests to an allocation of resources to a
its holder, so entities that have allocations from multiple sources resource holder, so entities that have allocations from multiple
will have multiple CA certificates. A CA also may issue distinct sources will have multiple CA certificates. A CA also may issue
certificates for each distinct allocation to the same entity, if the distinct certificates for each distinct allocation to the same
CA and the resource holder agree that such an arrangement will entity, if the CA and the resource holder agree that such an
facilitate management and use of the certificates. For example, an arrangement will facilitate management and use of the certificates.
LIR/ISP may have several certificates issued to it by one registry, For example, an LIR/ISP may have several certificates issued to it by
each describing a distinct set of address blocks, because the LIR/ISP one registry, each describing a distinct set of address blocks,
desires to treat the allocations as separate. because the LIR/ISP desires to treat the allocations as separate.
2.3. End-Entity (EE) Certificates 2.3. End-Entity (EE) Certificates
The private key corresponding to public key contained in an EE The private key corresponding to public key contained in an EE
certificate is not used to sign other certificates in a PKI. The certificate is not used to sign other certificates in a PKI. The
primary function of end-entity certificates in this PKI is the primary function of end-entity certificates in this PKI is the
verification of signed objects that relate to the usage of the verification of signed objects that relate to the usage of the
resources described in the certificate, e.g., ROAs and manifests. resources described in the certificate, e.g., ROAs and manifests.
For ROAs and manifests there will be a one-to-one correspondence For ROAs and manifests there will be a one-to-one correspondence
between end-entity certificates and signed objects, i.e., the private between end-entity certificates and signed objects, i.e., the private
key corresponding to each end-entity certificate is used to sign key corresponding to each end-entity certificate is used to sign
exactly one object, and each object is signed with only one key. exactly one object, and each object is signed with only one key.
This property allows the PKI to be used to revoke these signed This property allows the PKI to be used to revoke these signed
objects, rather than creating a new revocation mechanism. When the objects, rather than creating a new revocation mechanism. When the
end-entity certificate used to sign an object has been revoked, the end-entity certificate used to sign an object has been revoked, the
signature on that object (and any corresponding assertions) will be signature on that object (and any corresponding assertions) will be
considered invalid, so a signed object can be effectively revoked by considered invalid, so a signed object can be effectively revoked by
revoking the end-entity certificate used to sign it. revoking the end-entity certificate used to sign it.
skipping to change at page 7, line 40 skipping to change at page 8, line 26
A secondary advantage to this one-to-one correspondence is that the A secondary advantage to this one-to-one correspondence is that the
private key corresponding to the public key in a certificate is used private key corresponding to the public key in a certificate is used
exactly once in its lifetime, and thus can be destroyed after it has exactly once in its lifetime, and thus can be destroyed after it has
been used to sign its one object. This fact should simplify key been used to sign its one object. This fact should simplify key
management, since there is no requirement to protect these private management, since there is no requirement to protect these private
keys for an extended period of time. keys for an extended period of time.
Although this document describes only two uses for end-entity Although this document describes only two uses for end-entity
certificates, additional uses will likely be defined in the future. certificates, additional uses will likely be defined in the future.
For example, end-entity certificates could be used as a more general For example, end-entity certificates could be used as a more general
authorization for their subjects to act on behalf of the holder of authorization for their subjects to act on behalf of the specified
the specified resources. This could facilitate authentication of resource holder. This could facilitate authentication of inter-ISP
inter-ISP interactions, or authentication of interactions with the interactions, or authentication of interactions with the repository
repository system. These additional uses for end-entity certificates system. These additional uses for end-entity certificates may
may require retention of the corresponding private keys, even though require retention of the corresponding private keys, even though this
this is not required for the private keys associated with end-entity is not required for the private keys associated with end-entity
certificates keys used for verification of ROAs and manifests, as certificates keys used for verification of ROAs and manifests, as
described above. described above.
2.4. Trust Anchors 2.4. Trust Anchors
In any PKI, each relying party (RP) is free to choose its own set of In any PKI, each relying party (RP) chooses its own set of trust
trust anchors. This general property of PKIs applies here as well. anchors. This general property of PKIs applies here as well. There is
There is an extant IP address space and AS number allocation an extant IP address space and AS number allocation hierarchy, and
hierarchy. IANA is the obvious candidate to be the TA, but thus IANA and/or the five RIRs are obvious candidates to be default
operational considerations may argue for a multi-TA PKI, e.g., one in TAs here. Nonetheless, each RP ultimately chooses the set of trust
which both IANA and the RIRs form a default set of trust anchors. anchors it will use for certificate validation.
Nonetheless, every relying party is free to choose a different set of
trust anchors to use for certificate validation operations.
For example, an RP (e.g., an LIR/ISP) could create a trust anchor to For example, a RP (e.g., an LIR/ISP) could create a trust anchor to
which all address space and/or all AS numbers are assigned, and for which all address space and/or all AS numbers are assigned, and for
which the RP knows the corresponding private key. The RP could then which the RP knows the corresponding private key. The RP could then
issue certificates under this trust anchor to whatever entities in issue certificates under this trust anchor to whatever entities in
the PKI it wishes, with the result that the certificate paths the PKI it wishes, with the result that the certification paths
terminating at this locally-installed trust anchor will satisfy the terminating at this locally-installed trust anchor will satisfy the
RFC 3779 validation requirements. RFC 3779 validation requirements. A large ISP that uses private
(i.e., RFC 1918) IP address space and runs BGP internally will need
to create this sort of trust anchor to accommodate a CA to which all
private (RFC 1918) address space is assigned. The RP could then issue
certificates under this CA that correspond to the RP's internal use
of private address space.
An RP who elects to create and manage its own set of trust anchors Note that a RP who elects to create and manage its own set of trust
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.
2.5. Default Trust Anchors It is expected that some parties within the extant IP address space
and AS number allocation hierarchy may wish to publish trust anchor
The profile for resource certificates [6] specifies a format for a material for possible use by relying parties. A standard profile for
putative trust anchor to distribute to relying parties trust anchor the publication of trust anchor material for this public key
material consisting of both a self-signed certificate (which would infrastructure can be found in [9].
form the root of certification paths in the PKI) along with an
additional 'trust anchor' certificate used to validate the self-
signed certificate. Any entity claiming authoritative information
regarding the allocation of a portion of IP address space may offer
itself up in the role of a putative trust anchor by distributing such
material (in an out-of-band fashion). Given the extant IP address
space and AS number allocation hierarchy, it is envisioned that IANA
and the five RIRs will provide trust anchor information to relying
parties and that relying parties will generally accept trust anchors
from this set.
IANA forms the root of the extant IP address space and AS number
allocation hierarchy. Therefore, it is expected that IANA will
provide to relying parties trust anchor material whose self-signed
certificate has RFC 3779 extensions corresponding either to the
entirety of IP address space, or alternatively that portion of IP
address space that has not been sub-allocated to any of the five
RIRs.
As an example of the use of IANA as a trust anchor, consider the use
of private IP address space (i.e., 10/8, 172.16/12, and 192.168/16 in
IPv4 and FC00::/7 in IPv6). IANA could issue a CA certificate for
these blocks of private address space and then destroy the private
key corresponding to the 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-
allocated by IANA to one of the five RIRs. Therefore, it is expected
that each of the five RIRs will provide trust anchor material provide
to relying parties trust anchor material whose self-signed
certificate has RFC 3779 extensions corresponding to the IP address
and AS number resources that they manage.
One issue that the RIRs will need to consider when providing trust
anchor material is how to handle the approximately 49 /8 prefixes
containing legacy IPv4 allocations that are not each allocated to a
single RIR. Currently, for the purpose of administering reverse DNS
zones, each of these prefixes is administered by a single RIR who
delegates authority for allocations within the prefix as appropriate.
This existing arrangement could be used as the template for the
assignment of administrative responsibility for the certification of
these address blocks in the RPKI. Such an arrangement would in no way
alter the administrative arrangements and the associated policies
that apply to the individual legacy allocations that have been made
from these address blocks.
2.6. Representing Early-Registration Transfers (ERX) 2.5. Representing Early-Registration Transfers (ERX)
Currently, IANA allocates IPv4 address space to the RIRs at the level Currently, IANA allocates IPv4 address space to the RIRs at the level
of /8 prefixes. However, there exist allocations that cross these RIR of /8 prefixes. However, there exist allocations that cross these RIR
boundaries. For example, A LACNIC customer may have an allocation boundaries. For example, A LACNIC customer may have an allocation
that falls within a /8 prefix administered by ARIN. Therefore, the that falls within a /8 prefix administered by ARIN. Therefore, the
resource PKI must be able to represent such transfers from one RIR to resource PKI must be able to represent such transfers from one RIR to
another in a manner that permits the validation of certificates with another in a manner that permits the validation of certificates with
RFC 3779 extensions. RFC 3779 extensions.
+-------------------------------+ +-------------------------------+
skipping to change at page 10, line 38 skipping to change at page 10, line 7
| | LACNIC | | LACNIC | | | | LACNIC | | LACNIC | |
| | CA | | CA | | | | CA | | CA | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+-------------------------------+ +-------------------------------+
FIGURE 1: Representing EXR FIGURE 1: Representing EXR
To represent such transfers, RIRs will need to manage multiple CA To represent such transfers, RIRs will need to manage multiple CA
certificates, each with distinct public (and corresponding private) certificates, each with distinct public (and corresponding private)
keys. Each RIR will have a single ''root'' certificate (e.g., a self- 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), signed certificate or a certificate signed by IANA, see Section 2.5),
plus one additional CA certificate for each RIR from which it plus one additional CA certificate for each RIR from which it
receives a transfer. Each of these additional CA certificates will be receives a transfer. Each of these additional CA certificates will be
issued under the ''root'' certificate of the RIR from which the issued under the "root" certificate of the RIR from which the
transfer is received. This means that although the certificate is transfer is received. This means that although the certificate is
bound to the RIR that receives the transfer, for the purposes of bound to the RIR that receives the transfer, for the purposes of
certificate path construction and validation, it does not appear certificate path construction and validation, it does not appear
under that RIR's ''root'' certificate (see Figure 1). 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 address space to create an object that explicitly and holder of IP address space to create an object that explicitly and
verifiably asserts that an AS is authorized originate routes to verifiably asserts that an AS is authorized originate routes to a
prefixes. given set of prefixes.
3.1. Role in the overall architecture 3.1. Role in the overall architecture
A ROA is an attestation that the holder of a set of prefixes has A ROA is an attestation that the holder of a set of prefixes has
authorized an autonomous system to originate routes for those authorized an autonomous system to originate routes for those
prefixes. A ROA is structured according to the format described in prefixes. A ROA is structured according to the format described in
[7]. The validity of this authorization depends on the signer of the [7]. The validity of this authorization depends on the signer of the
ROA being the holder of the prefix(es) in the ROA; this fact is ROA being the holder of the prefix(es) in the ROA; this fact is
asserted by an end-entity certificate from the PKI, whose asserted by an end-entity certificate from the PKI, whose
corresponding private key is used to sign the ROA. corresponding private key is used to sign the ROA.
ROAs may be used by relying parties to verify that the AS that ROAs may be used by relying parties to verify that the AS that
originates a route for a given IP address prefix is authorized by the originates a route for a given IP address prefix is authorized by the
holder of that prefix to originate such a route. For example, an ISP holder of that prefix to originate such a route. For example, an ISP
might use ROAs as inputs to route filter construction for use by its might use validated ROAs as inputs to route filter construction for
BGP routers. These filters would prevent importation of any route in use by its BGP routers. (See [14] for information on the use of ROAs
which the origin AS of the AS-PATH attribute is not an AS that is to validate the origination of BGP routes.)
authorized (via a valid ROA) to originate the route. (See Section 6.3
for more details.)
Initially, the repository system will be the primary mechanism for Initially, the repository system will be the primary mechanism for
disseminating ROAs, since these repositories will hold the disseminating ROAs, since these repositories will hold the
certificates and CRLs needed to verify ROAs. In addition, ROAs also certificates and CRLs needed to verify ROAs. In addition, ROAs also
could be distributed in BGP UPDATE messages or via other could be distributed in BGP UPDATE messages or via other
communication paths, if needed to meet timeliness requirements. communication paths, if needed to meet timeliness requirements.
3.2. Syntax and semantics 3.2. Syntax and semantics
A ROA constitutes an explicit authorization for a single AS to A ROA constitutes an explicit authorization for a single AS to
skipping to change at page 12, line 4 skipping to change at page 11, line 17
A ROA constitutes an explicit authorization for a single AS to A ROA constitutes an explicit authorization for a single AS to
originate routes to one or more prefixes, and is signed by the holder originate routes to one or more prefixes, and is signed by the holder
of those prefixes. A detailed specification of the ROA syntax can be of those prefixes. A detailed specification of the ROA syntax can be
found in [7] but, at a high level, a ROA consists of (1) an AS found in [7] but, at a high level, a ROA consists of (1) an AS
number; (2) a list of IP address prefixes; and, optionally, (3) for number; (2) a list of IP address prefixes; and, optionally, (3) for
each prefix, the maximum length of more specific (longer) prefixes each prefix, the maximum length of more specific (longer) prefixes
that the AS is also authorized to advertise. (This last element that the AS is also authorized to advertise. (This last element
facilitates a compact authorization to advertise, for example, any facilitates a compact authorization to advertise, for example, any
prefixes of length 20 to 24 contained within a given length 20 prefixes of length 20 to 24 contained within a given length 20
prefix.) prefix.)
Note that a ROA contains only a single AS number. Thus, if an ISP has Note that a ROA contains only a single AS number. Thus, if an ISP has
multiple AS numbers that will be authorized to originate routes to multiple AS numbers that will be authorized to originate routes to
the prefix(es) in the ROA, an address space holder will need to issue the prefix(es) in the ROA, an address space holder will need to issue
multiple ROAs to authorize the ISP to originate routes from any of multiple ROAs to authorize the ISP to 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 verify 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 that time is quite low.
--------- --------- --------- ---------
| RIR | | NIR | | RIR | | NIR |
| CA | | CA | | CA | | CA |
--------- --------- --------- ---------
| | | |
| | | |
| | | |
--------- --------- --------- ---------
| ISP | | ISP | | ISP | | ISP |
skipping to change at page 14, line 17 skipping to change at page 13, line 17
The digital signatures on all objects in the repository ensure that The digital signatures on all objects in the repository ensure that
unauthorized modification of valid objects is detectable by relying unauthorized modification of valid objects is detectable by relying
parties. Additionally, the repository system uses manifests (see parties. Additionally, the repository system uses manifests (see
Section 5) to ensure that relying parties can detect the deletion of Section 5) to ensure that relying parties can detect the deletion of
valid objects and the insertion of out of date, valid signed objects. valid objects and the insertion of out of date, valid 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 of access controls prevents denial of
service attacks based on deletion of or tampering to repository service attacks based on deletion of or tampering to repository
objects. Indeed, although relying parties can detect tampering with objects. Indeed, although relying parties can detect tampering with
objects in the repository, it is preferable that the repository objects in the repository, it is preferable that the repository
system prevent such unauthorized modifications to the greatest extent system prevent such unauthorized modifications to the greatest extent
possible. possible.
4.1. Role in the overall architecture 4.1. Role in the overall architecture
The repository system is the central clearing-house for all signed The repository system is the central clearing-house for all signed
objects that must be globally accessible to relying parties. When objects that must be globally accessible to relying parties. When
certificates and CRLs are created, they are uploaded to this certificates and CRLs are created, they are uploaded to this
repository, and then downloaded for use by relying parties (primarily repository, and then downloaded for use by relying parties (primarily
LIRs/ISPs). ROAs and manifests are additional examples of such LIRs/ISPs). ROAs and manifests are additional examples of such
objects, but other types of signed objects may be added to this objects, but other types of signed objects may be added to this
architecture in the future. This document briefly describes the way architecture in the future. This document briefly describes the way
signed objects (certificates, CRLs, ROAs and manifests) are managed signed objects (certificates, CRLs, ROAs and manifests) are managed
in the repository system. As other types of signed objects are added in the repository system. As other types of signed objects are added
to the repository system it will be necessary to modify the to the repository system it will be necessary to modify the
description, but it is anticipated that most of the design principles description, but it is anticipated that most of the design principles
will still apply. The repository system is described in detail in will still apply. The repository system is described in detail in
[9]. [10].
4.2. Contents and structure 4.2. Contents and structure
Although there is a single repository system that is accessed by Although there is a single repository system that is accessed by
relying parties, it is comprised of multiple databases. These relying parties, it is comprised of multiple databases. These
databases will be distributed among registries (RIRs, NIRs, databases will be distributed among registries (RIRs, NIRs,
LIRs/ISPs). At a minimum, the database operated by each registry will LIRs/ISPs). At a minimum, the database operated by each registry will
contain all CA and EE certificates, CRLs, and manifests signed by the contain all CA and EE certificates, CRLs, and manifests signed by the
CA(s) associated with that registry. Repositories operated by CA(s) associated with that registry. Repositories operated by
LIRs/ISPs also will contain ROAs. Registries are encouraged maintain LIRs/ISPs also will contain ROAs. Registries are encouraged to
copies of repository data from their customers, and their customer's maintain copies of repository data from their customers, and their
customers (etc.), to facilitate retrieval of the whole repository customer's customers (etc.), to facilitate retrieval of the whole
contents by relying parties. Ideally, each RIR will hold PKI data repository contents by relying parties. Ideally, each RIR will hold
from all entities within its geopolitical scope. PKI data from all entities within its geopolitical scope.
For every certificate in the PKI, there will be a corresponding file For every certificate in the PKI, there will be a corresponding file
system directory in the repository that is the authoritative system directory in the repository that is the authoritative
publication point for all objects (certificates, CRLs, ROAs and publication point for all objects (certificates, CRLs, ROAs and
manifests) verifiable via this certificate. A certificate's Subject manifests) verifiable via this certificate. A certificate's Subject
Information Authority (SIA) extension provides a URI that references Information Authority (SIA) extension provides a URI that references
this directory. Additionally, a certificate's Authority Information this directory. Additionally, a certificate's Authority Information
Authority (AIA) extension contains a URI that references the Authority (AIA) extension contains a URI that references the
authoritative location for the CA certificate under which the given authoritative location for the CA certificate under which the given
certificate was issued. That is, if certificate A is used to verify certificate was issued. That is, if certificate A is used to verify
skipping to change at page 16, line 36 skipping to change at page 15, line 36
Upload/change/delete: Access protocols MUST also support mechanisms Upload/change/delete: Access protocols MUST also support mechanisms
for the issuers of certificates, CRLs, and other signed objects to for the issuers of certificates, CRLs, and other signed objects to
add them to the repository, and to remove them. Mechanisms for add them to the repository, and to remove them. Mechanisms for
modifying objects in the repository MAY also be provided. All access modifying objects in the repository MAY also be provided. All access
protocols that allow modification to the repository (through protocols that allow modification to the repository (through
addition, deletion, or modification of its contents) MUST support addition, deletion, or modification of its contents) MUST support
verification of the authorization of the entity performing the verification of the authorization of the entity performing the
modification, so that appropriate access controls can be applied (see modification, so that appropriate access controls can be applied (see
Section 4.4). Section 4.4).
Current efforts to implement a repository system use RSYNC [12] as Current efforts to implement a repository system use RSYNC [13] as
the single access protocol. RSYNC, as used in this implementation, the single access protocol. RSYNC, as used in this implementation,
provides all of the above functionality. A document specifying the provides all of the above functionality. A document specifying the
conventions for use of RSYNC in the PKI will be prepared. conventions for use of RSYNC in the PKI will be prepared.
4.4. Access control 4.4. Access control
In order to maintain the integrity of information in the repository, In order to maintain the integrity of information in the repository,
controls must be put in place to prevent addition, deletion, or controls must be put in place to prevent addition, deletion, or
modification of objects in the repository by unauthorized parties. modification of objects in the repository by unauthorized parties.
The identities of parties attempting to make such changes can be The identities of parties attempting to make such changes can be
skipping to change at page 18, line 9 skipping to change at page 17, line 9
time a manifest is issued by the authority. An authority is required time a manifest is issued by the authority. An authority is required
to issue a new manifest any time it alters any of its items in the to issue a new manifest any time it alters any of its items in the
repository, or when the specified time of the next update is reached. repository, or when the specified time of the next update is reached.
A manifest is thus valid until the specified time of the next update A manifest is thus valid until the specified time of the next update
or until a manifest is issued with a greater manifest number, or until a manifest is issued with a greater manifest number,
whichever comes first. (Note that when an EE certificate is used to whichever comes first. (Note that when an EE certificate is used to
sign only a single manifest, whenever the authority issues the new sign only a single manifest, whenever the authority issues the new
manifest, the CA MUST also issue a new CRL which includes the EE manifest, the CA MUST also issue a new CRL which includes the EE
certificate corresponding to the old manifest. The revoked EE certificate corresponding to the old manifest. The revoked EE
certificate for the old manifest will be removed from the CRL when it certificate for the old manifest will be removed from the CRL when it
expires, thus this procedure ought not result in significant CRLs expires, thus this procedure ought not to result in significant CRLs
growth.) growth.)
6. Local Cache Maintenance 6. Local Cache Maintenance
In order to utilize signed objects issued under this PKI (e.g. for In order to utilize signed objects issued under this PKI, a relying
route filter construction, see Section 6.3), a relying party must party must first obtain a local copy of the valid EE certificates for
first obtain a local copy of the valid EE certificates for the PKI. 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
corresponding manifest. Additionally, verify that the current corresponding manifest. Additionally, verify that the current
time is earlier than the time indicated in the nextUpdate field time is earlier than the time indicated in the nextUpdate field
of the manifest. of the manifest.
3. For each manifest, verify that certificates and CRLs issued 3. For each manifest, verify that certificates and CRLs issued
under the corresponding CA certificate match the hash values under the corresponding CA certificate match the hash values
contained in the manifest. If the hash values do not match, use contained in the manifest. Additionally, verify that no
an out-of-band mechanism to notify the appropriate repository certificate or manifest listed on the manifest is missing from
the repository. If the hash values do not match, or if any
certificate or CRL is missing, notify the appropriate repository
administrator that the repository data has been corrupted. administrator that the repository data has been corrupted.
4. Validate each EE certificate by constructing and verifying a 4. Validate each EE certificate by constructing and verifying a
certification path for the certificate (including checking certification path for the certificate (including checking
relevant CRLs) to the locally configured set of TAs. (See [6] relevant CRLs) to the locally configured set of TAs. (See [6]
for more details.) for more details.)
Note that when a relying party performs these operations regularly, Note that 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. A relying party may
checking all issued objects against the appropriate manifest, the choose any frequency it desires for downloading and validating
relying party can be certain that it is not missing an updated updates from the repository. However, a typical ISP might reasonably
choose to perform these operations on a daily schedule. Note also
that by checking all issued objects against the appropriate manifest,
the relying party can be certain that it is not missing an updated
version of any object. 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 entes a relationship subscriber with "portable" address space who enters 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 origin AS to
originate an advertised route. 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'' address allocations for the sub-allocations. Holders of "portable" IP address space
also must have certificates, so that a ROA can be issued to each ISP allocations also must have certificates, so that a ROA can be issued
that is authorized to originate a route to the allocation (since the to each ISP that is authorized to originate a route to the allocation
allocation does not come from any ISP). Additionally, multi-homed (since the allocation does not come from any ISP). Additionally,
subscribers may require certificates for their allocations if they multi-homed subscribers may require certificates for their
intend to issue the ROAs for their allocations (see Section 6.2.2). allocations if they intend to issue the ROAs for their allocations
Other holders of resources need not be issued CA certificates within (see Section 7.2.2). Other resource holders need not be issued CA
the PKI. 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.
If a resource holder receives multiple allocations over time, it may If a resource holder receives multiple allocations over time, it may
accrue a collection of resource certificates to attest to them. If a accrue a collection of resource certificates to attest to them. If a
resource holder receives multiple allocations from the same source, resource holder receives multiple allocations from the same source,
the set of resource certificates may be combined into a single the set of resource certificates may be combined into a single
resource certificate, if both the issuer and the resource holder resource certificate, if both the issuer and the resource holder
agree. This is effected by consolidating the IP Address Delegation agree. This is accomplished by consolidating the IP Address
and AS Identifier Delegation Extensions into a single extension (of Delegation and AS Identifier Delegation Extensions into a single
each type) in a new certificate. However, if the certificates for extension (of each type) in a new certificate. However, if the
these allocations contain different validity intervals, creating a certificates for these allocations contain different validity
certificate that combines them might create problems, and thus is NOT intervals, creating a certificate that combines them might create
RECOMMENDED. problems, and thus is NOT RECOMMENDED.
If a resource holder's allocations come from different sources, they If a resource holder's allocations come from different sources, they
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 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.
7.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 space holder that issues ROAs for a prefix must
resource certificate for an allocation containing that prefix. The have a resource certificate for an allocation containing that prefix.
standard procedure for issuing a ROA is as follows: The standard procedure for issuing a ROA is as follows:
1. Create an end-entity certificate containing the prefix(es) to be 1. Create an end-entity certificate containing the prefix(es) to be
authorized in the ROA. authorized in the ROA.
2. Construct the payload of the ROA, including the prefixes in the 2. Construct the payload of the ROA, including the prefixes in the
end-entity certificate and the AS number to be authorized. end-entity certificate and the AS number to be authorized.
3. Sign the ROA using the private key corresponding to the end- 3. Sign the ROA using the private key corresponding to the end-
entity certificate (the ROA is comprised of the payload entity certificate (the ROA is comprised of the payload
encapsulated in a CMS signed message [7]). encapsulated in a CMS signed message [7]).
skipping to change at page 21, line 6 skipping to change at page 20, line 15
7.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 from its own allocation. Thus, a single-homed subscriber
a non-portable allocation is not included in the RPKI, i.e., it does with a non-portable allocation is not included in the RPKI, i.e., it
not receive a CA certificate, nor issue EE certificates or ROAs. does not receive a CA certificate, nor issue EE certificates or ROAs.
7.2.2. Multi-homed subscribers
In order for multiple ASes to originate routers for prefixes held by 7.2.2. Multi-homed subscribers (without portable allocations)
a multi-homed subscriber, each AS must have a ROA that explicitly
authorizes such route origination. There are two ways that this can
be accomplished.
One option is for the multi-homed subscriber to obtain a CA Here we consider a subscriber who receives IP address space from a
certificate from the ISP who allocated the prefixes to the primary ISP (i.e., the IP addresses used by the subscriber are a
subscriber. The multi-homed subscriber can then create a ROA (and subset of ISP A's IP address space allocation) and receives redundant
associated end-entity certificate) that authorizes a second ISP to upstream connectivity from the primary ISP, as well as one or more
originate routes to the subscriber prefix(es). The ROA for the second secondary ISPs. The preferred option for such a multi-homed
ISP generally SHOULD be set to require an exact match, if the intent subscribers is for the subscriber to obtain an AS number (from an RIR
is to enable backup paths for the prefix. Note that the first ISP, or NIR) and run BGP with each of its upstream providers. In such a
who allocated the prefixes, will want to advertise the more specific case, there are two ways for ROA management to be handled. The first
prefix for this subscriber (vs. the encompassing prefix). Either the is that the primary ISP issues a CA certificate to the subscriber,
subscriber or the first ISP will need to issue an EE certificate and and the subscriber issues a ROA to containing the subscriber's AS
ROA for the (more specific) prefix, authorizing this ISP to advertise number and the subscriber's IP address prefixes. The second
this more specific prefix. possibility is that the primary ISP does not issue a ROA to the
subscriber, and instead issues a ROA on the subscriber's behalf that
contains the subscriber's AS number and the subscriber's IP address
prefixes.
A second option is that the multi-homed subscriber can request that If the subscriber is unable or unwilling to obtain an AS number and
the ISP that allocated the prefixes create a ROA that authorizes the run BGP, the other option is that the multi-homed subscriber can
second ISP to originate routes to the subscriber's prefixes. (The ISP request that the primary ISP create a ROA for each secondary ISP that
also creates an EE certificate and ROA for its own advertisement of authorizes the secondary ISP to originate routes to the subscriber's
the subscriber prefix, as above.) This option does not require that prefixes. The primary ISP will also create a ROA containing its own
the subscriber be issued a certificate or participate in ROA AS number and the subscriber's prefixes, as it is likely in such a
management. Therefore, this option is simpler for the subscriber, and case that the primary ISP wishes to advertise precisely the
is preferred if the option is supported by the ISP performing the subscriber's prefixes and not an encompassing aggregate. Note that
allocation. this approach results in inconsistent origin AS numbers for the
subscribers prefixes which are considered undesirable on the public
Internet; thus this approach is NOT RECOMMENDED.
7.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 RIR
regional or national registry. Because the prefixes represented in or NIR. Because the prefixes represented in such allocations are not
such allocations are not taken from an allocation held by an ISP, taken from an allocation held by an ISP, there is no ISP that holds
there is no ISP that holds and advertises a more general prefix. A and advertises a more general prefix. A holder of a portable IP
holder of a portable allocation MUST authorize one or more ASes to address space allocation MUST authorize one or more ASes to originate
originate routes to these prefixes. Thus the resource holder MUST routes to these prefixes. Thus the resource holder MUST generate one
generate one or more EE certificates and associated ROAs to enable or more EE certificates and associated ROAs to enable the AS(es) to
the AS(es) to originate routes for the prefix(es) in question. This originate routes for the prefix(es) in question. This ROA is required
ROA is required because none of the ISP's existing ROAs authorize it because none of the ISP's existing ROAs authorize it to originate
to originate routes to that portable allocation. routes to that portable allocation.
7.3. Route filter construction
The goal of this architecture is to support improved routing
security. One way to do this is to use ROAs to construct route
filters that reject routes that conflict with the origination
authorizations asserted by current ROAs. The following is intended to
provide a high-level description of how the architecture might be
used to construct a route filter. Additional guidance on the use of
ROAs to derive inferences about the validity of BGP UPDATE messages
is provided in [14]. The guidance in [14] is particularly important
during a transition period where not all ISPs implement this
architecture (and thus the filter described below which naively
rejects all UPDATES without a corresponding ROA would incorrectly
reject valid routes originated by ISPs that do not yet implement this
architecture).
1. Obtain a local copy of all currently valid EE certificates, as
specified in Section 5.
2. Query the repository system to obtain a local copy of all ROAs
issued under the PKI.
3. Verify that the each ROA matches the hash value contained in the
manifest of the CA certificate used to verify the EE certificate
that issued the ROA and that no ROAs are missing.
4. Validate each ROA by verifying that its signature is verifiable
by a valid end-entity certificate that matches the address
allocation in the ROA. (See [7] for more details.)
5. Based on the validated ROAs, construct a table of prefixes and
corresponding authorized origin ASes (or vice versa).
A BGP speaker that applies such a filter is thus guaranteed that for
a given IP address prefix, all routes that the BGP speaker accepts
for that prefix were originated by an AS that is authorized by the
owner of the prefix to authorize routes to that prefix.
The first three steps in the above procedure might incur a
substantial overhead if all objects in the repository system were
downloaded and validated every time a route filter was constructed.
Instead, it will be more efficient for users of the infrastructure to
initially download all of the signed objects and perform the
validation algorithm described above. Subsequently, a relying party
need only perform incremental downloads and validations on a regular
basis. A typical ISP using the infrastructure may choose any
frequency it desires for downloading updates from the repository,
uploading any modifications it has made, and constructing route
filters. However, an ISP might reasonably choose to perform these
actions on a daily schedule.
It should be noted that the transition to 4-byte AS numbers (see RFC
4893 [13]) weakens the security guarantees achieved by BGP speakers
who do not support 4-byte AS numbers (referred to as OLD BGP
speakers). RFC 4893 specifies that all 4-byte AS numbers (except
those whose first two bytes are entirely zero) be mapped to the
reserved value 23456 before being sent to a BGP speaker who does not
understand 4-byte AS numbers. Therefore, when an ISP creates a route
filter for use by an OLD BGP speaker, it must allow any 4-byte AS
number to advertise routes for an IP address prefix if there exists a
ROA that authorizes any 4-byte AS number to advertise routes to that
prefix. This means that if an OLD BGP speaker accepts a route that
was originated by an AS with a 4-byte AS number, there is no
guarantee that it was originated by an authorized 4-byte AS number
(unless the route was propagated by an intermediate NEW BGP speaker
who performed route filtering as described above).
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
described in Section 4.4. Likewise, because the repository system is described in Section 4.4. Likewise, because the repository system is
structured as a distributed database, it should be inherently structured as a distributed database, it should be inherently
resistant to denial of service attacks; nonetheless, appropriate resistant to denial of service attacks; nonetheless, appropriate
precautions should also be taken, both through replication and backup precautions should also be taken, both through replication and backup
of the constituent databases and through the physical security of of the constituent databases and through the physical security of
database servers database servers.
9. IANA Considerations 9. IANA Considerations
This document makes no request of IANA. This document requests that the IANA issue RPKI Certificates for the
resources for which it is authoritative, i.e., reserved IPv4
Note to RFC Editor: this section may be removed on publication as an addresses, IPv6 ULAs, and address space not yet allocated by IANA to
RFC the RIRs. IANA SHOULD make available trust anchor material in the
format defined in [10] in support of these functions.
10. Acknowledgments 10. Acknowledgments
The architecture described in this draft is derived from the The architecture described in this draft is derived from the
collective ideas and work of a large group of individuals. This work collective ideas and work of a large group of individuals. This work
would not have been possible without the intellectual contributions would not have been possible without the intellectual contributions
of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of
APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Time APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim
Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy
Bush of IIJ. Bush of IIJ.
Although we are indebted to everyone who has contributed to this Although we are indebted to everyone who has contributed to this
architecture, we would like to especially thank Rob Austein for the architecture, we would like to especially thank Rob Austein for the
concept of a manifest, Geoff Huston for the concept of managing concept of a manifest, Geoff Huston for the concept of managing
object validity through single-use EE certificate key pairs, and object validity through single-use EE certificate key pairs, and
Richard Barnes for help in preparing an early version of this Richard Barnes for help in preparing an early version of this
document. document.
skipping to change at page 25, line 20 skipping to change at page 23, line 20
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] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, [3] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
R., and W. Polk, "Internet X.509 Public Key Infrastructure R., and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC Certificate and Certificate Revocation List (CRL) Profile", RFC
5280, May 2008. 5280, May 2008.
[4] Housley, R., ''Cryptographic Message Syntax'', RFC 3852, July [4] Housley, R., "Cryptographic Message Syntax", RFC 3852, July
2004. 2004.
[5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for [6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for
X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs- X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-
14, October 2008. 16, February 2009.
[7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route [7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route
Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-04, Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-04,
November 2008. November 2008.
[8] Austein, R., et al., ''Manifests for the Resource Public Key [8] Austein, R., et al., "Manifests for the Resource Public Key
Infrastructure'', draft-ietf-sidr-rpki-manifests-04, October Infrastructure", draft-ietf-sidr-rpki-manifests-04, October
2008. 2008.
[9] Michaelson, G., Kent, S., and Huston, G., "A Profile for Trust
Anchor Material for the Resource Certificate PKI", draft-ietf-
sidr-ta-00, February 2009.
11.2. Informative References 11.2. Informative References
[9] Huston, G., Michaelson, G., and Loomans, R., ''A Profile for [10] Huston, G., Michaelson, G., and Loomans, R., "A Profile for
Resource Certificate Repository Structure'', draft-ietf-sidr- Resource Certificate Repository Structure", draft-ietf-sidr-
repos-struct-01, October 2008. repos-struct-01, October 2008.
[10] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway [11] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway
Protocol (Secure-BGP)'', IEEE Journal on Selected Areas in Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
Communications Vol. 18, No. 4, April 2000. Communications Vol. 18, No. 4, April 2000.
[11] White, R., "soBGP", May 2005, <ftp://ftp- [12] White, R., "soBGP", May 2005, <ftp://ftp-
eng.cisco.com/sobgp/index.html> eng.cisco.com/sobgp/index.html>
[12] Tridgell, A., "rsync", April 2006, [13] Tridgell, A., "rsync", April 2006,
<http://samba.anu.edu.au/rsync/> <http://samba.anu.edu.au/rsync/>
[13] Vohra, Q., and Chen, E., ''BGP Support for Four-octet AS Number [14] Huston, G., Michaelson, G., "Validation of Route Origination in
Space'', RFC 4893, May 2007. BGP using the Resource Certificate PKI", draft-ietf-sidr-roa-
validation-01, October 2008.
[14] Huston, G., Michaelson, G., ''Validation of Route Origination
in BGP using the Resource Certificate PKI'', draft-ietf-sidr-
roa-validation-01, October 2008.
Authors' Addresses Authors' Addresses
Matt Lepinski Matt Lepinski
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
Email: mlepinski@bbn.com Email: mlepinski@bbn.com
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
Email: kent@bbn.com Email: kent@bbn.com
Intellectual Property Statement Pre-5378 Material Disclaimer
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document may contain material from IETF Documents or IETF
contained in BCP 78, and except as set forth therein, the authors Contributions published or made publicly available before November
retain all their rights. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
 End of changes. 83 change blocks. 
423 lines changed or deleted 292 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/