< draft-ietf-sidr-arch-10.txt   draft-ietf-sidr-arch-11.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 September 21, 2010 Intended status: Informational September 21, 2010
Expires: March 21, 2011 Expires: March 21, 2011
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-10.txt draft-ietf-sidr-arch-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
disseminating the data objects that comprise the PKI, as well as disseminating the data objects that comprise the PKI, as well as
other signed objects necessary for improved routing security. As an other signed objects necessary for improved routing security. As an
initial application of this architecture, the document describes how initial application of this architecture, the document describes how
a legitimate holder of IP address space can explicitly and verifiably a legitimate holder of IP address space can explicitly and verifiably
authorize one or more ASes to originate routes to that address space. authorize one or more ASes to originate routes to that address space.
Such verifiable authorizations could be used, for example, to more Such verifiable authorizations could be used, for example, to more
securely construct BGP route filters. securely construct BGP route filters.
Table of Contents Table of Contents
1. Introduction ............................................... 3 1. Introduction ............................................. 3
1.1. Terminology ........................................... 4 1.1. Terminology ......................................... 4
2. PKI for Internet Number Resources .......................... 5 2. PKI for Internet Number Resources ........................ 5
2.1. Role in the overall architecture ...................... 5 2.1. Role in the overall architecture .................... 5
2.2. CA Certificates ....................................... 6 2.2. CA Certificates ..................................... 6
2.3. End-Entity (EE) Certificates .......................... 7 2.3. End-Entity (EE) Certificates ........................ 7
2.4. Trust Anchors ......................................... 8 2.4. Trust Anchors ....................................... 8
3. Route Origination Authorizations ........................... 9 3. Route Origination Authorizations ......................... 9
3.1. Role in the overall architecture ...................... 9 3.1. Role in the overall architecture .................... 9
3.2. Syntax and semantics .................................. 10 3.2. Syntax and semantics ................................ 10
4. Repositories ............................................... 11 4. Repositories ............................................. 11
4.1. Role in the overall architecture ...................... 12 4.1. Role in the overall architecture .................... 12
4.2. Contents and structure ................................ 12 4.2. Contents and structure .............................. 12
4.3. Access protocols ...................................... 14 4.3. Access protocols .................................... 14
4.4. Access control ........................................ 15 4.4. Access control ...................................... 15
5. Manifests .................................................. 15 5. Manifests ................................................ 15
5.1. Syntax and semantics .................................. 15 5.1. Syntax and semantics ................................ 15
6. Local Cache Maintenance .................................... 16 6. Local Cache Maintenance .................................. 16
7. Common Operations .......................................... 17 7. Common Operations ........................................ 17
7.1. Certificate issuance .................................. 17 7.1. Certificate issuance ................................ 17
7.2. CA Key Rollover ....................................... 18 7.2. CA Key Rollover ..................................... 18
7.3. ROA management ........................................ 19 7.3. ROA management ...................................... 19
7.3.1. Single-homed subscribers (with PA address space) . 20 7.3.1. Single-homed subscribers ....................... 20
7.3.2. Multi-homed subscribers (with PA address space) .. 20 7.3.2. Multi-homed subscribers ........................ 20
7.3.3. Provider-Independent Address Space ............... 21 7.3.3. Provider-Independent Address Space ............. 21
8. Security Considerations .................................... 21 8. Security Considerations .................................. 21
9. IANA Considerations ........................................ 21 9. IANA Considerations ...................................... 21
10. Acknowledgments ........................................... 22 10. Acknowledgments ......................................... 22
11. References ................................................ 23 11. References .............................................. 23
11.1. Normative References ................................. 23 11.1. Normative References ............................... 23
11.2. Informative References ............................... 24 11.2. Informative References ............................. 24
Authors' Addresses ............................................ 25 Authors' Addresses .......................................... 25
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 [RFC 4271] for the support improved security for BGP routing [RFC 4271] for the
Internet. The architecture encompasses three principle elements: Internet. The 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 16, line 49 skipping to change at page 16, line 49
administrator that the repository data has been corrupted. administrator that the repository data has been corrupted.
4. Validate each EE certificate by constructing and verifying a 4. Validate each EE certificate by constructing and verifying a
certification path for the certificate (including checking certification path for the certificate (including checking
relevant CRLs) to the locally configured set of TAs. (See [RES- relevant CRLs) to the locally configured set of TAs. (See [RES-
CERT] for more details.) CERT] for more details.)
Note that since relying parties will perform these operations Note that since relying parties will perform these operations
regularly, it is more efficient for the relying party to request from regularly, it is more efficient for the relying party to request from
the repository system only those objects that have changed since the the repository system only those objects that have changed since the
relying party last updated its local cache. A relying party may relying party last updated its local cache.
choose any frequency it desires for downloading and validating
updates from the repository. However, any relying party that uses
RPKI data as an input to operational routing decisions (e.g., ISPs,
RIRs, NIRs) SHOULD download and validate updates at least once every
three hours.
Note also that by checking all issued objects against the appropriate Note also that by checking all issued objects against the appropriate
manifest, the relying party can be certain that it is not missing an manifest, the relying party can be certain that it is not missing an
updated version of any object. updated 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
skipping to change at page 20, line 8 skipping to change at page 20, line 4
corresponding end-entity certificate by creating an appropriate CRL corresponding end-entity certificate by creating an appropriate CRL
and uploading it to the repository system. The revoked ROA and end- and uploading it to the repository system. The revoked ROA and end-
entity certificate SHOULD be removed from the repository system. entity certificate SHOULD be removed from the repository system.
Care must be taken when revoking ROAs in that revoking a ROA may Care must be taken when revoking ROAs in that revoking a ROA may
cause a relying party to treat routing advertisements corresponding cause a relying party to treat routing advertisements corresponding
to the prefixes and origin AS number in the ROA as unauthorized (and to the prefixes and origin AS number in the ROA as unauthorized (and
potentially even change routing behavior to no longer forward packets potentially even change routing behavior to no longer forward packets
based on those advertisements). In particular, resource holders based on those advertisements). In particular, resource holders
should adhere to the principle of "make before break" as follows. should adhere to the principle of "make before break" as follows.
Before revoking a ROA corresponding to a prefix which the resource Before revoking a ROA corresponding to a prefix which the resource
holder wishes to be routable on the Internet, it is very important holder wishes to be routable on the Internet, it is very important
for the resource holder to ensure that there exists another valid for the resource holder to ensure that there exists another valid
alternative ROA that lists the same prefix (possibly indicating a alternative ROA that lists the same prefix (possibly indicating a
different AS number). Additionally, the resource holder should ensure different AS number). Additionally, the resource holder should ensure
that the AS indicated in the valid alternative ROA is actually that the AS indicated in the valid alternative ROA is actually
originating routing advertisements to the prefixes in question. originating routing advertisements to the prefixes in question.
Furthermore, a relying party must fetch new ROAs from the repository Furthermore, a relying party must fetch new ROAs from the repository
system before taking any routing action in response to a ROA system before taking any routing action in response to a ROA
revocation. revocation.
7.3.1. Single-homed subscribers (with PA address space) 7.3.1. Single-homed subscribers
In BGP, a single-homed subscriber with Provider Aggregatable (PA) In BGP, a single-homed subscriber with Provider Aggregatable (PA)
address space does not need to explicitly authorize routes to be address space does not need to explicitly authorize routes to be
originated for the prefix(es) it is using, since its ISP will already originated for the prefix(es) it is using, since its ISP will already
advertise a more general prefix and route traffic for the advertise a more general prefix and route traffic for the
subscriber's prefix as an internal function. Since no routes are subscriber's prefix as an internal function. Since no routes are
originated specifically for prefixes held by these subscribers, no originated specifically for prefixes held by these subscribers, no
ROAs need to be issued under their allocations; rather, the ROAs need to be issued under their allocations; rather, the
subscriber's ISP will issue any necessary ROAs for its more general subscriber's ISP will issue any necessary ROAs for its more general
prefixes under resource certificates from its own allocation. Thus, a prefixes under resource certificates from its own allocation. Thus, a
single-homed subscriber with an IP address allocation from his single-homed subscriber with an IP address allocation from his
service provider is not included in the RPKI, i.e., it does not service provider is not included in the RPKI, i.e., it does not
receive a CA certificate, nor issue EE certificates or ROAs. receive a CA certificate, nor issue EE certificates or ROAs.
7.3.2. Multi-homed subscribers (with PA address space) 7.3.2. Multi-homed subscribers
Here we consider a subscriber who receives Provider Aggregatable (PA) Here we consider a subscriber who receives Provider Aggregatable (PA)
IP address space from a primary ISP (i.e., the IP addresses used by IP address space from a primary ISP (i.e., the IP addresses used by
the subscriber are a subset of ISP A's IP address space allocation) the subscriber are a subset of ISP A's IP address space allocation)
and receives redundant upstream connectivity from one or more and receives redundant upstream connectivity from one or more
secondary ISPs, in addition to the primary ISP. The preferred option secondary ISPs, in addition to the primary ISP. The preferred option
for such a multi-homed subscriber is for the subscriber to obtain an for such a multi-homed subscriber is for the subscriber to obtain an
AS number (from an RIR or NIR) and run BGP with each of its upstream AS number (from an RIR or NIR) and run BGP with each of its upstream
providers. In such a case, there are two ways for ROA management to providers. In such a case, there are two ways for ROA management to
be handled. The first is that the primary ISP issues a CA certificate be handled. The first is that the primary ISP issues a CA certificate
 End of changes. 6 change blocks. 
41 lines changed or deleted 37 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/