< draft-ietf-opsawg-finding-geofeeds-14.txt		draft-ietf-opsawg-finding-geofeeds-15.txt >
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft IIJ & Arrcus		Internet-Draft IIJ & Arrcus
	Intended status: Standards Track M. Candela		Intended status: Standards Track M. Candela
	Expires: November 22, 2021 NTT		Expires: November 23, 2021 NTT
	W. Kumari		W. Kumari
	Google		Google
	R. Housley		R. Housley
	Vigil Security		Vigil Security
	May 21, 2021		May 22, 2021
	Finding and Using Geofeed Data		Finding and Using Geofeed Data
	draft-ietf-opsawg-finding-geofeeds-14		draft-ietf-opsawg-finding-geofeeds-15
	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 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 November 22, 2021.		This Internet-Draft will expire on November 23, 2021.
	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/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
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 6 ¶
	multiple inetnum: objects. Files with geofeed references from		multiple inetnum: objects. Files with geofeed references from
	multiple inetnum: objects are not compatible with the signing		multiple inetnum: objects are not compatible with the signing
	procedure in Section 4.		procedure in Section 4.
	When geofeed references are provided by multiple inetnum: objects		When geofeed references are provided by multiple inetnum: objects
	which have identical address ranges, then the geofeed reference on		which have identical address ranges, then the geofeed reference on
	the inetnum: with the most recent last-modified: attribute SHOULD be		the inetnum: with the most recent last-modified: attribute SHOULD be
	preferred.		preferred.
	As inetnum: objects form a hierarchy, Geofeed references SHOULD be at		As inetnum: objects form a hierarchy, Geofeed references SHOULD be at
	the lowest applicable inetnum: object covering the relevant prefixes		the lowest applicable inetnum: object covering the relevant address
	in the referenced geofeed file. When fetching, the most specific		ranges in the referenced geofeed file. When fetching, the most
	inetnum: object with a geofeed reference MUST be used.		specific inetnum: object with a geofeed reference MUST be used.
	It is significant that geofeed data may have finer granularity than		It is significant that geofeed data may have finer granularity than
	the inetnum: which refers to them. For example an INETNUM object for		the inetnum: which refers to them. For example an INETNUM object for
	a prefix P could refer to a geofeed file in which P has been sub-		an address range P could refer to a geofeed file in which P has been
	divided into one or more longer prefixes.		sub-divided into one or more longer prefixes.
	Currently, the registry data published by ARIN is not the same RPSL		Currently, the registry data published by ARIN is not the same RPSL
	as that of the other registries (see [RFC7485] for a survey of the		as that of the other registries (see [RFC7485] for a survey of the
	whois Tower of Babel); therefore, when fetching from ARIN via FTP		whois Tower of Babel); therefore, when fetching from ARIN via FTP
	[RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the		[RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the
	"NetRange" attribute/key MUST be treated as "inetnum" and the		"NetRange" attribute/key MUST be treated as "inetnum" and the
	"Comment" attribute MUST be treated as "remarks".		"Comment" attribute MUST be treated as "remarks".
	4. Authenticating Geofeed Data		4. Authenticating Geofeed Data
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 35 ¶
	is valid, i.e. is authorized by the 'owner' of the IP address space		is valid, i.e. is authorized by the 'owner' of the IP address space
	and is authoritative in some sense. The inetnum: which points to the		and is authoritative in some sense. The inetnum: which points to the
	[RFC8805] geofeed file provides some assurance. Unfortunately, the		[RFC8805] geofeed file provides some assurance. Unfortunately, the
	RPSL in many repositories is weakly authenticated at best. An		RPSL in many repositories is weakly authenticated at best. An
	approach where RPSL was signed a la [RFC7909] would be good, except		approach where RPSL was signed a la [RFC7909] would be good, except
	it would have to be deployed by all RPSL registries, and there is a		it would have to be deployed by all RPSL registries, and there is a
	fair number of them.		fair number of them.
	A single optional authenticator MAY be appended to a [RFC8805]		A single optional authenticator MAY be appended to a [RFC8805]
	geofeed file. It is a digest of the main body of the file signed by		geofeed file. It is a digest of the main body of the file signed by
	the private key of the relevant RPKI certificate for the covering		the private key of the relevant RPKI certificate for a 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 of the geofeed text.		certificate with the signature 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. A blank line is represented solely by the <CRLF> sequence.		text. A blank line is represented solely by the <CRLF> sequence.
	For robustness, any non-printable characters MUST NOT be changed by		For robustness, any non-printable characters MUST NOT be changed by
	canonicalization. Trailing blank lines MUST NOT appear at the end of		canonicalization. Trailing blank lines MUST NOT appear at the end of
	the file. That is, the file must not end with multiple consecutive		the file. That is, the file must not end with multiple consecutive
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 18 ¶
	then padded BASE64 encoded (as per [RFC4648] Section 4), and line		then padded BASE64 encoded (as per [RFC4648] Section 4), and line
	wrapped to 72 or fewer characters. The same digest algorithm MUST be		wrapped to 72 or fewer characters. The same digest algorithm MUST be
	used for calculating the message digest on content being signed,		used for calculating the message digest on content being signed,
	which is the geofeed file, and calculating the message digest on the		which is the geofeed file, and calculating the message digest on the
	SignerInfo SignedAttributes [RFC8933]. The message digest algorithm		SignerInfo SignedAttributes [RFC8933]. The message digest algorithm
	identifier MUST appear in both the SigenedData		identifier MUST appear in both the SigenedData
	DigestAlgorithmIdentifiers and the SignerInfo		DigestAlgorithmIdentifiers and the SignerInfo
	DigestAlgorithmIdentifier [RFC5652].		DigestAlgorithmIdentifier [RFC5652].
	The address range of the signing certificate MUST cover all prefixes		The address range of the signing certificate MUST cover all prefixes
	in the geofeed file it signs; and therefore must be covered by the		in the geofeed file it signs.
	range of the inetnum:.
	An address range A 'covers' address range B if the range of B is		An address range A 'covers' address range B if the range of B is
	identical to or a subset of A. 'Address range' is used here because		identical to or a subset of A. 'Address range' is used here because
	inetnum: objects and RPKI certificates need not align on CIDR prefix		inetnum: objects and RPKI certificates need not align on CIDR prefix
	boundaries, while those of the CSV lines in the geofeed file do.		boundaries, while those of the CSV lines in a geofeed file do.
	As the signer specifies the covered RPKI resources relevant to the		As the signer specifies the covered RPKI resources relevant to the
	signature, the RPKI certificate covering the inetnum: object's		signature, the RPKI certificate covering the inetnum: object's
	address range is included in the [RFC5652] CMS SignedData		address range is included in the [RFC5652] CMS SignedData
	certificates field.		certificates field.
	Identifying the private key associated with the certificate, and		Identifying the private key associated with the certificate, and
	getting the department that controls the private key (which might be		getting the department that controls the private key (which might be
	trapped in a Hardware Security Module, HSM) to sign the CMS blob is		trapped in a Hardware Security Module, HSM) to sign the CMS blob is
	left as an exercise for the implementor. On the other hand,		left as an exercise for the implementor. On the other hand,
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 21 ¶
	[I-D.ietf-sidrops-rpki-rta] describes a Cryptographic Message Syntax		[I-D.ietf-sidrops-rpki-rta] describes a Cryptographic Message Syntax
	(CMS) profile for a general purpose Resource Tagged Attestation (RTA)		(CMS) profile for a general purpose Resource Tagged Attestation (RTA)
	based on the RPKI. While this is expected to become applicable in		based on the RPKI. While this is expected to become applicable in
	the long run, for the purposes of this document, a self-signed root		the long run, for the purposes of this document, a self-signed root
	trust anchor is used.		trust anchor is used.
	5. Operational Considerations		5. Operational Considerations
	To create the needed inetnum: objects, an operator wishing to		To create the needed inetnum: objects, an operator wishing to
	register the location of their geofeed file needs to coordinate with		register the location of their geofeed file needs to coordinate with
	their RIR/NIR and/or any provider LIR which has assigned prefixes to		their RIR/NIR and/or any provider LIR which has assigned address
	them. RIRs/NIRs provide means for assignees to create and maintain		ranges to them. RIRs/NIRs provide means for assignees to create and
	inetnum: objects. They also provide means of [sub-]assigning IP		maintain inetnum: objects. They also provide means of
	address resources and allowing the assignee to create whois data,		[sub-]assigning IP address resources and allowing the assignee to
	including inetnum: objects, and thereby referring to geofeed files.		create whois data, including inetnum: objects, and thereby referring
			to geofeed files.
	The geofeed files MUST be published via and fetched using HTTPS		The geofeed files MUST be published via and fetched using HTTPS
	[RFC2818].		[RFC2818].
	When using data from a geofeed file, one MUST ignore data outside the		When using data from a geofeed file, one MUST ignore data outside the
	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 lines in the geofeed file where the prefix is		consumer MUST use only lines in the geofeed file where the prefix is
	skipping to change at page 10, line 5 ¶		skipping to change at page 9, line 49 ¶
	It is generally prudent for a consumer of geofeed data to also use		It is generally prudent for a consumer of geofeed data to also use
	other sources to cross-validate the data. All the Security		other sources to cross-validate the data. All the Security
	Considerations of [RFC8805] apply here as well.		Considerations of [RFC8805] apply here as well.
	As mentioned in Section 4, many RPSL repositories have weak if any		As mentioned in Section 4, many RPSL repositories have weak if any
	authentication. This allows spoofing of inetnum: objects pointing to		authentication. This allows spoofing of inetnum: objects pointing to
	malicious geofeed files. Section 4 suggests an unfortunately complex		malicious geofeed files. Section 4 suggests an unfortunately complex
	method for stronger authentication based on the RPKI.		method for stronger authentication based on the RPKI.
	For example, if an inetnum: for a wide prefix (e.g. a /16) points to		For example, if an inetnum: for a wide address range (e.g. a /16)
	an RPKI-signed geofeed file, a customer or attacker could publish an		points to an RPKI-signed geofeed file, a customer or attacker could
	unsigned equal or narrower (e.g. a /24) inetnum: in a whois registry		publish an unsigned equal or narrower (e.g. a /24) inetnum: in a
	which has weak authorization, abusing the rule that the most-specific		whois registry which has weak authorization, abusing the rule that
	inetnum: object with a geofeed reference MUST be used.		the most-specific inetnum: object with a geofeed reference MUST be
			used.
	If signatures were mandatory, the above attack would be stymied. But		If signatures were mandatory, the above attack would be stymied. But
	of course that is not happening anytime soon.		of course that is not happening anytime soon.
	The RPSL providers have had to throttle fetching from their servers		The RPSL providers have had to throttle fetching from their servers
	due to too-frequent queries. Usually they throttle by the querying		due to too-frequent queries. Usually they throttle by the querying
	IP address or block. Similar defenses will likely need to be		IP address or block. Similar defenses will likely need to be
	deployed by geofeed file servers.		deployed by geofeed file servers.
	8. IANA Considerations		8. IANA Considerations
End of changes. 11 change blocks.
	23 lines changed or deleted		24 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/