draft-ietf-sidr-arch-05.txt   draft-ietf-sidr-arch-06.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 March 9, 2009 Intended status: Informational March 9, 2009
Expires: September 9, 2009 Expires: September 9, 2009
An Infrastructure to Support Secure Internet Routing An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-05.txt draft-ietf-sidr-arch-06.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 2, line 20 skipping to change at page 2, line 20
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
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..............................8
2.4. Trust Anchors.............................................8 2.4. Trust Anchors.............................................8
2.5. Default Trust Anchor Considerations.....Error! Bookmark not 2.5. Representing Early-Registration Transfers (ERX)...........9
defined.
2.6. Representing Early-Registration Transfers (ERX)...........9
3. Route Origination Authorizations..............................10 3. Route Origination Authorizations..............................10
3.1. Role in the overall architecture.........................10 3.1. Role in the overall architecture.........................11
3.2. Syntax and semantics.....................................11 3.2. Syntax and semantics.....................................11
4. Repositories..................................................12 4. Repositories..................................................13
4.1. Role in the overall architecture.........................13 4.1. Role in the overall architecture.........................13
4.2. Contents and structure...................................13 4.2. Contents and structure...................................14
4.3. Access protocols.........................................15 4.3. Access protocols.........................................15
4.4. Access control...........................................15 4.4. Access control...........................................16
5. Manifests.....................................................16 5. Manifests.....................................................16
5.1. Syntax and semantics.....................................16 5.1. Syntax and semantics.....................................16
6. Local Cache Maintenance.......................................17 6. Local Cache Maintenance.......................................17
7. Common Operations.............................................18 7. Common Operations.............................................18
7.1. Certificate issuance.....................................18 7.1. Certificate issuance.....................................18
7.2. ROA management...........................................19 7.2. ROA management...........................................19
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 (without portable allocations)20
7.2.3. Portable allocations................................21 7.2.3. Portable allocations................................21
7.3. Route filter construction......Error! Bookmark not defined.
8. Security Considerations.......................................21 8. Security Considerations.......................................21
9. IANA Considerations...........................................21 9. IANA Considerations...........................................21
10. Acknowledgments..............................................21 10. Acknowledgments..............................................22
11. References...................................................23 11. References...................................................23
11.1. Normative References....................................23 11.1. Normative References....................................23
11.2. Informative References..................................23 11.2. Informative References..................................23
Authors' Addresses...............................................24 Authors' Addresses...............................................24
Intellectual Property Statement..................................24 Pre-5378 Material Disclaimer.....................................24
Disclaimer of Validity.................Error! Bookmark not defined.
1. Introduction 1. Introduction
This document describes an architecture for an infrastructure to This document describes an architecture for an infrastructure to
support improved security for BGP routing [2] for the Internet. The support improved security for BGP routing [2] for the Internet. The
architecture encompasses three principle elements: architecture encompasses three principle elements:
. a public key infrastructure (PKI) . a public key infrastructure (PKI)
. digitally-signed routing objects to support routing security . digitally-signed routing objects to support routing security
skipping to change at page 7, line 20 skipping to change at page 7, line 17
. 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 or IANA, (e.g., If the subject of a certificate is not an RIR or IANA, (e.g.,
the subject is a NIR, or LIR/ISP) the distinguished name must not the subject is a NIR, or LIR/ISP) the distinguished name must not
attempt to convey the identity of the subject in a descriptive attempt to convey the identity of the subject in a descriptive
fashion. The subject's distinguished name must be unique among all fashion. The subject's distinguished name must be unique among all
certificates issued by a given authority. In this PKI, the certificates issued by a given authority. It is RECOMMENDED that the
certificate issuer, being an RIR, NIR, or LIR/ISP, is not in the distinguished name consist of two attributes: common name and serial.
business of verifying the legal right of the subject to assert a The common name should be a string that is consistent among all
particular identity. Therefore, selecting a distinguished name that certificates issued by a given authority to a given subject (this
does not convey the identity of the subject in a descriptive fashion allows an authority to correlate certificates issued to the same
minimizes the opportunity for the subject to misuse the certificate subject). The serial attribute should be a string that changes each
to assert an identity, and thus minimizes the legal liability of the time the certificate is re-issued (e.g. key roll-over), which
issuer. Since all CA certificates are issued to subjects with whom facilitates the uniqueness of distinguished names across all
the issuer has an existing relationship, it is recommended that the certificates issued by a given authority.
issuer select a subject name that enables the issuer to easily link
the certificate to existing database records associated with the In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP,
subject. For example, an authority may use internal database keys or is not in the business of verifying the legal right of the subject to
subscriber IDs as the subject common name in issued certificates. assert a particular identity. Therefore, selecting a distinguished
name that does not convey the identity of the subject in a
descriptive fashion minimizes the opportunity for the subject to
misuse the certificate to assert an identity, and thus minimizes the
legal liability of the issuer. Since all CA certificates are issued
to subjects with whom the issuer has an existing relationship, it is
recommended that the issuer select a subject name that enables the
issuer to easily link the certificate to existing database records
associated with the subject. For example, an authority may use
internal database keys or subscriber IDs as the subject common name
in issued certificates.
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. A CA also may issue
distinct certificates for each distinct allocation to the same distinct certificates for each distinct allocation to the same
entity, if the CA and the resource holder agree that such an 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.
 End of changes. 13 change blocks. 
27 lines changed or deleted 34 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/