< draft-ietf-opsawg-finding-geofeeds-11.txt		draft-ietf-opsawg-finding-geofeeds-12.txt >
	skipping to change at page 1, line 14 ¶		skipping to change at page 1, line 14 ¶
	Internet-Draft IIJ & Arrcus		Internet-Draft IIJ & Arrcus
	Intended status: Standards Track M. Candela		Intended status: Standards Track M. Candela
	Expires: November 20, 2021 NTT		Expires: November 20, 2021 NTT
	W. Kumari		W. Kumari
	Google		Google
	R. Housley		R. Housley
	Vigil Security		Vigil Security
	May 19, 2021		May 19, 2021
	Finding and Using Geofeed Data		Finding and Using Geofeed Data
	draft-ietf-opsawg-finding-geofeeds-11		draft-ietf-opsawg-finding-geofeeds-12
	Abstract		Abstract
	This document specifies how to augment the Routing Policy		This document specifies how to augment the Routing Policy
	Specification Language inetnum: class to refer specifically to		Specification Language inetnum: class to refer specifically to
	geofeed data CSV files, and describes an optional scheme to use the		geofeed data CSV files, and describes an optional scheme to use the
	Routing Public Key Infrastructure to authenticate the geofeed data		Routing Public Key Infrastructure to authenticate the geofeed data
	CSV files.		CSV files.
	Status of This Memo		Status of This Memo
	skipping to change at page 3, line 39 ¶		skipping to change at page 3, line 39 ¶
	Geofeed data do have privacy considerations, see Section 6; and this		Geofeed data do have privacy considerations, see Section 6; and this
	process makes bulk access to those data easier.		process makes bulk access to those data easier.
	This document also suggests an optional signature to strongly		This document also suggests an optional signature to strongly
	authenticate the data in the geofeed files.		authenticate the data in the geofeed files.
	3. inetnum: Class		3. inetnum: Class
	The original RPSL specifications starting with [RIPE81], [RIPE181],		The original RPSL specifications starting with [RIPE81], [RIPE181],
	and a trail of subsequent documents were done by the RIPE community.		and a trail of subsequent documents were done by the RIPE community.
	The IETF standardardized RPSL in [RFC2622] and [RFC4012]. Since		The IETF standardized RPSL in [RFC2622] and [RFC4012]. Since then,
	then, it has been modified and extensively enhanced in the Regional		it has been modified and extensively enhanced in the Regional
	Interney Registry (RIR) community, mostly by RIPE, [RIPE-DB].		Internet Registry (RIR) community, mostly by RIPE, [RIPE-DB].
	Currently, change control effectively lies in the operator community.		Currently, change control effectively lies in the operator community.
	The Routing Policy Specification Language (RPSL), and [RFC2622] and		The Routing Policy Specification Language (RPSL), and [RFC2622] and
	[RFC4012] used by the Regional Internet Registries (RIRs) specifies		[RFC4012] used by the Regional Internet Registries (RIRs) specifies
	the inetnum: database class. Each of these objects describes an IP		the inetnum: database class. Each of these objects describes an IP
	address range and its attributes. The inetnum: objects form a		address range and its attributes. The inetnum: objects form a
	hierarchy ordered on the address space.		hierarchy ordered on the address space.
	Ideally, RPSL would be augmented to define a new RPSL geofeed:		Ideally, RPSL would be augmented to define a new RPSL geofeed:
	attribute in the inetnum: class. Until such time, this document		attribute in the inetnum: class. Until such time, this document
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	the private key of the relevant RPKI certificate for the covering		the private key of the relevant RPKI certificate for the covering
	address range. One needs a format that bundles the relevant RPKI		address range. One needs a format that bundles the relevant RPKI
	certificate with the signature and the digest of the geofeed text.		certificate with the signature and the digest of the geofeed text.
	The canonicalization procedure converts the data from its internal		The canonicalization procedure converts the data from its internal
	character representation to the UTF-8 [RFC3629] character encoding,		character representation to the UTF-8 [RFC3629] character encoding,
	and the <CRLF> sequence MUST be used to denote the end of a line of		and the <CRLF> sequence MUST be used to denote the end of a line of
	text. Trailing space characters MUST NOT appear on a line of text.		text. Trailing space characters MUST NOT appear on a line of text.
	That is, the space or tab characters must not be followed by the		That is, the space or tab characters must not be followed by the
	<CRLF> sequence. Thus, a blank line is represented solely by the		<CRLF> sequence. Thus, a blank line is represented solely by the
	<CRLF> sequence. Other nonprintable characters, such as backspace,		<CRLF> sequence. Other non-printable characters, such as backspace,
	are not expected. For robustness, any nonprintable characters MUST		are not expected. For robustness, any non-printable characters MUST
	NOT be changed by canonicalization. Trailing blank lines MUST NOT		NOT be changed by canonicalization. Trailing blank lines MUST NOT
	appear at the end of the file. That is, the file must not end with		appear at the end of the file. That is, the file must not end with
	multiple consecutive <CRLF> sequences. Any end-of-file marker used		multiple consecutive <CRLF> sequences. Any end-of-file marker used
	by an operating system is not considered to be part of the file		by an operating system is not considered to be part of the file
	content. When present, such end-of-file markers MUST NOT be		content. When present, such end-of-file markers MUST NOT be
	processed by the digital signature algorithm.		processed by the digital signature algorithm.
	Should the authenticator be syntactically incorrect per the above,		Should the authenticator be syntactically incorrect per the above,
	the authenticator is invalid.		the authenticator is invalid.
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 40 ¶
	sign the CMS blob is left as an exercise for the implementor. On the		sign the CMS blob is left as an exercise for the implementor. On the
	other hand, verifying the signature requires no complexity; the		other hand, verifying the signature requires no complexity; the
	certificate, which can be validated in the public RPKI, has the		certificate, which can be validated in the public RPKI, has the
	needed public key. The trust anchors for the RIRs are expected to		needed public key. The trust anchors for the RIRs are expected to
	already be available to the party performing signature validation.		already be available to the party performing signature validation.
	Validation of the CMS signature on the geofeed file involves:		Validation of the CMS signature on the geofeed file involves:
	1. Obtain the signer's certificate from an RPKI Repository. The		1. Obtain the signer's certificate from an RPKI Repository. The
	certificate SubjectKeyIdentifier extension [RFC5280] MUST match		certificate SubjectKeyIdentifier extension [RFC5280] MUST match
	the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier		the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
	xref target="RFC5286"/>. If the key identifiers do not match,		[RFC5286]. If the key identifiers do not match, then validation
	then validation MUST fail.		MUST fail.
	2. Construct the certification path for the signer's certificate.		2. Construct the certification path for the signer's certificate.
	All of the needed certificates are expected to be readily		All of the needed certificates are expected to be readily
	available in the RPKI Repository. The certification path MUST be		available in the RPKI Repository. The certification path MUST be
	valid according to the validation algorithm in [RFC5280] and the		valid according to the validation algorithm in [RFC5280] and the
	additional checks specified in [RFC3779] associated with the IP		additional checks specified in [RFC3779] associated with the IP
	Address Delegation certificate extension and the Autonomous		Address Delegation certificate extension and the Autonomous
	System Identifier Delegation certificate extension. If		System Identifier Delegation certificate extension. If
	certification path validation is unsuccessful, then validation		certification path validation is unsuccessful, then validation
	MUST fail.		MUST fail.
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	referring inetnum: object's inetnum: attribute address range.		referring inetnum: object's inetnum: attribute address range.
	If and only if the geofeed file is not signed per Section 4, then		If and only if the geofeed file is not signed per Section 4, then
	multiple inetnum: objects MAY refer to the same geofeed file, and the		multiple inetnum: objects MAY refer to the same geofeed file, and the
	consumer MUST use only geofeed lines where the prefix is covered by		consumer MUST use only geofeed lines where the prefix is covered by
	the address range of the inetnum: object they have followed.		the address range of the inetnum: object they have followed.
	If the geofeed file is signed, and the signer's certificate changes,		If the geofeed file is signed, and the signer's certificate changes,
	the signature in the geofeed file MUST be updated.		the signature in the geofeed file MUST be updated.
	It is good key hygene to use a given key for only one purpose. To		It is good key hygiene to use a given key for only one purpose. To
	dedicate a signing private key for signing a geofeed file, an RPKI CA		dedicate a signing private key for signing a geofeed file, an RPKI CA
	may issue a subordinate certificate exclusively for the purpose as		may issue a subordinate certificate exclusively for the purpose as
	shown in Appendix A.		shown in Appendix A.
	To minimize the load on RIR whois [RFC3912] services, use of the		To minimize the load on RIR whois [RFC3912] services, use of the
	RIR's FTP [RFC0959] services SHOULD be the preferred access. This		RIR's FTP [RFC0959] services SHOULD be the preferred access. This
	also provides bulk access instead of fetching by brute force search		also provides bulk access instead of fetching by brute force search
	through the IP space.		through the IP space.
	Currently, geolocation providers have bulk whois data access at all		Currently, geolocation providers have bulk whois data access at all
	skipping to change at page 11, line 25 ¶		skipping to change at page 11, line 25 ¶
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
			[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
			IP Fast Reroute: Loop-Free Alternates", RFC 5286,
			DOI 10.17487/RFC5286, September 2008,
			<https://www.rfc-editor.org/info/rfc5286>.
	[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		[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
	Resource Certificate Repository Structure", RFC 6481,		Resource Certificate Repository Structure", RFC 6481,
	DOI 10.17487/RFC6481, February 2012,		DOI 10.17487/RFC6481, February 2012,
	<https://www.rfc-editor.org/info/rfc6481>.		<https://www.rfc-editor.org/info/rfc6481>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
End of changes. 6 change blocks.
	9 lines changed or deleted		14 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/