draft-ietf-sidr-arch-07.txt   draft-ietf-sidr-arch-08.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 July 13, 2009 Intended status: Informational July 29, 2009
Expires: January 13, 2010 Expires: January 29, 2010
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-07.txt draft-ietf-sidr-arch-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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 September 13, 2009. This Internet-Draft will expire on January 29, 20010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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......................................9 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...........................................14 4.4. Access control...........................................14
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. ROA management...........................................18 7.2. ROA management...........................................18
7.2.1. Single-homed subscribers (without provider independent 7.2.1. Single-homed subscribers (without provider independent
addresses).................................................19 addresses).................................................19
7.2.2. Multi-homed subscribers (without provider independent 7.2.2. Multi-homed subscribers (without provider independent
addresses).................................................19 addresses).................................................19
7.2.3. Provider-Independent Address Space..................20 7.2.3. Provider-Independent Address Space..................20
8. Security Considerations.......................................20 8. Security Considerations.......................................20
9. IANA Considerations...........................................20 9. IANA Considerations...........................................20
10. Acknowledgments..............................................20 10. Acknowledgments..............................................21
11. References...................................................22 11. References...................................................22
11.1. Normative References....................................22 11.1. Normative References....................................22
11.2. Informative References..................................22 11.2. Informative References..................................22
Authors' Addresses...............................................23 Authors' Addresses...............................................23
Pre-5378 Material Disclaimer.....................................23 Pre-5378 Material Disclaimer.....................................23
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
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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, the
is intended to provide authorization, but not authentication. This is resource PKI is intended to provide authorization, but not
in contrast to most PKIs where the issuer ensures that the authentication. This is in contrast to most PKIs where the issuer
descriptive subject name in a certificate is properly associated with ensures that the descriptive subject name in a certificate is
the entity that holds the private key corresponding to the public key properly associated with the entity that holds the private key
in the certificate. Because issuers need not verify the right of an corresponding to the public key in the certificate. Because issuers
entity to use a subject name in a certificate, they avoid the costs need not verify the right of an entity to use a subject name in a
and liabilities of such verification. This makes it easier for these certificate, they avoid the costs and liabilities of such
entities to take on the additional role of Certificate Authority verification. This makes it easier for these entities to take on the
(CA). additional role of Certificate Authority (CA).
Most of the certificates in the PKI assert the basic facts on which Most of the certificates in the PKI assert the basic facts on which
the rest of the infrastructure operates. CA certificates within the the rest of the infrastructure operates. CA certificates within the
PKI attest to IP address space and AS number holdings. End-entity PKI attest to IP address space and AS number holdings. End-entity
(EE) certificates are issued by resource holder CAs to delegate the (EE) certificates are issued by resource holder CAs to delegate the
authority attested by their allocation certificates. The primary use authority attested by their allocation certificates. The primary use
for EE certificates is the validation of Route Origination for EE certificates is the validation of Route Origination
Authorizations (ROAs). Additionally, signed objects called manifests Authorizations (ROAs). Additionally, signed objects called manifests
will be used to help ensure the integrity of the repository system, will be used to help ensure the integrity of the repository system,
and the signature on each manifest will be verified via an EE and the signature on each manifest will be verified via an EE
skipping to change at page 6, line 50 skipping to change at page 6, line 50
independent allocation, to enable them to issue ROAs. (A subscriber independent allocation, 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 who has not moved to a different LIR/ISP, need not be represented in
the PKI. Moreover, a multi-homed subscriber with an allocation from the PKI. Moreover, a multi-homed subscriber with an allocation from
an LIR/ISP may or may not need to be explicitly represented, as an LIR/ISP may or may not need to be explicitly represented, as
discussed in Section 7.2.2) discussed in Section 7.2.2)
Unlike in most PKIs, the distinguished name of the subject in a CA Unlike in most PKIs, the distinguished name of the subject in a CA
certificate is chosen by the certificate issuer. The subject's certificate is chosen by the certificate issuer. The subject's
distinguished name must not attempt to convey the identity of the distinguished name must not attempt to convey the identity of the
subject in a descriptive fashion, and must be unique among all subject in a descriptive fashion. The subject's distinguished name
certificates issued by a given authority. The subject's distinguished must include the common name attribute and may additionally include
name must include the common name attribute and may additionally the serial attribute.
include the serial attribute.
In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP, In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP,
is not in the business of verifying the legal right of the subject to is not in the business of verifying the legal right of the subject to
assert a particular identity. Therefore, selecting a distinguished assert a particular identity. Therefore, selecting a distinguished
name that does not convey the identity of the subject in a name that does not convey the identity of the subject in a
descriptive fashion minimizes the opportunity for the subject to descriptive fashion minimizes the opportunity for the subject to
misuse the certificate to assert an identity, and thus minimizes the misuse the certificate to assert an identity, and thus minimizes the
legal liability of the issuer. Since all CA certificates are issued legal liability of the issuer. Since all CA certificates are issued
to subjects with whom the issuer has an existing relationship, it is to subjects with whom the issuer has an existing relationship, it is
recommended that the issuer select a subject name that enables the recommended that the issuer select a subject name that enables the
issuer to easily link the certificate to existing database records issuer to easily link the certificate to existing database records
associated with the subject. For example, an authority may use associated with the subject. For example, an authority may use
internal database keys or subscriber IDs as the subject common name internal database keys or subscriber IDs as the subject common name
in issued certificates. in issued certificates.
Although the subject's common name in a certificate does not convey
identity, it is still the case that the common name must be unique
among all subjects to whom a certification authority issues
certificates. That is, a CA must not issue certificates to two
different entities which use the same common name for the subject.
Each Resource Certificate attests to an allocation of resources to a Each Resource Certificate attests to an allocation of resources to a
resource holder, so entities that have allocations from multiple resource holder, so entities that have allocations from multiple
sources will have multiple CA certificates. A CA also may issue sources will have multiple CA certificates. Note that when an entity
distinct certificates for each distinct allocation to the same receives multiple certificates from different issuers that the
entity, if the CA and the resource holder agree that such an subject names in these certificates will generally be different. A CA
also may issue distinct certificates for each distinct allocation to
the same entity, if the CA and the resource holder agree that such an
arrangement will facilitate management and use of the certificates. arrangement will facilitate management and use of the certificates.
For example, an LIR/ISP may have several certificates issued to it by For example, an LIR/ISP may have several certificates issued to it by
one registry, each describing a distinct set of address blocks, one registry, each describing a distinct set of address blocks,
because the LIR/ISP desires to treat the allocations as separate. because the LIR/ISP desires to treat the allocations as separate.
2.3. End-Entity (EE) Certificates 2.3. End-Entity (EE) Certificates
The private key corresponding to public key contained in an EE The private key corresponding to public key contained in an EE
certificate is not used to sign other certificates in a PKI. The certificate is not used to sign other certificates in a PKI. The
primary function of end-entity certificates in this PKI is the primary function of end-entity certificates in this PKI is the
skipping to change at page 19, line 5 skipping to change at page 18, line 49
encapsulated in a CMS signed message [7]). encapsulated in a CMS signed message [7]).
4. Upload the end-entity certificate and the ROA to the repository 4. Upload the end-entity certificate and the ROA to the repository
system. system.
The standard procedure for revoking a ROA is to revoke the The standard procedure for revoking a ROA is to revoke the
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
cause a relying party to treat routing advertisements corresponding
to the prefixes and origin AS number in the ROA as unauthorized (and
potentially even change routing behavior to no longer forward packets
based on those advertisements). In particular, resource holders
should adhere to the principle of "make before break" as follows.
Before revoking a ROA corresponding to a prefix which the resource
holder wishes to be routable on the Internet, it is very important
for the resource holder to ensure that there exists another valid
alternative ROA that lists the same prefix (possibly indicating a
different AS number). Additionally, the resource holder should ensure
that the AS indicated in the valid alternative ROA is actually
originating routing advertisements to the prefixes in question.
Furthermore, a relying party must fetch new ROAs from the repository
system before taking any routing action in response to a ROA
revocation.
7.2.1. Single-homed subscribers (without provider independent addresses) 7.2.1. Single-homed subscribers (without provider independent addresses)
In BGP, a single-homed subscriber with provider allocated (non- In BGP, a single-homed subscriber with provider allocated (non-
portable) address space does not need to explicitly authorize routes portable) address space does not need to explicitly authorize routes
to be originated for the prefix(es) it is using, since its ISP will to be originated for the prefix(es) it is using, since its ISP will
already advertise a more general prefix and route traffic for the already 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
 End of changes. 10 change blocks. 
23 lines changed or deleted 47 lines changed or added

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