< draft-ietf-opsawg-finding-geofeeds-04.txt		draft-ietf-opsawg-finding-geofeeds-05.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: August 23, 2021 NTT		Expires: October 15, 2021 NTT
	W. Kumari		W. Kumari
	Google		Google
	R. Housley		R. Housley
	Vigil Security		Vigil Security
	February 19, 2021		April 13, 2021
	Finding and Using Geofeed Data		Finding and Using Geofeed Data
	draft-ietf-opsawg-finding-geofeeds-04		draft-ietf-opsawg-finding-geofeeds-05
	Abstract		Abstract
	This document describes how to find and authenticate geofeed data.		This document describes how to find and authenticate geofeed data.
	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 August 23, 2021.		This Internet-Draft will expire on October 15, 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
	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
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3		3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 4		4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 5
	5. Operational Considerations . . . . . . . . . . . . . . . . . 6		5. Operational Considerations . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Providers of Internet content and other services may wish to		Providers of Internet content and other services may wish to
	customize those services based on the geographic location of the user		customize those services based on the geographic location of the user
	of the service. This is often done using the source IP address used		of the service. This is often done using the source IP address used
	to contact the service. Also, infrastructure and other services		to contact the service. Also, infrastructure and other services
	might wish to publish the locale of their services. [RFC8805]		might wish to publish the locale of their services. [RFC8805]
	defines geofeed, a syntax to associate geographic locales with IP		defines geofeed, a syntax to associate geographic locales with IP
	addresses. But it does not specify how to find the relevant geofeed		addresses. But it does not specify how to find the relevant geofeed
	data given an IP address.		data given an IP address.
	This document specifies how to augment the Routing Policy		This document specifies how to augment the Routing Policy
	Specification Language (RPSL) [RFC4012] inetnum: class [RFC2725] and		Specification Language (RPSL) [RFC4012] inetnum: class to refer
	[INETNUM] to refer to geofeed data, and how to prudently use them.		specifically to geofeed data CSV files, and how to prudently use
	In all places inetnum: is used, inet6num: should also be assumed		them. In all places inetnum: is used, inet6num: should also be
	[RFC4012] and [INET6NUM].		assumed [RFC4012].
	An optional, but utterly awesome, means for authenticating geofeed		The reader may find [INETNUM] and [INET6NUM] informative, and
	data is also defined.		certainly more verbose, descriptions of the inetnum: database
			classes.
			An optional, utterly awesome but slightly complex, means for
			authenticating geofeed data is also defined.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Geofeed Files		2. Geofeed Files
	Geofeed files are described in [RFC8805]. They provide a facility		Geofeed files are described in [RFC8805]. They provide a facility
	for an IP address resource 'owner' to associate those IP addresses to		for an IP address resource 'owner' to associate those IP addresses to
	geographic locale(s).		geographic locale(s).
	Content providers and other parties who wish to locate an IP address		Content providers and other parties who wish to locate an IP address
	to a geographic locale need to find the relevant geofeed data. In		to a geographic locale need to find the relevant geofeed data. In
	Section 3 this document specifies how to find the relevant geofeed		Section 3 this document specifies how to find the relevant [RFC8805]
	file given an IP address.		geofeed file given an IP address.
	Geofeed data for large providers with significant horizontal scale		Geofeed data for large providers with significant horizontal scale
	and high granularity can be quite large. The size of a file can be		and high granularity can be quite large. The size of a file can be
	even larger if an unsigned geofeed file combines data for many		even larger if an unsigned geofeed file combines data for many
	prefixes, as may be likely if the location data are maintained by a		prefixes, dual IPv4/IPv6 spaces are represented, etc.
	different department than address management, dual IPv4/IPv6 spaces
	are represented, etc.
	[RFC8805] geofeed data may reveal the approximate location of an IP		[RFC8805] geofeed data may reveal the approximate location of an IP
	address, which might in turn reveal the approximate location of an		address, which might in turn reveal the approximate location of an
	individual user. Unfortunately, [RFC8805] provides no privacy		individual user. Unfortunately, [RFC8805] provides no privacy
	guidance on avoiding or ameliorating possible damage due to this		guidance on avoiding or ameliorating possible damage due to this
	exposure of the user. In publishing pointers to geofeed files as		exposure of the user. In publishing pointers to geofeed files as
	described in this document the operator should be aware of this		described in this document the operator should be aware of this
	exposure in geofeed data and be cautious. All the privacy		exposure in geofeed data and be cautious. All the privacy
	considerations of [RFC8805] Section 4 apply to this document.		considerations of [RFC8805] Section 4 apply to this document.
	This document also suggests optional data for geofeed files to		This document also suggests optional signature, which authenticates
	provide stronger authenticity to the data.		the data when present, for geofeed files to provide stronger
			authenticity to the data.
	3. inetnum: Class		3. inetnum: Class
	RPSL, [RFC4012], as used by the Regional Internet Registries (RIRs),		The Routing Policy Specification Language (RPSL), [RFC4012] used by
	has been augmented with the inetnum: [INETNUM] and the inet6num:		the Regional Internet Registries (RIRs) specifies inetnum: database
	[INET6NUM] classes; each of which describes an IP address range and		classs. Each of these objects describes an IP address range and its
	its attributes.		attributes. The inetnum: objects form a 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
	defines the syntax of a Geofeed remarks: attribute which contains an		defines the syntax of a Geofeed remarks: attribute which contains an
	HTTPS URL of a geofeed file. The format MUST be as in this example,		HTTPS URL of a geofeed file. The format of the inetnum: geofeed
	"remarks: Geofeed " followed by a URL which will vary.		attribute MUST be as in this example, "remarks: Geofeed" followed by
			a URL which will vary, but MUST refer only to a single [RFC8805]
			geofeed file.
	inetnum: 192.0.2.0/24 # example		inetnum: 192.0.2.0/24 # example
	remarks: Geofeed https://example.com/geofeed.csv		remarks: Geofeed https://example.com/geofeed.csv
	While we leave global agreement of RPSL modification to the relevant		While we leave global agreement of RPSL modification to the relevant
	parties, we suggest that a proper geofeed: attribute in the inetnum:		parties, we specify that a proper geofeed: attribute in the inetnum:
	class be simply "geofeed: " followed by a URL which will vary.		class be simply "geofeed: " followed by a URL which will vary, but
			MUST refer only to a [RFC8805] geofeed file.
	inetnum: 192.0.2.0/24 # example		inetnum: 192.0.2.0/24 # example
	geofeed: https://example.com/geofeed.csv		geofeed: https://example.com/geofeed.csv
	Until all producers of inetnum:s, i.e. the RIRs, state that they have		Until all producers of inetnum:s, i.e. the RIRs, state that they have
	migrated to supporting a geofeed: attribute, consumers looking at		migrated to supporting a geofeed: attribute, consumers looking at
	inetnum:s to find geofeed URLs MUST be able to consume both the		inetnum:s to find geofeed URLs MUST be able to consume both the
	remarks: and geofeed: forms. This not only implies that the RIRs		remarks: and geofeed: forms. This not only implies that the RIRs
	support the geofeed: attribute, but that all registrants have		support the geofeed: attribute, but that all registrants have
	migrated any inetnum:s from remarks: use to geofeed:s.		migrated any inetnum:s from remarks: use to geofeed:s.
	Any particular inetnum: object MAY have, at most, one geofeed		Any particular inetnum: object MUST have at most, one geofeed
	reference, whether a remarks: or a proper geofeed: attribute when one		reference, whether a remarks: or a proper geofeed: attribute when it
	is defined.		is implemented. If there is more than one, all are ignored.
	inetnum: objects form a hierarchy, see [INETNUM] Section 4.2.4.1,		If a geofeed CSV file describes multiple disjoint ranges of IP
	Hierarchy of INETNUM Objects. Geofeed references SHOULD be at the		address space, there are likely to be geofeed references from
	lowest applicable inetnum: object. When fetching, the most specific		multiple inetnum: objects.
			As inetnum: objects form a hierarchy, Geofeed references SHOULD be at
			the lowest applicable inetnum: object covering the relevant prefixes
			in the referenced geofeed file. When fetching, the most specific
	inetnum: object with a geofeed reference MUST be used.		inetnum: object with a geofeed reference MUST be used.
	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.
	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.		the inetnum: which refers to them. I.e. an INETNUM object for a
			prefix P could refer to a geofeed file in which P has been 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 the other registries; therefore, when fetching from ARIN via FTP		as the other registries; 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
	The question arises of whether a particular geofeed data set is		The question arises of whether a particular [RFC8805] geofeed data
	valid, i.e. authorized by the 'owner' of the IP address space and is		set is valid, i.e. authorized by the 'owner' of the IP address space
	authoritative in some sense. The inetnum: which points to the		and is authoritative in some sense. The inetnum: which points to the
	geofeed file provides some assurance. Unfortunately the RPSL in many		[RFC8805] geofeed file provides some assurance. Unfortunately the
	repositories is weakly authenticated at best. An approach where RPSL		RPSL in many repositories is weakly authenticated at best. An
	was signed a la [RFC7909] would be good, except it would have to be		approach where RPSL was signed a la [RFC7909] would be good, except
	deployed by all RPSL registries, and there is a fair number of them.		it would have to be deployed by all RPSL registries, and there is a
			fair number of them.
	An optional authenticator MAY be appended to a geofeed file. It		An optional authenticator MAY be appended to a [RFC8805] geofeed
	would be essentially a digest of the main body of the file signed by		file. It is a digest of the main body of the file signed by the
	the private key of the relevant RPKI certificate for the covering		private key of the relevant Resource Public Key Infrastructure (RPKI,
	address range. One needs a format that bundles the relevant RPKI		see [RFC6481]) certificate for the covering address range. One needs
	certificate with the signature and the digest of the geofeed text.		a format that bundles the relevant RPKI certificate with the
			signature and the digest of the geofeed text.
	Borrowing detached signatures from [RFC5485], after text file		The canonicalization procedure converts the data from its internal
	canonicalization (Sec 2.2), the Cryptographic Message Syntax (CMS)		character representation to the UTF-8 [RFC3629] character encoding,
	[RFC5652] would be used to create a detached DER encoded signature		and the <CRLF> sequence MUST be used to denote the end of a line of
	which is then BASE64 encoded and line wrapped to 72 or fewer		text. Trailing space characters MUST NOT appear on a line of text.
	characters.		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. Other nonprintable characters, such as backspace,
			are not expected. For robustness, any nonprintable characters MUST
			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
			multiple consecutive <CRLF> sequences. Any end-of-file marker used
			by an operating system is not considered to be part of the file
			content. When present, such end-of-file markers MUST NOT be
			processed by the digital signature algorithm. Borrowing detached
			signatures from [RFC5485], after file canonicalization, the
			Cryptographic Message Syntax (CMS) [RFC5652] would be used to create
			a detached DER encoded signature which is then BASE64 encoded and
			line wrapped to 72 or fewer characters.
	Both the address ranges of the signing certificate and of the		The address range of the signing certificate MUST cover all prefixes
	inetnum: MUST cover all prefixes in the geofeed file; and the address		in the geofeed file it signs; and therefore must be covered by the
	range of the signing certificate must cover that of the inetnum:.		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 geofeed lines must.		boundaries, while those of the CSV lines in the geofeed file do.
	As the signer would need to specify the covered RPKI resources		As the signer specifies the covered RPKI resources relevant to the
	relevant to the signature, the RPKI certificate covering the inetnum:		signature, the RPKI certificate covering the inetnum: object's
	object's address range would be included in the [RFC5652] CMS		address range is included in the [RFC5652] CMS SignedData
	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 with the HSM to sign the CMS blob is left as		getting the department with the Hardware Security Module (HSM) to
	an exercise for the implementor. On the other hand, verifying the		sign the CMS blob is left as an exercise for the implementor. On the
	signature requires no complexity; the certificate, which can be		other hand, verifying the signature requires no complexity; the
	validated in the public RPKI, has the needed public key.		certificate, which can be validated in the public RPKI, has the
			needed public key.
	Until [RFC8805] is updated to formally define such an appendix, it		Unless [RFC8805] is modified to formally define such an appendix, it
	MUST be 'hidden' as a series of "#" comments at the end of the		MUST be 'hidden' as a series of "#" comments at the end of the
	geofeed file. This is a cryptographically incorrect, albeit simple		geofeed file. The following is a cryptographically incorrect, albeit
	example. A correct and full example is in Appendix A.		simple example. A correct and full example is in Appendix A.
	# RPKI Signature: 192.0.2.0/24		# RPKI Signature: 192.0.2.0/24
	# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ		# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
	# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu		# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
	...		...
	# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa		# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
	# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=		# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
	# End Signature: 192.0.2.0/24		# End Signature: 192.0.2.0/24
			The signature does not cover the signature lines.
	[I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a		[I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a
	Cryptographic Message Syntax (CMS) profile for a general purpose		Cryptographic Message Syntax (CMS) profile for a general purpose
	listing of checksums (a 'checklist'), for use with the Resource		listing of checksums (a 'checklist'), for use with the Resource
	Public Key Infrastructure (RPKI). It provides usable, albeit		Public Key Infrastructure (RPKI). It provides usable, albeit
	complex, code to sign geofeed files.		complex, code to sign geofeed files.
	[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
	skipping to change at page 6, line 29 ¶		skipping to change at page 7, line 14 ¶
	inetnum: objects. They also provide means of [sub-]assigning IP		inetnum: objects. They also provide means of [sub-]assigning IP
	address resources and allowing the assignee to create whois data,		address resources and allowing the assignee to create whois data,
	including inetnum: objects, and thereby referring to geofeed files.		including inetnum: objects, and thereby referring to geofeed files.
	The geofeed files SHOULD be published over and fetched using https		The geofeed files SHOULD be published over and fetched using https
	[RFC8446].		[RFC8446].
	When using data from a geofeed file, one MUST ignore data outside of		When using data from a geofeed file, one MUST ignore data outside of
	the referring inetnum: object's inetnum: attribute address range.		the referring inetnum: object's inetnum: attribute address range.
	Iff the geofeed file is not signed per Section 4, then multiple		If and only if the geofeed file is not signed per Section 4, then
	inetnum: objects MAY refer to the same geofeed file, and the consumer		multiple inetnum: objects MAY refer to the same geofeed file, and the
	MUST use only geofeed lines where the prefix is covered by the		consumer MUST use only geofeed lines where the prefix is covered by
	address range of the inetnum: object they have followed.		the address range of the inetnum: object they have followed.
	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 with a tweezers.		also provides bulk access instead of fetching with tweezers.
	Currently, geolocation providers have bulk whois data access at all		Currently, geolocation providers have bulk whois data access at all
	the RIRs. An anonymized version of such data is openly available for		the RIRs. An anonymized version of such data is openly available for
	all RIRs except ARIN, which requires an authorization. However, for		all RIRs except ARIN, which requires an authorization. However, for
	users without such authorization the same result can be achieved with		users without such authorization the same result can be achieved with
	extra RDAP effort. There is open source code to pass over such data		extra RDAP effort. There is open source code to pass over such data
	across all RIRs, collect all geofeed references, and process them		across all RIRs, collect all geofeed references, and process them
	[geofeed-finder].		[geofeed-finder].
	An entity fetching geofeed data using these mechanisms MUST NOT do		An entity fetching geofeed data using these mechanisms MUST NOT do
	frequent real-time look-ups to prevent load on RPSL and geofeed		frequent real-time look-ups to prevent load on RPSL and geofeed
	servers. [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP		servers. [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP
	Expires Caching Header to signal when geofeed data should be		Expires Caching Header to signal when geofeed data should be
	refetched. As the data change very infrequently, in the absence of		refetched. As the data change very infrequently, in the absence of
	such an HTTP Header signal, collectors MUST NOT fetch more frequently		such an HTTP Header signal, collectors MUST NOT fetch more frequently
	than weekly. It would be wise not to fetch at magic times such as		than weekly. It would be polite not to fetch at magic times such as
	midnight UTC, the first of the month, etc., because too many others		midnight UTC, the first of the month, etc., because too many others
	are likely to do the same.		are likely to do the same.
	6. Security Considerations		6. Security Considerations
	It would be generally prudent for a consumer of geofeed data to also		It is generally prudent for a consumer of geofeed data to also use
	use other sources to cross-validate the data. All of the Security		other sources to cross-validate the data. All of 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 would allow spoofing of inetnum: objects		authentication. This allows spoofing of inetnum: objects pointing to
	pointing to malicious geofeed files. Section 4 suggests an		malicious geofeed files. Section 4 suggests an unfortunately complex
	unfortunately complex method for stronger authentication based on the		method for stronger authentication based on the RPKI.
	RPKI.
	If an inetnum: for a wide prefix (e.g. a /16) points to an RPKI-		If an inetnum: for a wide prefix (e.g. a /16) points to an RPKI-
	signed geofeed file, a customer or attacker could publish an unsigned		signed geofeed file, a customer or attacker could publish an unsigned
	equal or narrower (e.g. a /24) inetnum: in a whois registry which has		equal or narrower (e.g. a /24) inetnum: in a whois registry which has
	weak authorization.		weak authorization.
	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.
	skipping to change at page 7, line 51 ¶		skipping to change at page 8, line 36 ¶
	Thanks to Rob Austein for CMS and detached signature clue. George		Thanks to Rob Austein for CMS and detached signature clue. George
	Michaelson for the first, and a substantial, external review. Erik		Michaelson for the first, and a substantial, external review. Erik
	Kline who was too shy to agree to co-authorship. Additionally, we		Kline who was too shy to agree to co-authorship. Additionally, we
	express our gratitude to early implementors, including Menno		express our gratitude to early implementors, including Menno
	Schepers, Flavio Luciani, Eric Dugas, Job Snijders who provided		Schepers, Flavio Luciani, Eric Dugas, Job Snijders who provided
	running code, and Kevin Pack. Also to geolocation providers that are		running code, and Kevin Pack. Also to geolocation providers that are
	consuming geofeeds with this described solution, Jonathan Kosgei		consuming geofeeds with this described solution, Jonathan Kosgei
	(ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat		(ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat
	(bigdatacloud.com). For reviews, we thank Adrian Farrel, Antonio		(bigdatacloud.com). For reviews, we thank Adrian Farrel, Antonio
	Prado, and George Michaelson, the document shepherd.		Prado, Rob Wilton, and George Michaelson, the document shepherd.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	Murphy, "Routing Policy System Security", RFC 2725,		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	DOI 10.17487/RFC2725, December 1999,		2003, <https://www.rfc-editor.org/info/rfc3629>.
	<https://www.rfc-editor.org/info/rfc2725>.
	[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,		[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
	"Routing Policy Specification Language next generation		"Routing Policy Specification Language next generation
	(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,		(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,
	<https://www.rfc-editor.org/info/rfc4012>.		<https://www.rfc-editor.org/info/rfc4012>.
	[RFC5485] Housley, R., "Digital Signatures on Internet-Draft		[RFC5485] Housley, R., "Digital Signatures on Internet-Draft
	Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009,		Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009,
	<https://www.rfc-editor.org/info/rfc5485>.		<https://www.rfc-editor.org/info/rfc5485>.
	[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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.		[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
	Kumari, "A Format for Self-Published IP Geolocation		Kumari, "A Format for Self-Published IP Geolocation
	skipping to change at page 9, line 13 ¶		skipping to change at page 9, line 50 ¶
	<https://github.com/massimocandela/geofeed-finder>.		<https://github.com/massimocandela/geofeed-finder>.
	[I-D.ietf-sidrops-rpki-rta]		[I-D.ietf-sidrops-rpki-rta]
	Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T.,		Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T.,
	and M. Hoffmann, "A profile for Resource Tagged		and M. Hoffmann, "A profile for Resource Tagged
	Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work		Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work
	in progress), January 2021.		in progress), January 2021.
	[I-D.spaghetti-sidrops-rpki-rsc]		[I-D.spaghetti-sidrops-rpki-rsc]
	Snijders, J., "RPKI Signed Checklists", draft-spaghetti-		Snijders, J., "RPKI Signed Checklists", draft-spaghetti-
	sidrops-rpki-rsc-02 (work in progress), February 2021.		sidrops-rpki-rsc-03 (work in progress), February 2021.
	[INET6NUM]		[INET6NUM]
	RIPE, "Description of the INET6NUM Object",		RIPE, "Description of the INET6NUM Object",
	<https://www.ripe.net/manage-ips-and-		<https://www.ripe.net/manage-ips-and-
	asns/db/support/documentation/ripe-database-documentation/		asns/db/support/documentation/ripe-database-documentation/
	rpsl-object-types/4-2-descriptions-of-primary-		rpsl-object-types/4-2-descriptions-of-primary-
	objects/4-2-3-description-of-the-inet6num-object>.		objects/4-2-3-description-of-the-inet6num-object>.
	[INETNUM] RIPE, "Description of the INETNUM Object",		[INETNUM] RIPE, "Description of the INETNUM Object",
	<https://www.ripe.net/manage-ips-and-		<https://www.ripe.net/manage-ips-and-
End of changes. 41 change blocks.
	90 lines changed or deleted		125 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/