< draft-ietf-sidrops-aspa-profile-05.txt		draft-ietf-sidrops-aspa-profile-06.txt >
	Network Working Group A. Azimov		Network Working Group A. Azimov
	Internet-Draft Yandex		Internet-Draft Yandex
	Intended status: Standards Track E. Uskov		Intended status: Standards Track E. Uskov
	Expires: August 26, 2021 JetLend		Expires: 31 January 2022 JetLend
	R. Bush		R. Bush
	Internet Initiative Japan		Internet Initiative Japan
	K. Patel		K. Patel
	Arrcus		Arrcus
	J. Snijders		J. Snijders
	NTT		Fastly
	R. Housley		R. Housley
	Vigil Security		Vigil Security
	February 22, 2021		30 July 2021
	A Profile for Autonomous System Provider Authorization		A Profile for Autonomous System Provider Authorization
	draft-ietf-sidrops-aspa-profile-05		draft-ietf-sidrops-aspa-profile-06
	Abstract		Abstract
	This document defines a standard profile for Autonomous System		This document defines a standard profile for Autonomous System
	Provider Authorization in the Resource Public Key Infrastructure. An		Provider Authorization in the Resource Public Key Infrastructure. An
	Autonomous System Provider Authorization is a digitally signed object		Autonomous System Provider Authorization is a digitally signed object
	that provides a means of verifying that a Customer Autonomous System		that provides a means of verifying that a Customer Autonomous System
	holder has authorized members of Provider set to be its upstream		holder has authorized members of Provider set to be its upstream
	providers and for the Providers to send prefixes received from the		providers and for the Providers to send prefixes received from the
	Customer Autonomous System in all directions including providers and		Customer Autonomous System in all directions including providers and
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on August 26, 2021.		This Internet-Draft will expire on 31 January 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The ASPA Content Type . . . . . . . . . . . . . . . . . . . . 3		2. The ASPA Content Type . . . . . . . . . . . . . . . . . . . . 3
	3. The ASPA eContent . . . . . . . . . . . . . . . . . . . . . . 3		3. The ASPA eContent . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. AFI . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. AFI . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. customerASID . . . . . . . . . . . . . . . . . . . . . . 4		3.3. customerASID . . . . . . . . . . . . . . . . . . . . . . 4
	3.4. providerASSET . . . . . . . . . . . . . . . . . . . . . . 4		3.4. providerASSET . . . . . . . . . . . . . . . . . . . . . . 5
	4. ASPA Validation . . . . . . . . . . . . . . . . . . . . . . . 5		4. ASPA Validation . . . . . . . . . . . . . . . . . . . . . . . 5
	5. ASN.1 Module for the ASPA Content Type . . . . . . . . . . . 5		5. ASN.1 Module for the ASPA Content Type . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The primary purpose of the Resource Public Key Infrastructure (RPKI)		The primary purpose of the Resource Public Key Infrastructure (RPKI)
	is to improve routing security. (See [RFC6480] for more		is to improve routing security. (See [RFC6480] for more
	information.) As part of this infrastructure, a mechanism is needed		information.) As part of this infrastructure, a mechanism is needed
	to verify that a AS has permission from a Customer AS (CAS) holder to		to verify that a AS has permission from a Customer AS (CAS) holder to
	send routes in all directions. The digitally signed Autonomous		send routes in all directions. The digitally signed Autonomous
	System Provider Authorization (ASPA) object provides this		System Provider Authorization (ASPA) object provides this
	verification mechanism.		verification mechanism.
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 19 ¶
	address family received from the customer.		address family received from the customer.
	4. ASPA Validation		4. ASPA Validation
	Before a relying party can use an ASPA to validate a routing		Before a relying party can use an ASPA to validate a routing
	announcement, the relying party MUST first validate the ASPA object		announcement, the relying party MUST first validate the ASPA object
	itself. To validate an ASPA, the relying party MUST perform all the		itself. To validate an ASPA, the relying party MUST perform all the
	validation checks specified in [RFC6488] as well as the following		validation checks specified in [RFC6488] as well as the following
	additional ASPA-specific validation step.		additional ASPA-specific validation step.
	o The autonomous system identifier delegation extension [RFC3779] is		* The autonomous system identifier delegation extension [RFC3779] is
	present in the end-entity (EE) certificate (contained within the		present in the end-entity (EE) certificate (contained within the
	ASPA), and the customer AS number in the ASPA is contained within		ASPA), and the customer AS number in the ASPA is contained within
	the set of AS numbers specified by the EE certificate's autonomous		the set of AS numbers specified by the EE certificate's autonomous
	system identifier delegation extension.		system identifier delegation extension.
	5. ASN.1 Module for the ASPA Content Type		5. ASN.1 Module for the ASPA Content Type
	RPKI-ASPA-2020		RPKI-ASPA-2020
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2020(TBD2) }		pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2020(TBD2) }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	skipping to change at page 7, line 17 ¶		skipping to change at page 7, line 17 ¶
	TBD2 | id-mod-rpki-aspa-2020 | [ThisRFC]		TBD2 | id-mod-rpki-aspa-2020 | [ThisRFC]
	Please add the ASPA to the SMI Security for S/MIME CMS Content Type		Please add the ASPA to the SMI Security for S/MIME CMS Content Type
	(1.2.840.113549.1.9.16.1) registry (https://www.iana.org/assignments/		(1.2.840.113549.1.9.16.1) registry (https://www.iana.org/assignments/
	smi-numbers/smi-numbers.xml#security-smime-1) as follows:		smi-numbers/smi-numbers.xml#security-smime-1) as follows:
	Decimal | Description | Specification		Decimal | Description | Specification
	-----------------------------------------------------------		-----------------------------------------------------------
	TBD | id-ct-ASPA | [ThisRFC]		TBD | id-ct-ASPA | [ThisRFC]
	Please add the ASPA to the RPKI Signed Object registry		Please add Autonomous System Provider Authorization to the RPKI
	(https://www.iana.org/assignments/rpki/rpki.xhtml#signed-objects) as		Signed Object registry (https://www.iana.org/assignments/rpki/
	follows:		rpki.xhtml#signed-objects) as follows:
	Name | OID | Specification		Name | OID | Specification
	-----------------------------------------------------------		--------------------------------------------------------------------------------------
	ASPA | 1.2.840.113549.1.9.16.1.TBD | [ThisRFC]		Autonomous System Provider Authorization | 1.2.840.113549.1.9.16.1.TBD | [ThisRFC]
			Please add an item for the Autonomous System Provider Authorization
			file extension to the "RPKI Repository Name Scheme" registry created
			by [RFC6481] as follows:
			Filename
			Extension RPKI Object Reference
			--------------------------------------------------------------------------------------
			.asa Autonomous System Provider Authorization [draft-ietf-sidrops-aspa-profile]
	7. Security Considerations		7. Security Considerations
	While it's not restricted, but it's highly recommended maintaining		While it's not restricted, but it's highly recommended maintaining
	for selected Customer AS a single ASPA object that covers all its		for selected Customer AS a single ASPA object that covers all its
	providers. Such policy should prevent race conditions during ASPA		providers. Such policy should prevent race conditions during ASPA
	updates that might affect prefix propagation. The software that		updates that might affect prefix propagation. The software that
	provides hosting for ASPA records SHOULD support enforcement of this		provides hosting for ASPA records SHOULD support enforcement of this
	rule. In the case of the transition process between different CA		rule. In the case of the transition process between different CA
	registries, the ASPA records SHOULD be kept identical in all		registries, the ASPA records SHOULD be kept identical in all
	skipping to change at page 8, line 14 ¶		skipping to change at page 8, line 23 ¶
	[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP		[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
	Addresses and AS Identifiers", RFC 3779,		Addresses and AS Identifiers", RFC 3779,
	DOI 10.17487/RFC3779, June 2004,		DOI 10.17487/RFC3779, June 2004,
	<https://www.rfc-editor.org/info/rfc3779>.		<https://www.rfc-editor.org/info/rfc3779>.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, DOI 10.17487/RFC5652, September 2009,		RFC 5652, DOI 10.17487/RFC5652, September 2009,
	<https://www.rfc-editor.org/info/rfc5652>.		<https://www.rfc-editor.org/info/rfc5652>.
			[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
			Resource Certificate Repository Structure", RFC 6481,
			DOI 10.17487/RFC6481, February 2012,
			<https://www.rfc-editor.org/info/rfc6481>.
	[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for		[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
	Use in the Resource Public Key Infrastructure (RPKI)",		Use in the Resource Public Key Infrastructure (RPKI)",
	RFC 6485, DOI 10.17487/RFC6485, February 2012,		RFC 6485, DOI 10.17487/RFC6485, February 2012,
	<https://www.rfc-editor.org/info/rfc6485>.		<https://www.rfc-editor.org/info/rfc6485>.
	[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object		[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
	Template for the Resource Public Key Infrastructure		Template for the Resource Public Key Infrastructure
	(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,		(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
	<https://www.rfc-editor.org/info/rfc6488>.		<https://www.rfc-editor.org/info/rfc6488>.
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 15 ¶
	[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support		[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,		Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
	February 2012, <https://www.rfc-editor.org/info/rfc6480>.		February 2012, <https://www.rfc-editor.org/info/rfc6480>.
	Authors' Addresses		Authors' Addresses
	Alexander Azimov		Alexander Azimov
	Yandex		Yandex
	Email: a.e.azimov@gmail.com		Email: a.e.azimov@gmail.com
	Eugene Uskov		Eugene Uskov
	JetLend		JetLend
	Email: eu@jetlend.ru		Email: eu@jetlend.ru
	Randy Bush		Randy Bush
	Internet Initiative Japan		Internet Initiative Japan
	Email: randy@psg.com		Email: randy@psg.com
	Keyur Patel		Keyur Patel
	Arrcus, Inc.		Arrcus, Inc.
	Email: keyur@arrcus.com		Email: keyur@arrcus.com
	Job Snijders		Job Snijders
	NTT Communications		Fastly
	Theodorus Majofskistraat 100		Amsterdam
	Amsterdam 1065 SZ
	The Netherlands
	Email: job@ntt.net		Email: job@fastly.com
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		United States of America
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 18 change blocks.
	31 lines changed or deleted		43 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/