rfc8897.original		rfc8897-07.txt
	SIDROPS D. Ma		SIDROPS D. Ma
	Internet-Draft ZDNS		Internet-Draft ZDNS
	Intended status: Informational S. Kent		Intended status: Informational S. Kent
	Expires: April 9, 2020 Independent		Expires: November 14, 2020 Independent
	October 7, 2019		May 13, 2020
	Requirements for Resource Public Key Infrastructure (RPKI) Relying		Requirements for Resource Public Key Infrastructure (RPKI) Relying
	Parties		Parties
	draft-ietf-sidrops-rp-06		draft-ietf-sidrops-rp-07
	Abstract		Abstract
	This document provides a single reference point for requirements for		This document provides a single reference point for requirements for
	Relying Party (RP) software for use in the Resource Public Key		Relying Party (RP) software for use in the Resource Public Key
	Infrastructure (RPKI) in the context of securing Internet routing.		Infrastructure (RPKI). It cites requirements that appear in several
	It cites requirements that appear in several RPKI RFCs, making it		RPKI RFCs, making it easier for implementers to become aware of these
	easier for implementers to become aware of these requirements that		requirements. This document will be updated to reflect changes in
	are segmented with orthogonal functionalities.		the RFCs that it cites as normative.
	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). 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 April 9, 2020.		This Internet-Draft will expire on November 14, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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/license-info) in effect on the date of		(https://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Fetching and Caching RPKI Repository Objects . . . . . . . . 3		2. Fetching and Caching RPKI Repository Objects . . . . . . . . 3
	2.1. TAL Acquisition and Processing . . . . . . . . . . . . . 4		2.1. TAL Configuration and Processing . . . . . . . . . . . . 4
	2.2. Locating RPKI Objects Using Authority and Subject		2.2. Locating RPKI Objects Using Authority and Subject
	Information Extensions . . . . . . . . . . . . . . . . . 4		Information Extensions . . . . . . . . . . . . . . . . . 4
	2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4		2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4
	2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4		2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4
	2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5		2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5
	3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5		3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5
	3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5		3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5
	3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5		3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5
	3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 6		3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 6
	4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6		4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6
	4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6		4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6
	4.2. Syntax and Validation for Each Type of Signed Object . . 6		4.2. Syntax and Validation for Each Type of Signed Object . . 6
	4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6		4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6
	4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7		4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7
	4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7		4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7
	4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7		4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 8
	4.4. What to Do with Ghostbusters Information . . . . . . . . 8		4.4. What to Do with Ghostbusters Information . . . . . . . . 8
	5. Distributing Validated Cache . . . . . . . . . . . . . . . . 8		5. Distributing Validated Cache . . . . . . . . . . . . . . . . 8
	6. Local Control . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Local Control . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The RPKI Relying Party (RP) software is used by network operators and		RPKI Relying Party (RP) software is used by network operators and
	others to acquire and verify Internet Number Resource (INR) data		others to acquire and verify Internet Number Resource (INR) data
	stored in the RPKI repository system. RPKI data, when verified,		stored in the RPKI repository system. RPKI data, when verified,
	allow an RP to verify assertions about which Autonomous Systems		allows an RP to verify assertions about which Autonomous Systems
	(ASes) are authorized to originate routes for IP address prefixes.		(ASes) are authorized to originate routes for IP address prefixes.
	RPKI data also establishes binding between public keys and BGP		RPKI data also establishes a binding between public keys and BGP
	routers, and indicates the AS numbers that each router is authorized		routers, and indicates the AS numbers that each router is authorized
	to represent.		to represent.
	Noting that the essential requirements imposed on RPs to support		The essential requirements imposed on RP software to support securing
	securing Internet routing ([RFC6480]) are scattered throughout		Internet routing ([RFC6480]) are scattered throughout numerous RFC
	numerous RFC documents that are protocol specific or provide best		documents that are protocol-specific or provide best practices. The
	practices, as follows:		following RFCs define these requirements (or best practices):
	RFC 6481 (Repository Structure)		RFC 6481 (Repository Structure)
	RFC 6482 (ROA format)		RFC 6482 (ROA format)
	RFC 6486 (Manifests)		RFC 6486 (Manifests)
	RFC 6487 (Certificate and CRL profile)		RFC 6487 (Certificate and CRL profile)
	RFC 6488 (RPKI Signed Objects)		RFC 6488 (RPKI Signed Objects)
	RFC 6489 (Key Rollover)		RFC 6489 (Key Rollover)
	RFC 6810 (RPKI to Router Protocol)		RFC 6810 (RPKI to Router Protocol)
	RFC 6916 (Algorithm Agility)		RFC 6916 (Algorithm Agility)
	RFC 7935 (Algorithms)		RFC 7935 (Algorithms)
	RFC 8209 (Router Certificates)		RFC 8209 (Router Certificates)
	RFC 8210 (RPKI to Router Protocol,Version 1)		RFC 8210 (RPKI to Router Protocol,Version 1)
	RFC 8360 (Certificate Validation Procedure)		RFC 8360 (Certificate Validation Procedure)
	RFC 8630 (Trust Anchor Locator)		RFC 8630 (Trust Anchor Locator)
	This makes it hard for an implementer to be confident that he/she has		The distribution of RPKI RP requirements across these 13 documents
	addressed all of these generalized requirements. Besides, software		makes it hard for an implementer to be confident that he/she has
	engineering calls for how to segment the RP system into components		addressed all of these requirements. Additionaly, good software
	with orthogonal functionalities, so that those components could be		engineering practice may call for segmenting the RP system into
	distributed across the operational timeline of the user. Taxonomy of		components with orthogonal functionalities, so that those components
	generalized RP requirements is going to help have 'the role of the		may be distributed. A taxonomy of the collected RP software
	RP' well framed.		requirements can help clarify the role of the RP.
	To consolidate RP requirements in one document, with pointers to all		To consolidate RP software requirements in one document, with
	the relevant RFCs, this document outlines a set of baseline		pointers to all the relevant RFCs, this document outlines a set of
	requirements imposed on RPs and provides a single reference point for		baseline requirements imposed on RPs and provides a single reference
	requirements for RP software for use in the RPKI, as segmented with		point for requirements for RP software for use in the RPKI. The
	orthogonal functionalities:		requirements are organized into four groups:
	o Fetching and Caching RPKI Repository Objects		o Fetching and Caching RPKI Repository Objects
	o Processing Certificates and CRLs		o Processing Certificates and CRLs
	o Processing RPKI Repository Signed Objects		o Processing RPKI Repository Signed Objects
	o Distributing Validated Cache of the RPKI Data		o Distributing Validated Cache of the RPKI Data
	This document will be update to reflect new or changed requirements		This document will be updated to reflect new or changed requirements
	as these RFCs are updated, or new RFCs are written.		as these RFCs are updated, or additional RFCs are written.
	2. Fetching and Caching RPKI Repository Objects		2. Fetching and Caching RPKI Repository Objects
	RP software uses synchronization mechanisms supported by targeted		RP software uses synchronization mechanisms supported by targeted
	repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI		repositories (e.g., [rsync] or RRDP [RFC8182]) to download RPKI
	changed data objects in the repository system and cache them locally.		signed objects from the repository system, in order to update a local
	The software validates the RPKI data and uses it to generate		cache. These mechanisms download only those objects that have been
	authenticated data identifying which ASes are authorized to originate		added, or replaced with new versions, since the time when the RP most
	routes for address prefixes, and which routers are authorized to sign		recently checked the repository. RP software validates the RPKI data
	BGP updates on behalf of ASes.		and uses it to generate authenticated data identifying which ASes are
			authorized to originate routes for address prefixes, and which
			routers are authorized to sign BGP updates on behalf of specified
			ASes.
	2.1. TAL Acquisition and Processing		2.1. TAL Configuration and Processing
	In the RPKI, each RP chooses its own set of trust anchors (TAs).		In the RPKI, each RP chooses a set of trust anchors (TAs).
	Consistent with the extant INR allocation hierarchy, the IANA and/or		Consistent with the extant INR allocation hierarchy, the IANA and/or
	the five RIRs are obvious candidates to be default TAs for the RP.		the five RIRs are obvious candidates to be default TAs for the RP.
	An RP does not retrieve TAs directly. A set of Trust Anchor Locators		An RP does not retrieve TAs directly. A set of Trust Anchor Locators
	(TALs) is used by each RP to retrieve and verify the authenticity of		(TALs) is used by RP software to retrieve and verify the authenticity
	each TA.		of each TA.
	TAL acquisition and processing are specified in Section 3 of		TAL configuration and processing are specified in Section 3 of
	[RFC8630].		[RFC8630].
	2.2. Locating RPKI Objects Using Authority and Subject Information		2.2. Locating RPKI Objects Using Authority and Subject Information
	Extensions		Extensions
	The RPKI repository system is a distributed one, consisting of		TThe RPKI repository system is a distributed one, consisting of
	multiple repository instances. Each repository instance contains one		multiple repository instances. Each repository instance contains one
	or more repository publication points. An RP discovers publication		or more repository publication points. RP software discovers
	points using the Subject Information Access (SIA) and the Authority		publication points using the Subject Information Access (SIA) and the
	Information Access (AIA) extensions from (validated) certificates.		Authority Information Access (AIA) extensions from (validated)
			certificates.
	Section 5 of [RFC6481] specifies how an RP locates all RPKI objects		Section 5 of [RFC6481] specifies how RP software locates all RPKI
	by using the SIA and AIA extensions. Detailed specifications of SIA		objectsby using the SIA and AIA extensions. Detailed specifications
	and AIA extensions in a resource certificate are described in		of SIA and AIA extensions in a resource certificate are described in
	Section 4 of [RFC6487].		Section 4.8.8 of [RFC6481] and Section 4.8.7 of [RFC6481]
			respectively.
	2.3. Dealing with Key Rollover		2.3. Dealing with Key Rollover
	An RP takes the key rollover period into account with regard to its		RP software takes the key rollover period into account with regard to
	frequency of synchronization with RPKI repository system.		its frequency of synchronization with the RPKI repository system.
	RP requirements in dealing with key rollover are described in		RP software requirements for dealing with key rollover are described
	Section 3 of [RFC6489] and Section 3 of [RFC8634].		in Section 3 of [RFC6489] and Section 3 of [RFC8634].
	2.4. Dealing with Algorithm Transition		2.4. Dealing with Algorithm Transition
	The set of cryptographic algorithms used with the RPKI is expected to		The set of cryptographic algorithms used with the RPKI is expected to
	change over time. Each RP is expected to be aware of the milestones		change over time. Each RP is expected to be aware of the milestones
	established for the algorithm transition and what actions are		established for the algorithm transition and what actions are
	required at every juncture.		required at every juncture.
	RP requirements for dealing with algorithm transition are specified		RP software requirements for dealing with algorithm transition are
	in Section 4 of [RFC6916].		specified in Section 4 of [RFC6916].
	2.5. Strategies for Efficient Cache Maintenance		2.5. Strategies for Efficient Cache Maintenance
	Each RP is expected to maintain a local cache of RPKI objects. The		Each RP is expected to maintain a local cache of RPKI objects. The
	cache needs to be as up to date and consistent with repository		cache needs to be as up to date and consistent with repository
	publication point data as the RP's frequency of checking permits.		publication point data as the RP's frequency of checking permits.
	The last paragraph of Section 5 of [RFC6481] provides guidance for		The last paragraph of Section 5 of [RFC6481] provides guidance for
	maintenance of a local cache.		maintenance of a local cache.
	3. Certificate and CRL Processing		3. Certificate and CRL Processing
	The RPKI make use of X.509 certificates and CRLs, but it profiles		The RPKI makes use of X.509 certificates and CRLs, but it profiles
	these standard formats [RFC6487]. The major change to the profile		these standard formats [RFC6487]. The major change to the profile
	established in [RFC5280] is the mandatory use of a new extension to		established in [RFC5280] is the mandatory use of a new extension in
	X.509 certificate [RFC3779].		RPKI certificates, defined in [RFC3779].
	3.1. Verifying Resource Certificate and Syntax		3.1. Verifying Resource Certificate and Syntax
	Certificates in the RPKI are called resource certificates, and they		Certificates in the RPKI are called resource certificates, and they
	are required to conform to the profile [RFC6487]. An RP is required		are required to conform to the profile [RFC6487]. An RP is required
	to verify that a resource certificate adheres to the profile		to verify that a resource certificate adheres to the profile
	established by Section 4 of [RFC6487]. This means that all		established by Section 4 of [RFC6487]. This means that all
	extensions mandated by Section 4.8 of [RFC6487] must be present and		extensions mandated by Section 4.8 of [RFC6487] must be present and
	value of each extension must be within the range specified by this		the value of each extension must be within the range specified by
	RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487]		[RFC6487]. Moreover, any extension excluded by Section 4.8 of
	must be omitted.		[RFC6487] must be omitted.
	Section 7.1 of [RFC6487] gives the procedure that the RP should		Section 7.1 of [RFC6487] specifies the procedure that RP software
	follow to verify resource certificate and syntax.		follows when verifying [RFC3779] extensions.
	3.2. Certificate Path Validation		3.2. Certificate Path Validation
	The INRs in issuer's certificate are required to encompass the INRs		Initially, the INRs in issuer's certificate are required to encompass
	in the subject's certificate. This is one of necessary principles of		the INRs in the subject's certificate. This is one of the necessary
	certificate path validation in addition to cryptographic verification		principles of certificate path validation in addition to
	i.e., verification of the signature on each certificate using the		cryptographic verification i.e., verification of the signature on
	public key of the parent certificate).		each certificate using the public key of the parent certificate).
	Section 7.2 of [RFC6487] gives the procedure that the RP should		Section 7.2 of [RFC6487] specifies the procedure that RP software
	follow to perform certificate path validation.		should follow to perform certificate path validation.
	Certificate Authorities that want to reduce aspects of operational		Certification Authorities that want to reduce aspects of operational
	fragility will migrate to the new OIDs [RFC8360], informing the RP of		fragility will migrate to the new OIDs [RFC8360], informing RP
	using an alternative RPKI validation algorithm. An RP is expected to		software to use an alternative RPKI validation algorithm. An RP is
	support the amended procedure to handle with accidental over-claim.		expected to support the amended procedure to handle accidental
			overclaiming, which is described in Section 4 of [RFC8360].
	3.3. CRL Processing		3.3. CRL Processing
	The CRL processing requirements imposed on CAs and RP are described		The CRL processing requirements imposed on CAs and RP are described
	in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained;		in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained;
	only the AuthorityKeyIndetifier and CRLNumber extensions are allowed,		only the AuthorityKeyIndentifier (Section 4.8.3 of [[RFC6487]) and
	and they are required to be present. No other CRL extensions are		CRLNumber(Section 5.2.3 of [RFC5280]) extensions are allowed, and
	allowed, and no CRLEntry extensions are permitted. RPs are required		they are required to be present. No other CRL extensions are
	to verify that these constraints have been met. Each CRL in the RPKI		allowed, and no CRLEntry extensions are permitted. RP software is
	must be verified using the public key from the certificate of the CA		required to verify that these constraints have been met. Each CRL in
	that issued the CRL.		the RPKI must be verified using the public key from the certificate
			of the CA that issued the CRL.
	In the RPKI, RPs are expected to pay extra attention when dealing		In the RPKI, RPs are expected to pay extra attention when dealing
	with a CRL that is not consistent with the Manifest associated with		with a CRL that is not consistent with the Manifest associated with
	the publication point associated with the CRL.		the publication point associated with the CRL.
	Processing of a CRL that is not consistent with a manifest is a		Processing of a CRL that is not consistent with a manifest is a
	matter of local policy, as described in the fourth paragraph of		matter of local policy, as described in the fifth paragraph of
	Section 6.6 of [RFC6486].		Section 6.6 of [RFC6486].
	4. Processing RPKI Repository Signed Objects		4. Processing RPKI Repository Signed Objects
	4.1. Basic Signed Object Syntax Checks		4.1. Basic Signed Object Syntax Checks
	Before an RP can use a signed object from the RPKI repository, the RP		Before an RP can use a signed object from the RPKI repository, RP
	is required to check the signed object syntax.		software is required to check the signed object syntax.
	Section 3 of [RFC6488] lists all the steps that the RP is required to		Section 3 of [RFC6488] lists all the steps that RP software is
	execute in order to validate the top level syntax of a repository		required to execute in order to validate the top level syntax of a
	signed object.		repository signed object.
	Note that these checks are necessary, but not sufficient. Additional		Note that these checks are necessary, but not sufficient. Additional
	validation checks must be performed based on the specific type of		validation checks must be performed based on the specific type of
	signed object.		signed object as described in Section 4.2.
	4.2. Syntax and Validation for Each Type of Signed Object		4.2. Syntax and Validation for Each Type of Signed Object
	4.2.1. Manifest		4.2.1. Manifest
	To determine whether a manifest is valid, the RP is required to		To determine whether a manifest is valid, RP software is required to
	perform manifest-specific checks in addition to those specified in		perform manifest-specific checks in addition to the generic signed
	[RFC6488].		object checks specified in [RFC6488].
	Specific checks for a Manifest are described in Section 4 of		Specific checks for a Manifest are described in Section 4 of
	[RFC6486]. If any of these checks fails, indicating that the		[RFC6486]. If any of these checks fails, indicating that the
	manifest is invalid, then the manifest will be discarded and treated		manifest is invalid, then the manifest will be discarded and RP
	as though no manifest were present.		software will act as though no manifest were present.
	4.2.2. ROA		4.2.2. ROA
	To validate a ROA, the RP is required perform all the checks		To validate a ROA, RP software is required to perform all the checks
	specified in [RFC6488] as well as the additional ROA-specific		specified in [RFC6488] as well as additional, ROA-specific validation
	validation steps. The IP address delegation extension [RFC3779]		steps. The IP address delegation extension [RFC3779] present in the
	present in the end-entity (EE) certificate (contained within the		end-entity (EE) certificate (contained within the ROA), must
	ROA), must encompass each of the IP address prefix(es) in the ROA.		encompass each of the IP address prefix(es) in the ROA.
	More details for ROA validation are specified in Section 4 of		More details for ROA validation are specified in Section 4 of
	[RFC6482].		[RFC6482].
	4.2.3. Ghostbusters		4.2.3. Ghostbusters
	The Ghostbusters Record is optional; a publication point in the RPKI		The Ghostbusters Record is optional; a publication point in the RPKI
	can have zero or more associated Ghostbuster Records. If a CA has at		can have zero or more associated Ghostbuster Records. If a CA has at
	least one Ghostbuster Record, RP is required to verify that this		least one Ghostbuster Record, RP software is required to verify that
	Ghostbusters Record conforms to the syntax of signed object defined		this Ghostbusters Record conforms to the syntax of signed object
	in [RFC6488].		defined in [RFC6488].
	The payload of this signed object is a (severely) profiled vCard. An		The payload of this signed object is a (severely) profiled vCard. RP
	RP is required to verify that the payload of Ghostbusters conforms to		software is required to verify that the payload of Ghostbusters
	format as profiled in [RFC6493].		conforms to format as profiled in [RFC6493].
	4.2.4. Verifying BGPsec Router Certificate		4.2.4. Verifying BGPsec Router Certificate
	A BGPsec Router Certificate is a resource certificate, so it is		A BGPsec Router Certificate is a resource certificate, so it is
	required to comply with [RFC6487]. Additionally, the certificate		required to comply with [RFC6487]. Additionally, the certificate
	must contain an AS Identifier Delegation extension, and must not		must contain an AS Identifier Delegation extension (Section 4.8.11 of
	contain an IP Address Delegation extension. The validation procedure		[RFC6487]), and must not contain an IP Address Delegation extension
	used for BGPsec Router Certificates is identical to the validation		(Section 4.8.10 of [RFC6487]). The validation procedure used for
	procedure described in Section 7 of [RFC6487], but using the		BGPsec Router Certificates is analogous to the validation procedure
	constraints applied come from specification of Section 7 of		described in Section 7 of [RFC6487], but it uses the constraints
	[RFC8209].		defined in Section 3 of [RFC8209].
	Note that the cryptographic algorithms used by BGPsec routers are		Note that the cryptographic algorithms used by BGPsec routers are
	found in [RFC8208]. Currently, the algorithms specified in		found in [RFC8208]. Currently, the algorithms specified in [RFC8208]
	[RFC8208]and [RFC7935] are different. BGPsec RPs will need to		and [RFC7935] are different. BGPsec RP software will need to support
	support algorithms that are used to validate BGPsec signatures as		algorithms that are used to validate BGPsec signatures as well as the
	well as the algorithms that are needed to validate signatures on		algorithms that are needed to validate signatures on BGPsec
	BGPsec certificates, RPKI CA certificates, and RPKI CRLs.		certificates, RPKI CA certificates, and RPKI CRLs.
	4.3. How to Make Use of Manifest Data		4.3. How to Make Use of Manifest Data
	For a given publication point, the RP ought to perform tests, as		For a given publication point, RP software ought to perform tests, as
	specified in Section 6.1 of [RFC6486], to determine the state of the		specified in Section 6.1 of [RFC6486], to determine the state of the
	Manifest at the publication point. A Manifest can be classified as		Manifest at the publication point. A Manifest can be classified as
	either valid or invalid, and a valid Manifest is either current and		either valid or invalid, and a valid Manifest is either current or
	stale. An RP decides how to make use of a Manifest based on its		stale. An RP decides how to make use of a Manifest based on its
	state, according to local (RP) policy.		state, according to local (RP) policy.
	If there are valid objects in a publication point that are not		If there are valid objects in a publication point that are not
	present on a Manifest, [RFC6486] does not mandate specific RP		present on a Manifest, [RFC6486] does not mandate specific RP
	behavior with respect to such objects. However, most RP software		behavior with respect to such objects.
	ignores such objects and the authors of this document suggest this
	behavior be adopted uniformly.
	In the absence of a Manifest, an RP is expected to accept all valid		In the absence of a Manifest, an RP is expected to accept all valid
	signed objects present in the publication point. If a Manifest is		signed objects present in the publication point (see Section 6.2 of
	stale or invalid (see [RFC6486]) and an RP has no way to acquire a		[RFC6486]). If a Manifest is stale or invalid and an RP has no way
	more recently valid Manifest, the RP is expected to contact the		to acquire a more recent valid Manifest, the RP is expected to
	repository manager via Ghostbusters record and thereafter make		contact the repository manager via Ghostbusters record and thereafter
	decision according to local (RP) policy.		make decisions according to local (RP) policy (see Section 6.3 of
			[RFC6486] and Section 6.4 of [RFC6486]).
	4.4. What to Do with Ghostbusters Information		4.4. What to Do with Ghostbusters Information
	An RP may encounter a stale Manifest or CRL, or an expired CA		RP software may encounter a stale Manifest or CRL, or an expired CA
	certificate or ROA at a publication point. An RP is expected to use		certificate or ROA at a publication point. An RP is expected to use
	the information from the Ghostbusters record to contact the		the information from the Ghostbusters record to contact the
	maintainer of the publication point where any stale/expired objects		maintainer of the publication point where any stale/expired objects
	were encountered. The intent here is to encourage the relevant CA		were encountered. The intent here is to encourage the relevant CA
	and/or repository manager to update the slate or expired objects.		and/or repository manager to update the stale or expired objects.
	5. Distributing Validated Cache		5. Distributing Validated Cache
	On a periodic basis, BGP speakers within an AS request updated		On a periodic basis, BGP speakers within an AS request updated
	validated origin AS data and router/ASN data from the validated cache		validated origin AS data and router/ASN data from the (local)
	of RPKI data. The RP may either transfer the validated data to the		validated cache of RPKI data. The RP may either transfer the
	BGP speakers directly, or it may transfer the validated data to a		validated data to the BGP speakers directly, or it may transfer the
	cache server that is responsible for provisioning such data to BGP		validated data to a cache server that is responsible for provisioning
	speakers. The specification of the protocol designed to deliver		such data to BGP speakers. The specifications of the protocol
	validated cache data to a BGP Speaker is provided in [RFC6810] and		designed to deliver validated cache data to a BGP Speaker is provided
	[RFC8210].		in [RFC6810] and [RFC8210].
	6. Local Control		6. Local Control
	ISPs may want to establish a local view of exceptions to the RPKI		ISPs may want to establish a local view of exceptions to the RPKI
	data in the form of local filters and additions. For instance, a		data in the form of local filters and additions. For instance, a
	network operator might wish to make use of a local override		network operator might wish to make use of a local override
	capability to protect routes from adverse actions [RFC8211] . The		capability to protect routes from adverse actions [RFC8211]. The
	mechanisms developed to provide this capability to network operators		mechanisms developed to provide this capability to network operators
	are called "Simplified Local Internet Number Resource Management with		are called "Simplified Local Internet Number Resource Management with
	the RPKI (SLURM). If an ISP wants to implement SLURM, its RP system		the RPKI (SLURM). If an ISP wants to implement SLURM, its RP system
	can follow the instruction specified in [RFC8416] .		can follow the instruction specified in [RFC8416].
	7. Security Considerations		7. Security Considerations
	The RP links the RPKI provisioning side and the routing system,		This document doesn't introduce any new security considerations; it
	establishing the local view of global RPKI data to BGP speakers. The		is a resource for implementers. The RP links the RPKI provisioning
	security of the RP is critical to BGP messages exchanging. The RP		side and the routing system, establishing a verified, local view of
	implementation is expected to offer cache backup management to		global RPKI data to BGP speakers. The security of the RP is critical
	facilitate recovery from outage state. The RP implementation also		to BGP messages exchanges. Each RP implementation is expected to
	should support application of secure transport (e.g., IPsec		offer cache backup management to facilitate recovery from outages.
	[RFC4301]) that is able to protect validated cache delivery in a		RP software also should support application of secure transport
	unsafe environment.		(e.g., IPsec [RFC4301]) that is able to protect validated cache
			delivery in a unsafe environment. This document highlights many
			validation actions applied to RPKI signed objects, an essential
			element of secure operation of RPKI security.
	8. IANA Considerations		8. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	9. Acknowledgements		9. Acknowledgements
	The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George		The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George
	Michaelson and Oleg Muravskiy for their review, feedback and		Michaelson and Oleg Muravskiy for their review, feedback and
	editorial assistance in preparing this document.		editorial assistance in preparing this document.
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 25 ¶
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<https://www.rfc-editor.org/info/rfc6487>.		<https://www.rfc-editor.org/info/rfc6487>.
	[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>.
			[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
			Authority (CA) Key Rollover in the Resource Public Key
			Infrastructure (RPKI)", BCP 174, RFC 6489,
			DOI 10.17487/RFC6489, February 2012,
			<https://www.rfc-editor.org/info/rfc6489>.
	[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)		[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
	Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,		Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
	February 2012, <https://www.rfc-editor.org/info/rfc6493>.		February 2012, <https://www.rfc-editor.org/info/rfc6493>.
	[RFC6810] Bush, R. and R. Austein, "The Resource Public Key		[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
	Infrastructure (RPKI) to Router Protocol", RFC 6810,		Infrastructure (RPKI) to Router Protocol", RFC 6810,
	DOI 10.17487/RFC6810, January 2013,		DOI 10.17487/RFC6810, January 2013,
	<https://www.rfc-editor.org/info/rfc6810>.		<https://www.rfc-editor.org/info/rfc6810>.
			[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
			Procedure for the Resource Public Key Infrastructure
			(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
			2013, <https://www.rfc-editor.org/info/rfc6916>.
	[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for		[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
	Algorithms and Key Sizes for Use in the Resource Public		Algorithms and Key Sizes for Use in the Resource Public
	Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,		Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
	August 2016, <https://www.rfc-editor.org/info/rfc7935>.		August 2016, <https://www.rfc-editor.org/info/rfc7935>.
	[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key		[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
	Formats, and Signature Formats", RFC 8208,		Formats, and Signature Formats", RFC 8208,
	DOI 10.17487/RFC8208, September 2017,		DOI 10.17487/RFC8208, September 2017,
	<https://www.rfc-editor.org/info/rfc8208>.		<https://www.rfc-editor.org/info/rfc8208>.
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 32 ¶
	Newton, A., and D. Shaw, "Resource Public Key		Newton, A., and D. Shaw, "Resource Public Key
	Infrastructure (RPKI) Validation Reconsidered", RFC 8360,		Infrastructure (RPKI) Validation Reconsidered", RFC 8360,
	DOI 10.17487/RFC8360, April 2018,		DOI 10.17487/RFC8360, April 2018,
	<https://www.rfc-editor.org/info/rfc8360>.		<https://www.rfc-editor.org/info/rfc8360>.
	[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.		[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
	Bruijnzeels, "Resource Public Key Infrastructure (RPKI)		Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
	Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,		Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
	August 2019, <https://www.rfc-editor.org/info/rfc8630>.		August 2019, <https://www.rfc-editor.org/info/rfc8630>.
			[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
			Certificate Rollover", BCP 224, RFC 8634,
			DOI 10.17487/RFC8634, August 2019,
			<https://www.rfc-editor.org/info/rfc8634>.
	10.2. Informative References		10.2. Informative References
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[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>.
	[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
	Authority (CA) Key Rollover in the Resource Public Key
	Infrastructure (RPKI)", BCP 174, RFC 6489,
	DOI 10.17487/RFC6489, February 2012,
	<https://www.rfc-editor.org/info/rfc6489>.
	[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
	Procedure for the Resource Public Key Infrastructure
	(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
	2013, <https://www.rfc-editor.org/info/rfc6916>.
	[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,		[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
	"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,		"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
	DOI 10.17487/RFC8182, July 2017,		DOI 10.17487/RFC8182, July 2017,
	<https://www.rfc-editor.org/info/rfc8182>.		<https://www.rfc-editor.org/info/rfc8182>.
	[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification		[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification
	Authority (CA) or Repository Manager in the Resource		Authority (CA) or Repository Manager in the Resource
	Public Key Infrastructure (RPKI)", RFC 8211,		Public Key Infrastructure (RPKI)", RFC 8211,
	DOI 10.17487/RFC8211, September 2017,		DOI 10.17487/RFC8211, September 2017,
	<https://www.rfc-editor.org/info/rfc8211>.		<https://www.rfc-editor.org/info/rfc8211>.
	[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified		[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
	Local Internet Number Resource Management with the RPKI		Local Internet Number Resource Management with the RPKI
	(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,		(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
	<https://www.rfc-editor.org/info/rfc8416>.		<https://www.rfc-editor.org/info/rfc8416>.
	[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
	Certificate Rollover", BCP 224, RFC 8634,
	DOI 10.17487/RFC8634, August 2019,
	<https://www.rfc-editor.org/info/rfc8634>.
	[rsync] "rsync web page", <http://rsync.samba.org/>.		[rsync] "rsync web page", <http://rsync.samba.org/>.
	Authors' Addresses		Authors' Addresses
	Di Ma		Di Ma
	ZDNS		ZDNS
	4 South 4th St. Zhongguancun		4 South 4th St. Zhongguancun
	Haidian, Beijing 100190		Haidian, Beijing 100190
	China		China
End of changes. 59 change blocks.
	161 lines changed or deleted		170 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/