< draft-ymbk-opsawg-finding-geofeeds-03.txt		draft-ymbk-opsawg-finding-geofeeds-04.txt >
	Network Working Group M. Candela		Network Working Group M. Candela
	Internet-Draft NTT		Internet-Draft NTT
	Intended status: Standards Track R. Bush		Intended status: Standards Track R. Bush
	Expires: March 19, 2021 IIJ & Arrcus		Expires: April 15, 2021 IIJ & Arrcus
	W. Kumari		W. Kumari
	Google		Google
	R. Housley		R. Housley
	Vigil Security		Vigil Security
	September 15, 2020		October 12, 2020
	Finding and Using Geofeed Data		Finding and Using Geofeed Data
	draft-ymbk-opsawg-finding-geofeeds-03		draft-ymbk-opsawg-finding-geofeeds-04
	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 March 19, 2021.		This Internet-Draft will expire on April 15, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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 . . . . . . . . . . . . . . . . . . 2
	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 . . . . . . . . . . . . . . . . . 4
	5. Operational Considerations . . . . . . . . . . . . . . . . . 5		5. Operational Considerations . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	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
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	3. inetnum: Class		3. inetnum: Class
	RPSL, [RFC2622], as used by the Regional Internet Registries (RIRs),		RPSL, [RFC2622], as used by the Regional Internet Registries (RIRs),
	has been augmented with the inetnum: [INETNUM] and the inet6num:		has been augmented with the inetnum: [INETNUM] and the inet6num:
	[INET6NUM] classes; each of which describes an IP address range and		[INET6NUM] classes; each of which describes an IP address range and
	its attributes.		its attributes.
	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 a		defines the syntax of a Geofeed remarks: attribute which contains an
	URL of a geofeed file. The format MUST be as in this example,		HTTPS URL of a geofeed file. The format MUST be as in this example,
	"remarks: Geofeed " followed by a URL which will vary.		"remarks: Geofeed " followed by a URL which will vary.
	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
	Any particular inetnum: object MAY have, at most, one geofeed		Any particular inetnum: object MAY have, at most, one geofeed
	reference.		reference, whether a remark: or a proper geofeed: attribute when one
			is defined.
	inetnum: objects form a hierarchy, see [INETNUM] Section 4.2.4.1,		inetnum: objects form a hierarchy, see [INETNUM] Section 4.2.4.1,
	Hierarchy of INETNUM Objects. Geofeed references SHOULD be at the		Hierarchy of INETNUM Objects. Geofeed references SHOULD be at the
	lowest applicable inetnum: object. When fetching, the most specific		lowest applicable inetnum: object. 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.
	Currently, the registry data published by ARIN and LACNIC are not		Currently, the registry data published by ARIN is not the same RPSL
	RPSL; therefore, when fetching from ARIN or LACNIC, via whois		as the other registries; therefore, when fetching from ARIN via FTP
	[RFC3912], RDAP [RFC7482], or whatever, the "NetRange" attribute/key		[RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the
	must be treated as "inetnum" and the "Comment" attribute must be		"NetRange" attribute/key must be treated as "inetnum" and the
	treated as "remarks".		"Comment" attribute must be treated as "remarks".
	4. Authenticating Geofeed Data		4. Authenticating Geofeed Data
	The question arises on whether a particular geofeed data set is		The question arises of whether a particular geofeed data set is
	valid, i.e. authorized by the 'owner' of the IP address space and is		valid, i.e. authorized by the 'owner' of the IP address space and is
	authoritative in some sense. The inetnum: which points to the		authoritative in some sense. The inetnum: which points to the
	geofeed file provides some assurance. Unfortunately the RPSL in many		geofeed file provides some assurance. Unfortunately the RPSL in many
	repositories is weakly authenticated at best. An approach where RPSL		repositories is weakly authenticated at best. An approach where RPSL
	was signed a la [RFC7909] would be good, except it would have to be		was signed a la [RFC7909] would be good, except it would have to be
	deployed by all RPSL registries.		deployed by all RPSL registries.
	An optional authenticator MAY be appended to a geofeed file. It		An optional authenticator MAY be appended to a geofeed file. It
	would be essentially a digest of the main body of the file signed by		would be essentially 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 the covering
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	an exercise for the implementor. On the other hand, verifying the		an exercise for the implementor. On the other hand, verifying the
	signature requires no complexity; the certificate, which can be		signature requires no complexity; the certificate, which can be
	validated in the public RPKI, has the needed public key.		validated in the public RPKI, has the needed public key.
	Until [RFC8805] is updated to formally define such an appendix, it		Until [RFC8805] is updated 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. This is a cryptographically incorrect, albeit simple
	example. A correct and full example is in Appendix A.		example. A correct and full example is in Appendix A.
	# RPKI Signature: 192.0.2.0/24		# RPKI Signature: 192.0.2.0/24
	# MIIGugYJKoZIhvcNAQcCoIDTALBglghkgBZQMEAgEwKQYLKoZIhvcNAQkQARig		# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
	# GgQYMBYCAhzRMBAwDgQCAAoIIEuDCCBLQwggOcoAMCAQICAwDe4TANBgkqhkiG		# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
	# 9w0BAQsFADAzMTEwLwYDVQQ0VBREI5Mzk2MTFDOTFGMDI3REI1NjNGQ0NDNUI5		...
	# ...		# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
	# w+nU1q1VSZDvw/YVpyaWAu99SjHTxpIBdwp3avpZ84Daxy4h4v084xFvjnqAAg		# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
	# ukYLIfBPdZiuvtLaLR/vjZR4s7mR4L4SNj0WSNPYKwad9cs+ozQpymByDL8VW8		# End Signature: 192.0.2.0/24
	# pUXCTD5sPYzBKsTpAbiDsQ==
	# END Signature: 192.0.2.0/24
	5. Operational Considerations		5. Operational Considerations
	Geofeed data SHOULD be fetched using https [RFC2818].		To create the needed inetnum: objects, an operator wishing to
			register the location of their geofeed file needs to coordinate with
			their RIR/NIR and/or any provider LIR which has assigned prefixes to
			them. RIRs/NIRs provide means for assignees to create and maintain
			inetnum: objects. They also provide means of [sub-]assigning IP
			address resources and allowing the assignee to create whois data,
			including inetnum: objects, and thereby referring to geofeed files.
			The geofeed files SHOULD be published over and fetched using https
			[RFC2818].
	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 inetnum: object's inetnum: attribute's address range.		the referring inetnum: object's inetnum: attribute address range.
	Iff the geofeed file is not signed per Section 4, then multiple		Iff the geofeed file is not signed per Section 4, then multiple
	inetnum: objects MAY refer to the same geofeed file, and the consumer		inetnum: objects MAY refer to the same geofeed file, and the consumer
	MUST use only geofeed lines where the prefix is covered by the		MUST use only geofeed lines where the prefix is covered by the
	address range of the inetnum: object they have followed.		address range of the inetnum: object they have followed.
			To minimize the load on RIR whois [RFC3912] services, use of the
			RIR's FTP [RFC0959] services SHOULD be the preferred access. This
			also provides bulk access instead of fetching with a tweezers.
			Currently, geolocation providers have bulk whois data access at all
			the RIRs. An anonymized version of such data is openly available for
			all RIRs except ARIN, which requires an authorization. However, for
			users without such authorization the same result can be achieved with
			extra RDAP effort. There is open source code to pass over such data
			across all RIRs, collect all geofeed references, and process them
			[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 Cacheing 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 absense 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 wise 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 would be generally prudent for a consumer of geofeed data to also
	use other sources to cross-validate the data. All of the Security		use 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 would allow spoofing of inetnum: objects
	pointing to malicious geofeed files. Section 4 suggests a sadly		pointing to malicious geofeed files. Section 4 suggests an
	complex method for stronger authentication based on the RPKI.		unfortunately complex method for stronger authentication based on the
			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 a unsigned
			equal or narrower (e.g. a /24) inetnum: in a whois registry which has
			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.
	7. IANA Considerations		7. IANA Considerations
	IANA is asked to register object identifiers for one content type in		IANA is asked to register object identifiers for one content type in
	the "SMI Security for S/MIME CMS Content Type		the "SMI Security for S/MIME CMS Content Type
	(1.2.840.113549.1.9.16.1)" registry as follows:		(1.2.840.113549.1.9.16.1)" registry as follows:
	Description OID Specification		Description OID Specification
	-----------------------------------------------------------------		-----------------------------------------------------------------
	id-ct-geofeedCSVwithCRLF 1.2.840.113549.1.9.16.1.47 [RFC-TBD]		id-ct-geofeedCSVwithCRLF 1.2.840.113549.1.9.16.1.47 [RFC-TBD]
	8. Acknowledgements		8. Acknowledgements
	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. Also		Michaelson for the first, and a substantial, external review. Erik
	to Erik Kline who was too shy to agree to co-authorship.		Kline who was too shy to agree to co-authorship. Additionally, we
			express our gratitude to early implementors, including Menno
			Schepers, Flavio Luciani, Eric Dugas, and Kevin Pack. Also to
			geolocation providers that are consuming geofeeds with this described
			solution, Jonathan Kosgei (ipdata.co), and Ben Dowling (ipinfo.io).
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[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-
	skipping to change at page 7, line 34 ¶		skipping to change at page 8, line 20 ¶
	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>.
	[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
	Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,		Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
	<https://www.rfc-editor.org/info/rfc8805>.		<https://www.rfc-editor.org/info/rfc8805>.
	9.2. Informative References		9.2. Informative References
			[geofeed-finder]
			Massimo Candela, "geofeed-finder",
			<https://github.com/massimocandela/geofeed-finder>.
			[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
			STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
			<https://www.rfc-editor.org/info/rfc959>.
	[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,		[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
	DOI 10.17487/RFC3912, September 2004,		DOI 10.17487/RFC3912, September 2004,
	<https://www.rfc-editor.org/info/rfc3912>.		<https://www.rfc-editor.org/info/rfc3912>.
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<https://www.rfc-editor.org/info/rfc7234>.		<https://www.rfc-editor.org/info/rfc7234>.
	[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access		[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
End of changes. 19 change blocks.
	35 lines changed or deleted		73 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/