< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/