draft-ietf-sidr-arch-11.txt   draft-ietf-sidr-arch-12.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 February 16, 2011
Expires: March 21, 2011 Expires: August 16, 2011
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-11.txt draft-ietf-sidr-arch-12.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 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 21, 20010. This Internet-Draft will expire on August 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
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 ....................... 20 7.3.1. Single-homed subscribers ....................... 20
7.3.2. Multi-homed subscribers ........................ 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 ............................ 23
Authors' Addresses .......................................... 25 Authors' Addresses ......................................... 24
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 4, line 31 skipping to change at page 4, line 31
security functions; this document describes how they can be used to security functions; this document describes how they can be used to
improve route filter generation, and to perform several other common improve route filter generation, and to perform several other common
operations in such a way as to make them cryptographically operations in such a way as to make them cryptographically
verifiable. verifiable.
1.1. Terminology 1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC 5280], and "X.509 and Certificate Revocation List (CRL) Profile" [RFC 5280], and "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3 779]. Extensions for IP Addresses and AS Identifiers" [RFC 3779].
Throughout this document we use the terms "address space holder" or Throughout this document we use the terms "address space holder" or
"holder of IP address space" interchangeably to refer to a legitimate "holder of IP address space" interchangeably to refer to a legitimate
holder of IP address space who has received this address space holder of IP address space who has received this address space
through the standard IP address allocation hierarchy. That is, the through the standard IP address allocation hierarchy. That is, the
address space holder has either directly received the address space address space holder has either directly received the address space
as an allocation from a Regional Internet Registry (RIR) or IANA; or as an allocation from a Regional Internet Registry (RIR) or IANA; or
else the address space holder has received the address space as a else the address space holder has received the address space as a
sub-allocation from a National Internet Registry (NIR) or Local sub-allocation from a National Internet Registry (NIR) or Local
Internet Registry (LIR). We use the term "resource holder" to refer Internet Registry (LIR). We use the term "resource holder" to refer
to a legitimate holder of either IP address or AS number resources. to a legitimate holder of either IP address or AS number resources.
Throughout this document we use the terms "registry" and ISP to refer Throughout this document we use the terms "registry" and ISP to refer
to an entity that has an IP address space and/or AS number allocation to an entity that has an IP address space and/or AS number allocation
that it is permitted to sub-allocate. that it is permitted to sub-allocate.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC 2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC 2119].
2. PKI for Internet Number Resources 2. PKI for Internet Number Resources
Because the holder of a block of IP address space is entitled to Because the holder of a block of IP address space is entitled to
define the topological destination of IP datagrams whose destinations define the topological destination of IP datagrams whose destinations
fall within that block, decisions about inter-domain routing are fall within that block, decisions about inter-domain routing are
inherently based on knowledge of the allocation of the IP address inherently based on knowledge of the allocation of the IP address
space. Thus, a basic function of this architecture is to provide space. Thus, a basic function of this architecture is to provide
cryptographically verifiable attestations as to these allocations. In cryptographically verifiable attestations as to these allocations. In
current practice, the allocation of IP addresses is hierarchical. The current practice, the allocation of IP addresses is hierarchical. The
skipping to change at page 14, line 44 skipping to change at page 14, line 44
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).
To ensure all relying parties are able to acquire all RPKI signed To ensure all relying parties are able to acquire all RPKI signed
objects, all publication points MUST be accessible via RSYNC (see objects, all publication points MUST be accessible via RSYNC (see
[RFC 5871] and [RSYNC]), although other download protocols also be [RFC 5781] and [RSYNC]), although other download protocols also be
supported. A repository publication point may provide supported. A repository publication point may provide
update/change/delete functionality via (set of) access protocols that update/change/delete functionality via (set of) access protocols that
it desires, provided that the supported protocols are clearly it desires, provided that the supported protocols are clearly
communicated to all certification authorities publishing data at a communicated to all certification authorities publishing data at a
given publication point. given publication point.
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
skipping to change at page 23, line 28 skipping to change at page 23, line 28
List (CRL) Profile", RFC 5280, May 2008. List (CRL) Profile", RFC 5280, May 2008.
[RFC 5652] Housley, R., "Cryptographic Message Syntax", RFC 5652, [RFC 5652] Housley, R., "Cryptographic Message Syntax", RFC 5652,
September 2009. September 2009.
[RFC 3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC 3779] 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.
[RES-CERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile [RES-CERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile
for X.509 PKIX Resource Certificates", draft-ietf-sidr- for X.509 PKIX Resource Certificates", draft-ietf-sidr-
res-certs, May 2010. res-certs, December 2010.
[ROA-FORM] Lepinski, M., Kent, S., and Kong, D., "A Profile for [ROA-FORM] Lepinski, M., Kent, S., and Kong, D., "A Profile for
Route Origin Authorizations (ROA)", draft-ietf-sidr-roa- Route Origin Authorizations (ROA)", draft-ietf-sidr-roa-
format, September 2010. format, February 2011.
[SIGN-OBJ] Chi, A., Kent, S., and Lepinski, M., "Signed Object [SIGN-OBJ] Chi, A., Kent, S., and Lepinski, M., "Signed Object
Template for the Resource Public Key Infrastructure", Template for the Resource Public Key Infrastructure",
draft-ietf-sidr-rpki-signed-object, September 2010. draft-ietf-sidr-signed-object, February 2010.
[MANIFEST] Austein, R., et al., "Manifests for the Resource Public [MANIFEST] Austein, R., et al., "Manifests for the Resource Public
Key Infrastructure", draft-ietf-sidr-rpki-manifests, May Key Infrastructure", draft-ietf-sidr-rpki-manifests,
2010. November 2010.
[SIDR-ALG] Huston, G., "A Profile for Algorithms and Key Sizes for
use in the Resource Public Key Infrastructure", draft-
ietf-sidr-rpki-algs, May 2010.
[REPOS] Huston, G., Michaelson, G., and Loomans, R., "A Profile [REPOS] Huston, G., Michaelson, G., and Loomans, R., "A Profile
for Resource Certificate Repository Structure", draft- for Resource Certificate Repository Structure", draft-
ietf-sidr-repos-struct, May 2010. ietf-sidr-repos-struct, November 2010.
11.2. Informative References 11.2. Informative References
[KEY-ROLL] Huston, G., Michaelson, G., and Kent, K., "CA Key [KEY-ROLL] Huston, G., Michaelson, G., and Kent, K., "CA Key
Rollover in the RPKI", draft-huston-sidr-keyroll, July Rollover in the RPKI", draft-huston-sidr-keyroll,
2010. December 2010.
[ROA-VALID] Huston, G., Michaelson, G., "Validation of Route [ROA-VALID] Huston, G., Michaelson, G., "Validation of Route
Origination in BGP using the Resource Certificate PKI", Origination in BGP using the Resource Certificate PKI",
draft-ietf-sidr-roa-validation, May 2010. draft-ietf-sidr-roa-validation, November 2010.
[PROVISION] Huston, G., Michaelson, G., Ellacott, B., and Austein,
R., "A Protocol for Provisioning Resource Certificates",
draft-ietf-sidr-rescert-provisioning, May 2010.
[RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI
Scheme", RFC 5781, February 2010. Scheme", RFC 5781, February 2010.
[SIDR-TA] Michaelson, G., Kent, S., and Huston, G., "A Profile for [SIDR-TA] Michaelson, G., Kent, S., and Huston, G., "A Profile for
Trust Anchor Material for the Resource Certificate PKI", Trust Anchor Material for the Resource Certificate PKI",
draft-ietf-sidr-ta, May 2010. draft-ietf-sidr-ta, May 2010.
[S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway [S-BGP] 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.
[soBGP] White, R., "soBGP", May 2005, <ftp://ftp- [soBGP] White, R., "soBGP", May 2005, <ftp://ftp-
eng.cisco.com/sobgp/index.html> eng.cisco.com/sobgp/index.html>
[RSYNC] Tridgell, A., "rsync", March 2008, < [RSYNC] Tridgell, A., "rsync", March 2008, <
http://rsync.samba.org/> http://rsync.samba.org/>
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
 End of changes. 19 change blocks. 
40 lines changed or deleted 33 lines changed or added

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