< draft-ietf-sidr-arch-03.txt   draft-ietf-sidr-arch-04.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 February 25, 2008 Intended status: Informational November 3, 2008
Expires: August 2008 Expires: May 3, 2009
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-03.txt draft-ietf-sidr-arch-04.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 August 25, 2008. This Internet-Draft will expire on August 3, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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 improved security of Internet routing. The foundation of this
is a public key infrastructure (PKI) that represents the allocation architecture is a public key infrastructure (PKI) that represents the
hierarchy of IP address space and Autonomous System Numbers; allocation hierarchy of IP address space and Autonomous System
certificates from this PKI are used to verify signed objects that Numbers; and a distributed repository system for storing and
authorize autonomous systems to originate routes for specified IP disseminating the data objects that comprise the PKI, as well as
address prefixes. The data objects that comprise the PKI, as well as other signed objects necessary for improved routing security. As an
other signed objects necessary for secure routing, are stored and initial application of this architecture, the document describes how
disseminated through a distributed repository system. This document a holder of IP address space can explicitly and verifiably authorize
also describes at a high level how this architecture can be used to one or more ASes to originate routes to that address space. Such
add security features to common operations such as IP address space verifiable authorizations could be used, for example, to more
allocation and route filter construction. securely construct BGP route filters.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. PKI for Internet Number Resources..............................4 2. PKI for Internet Number Resources..............................4
2.1. Role in the overall architecture..........................5 2.1. Role in the overall architecture..........................5
2.2. CA Certificates...........................................5 2.2. CA Certificates...........................................5
2.3. End-Entity (EE) Certificates..............................7 2.3. End-Entity (EE) Certificates..............................7
2.4. Trust Anchors.............................................7 2.4. Trust Anchors.............................................8
2.5. Default Trust Anchor Considerations.......................8 2.5. Default Trust Anchor Considerations.......................8
2.6. Representing Early-Registration Transfers (ERX)...........9 2.6. Representing Early-Registration Transfers (ERX)..........10
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.........................13 4.1. Role in the overall architecture.........................14
4.2. Contents and structure...................................13 4.2. Contents and structure...................................14
4.3. Access protocols.........................................15 4.3. Access protocols.........................................16
4.4. Access control...........................................15 4.4. Access control...........................................16
5. Manifests.....................................................16 5. Manifests.....................................................17
5.1. Syntax and semantics.....................................16 5.1. Syntax and semantics.....................................17
6. Local Cache Maintenance.......................................17 6. Local Cache Maintenance.......................................18
7. Common Operations.............................................18 7. Common Operations.............................................18
7.1. Certificate issuance.....................................18 7.1. Certificate issuance.....................................19
7.2. ROA management...........................................19 7.2. ROA management...........................................20
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.............................20 7.2.2. Multi-homed subscribers.............................21
7.2.3. Portable allocations................................21 7.2.3. Portable allocations................................21
7.3. Route filter construction................................21 7.3. Route filter construction................................22
8. Security Considerations.......................................22 8. Security Considerations.......................................23
9. IANA Considerations...........................................22 9. IANA Considerations...........................................24
10. Acknowledgments..............................................23 10. Acknowledgments..............................................24
11. References...................................................24 11. References...................................................25
11.1. Normative References....................................24 11.1. Normative References....................................25
11.2. Informative References..................................24 11.2. Informative References..................................25
Authors' Addresses...............................................25 Authors' Addresses...............................................26
Intellectual Property Statement..................................25 Intellectual Property Statement..................................26
Disclaimer of Validity...........................................26 Disclaimer of Validity...........................................27
1. Introduction 1. Introduction
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
support improved security for BGP routing [2] for the Internet. The support improved security for BGP routing [2] for the Internet. The
architecture encompasses three principle elements: architecture encompasses three principle elements:
. a public key infrastructure (PKI) . a public key infrastructure (PKI)
. digitally-signed routing objects to support routing security . digitally-signed routing objects to support routing security
. a distributed repository system to hold the PKI objects and the . a distributed repository system to hold the PKI objects and the
signed routing objects signed routing objects
The architecture described by this document supports, at a minimum, The architecture described by this document enables an entity to
two aspects of routing security; it enables an entity to verifiably verifiably assert that it is the legitimate holder of a set of IP
assert that it is the legitimate holder of a set of IP addresses or a addresses or a set of Autonomous System (AS) numbers. As an initial
set of Autonomous System (AS) numbers, and it allows the holder of IP application of this architecture, the document describes how a holder
address space to explicitly and verifiably authorize one or more ASes of IP address space can explicitly and verifiably authorize one or
to originate routes to that address space. In addition to these more ASes to originate routes to that address space. Such verifiable
initial applications, the infrastructure defined by this architecture authorizations could be used, for example, to more securely construct
also is intended to be able to support security protocols such as S- BGP route filters. In addition to this initial application, the
BGP [10] or soBGP [11]. This architecture is applicable to the infrastructure defined by this architecture also is intended to
routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently provide future support for security protocols such as S-BGP [10] or
the only address families supported by this architecture. Thus, for soBGP [11]. This architecture is applicable to the routing of both
example, use of this architecture with MPLS labels is beyond the IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only address
scope of this document. families supported by this architecture. Thus, for example, use of
this architecture with MPLS labels is beyond the scope of this
document.
In order to facilitate deployment, the architecture takes advantage In order to facilitate deployment, the architecture takes advantage
of existing technologies and practices. The structure of the PKI of existing technologies and practices. The structure of the PKI
element of the architecture corresponds to the existing resource element of the architecture corresponds to the existing resource
allocation structure. Thus management of this PKI is a natural allocation structure. Thus management of this PKI is a natural
extension of the resource-management functions of the organizations extension of the resource-management functions of the organizations
that are already responsible for IP address and AS number resource that are already responsible for IP address and AS number resource
allocation. Likewise, existing resource allocation and revocation allocation. Likewise, existing resource allocation and revocation
practices have well-defined correspondents in this architecture. To practices have well-defined correspondents in this architecture. To
ease implementation, existing IETF standards are used wherever ease implementation, existing IETF standards are used wherever
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 infrastructure 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
(Route Origination Authorizations and manifests) used by the (including route origination authorizations and manifests) used by
infrastructure; and a distributed repository system that makes all of the infrastructure; and a distributed repository system that makes
these signed objects available for use by ISPs in making routing all of these signed objects available for use by ISPs in making
decisions. These three basic components enable several security routing decisions. These three basic components enable several
functions; this document describes how they can be used to improve security functions; this document describes how they can be used to
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
It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [3], and "X.509
Extensions for IP Addresses and AS Identifiers" [5].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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 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
skipping to change at page 5, line 44 skipping to change at page 6, line 4
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 holder of Internet resources who is authorized to sub-allocate
them must be able to issue Resource Certificates to correspond to them must be able to issue Resource Certificates to correspond to
these sub-allocations. Thus, for example, CA certificates will be these sub-allocations. Thus, for example, CA certificates will be
associated with 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 subscribers also will need to
have CA certificates for their allocations, e.g., subscribers with have CA certificates for their allocations, e.g., subscribers with
portable allocations, to enable them to issue ROAs. (A subscriber who portable allocations, to enable them to issue ROAs. (A subscriber who
is not multi-homed, whose allocation comes from an LIR/ISP, and who is not multi-homed, whose allocation comes from an LIR/ISP, and who
has not moved to a different LIR/ISP, need not be represented in the has not moved to a different LIR/ISP, need not be represented in the
PKI. Moreover, a multi-homed subscriber with an allocation from an PKI. Moreover, a multi-homed subscriber with an allocation from an
LIR/ISP may or may not need to be explicitly represented, as LIR/ISP may or may not need to be explicitly represented, as
discussed in Section 6.2.2) discussed in Section 6.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, then the distinguished name of the subject certificate is an RIR or IANA, then the distinguished name of the
will be chosen to convey the identity of the registry and should subject will be chosen to convey the identity of the registry and
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, (e.g., the subject is If the subject of a certificate is not an RIR or IANA, (e.g., the
a NIR, or LIR/ISP) the distinguished name MUST consist only of the subject is a NIR, or LIR/ISP) the distinguished name MUST consist
common name attribute and must not attempt to convey the identity of only of the common name attribute and must not attempt to convey the
the subject in a descriptive fashion. Additionally, the subject's identity of the subject in a descriptive fashion. Additionally, the
distinguished name must be unique among all certificates issued by a subject's distinguished name must be unique among all certificates
given authority. In this PKI, the certificate issuer, being an issued by a given authority. In this PKI, the certificate issuer,
internet registry or LIR/ISP, is not in the business of verifying the being an internet registry or LIR/ISP, is not in the business of
legal right of the subject to assert a particular identity. verifying the legal right of the subject to assert a particular
Therefore, selecting a distinguished name that does not convey the identity. Therefore, selecting a distinguished name that does not
identity of the subject in a descriptive fashion minimizes the convey the identity of the subject in a descriptive fashion minimizes
opportunity for the subject to misuse the certificate to assert an the opportunity for the subject to misuse the certificate to assert
identity, and thus minimizes the legal liability of the issuer. Since an identity, and thus minimizes the legal liability of the issuer.
all CA certificates are issued to subjects with whom the issuer has Since all CA certificates are issued to subjects with whom the issuer
an existing relationship, it is recommended that the issuer select a has an existing relationship, it is recommended that the issuer
subject name that enables the issuer to easily link the certificate select a subject name that enables the issuer to easily link the
to existing database records associated with the subject. For certificate to existing database records associated with the subject.
example, an authority may use internal database keys or subscriber For example, an authority may use internal database keys or
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
its holder, so entities that have allocations from multiple sources its holder, so entities that have allocations from multiple sources
will have multiple CA certificates. A CA also may issue distinct will have multiple CA certificates. A CA also may issue distinct
certificates for each distinct allocation to the same entity, if the certificates for each distinct allocation to the same entity, if the
CA and the resource holder agree that such an arrangement will CA and the resource holder agree that such an arrangement will
facilitate management and use of the certificates. For example, an facilitate management and use of the certificates. For example, an
LIR/ISP may have several certificates issued to it by one registry, LIR/ISP may have several certificates issued to it by one registry,
each describing a distinct set of address blocks, because the LIR/ISP each describing a distinct set of address blocks, because the LIR/ISP
desires to treat the allocations as separate. desires to treat the allocations as separate.
skipping to change at page 7, line 30 skipping to change at page 7, line 37
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.
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 defines 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 holder of
the specified resources. This could facilitate authentication of the specified resources. This could facilitate authentication of
inter-ISP interactions, or authentication of interactions with the inter-ISP interactions, or authentication of interactions with the
repository system. These additional uses for end-entity certificates repository system. These additional uses for end-entity certificates
may require retention of the corresponding private keys, even though may require retention of the corresponding private keys, even though
this is not required for the private keys associated with end-entity this 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.
skipping to change at page 8, line 5 skipping to change at page 8, line 16
In any PKI, each relying party (RP) is free to choose its own set of In any PKI, each relying party (RP) is free to choose its own set of
trust anchors. This general property of PKIs applies here as well. trust anchors. This general property of PKIs applies here as well.
There is an extant IP address space and AS number allocation There is an extant IP address space and AS number allocation
hierarchy. IANA is the obvious candidate to be the TA, but hierarchy. IANA is the obvious candidate to be the TA, but
operational considerations may argue for a multi-TA PKI, e.g., one in operational considerations may argue for a multi-TA PKI, e.g., one in
which both IANA and the RIRs form a default set of trust anchors. which both IANA and the RIRs form a default set of trust anchors.
Nonetheless, every relying party is free to choose a different set of Nonetheless, every relying party is free to choose a different set of
trust anchors to use for certificate validation operations. trust anchors to use for certificate validation operations.
For example, an RP (e.g., an LIR/ISP) could create a self-signed For example, an RP (e.g., an LIR/ISP) could create a trust anchor to
certificate to which all address space and/or all AS numbers are which all address space and/or all AS numbers are assigned, and for
assigned, and for which the RP knows the corresponding private key. which the RP knows the corresponding private key. The RP could then
The RP could then issue certificates under this trust anchor to issue certificates under this trust anchor to whatever entities in
whatever entities in the PKI it wishes, with the result that the the PKI it wishes, with the result that the certificate paths
certificate paths terminating at this locally-installed trust anchor terminating at this locally-installed trust anchor will satisfy the
will satisfy the RFC 3779 validation requirements. RFC 3779 validation requirements.
An RP who elects to create and manage its own set of trust anchors An RP who elects to create and manage its own set of trust anchors
may fail to detect allocation errors that arise under such may fail to detect allocation errors that arise under such
circumstances, but the resulting vulnerability is local to the RP. circumstances, but the resulting vulnerability is local to the RP.
2.5. Default Trust Anchor Considerations 2.5. Default Trust Anchors
The profile for resource certificates [6] specifies a format for a
putative trust anchor to distribute to relying parties trust anchor
material consisting of both a self-signed certificate (which would
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 IANA forms the root of the extant IP address space and AS number
allocation hierarchy. Therefore, it is natural to consider a model in allocation hierarchy. Therefore, it is expected that IANA will
which most relying parties have as their single trust anchor a self- provide to relying parties trust anchor material whose self-signed
signed IANA certificate whose RFC 3779 extensions specify the certificate has RFC 3779 extensions corresponding either to the
entirety of the AS number and IP address spaces. 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 such model, consider the use of private IP address As an example of the use of IANA as a trust anchor, consider the use
space (i.e., 10/8, 172.16/12, and 192.168/16 in IPv4 and FC00::/7 in of private IP address space (i.e., 10/8, 172.16/12, and 192.168/16 in
IPv6). IANA could issue a CA certificate for these blocks of private IPv4 and FC00::/7 in IPv6). IANA could issue a CA certificate for
address space and then destroy the private key corresponding to the these blocks of private address space and then destroy the private
public key in the certificate. In this way, any relying party who key corresponding to the public key in the certificate. In this way,
configured IANA as their sole trust anchor would automatically reject any relying party who configured IANA as their sole trust anchor
any ROA containing private addresses, appropriate behavior with would automatically reject any ROA containing private addresses,
regard to routing in the public Internet. On the other hand, such an appropriate behavior with regard to routing in the public Internet.
approach would not interfere with an organization that wishes to use On the other hand, such an approach would not interfere with an
private address space in conjunction with BGP and this PKI organization that wishes to use private address space in conjunction
technology. Such an organization could configure its relying parties with BGP and this PKI technology. Such an organization could
with an additional, local trust anchor that issues certificates for configure its relying parties with an additional, local trust anchor
private addresses used within the organization. In this manner, BGP that issues certificates for private addresses used within the
advertisements for these private addresses would be accepted within organization. In this manner, BGP advertisements for these private
the organization but would be rejected if mistakenly sent outside the addresses would be accepted within the organization but would be
private address space context in question. 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 In the DNSSEC context, IANA (as the root of the DNS) is already
experimenting with the operational procedures needed to digitally experimenting with the operational procedures needed to digitally
sign the root zone. This is very much analogous to the role it would 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 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, though DNSSEC does not make use of X.509 certificates. Nonetheless,
it is appropriate consider alternative default trust anchor models, it is appropriate consider alternative default trust anchor models,
if IANA does not act in this capacity. This motivates the if IANA does not act in this capacity. This motivates the
consideration of alternative default trust anchor options for RPKI consideration of alternative default trust anchor options for RPKI
relying parties. relying parties.
Essentially all allocated IP address and AS number resources are sub- Essentially all allocated IP address and AS number resources are sub-
allocated by IANA to one of the five RIRs. Therefore, one could allocated by IANA to one of the five RIRs. Therefore, it is expected
consider a model in which the default trust anchors are a set of five that each of the five RIRs will provide trust anchor material provide
self-signed certificates, one for each RIR. There are two to relying parties trust anchor material whose self-signed
difficulties that such an approach must overcome. certificate has RFC 3779 extensions corresponding to the IP address
and AS number resources that they manage.
The first difficulty is that IANA retains authority for 44 /8
prefixes in IPv4 and a /26 prefix in IPv6. Therefore, any approach
that recommends the RIRs as default trust anchors will also require
as a default trust anchor an IANA certificate who's RFC 3779
extensions correspond to this address space. Additionally, there are
about 49 /8 prefixes containing legacy 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.
The second difficulty is that the resource allocations of the RIRs One issue that the RIRs will need to consider when providing trust
may change several times a year. Typically in a PKI, trust anchors anchor material is how to handle the approximately 49 /8 prefixes
are quite long-lived and distributed to relying parties via some out- containing legacy IPv4 allocations that are not each allocated to a
of-band mechanism. However, such out-of-band distribution of new single RIR. Currently, for the purpose of administering reverse DNS
trust anchors is not feasible if the allocations change every few zones, each of these prefixes is administered by a single RIR who
months. Therefore, any approach that recommends the RIRs as default delegates authority for allocations within the prefix as appropriate.
trust anchors must provide an in-band mechanism for managing the This existing arrangement could be used as the template for the
changes that will occur in the RIR allocations (as expressed via RFC assignment of administrative responsibility for the certification of
3779 extensions). 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.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.
skipping to change at page 11, line 36 skipping to change at page 11, line 44
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. 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 (3) a flag indicating number; (2) a list of IP address prefixes; and, optionally, (3) for
whether an exact match is required between the IP address prefix(es) each prefix, the maximum length of more specific (longer) prefixes
of the ROA and the IP address prefix(es) originated by the AS, or that the AS is also authorized to advertise. (This last element
whether the AS is also authorized to advertise long (more specific) facilitates a compact authorization to advertise, for example, any
prefixes. prefixes of length 20 to 24 contained within a given length 20
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
skipping to change at page 13, line 13 skipping to change at page 13, line 49
routes for these allocations, must issue multiple ROAs to the AS. routes for these allocations, must issue multiple ROAs to the AS.
4. Repositories 4. Repositories
Initially, an LIR/ISP will make use of the resource PKI by acquiring Initially, an LIR/ISP will make use of the resource PKI by acquiring
and validating every ROA, to create a table of the prefixes for which and validating every ROA, to create a table of the prefixes for which
each AS is authorized to originate routes. To validate all ROAs, an each AS is authorized to originate routes. To validate all ROAs, an
LIR/ISP needs to acquire all the certificates and CRLs. The primary LIR/ISP needs to acquire all the certificates and CRLs. The primary
function of the distributed repository system described here is to function of the distributed repository system described here is to
store these signed objects and to make them available for download by store these signed objects and to make them available for download by
LIRs/ISPs. The digital signatures on all objects in the repository LIRs/ISPs. Note that this repository system provides a mechanism by
ensure that unauthorized modification of valid objects is detectable which relying parties can pull fresh data at whatever frequency they
by relying parties. Additionally, the repository system uses deem appropriate. However, it does not provide a mechanism for
manifests (see Section 5) to ensure that relying parties can detect pushing fresh data to relying parties (e.g. by including resource PKI
the deletion of valid objects and the insertion of out of date, valid objects in BGP or other protocol messages) and such a mechanism is
signed objects. beyond the scope of the current document.
The digital signatures on all objects in the repository ensure that
unauthorized modification of valid objects is detectable by relying
parties. Additionally, the repository system uses manifests (see
Section 5) to ensure that relying parties can detect the deletion of
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 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.
skipping to change at page 21, line 24 skipping to change at page 22, line 12
generate one or more EE certificates and associated ROAs to enable generate one or more EE certificates and associated ROAs to enable
the AS(es) to originate routes for the prefix(es) in question. This the AS(es) to originate routes for the prefix(es) in question. This
ROA is required because none of the ISP's existing ROAs authorize it ROA is required because none of the ISP's existing ROAs authorize it
to originate routes to that portable allocation. to originate routes to that portable allocation.
7.3. Route filter construction 7.3. Route filter construction
The goal of this architecture is to support improved routing The goal of this architecture is to support improved routing
security. One way to do this is to use ROAs to construct route security. One way to do this is to use ROAs to construct route
filters that reject routes that conflict with the origination filters that reject routes that conflict with the origination
authorizations asserted by current ROAs, which can be accomplished authorizations asserted by current ROAs. The following is intended to
with the following procedure: 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 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.
contained in files with a ''.roa'' suffix, so missing ROAs are
readily detected.)
4. Validate each ROA by verifying that it's signature is verifiable 4. Validate each ROA by verifying that its 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
a given IP address prefix, all routes that the BGP speaker accepts 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 for that prefix were originated by an AS that is authorized by the
owner of the prefix to authorize routes to that prefix. owner of the prefix to authorize routes to that prefix.
The first three steps in the above procedure might incur a The first three steps in the above procedure might incur a
substantial overhead if all objects in the repository system were substantial overhead if all objects in the repository system were
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 may choose any
schedule to download updates from the repository, upload any frequency it desires for downloading updates from the repository,
modifications it has made, and construct route filters. 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 It should be noted that the transition to 4-byte AS numbers (see RFC
4893 [13]) 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
skipping to change at page 24, line 15 skipping to change at page 25, line 15
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] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
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
3280, April 2002. 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-
09, November 2007. 14, October 2008.
[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-02, Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-04,
February 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-00, January Infrastructure'', draft-ietf-sidr-rpki-manifests-04, October
2008. 2008.
11.2. Informative References 11.2. Informative References
[9] Huston, G., Michaelson, G., and Loomans, R., ''A Profile for [9] Huston, G., Michaelson, G., and Loomans, R., ''A Profile for
Resource Certificate Repository Structure'', draft-huston-sidr- Resource Certificate Repository Structure'', draft-ietf-sidr-
repos-struct-01, February 2008. repos-struct-01, October 2008.
[10] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway [10] 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- [11] 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, [12] 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 [13] Vohra, Q., and Chen, E., ''BGP Support for Four-octet AS Number
Space'', RFC 4893, May 2007. Space'', RFC 4893, May 2007.
[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
 End of changes. 36 change blocks. 
171 lines changed or deleted 202 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/