< draft-ietf-sidr-arch-02.txt   draft-ietf-sidr-arch-03.txt >
Secure Inter-Domain Routing M. Lepinski Secure Inter-Domain Routing M. Lepinski
Working Group S. Kent Working Group S. Kent
Internet Draft R. Barnes Internet Draft BBN Technologies
Intended status: Informational BBN Technologies Intended status: Informational February 25, 2008
Expires: May 2008 November 18, 2007 Expires: August 2008
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-02.txt draft-ietf-sidr-arch-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 18, 2007. This Internet-Draft will expire on August 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
support secure Internet routing. The foundation of this architecture support secure Internet routing. The foundation of this architecture
is a public key infrastructure (PKI) that represents the allocation is a public key infrastructure (PKI) that represents the allocation
hierarchy of IP address space and Autonomous System Numbers; hierarchy of IP address space and Autonomous System Numbers;
certificates from this PKI are used to verify signed objects that certificates from this PKI are used to verify signed objects that
authorize autonomous systems to originate routes for specified IP authorize autonomous systems to originate routes for specified IP
address prefixes. The data objects that comprise the PKI, as well as address prefixes. The data objects that comprise the PKI, as well as
skipping to change at page 2, line 26 skipping to change at page 2, line 24
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. PKI for Internet Number Resources..............................4 2. PKI for Internet Number Resources..............................4
2.1. Role in the overall architecture..........................5 2.1. Role in the overall architecture..........................5
2.2. CA Certificates...........................................5 2.2. CA Certificates...........................................5
2.3. End-Entity (EE) Certificates..............................7 2.3. End-Entity (EE) Certificates..............................7
2.4. Trust Anchors.............................................8 2.4. Trust Anchors.............................................7
2.5. Default Trust Anchor Considerations.......................8 2.5. Default Trust Anchor Considerations.......................8
2.6. Representing Early-Registration Transfers (ERX)...........9 2.6. Representing Early-Registration Transfers (ERX)...........9
3. Route Origination Authorizations..............................10 3. Route Origination Authorizations..............................10
3.1. Role in the overall architecture.........................11 3.1. Role in the overall architecture.........................11
3.2. Syntax and semantics.....................................11 3.2. Syntax and semantics.....................................11
4. Repositories..................................................13 4. Repositories..................................................13
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. Manifest Syntax..........................................17 5.1. Syntax and semantics.....................................16
5.2. Certificate Requests.....................................18 6. Local Cache Maintenance.......................................17
5.3. Publication Repositories.................................19 7. Common Operations.............................................18
5.4. Relying Party processing of a Manifest...................19 7.1. Certificate issuance.....................................18
5.4.1. The nominal good case:..............................20 7.2. ROA management...........................................19
5.4.2. The bad cases:......................................20
5.4.3. Warning List........................................21
6. Local Cache Maintenance.......................................22
7. Common Operations.............................................23
7.1. Certificate issuance.....................................23
7.2. ROA management...........................................24
7.2.1. Single-homed subscribers (without portable allocations) 7.2.1. Single-homed subscribers (without portable allocations)
...........................................................25 ...........................................................20
7.2.2. Multi-homed subscribers.............................25 7.2.2. Multi-homed subscribers.............................20
7.2.3. Portable allocations................................26 7.2.3. Portable allocations................................21
7.3. Route filter construction................................26 7.3. Route filter construction................................21
8. Security Considerations.......................................27 8. Security Considerations.......................................22
9. IANA Considerations...........................................27 9. IANA Considerations...........................................22
10. Acknowledgments..............................................28 10. Acknowledgments..............................................23
11. References...................................................29 11. References...................................................24
11.1. Normative References....................................29 11.1. Normative References....................................24
11.2. Informative References..................................29 11.2. Informative References..................................24
Author's Addresses...............................................30 Authors' Addresses...............................................25
Intellectual Property Statement..................................30 Intellectual Property Statement..................................25
Disclaimer of Validity...........................................31 Disclaimer of Validity...........................................26
1. Introduction 1. Introduction
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
support improved security for BGP routing [2] for the Internet. The support improved security for BGP routing [2] for the Internet. The
architecture encompasses three principle elements: architecture encompasses three principle elements:
. a public key infrastructure (PKI) . a public key infrastructure (PKI)
. digitally-signed routing objects to support routing security . digitally-signed routing objects to support routing security
skipping to change at page 3, line 38 skipping to change at page 3, line 30
signed routing objects signed routing objects
The architecture described by this document supports, at a minimum, The architecture described by this document supports, at a minimum,
two aspects of routing security; it enables an entity to verifiably two aspects of routing security; it enables an entity to verifiably
assert that it is the legitimate holder of a set of IP addresses or a assert that it is the legitimate holder of a set of IP addresses or a
set of Autonomous System (AS) numbers, and it allows the holder of IP set of Autonomous System (AS) numbers, and it allows the holder of IP
address space to explicitly and verifiably authorize one or more ASes address space to explicitly and verifiably authorize one or more ASes
to originate routes to that address space. In addition to these to originate routes to that address space. In addition to these
initial applications, the infrastructure defined by this architecture initial applications, the infrastructure defined by this architecture
also is intended to be able to support security protocols such as S- also is intended to be able to support security protocols such as S-
BGP [8] or soBGP [9]. This architecture is applicable to the routing BGP [10] or soBGP [11]. This architecture is applicable to the
of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently
address families supported by this architecture. Thus, for example, the only address families supported by this architecture. Thus, for
use of 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. To
ease implementation, existing IETF standards are used wherever ease implementation, existing IETF standards are used wherever
skipping to change at page 4, line 39 skipping to change at page 4, line 31
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 the allocation of the IP address space.
Thus, a basic function of this architecture is to provide 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 address 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 and
(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 set of IP addresses may sub-allocate
portions of that set, either to itself (e.g., to a particular unit of portions of that set, either to itself (e.g., to a particular unit of
the same organization), or to another organization, subject to the same organization), or to another organization, subject to
contractual constraints established by the registries. Because of contractual constraints established by the registries. Because of
skipping to change at page 5, line 26 skipping to change at page 5, line 18
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 PKI certificates are not intended to be ''descriptive.'' That is, this
is intended to provide authorization, but not authentication. This is PKI is intended to provide authorization, but not authentication.
in contrast to most PKIs where the issuer ensures that the This is 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 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
skipping to change at page 10, line 9 skipping to change at page 10, line 5
2.6. Representing Early-Registration Transfers (ERX) 2.6. 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.
--------------------------------- +-------------------------------+
| | | |
| LACNIC Administrative | | LACNIC Administrative |
| Boundary | | Boundary |
| | | |
---------- | ---------- | ---------- +--------+ | +--------+ | +--------+
| ARIN | | | LACNIC | | | RIPE | | ARIN | | | LACNIC | | | RIPE |
| ROOT | | | ROOT | | | ROOT | | ROOT | | | ROOT | | | ROOT |
---------- | ---------- | ---------- +--------+ | +--------+ | +--------+
\ | | / \ | | /
------------ ------------ ------------ ------------
| \ / | | \ / |
| ---------- ---------- | | +--------+ +--------+ |
| | 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
skipping to change at page 11, line 37 skipping to change at page 11, line 34
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
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. Syntactically, a ROA is a CMS signed-data object of those prefixes. A detailed specification of the ROA syntax can be
whose content is defined as follows: found in [7] but, at a high level, a ROA consists of (1) an AS
number; (2) a list of IP address prefixes; and (3) a flag indicating
RouteOriginAttestation ::= SEQUENCE { whether an exact match is required between the IP address prefix(es)
version [0] INTEGER DEFAULT 0, of the ROA and the IP address prefix(es) originated by the AS, or
asID ASID, whether the AS is also authorized to advertise long (more specific)
exactMatch BOOLEAN, prefixes.
ipAddrBlocks ROAIPAddrBlocks }
ASID ::= INTEGER
ROAIPAddrBlocks ::= SEQUENCE of ROAIPAddressFamily
ROAIPAddressFamily ::= SEQUENCE {
addressFamily OCTET STRING (SIZE (2..3)),
addresses SEQUENCE OF IPAddress }
-- Only two address families are allowed: IPv4 and IPv6
IPAddress ::= BIT STRING
That is, the signed data within the ROA consists of a version number,
the AS number that is being authorized, and a list of IP prefixes to
which the AS is authorized to originate routes. If the exactMatch
flag is set to TRUE, then the AS is authorized to originate routes
only for the specific prefix(es) listed in the ROA. If the exactMatch
flag is set to FALSE, the AS is authorized to originate routes to the
prefix(es) in the ROA as well as any longer (more specific) prefixes.
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
skipping to change at page 14, line 32 skipping to change at page 13, line 44
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].
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 maintain
skipping to change at page 15, line 14 skipping to change at page 14, line 25
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
certificate B, then the AIA extension of certificate B points to certificate B, then the AIA extension of certificate B points to
certificate A, and the SIA extension of certificate A points to a certificate A, and the SIA extension of certificate A points to a
directory containing certificate B (see Figure 2). directory containing certificate B (see Figure 2).
---------- +--------+
---------->| Cert A |<----- +--------->| Cert A |<----+
| | CRLDP | | ----------- | | CRLDP | | +---------+
| | AIA | | --->| A's CRL |<-- | | AIA | | +-->| A's CRL |<-+
| --------+- SIA | | | ----------- | | +--------- SIA | | | +---------+ |
| | ---------- | | | | | +--------+ | | |
| | | | | | | | | |
| | ----+----- | | | +---+----+ |
| | | | | | | | | |
| | ----------------|---|------------------ | | | +---------------|---|-----------------+ |
| | | | | | | | | | | | | |
| -->| ---------- | | ---------- | | | +->| +--------+ | | +--------+ | |
| | | Cert B | | | | Cert C | | | | | | Cert B | | | | Cert C | | |
| | | CRLDP -+--- | | CRLDP -+----|---- | | | CRLDP ----+ | | CRLDP -+--------+
----------+- AIA | ----+- AIA | | +----------- AIA | +----- AIA | |
| | SIA | | SIA | | | | SIA | | SIA | |
| ---------- ---------- | | +--------+ +--------+ |
| | | |
--------------------------------------- +-------------------------------------+
FIGURE 3: In this example, certificates B and C are issued under FIGURE 3: In this example, certificates B and C are issued under
certificate A. Therefore, the AIA extensions of certificates B and C certificate A. Therefore, the AIA extensions of certificates B and C
point to A, and the SIA extension of certificate A points to the point to A, and the SIA extension of certificate A points to the
directory containing certificates B and C. directory containing certificates B and C.
If a CA certificate is reissued with the same public key, it should If a CA certificate is reissued with the same public key, it should
not be necessary to reissue (with an updated AIA URI) all not be necessary to reissue (with an updated AIA URI) all
certificates signed by the certificate being reissued. Therefore, a certificates signed by the certificate being reissued. Therefore, a
certification authority SHOULD use a persistent URI naming scheme for certification authority SHOULD use a persistent URI naming scheme for
skipping to change at page 16, line 34 skipping to change at page 15, line 42
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 [10] as Current efforts to implement a repository system use RSYNC [12] 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
authenticated through the relevant access protocols. Although authenticated through the relevant access protocols. Although
specific access control policies are subject to the local control of specific access control policies are subject to the local control of
repository operators, it is recommended that repositories allow only repository operators, it is recommended that repositories allow only
the issuers of signed objects to add, delete, or modify them. the issuers of signed objects to add, delete, or modify them.
Alternatively, it may be advantageous in the future to define a Alternatively, it may be advantageous in the future to define a
formal delegation mechanism to allow resource holders to authorize formal delegation mechanism to allow resource holders to authorize
other parties to act on their behalf, as suggested in Section 2.3 other parties to act on their behalf, as suggested in Section 2.3
above. above.
skipping to change at page 17, line 18 skipping to change at page 16, line 26
A manifest is a signed object listing of all of the signed objects A manifest is a signed object listing of all of the signed objects
issued by an authority responsible for a publication in the issued by an authority responsible for a publication in the
repository system. For each certificate, CRL, or ROA issued by the repository system. For each certificate, CRL, or ROA issued by the
authority, the manifest contains both the name of the file containing authority, the manifest contains both the name of the file containing
the object, and a hash of the file content. the object, and a hash of the file content.
As with ROAs, a manifest is signed by a private key, for which the As with ROAs, a manifest is signed by a private key, for which the
corresponding public key appears in an end-entity certificate. This corresponding public key appears in an end-entity certificate. This
EE certificate, in turn, is signed by the CA in question. The EE EE certificate, in turn, is signed by the CA in question. The EE
certificate private key may be used to sign one for more manifests. certificate private key may be used to issue one for more manifests.
If the private key is used to sign only a single manifest, then the If the private key is used to sign only a single manifest, then the
manifest can be revoked by revoking the EE certificate. In such a manifest can be revoked by revoking the EE certificate. In such a
case, to avoid needless CRL growth, the EE certificate used to case, to avoid needless CRL growth, the EE certificate used to
validate a manifest SHOULD expire at the same time that the manifest validate a manifest SHOULD expire at the same time that the manifest
expires, i.e., the notAfter value in the EE certificate should be the expires. If an EE certificate is used to issue multiple (sequential)
same as the nextUpdate value in the manifest. If a private key manifests for the CA in question, then there is no revocation
corresponding to a the public key in an EE certificate is used to mechanism for these individual manifests.
sign multiple (sequential) manifests for the CA in question, then
there is no revocation mechanism for these manifests. In such a case
a relying party will treat a manifest as valid until either (a) he
obtains a new manifest for the same CA having a higher
manifestNumber; or (b) the nextUpdate time is reached.
This EE certificate has an SIA extension access description field
with an accessMethod OID value of id-ad-signedobjectrepository where
the associated accessLocation references the publication point of the
manifest as an object URL.
5.1. Manifest Syntax
Syntactically, a manifest is a CMS signed-data object. As it is
intended that the manifest will be used in the context of assembling
a local copy of the entire RPKI repository, then the necessary
information to validate the certificate path for the manifest's
signature will be at hand for the relying party, thus duplication of
superior certificates and of CRLs in the CMS SignedData of the
manifest is not required. Only the EE certificate needed to directly
verify the signature on the manifest MUST be included in the CMS
SignedData; other certificates MUST NOT be included and CRLs MUST NOT
be included.
The CMS timestamp field MUST be included in the CMS SignedData.
The content of the CMS signed-data object is defined as follows:
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER,
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash
}
FileAndHash ::=SEQUENCE {
file IA5String
hash BIT STRING
}
The manifestNumber field is a sequence number that is incremented
each time a manifest is issued by a authority. The thisUpdate field
contains the time when the manifest was created and the nextUpdate
field contains the time at which the next scheduled manifest will be
issued. If the authority alters any of its items in the repository,
then it MUST issue a new manifest before nextUpdate. A manifest is
valid until the time specified in nextUpdate or until a manifest is
issued with a greater manifest number, whichever comes first. (Note
that when an EE certificate is used to sign only a single manifest,
whenever the authority issues the new manifest, the CA MUST also
issue a new CRL which includes the EE certificate corresponding to
the old manifest. The revoked EE certificate for the old manifest
will be removed from the CRL when it expires, thus this procedure
ought not result in significant CRLs growth.)
The fileHashAlg field contains the OID of the hash algorithm used to
hash the files that the authority has placed into the repository. The
mandatory to implement hash algorithm is SHA-256 and its OID is
2.16.840.1.101.3.4.2.1. [12]
The fileList field contains a sequence of FileAndHash pairs, one for
each currently valid certificate, CRL and ROA that has been issued by
the authority. Each of the FileAndHash pairs contains the name of the
file in the repository that contains the object in question, and a
hash of the file's contents.
5.2. Certificate Requests
A request for a CA certificate MUST include in the SIA of the request
an accessMethod OID of id-ad-manifest, where the associated
accessLocation refers to the subject's published manifest object as
an object URL. The manifest refers to the list of all products of
this CA certificate (except of course the manifest itself) that are
published at the publication point referred to by the SIA repository
pointer. This implies that the name of the manifest object is known
in advance, requiring the manifest object name to be a PURL, i.e., a
URL that is unchanged across manifest generation cycles.
Certificate requests for EE certificates MUST include in the SIA of
the request an access method OID of id-ad-manifest, where the
associated access location refers to the publication point of the
object verified using this EE certificate.
This implies that all certificate issuance requests where there is an
SIA extension present should include the id-ad-manifest access method
and the associated access location in the request, and the issuer
should honour these values in the issued certificate.
5.3. Publication Repositories
The RPKI publication directory model requires that every publication
point be associated with a CA, and be non-empty. Upon creation of the
publication repository, the CA MUST create an manifest. The manifest
will contain at least one entry, the CRL issued by the CA.
For a CA-issuer who is digitally signing documents and publishing
these signed objects, the EE certifate used to verify the signing of
an object would use the id-ad-manifest SIA access method to refer to
the signed object itself. If the signing format is CMS and the EE
certificate is attached to the signed document, then there is no
requirement to publish the EE cert in the publication repository of
the CA. On the other hand, of the CA wants to ensure that relying
parties can assure themselves that they have the complete collection
of signed objects then publishing the EE cert in the CA's publication
repository would be sufficient.
5.4. Relying Party processing of a Manifest
In this section, we describe the recommended behavior of a relying
party when processing a manifest. We begin by describing the
scenario where the relying party is able to successfully validate a
manifest the corresponds to the contents of the repository. We then
describe the recommended behavior in the various cases where the
relying party is unable to validate such a manifest.
5.4.1. The nominal good case:
A manifest is present in the repository, is current (i.e., the
current time is bounded by the manifest validity interval), and its
signature can be verified. All files listed in the manifest are found
in the repository and the hashes match. Any files in the repository
that are NOT listed in the manifest but that validate anyway SHOUD be
ignored (since they could be older instances of objects covered by
the manifest).
5.4.2. The bad cases:
1. No manifest is found in the repository at the publication point.
In this case, the relying party cannot use the manifest in question.
a. If the relying party has a prior manifest for this publication
point, he should use most recent, verified manifest for the
publication point in question and generate warning A.
b. If no prior manifest for this publication point is available,
there is no basis for detecting missing files, so just process
certificate, CRL, and ROA files and generate warning B.
2. The Signature on manifest fetched from the repository cannot be
verified (or the format is bad). In this case, the relying party
cannot use the manifest in question.
a. If the relying party has a prior manifest for this publication
point, he should use most recent, verified manifest for the
publication point in question and generate warning A.
b. If no prior manifest for this publication point is available,
there is no basis for detecting missing files, so he should just
process certificate, CRL, and ROA files and generate warning B.
3. The manifest is present and current and its signature can be
verified using a matching EE certificate
a. If the EE certificate is valid (current and not revoked) and
all files listed in the manifest are found in the repository and the
hashes match, then the relying party should use the manifest as in
Section 5.
b. If the EE certificate is valid and one or more files listed in
the manifest have hashes that do not match the files in the
repository with the indicates names, then the corresponding files are
likely to be old and intended to be replaced, and thus SHOULD NOT be
used. The relying party should generate Warning C.
c. If the EE certificate is valid and one or more files listed in
the manifest are missing, the relying party should Generate Warning
D.
d. If the EE certificate is expired. (this says the issuer of the
manifest screwed up!), the relying party should generate warning E,
but proceed with processing.
e. If the EE certificate is revoked but not expired, then the
manifest SHOULD be ignored. The relying party should generate warning
F and proceed with processing as if no manifest is available (since
the CA explicitly revoked the certificate for the manifest.)
4. The manifest is present but expired. If the signature cannot be
verified, treat as case 1/2. If the manifest signature can be
verified using a matching EE certificate:
a. If the EE certificate is valid (current and not revoked), then
generate warning A and proceed.
b. If the EE certificate is expired. (this says the issuer of the
manifest screwed up!), then generate warning G and proceed.
c. If EE certificate is revoked but not expired, the manifest
SHOULD be ignored. Generate warning F and proceed with processing as
if no manifest is available (since the CA explicitly revoked the
certificate for the manifest.)
5.4.3. Warning List
Warning A: A current manifest is not available for <pub point name>.
A older manifest for this publication point will be used, but there
may be undetected deletions from the publication point.
Warning B: No manifest is available for <pub point name>, and thus
there may have been undetected deletions from the publication point.
Warning C: The following files at <pub point name> appear to be
SUPERCEDED and are NOT being processed.
Warning D: The following files that should have been present in the Manifests may be used by relying parties when constructing a local
repository at <pub point name>, are missing <file list>. This cache (see Section 6) to mitigate the risk of an attacker who deletes
indicates an attack against this publication point, or the files from a repository or replaces current signed objects with stale
repository, or an error by the publisher. versions of the same object. Such protection is needed because
although all objects in the repository system are signed, the
repository system itself is untrusted.
Warning E: EE certificate for manifest verification for <pub point 5.1. Syntax and semantics
name> is expired. This indicates an error by the publisher, but
processing for this publication point will proceed using the current
manifest.
Warning F: The EE certificate for <pub point name> has been revoked. A manifest constitutes a list of (the hashes of) all the files in a
The manifest will be ignored and all files found at this publication repository point at a particular point in time. A detailed
point will be processed. specification of manifest syntax is provided in [8] but, at a high
level, a manifest consists of (1) a manifest number; (2) the time the
manifest was issued; (3) the time of the next planned update; and (4)
a list of filename and hash value pairs.
Warning G: EE certificate for manifest verification for <pub point The manifest number is a sequence number that is incremented each
name> is expired. This indicates an error by the publisher, but time a manifest is issued by the authority. An authority is required
processing for this publication point will proceed using the most to issue a new manifest any time it alters any of its items in the
recent (but expired) manifest. 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
or until a manifest is issued with a greater manifest number,
whichever comes first. (Note that when an EE certificate is used to
sign only a single manifest, whenever the authority issues the new
manifest, the CA MUST also issue a new CRL which includes the EE
certificate corresponding to the old manifest. The revoked EE
certificate for the old manifest will be removed from the CRL when it
expires, thus this procedure ought not result in significant CRLs
growth.)
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 (e.g. for
route filter construction, see Section 6.3), a relying party must route filter construction, see Section 6.3), a relying party must
first obtain a local copy of the valid EE certificates for the PKI. first obtain a local copy of the valid EE certificates for the PKI.
To do so, the relying party performs the following steps: To do so, the relying party performs the following steps:
1. Query the registry system to obtain a copy of all certificates, 1. Query the registry system to obtain a copy of all certificates,
manifests and CRLs issued under the PKI. manifests and CRLs issued under the PKI.
skipping to change at page 23, line 10 skipping to change at page 18, line 8
it is more efficient for the relying party to request from the it is more efficient for the relying party to request from the
repository system only those objects that have changed since the repository system only those objects that have changed since the
relying party last updated its local cache. Note also that by relying party last updated its local cache. Note also that by
checking all issued objects against the appropriate manifest, the checking all issued objects against the appropriate manifest, the
relying party can be certain that it is not missing an updated relying party can be certain that it is not missing an updated
version of any object. version of any object.
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 entes a relationship
with an ISP will need to issue one or more ROAs identifying that ISP, with an ISP will need to issue one or more ROAs identifying that ISP,
in addition to conducting any other necessary technical or business in addition to conducting any other necessary technical or business
procedures. The current primary use of this infrastructure is for procedures. The current primary use of this infrastructure is for
route filter construction; using ROAs, route filters can be route filter construction; using ROAs, route filters can be
constructed in an automated fashion with high assurance that the constructed in an automated fashion with high assurance that the
holder of the advertised prefix has authorized the first-hop AS to holder of the advertised prefix has authorized the first-hop AS to
originate an advertised route. originate an advertised route.
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'' address allocations
also must have certificates, so that a ROA can be issued to each ISP also must have certificates, so that a ROA can be issued to each ISP
that is authorized to originate a route to the allocation (since the that is authorized to originate a route to the allocation (since the
allocation does not come from any ISP). Additionally, multi-homed allocation does not come from any ISP). Additionally, multi-homed
subscribers may require certificates for their allocations if they subscribers may require certificates for their allocations if they
intend to issue the ROAs for their allocations (see Section 6.2.2). intend to issue the ROAs for their allocations (see Section 6.2.2).
Other holders of resources need not be issued CA certificates within Other holders of resources need not be issued CA certificates within
the PKI. 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
skipping to change at page 26, line 36 skipping to change at page 21, line 36
1. Obtain a local copy of all currently valid EE certificates, as 1. Obtain a local copy of all currently valid EE certificates, as
specified in Section 5. specified in Section 5.
2. Query the repository system to obtain a local copy of all ROAs 2. Query the repository system to obtain a local copy of all ROAs
issued under the PKI. issued under the PKI.
3. Verify that the each ROA matches the hash value contained in the 3. Verify that the each ROA matches the hash value contained in the
manifest of the CA certificate used to verify the EE certificate manifest of the CA certificate used to verify the EE certificate
that issued the ROA and that no ROAs are missing. (ROAs are that issued the ROA and that no ROAs are missing. (ROAs are
contained in files with a ".roa" suffix, so missing ROAs are contained in files with a ''.roa'' suffix, so missing ROAs are
readily detected.) readily detected.)
4. Validate each ROA by verifying that it's signature is verifiable 4. Validate each ROA by verifying that it's signature is verifiable
by a valid end-entity certificate that matches the address by a valid end-entity certificate that matches the address
allocation in the ROA. (See [7] for more details.) allocation in the ROA. (See [7] for more details.)
5. Based on the validated ROAs, construct a table of prefixes and 5. Based on the validated ROAs, construct a table of prefixes and
corresponding authorized origin ASes (or vice versa). corresponding authorized origin ASes (or vice versa).
A BGP speaker that applies such a filter is thus guaranteed that for A BGP speaker that applies such a filter is thus guaranteed that for
skipping to change at page 27, line 17 skipping to change at page 22, line 17
downloaded and validated every time a route filter was constructed. downloaded and validated every time a route filter was constructed.
Instead, it will be more efficient for users of the infrastructure to Instead, it will be more efficient for users of the infrastructure to
initially download all of the signed objects and perform the initially download all of the signed objects and perform the
validation algorithm described above. Subsequently, a relying party validation algorithm described above. Subsequently, a relying party
need only perform incremental downloads and validations on a regular need only perform incremental downloads and validations on a regular
basis. A typical ISP using the infrastructure might have a daily basis. A typical ISP using the infrastructure might have a daily
schedule to download updates from the repository, upload any schedule to download updates from the repository, upload any
modifications it has made, and construct route filters. modifications it has made, and construct route filters.
It should be noted that the transition to 4-byte AS numbers (see RFC It should be noted that the transition to 4-byte AS numbers (see RFC
4893 [11]) weakens the security guarantees achieved by BGP speakers 4893 [13]) weakens the security guarantees achieved by BGP speakers
who do not support 4-byte AS numbers (referred to as OLD BGP who do not support 4-byte AS numbers (referred to as OLD BGP
speakers). RFC 4893 specifies that all 4-byte AS numbers (except speakers). RFC 4893 specifies that all 4-byte AS numbers (except
those whose first two bytes are entirely zero) be mapped to the those whose first two bytes are entirely zero) be mapped to the
reserved value 23456 before being sent to a BGP speaker who does not reserved value 23456 before being sent to a BGP speaker who does not
understand 4-byte AS numbers. Therefore, when an ISP creates a route understand 4-byte AS numbers. Therefore, when an ISP creates a route
filter for use by an OLD BGP speaker, it must allow any 4-byte AS filter for use by an OLD BGP speaker, it must allow any 4-byte AS
number to advertise routes for an IP address prefix if there exists a number to advertise routes for an IP address prefix if there exists a
ROA that authorizes any 4-byte AS number to advertise routes to that ROA that authorizes any 4-byte AS number to advertise routes to that
prefix. This means that if an OLD BGP speaker accepts a route that prefix. This means that if an OLD BGP speaker accepts a route that
was originated by an AS with a 4-byte AS number, there is no was originated by an AS with a 4-byte AS number, there is no
skipping to change at page 28, line 20 skipping to change at page 23, line 20
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, Time
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, and 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. object validity through single-use EE certificate key pairs, and
Richard Barnes for help in preparing an early version of this
document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006 (BGP-4)", RFC 4271, January 2006
[3] Housley, R., et al., "Internet X.509 Public Key Infrastructure [3] Housley, R., et al., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC Certificate and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002. 3280, April 2002.
[4] Housley, R., "Cryptographic Message Syntax", RFC 3852, July [4] Housley, R., ''Cryptographic Message Syntax'', RFC 3852, July
2004. 2004.
[5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for [6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for
X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs- X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-
09, November 2007. 09, November 2007.
[7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route [7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route
Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-01, Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-02,
July 2008. February 2008.
[8] Austein, R., et al., ''Manifests for the Resource Public Key
Infrastructure'', draft-ietf-sidr-rpki-manifests-00, January
2008.
11.2. Informative References 11.2. Informative References
[8] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway [9] Huston, G., Michaelson, G., and Loomans, R., ''A Profile for
Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Resource Certificate Repository Structure'', draft-huston-sidr-
repos-struct-01, February 2008.
[10] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway
Protocol (Secure-BGP)'', IEEE Journal on Selected Areas in
Communications Vol. 18, No. 4, April 2000. Communications Vol. 18, No. 4, April 2000.
[9] White, R., "soBGP", May 2005, <ftp://ftp- [11] White, R., "soBGP", May 2005, <ftp://ftp-
eng.cisco.com/sobgp/index.html> eng.cisco.com/sobgp/index.html>
[10] Tridgell, A., "rsync", April 2006, [12] Tridgell, A., "rsync", April 2006,
<http://samba.anu.edu.au/rsync/> <http://samba.anu.edu.au/rsync/>
[11] Vohra, Q., and Chen, E., "BGP Support for Four-octet AS Number [13] Vohra, Q., and Chen, E., ''BGP Support for Four-octet AS Number
Space", RFC 4893, May 2007. Space'', RFC 4893, May 2007.
[12] Schaad, J., Kaliski, B., Housley, R., "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure for use in the Internet X.509
Public Key Infrastructure", RFC 4055, June 2005.
Author's Addresses 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
Richard Barnes
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
Email: rbarnes@bbn.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 31, line 23 skipping to change at page 26, line 17
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 52 change blocks. 
350 lines changed or deleted 129 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/