< draft-ietf-opsawg-finding-geofeeds-00.txt		draft-ietf-opsawg-finding-geofeeds-01.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: May 19, 2021 IIJ & Arrcus		Expires: July 23, 2021 IIJ & Arrcus
	W. Kumari		W. Kumari
	Google		Google
	R. Housley		R. Housley
	Vigil Security		Vigil Security
	November 15, 2020		January 19, 2021
	Finding and Using Geofeed Data		Finding and Using Geofeed Data
	draft-ietf-opsawg-finding-geofeeds-00		draft-ietf-opsawg-finding-geofeeds-01
	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 May 19, 2021.		This Internet-Draft will expire on July 23, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	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 . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 9		Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	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 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	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 MAY have, at most, one geofeed
	reference, whether a remark: or a proper geofeed: attribute when one		reference, whether a remarks: or a proper geofeed: attribute when one
	is defined.		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
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	"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 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, and there are a fair number of them.
	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
	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.
			[I-D.michaelson-rpki-rta] describes a Cryptographic Message Syntax
			(CMS) profile for a general purpose Resource Tagged Attestation (RTA)
			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
			trust anchor is used.
	Borrowing detached signatures from [RFC5485], after text file		Borrowing detached signatures from [RFC5485], after text file
	canonicalization (Sec 2.2), the Cryptographic Message Syntax (CMS)		canonicalization (Sec 2.2), the Cryptographic Message Syntax (CMS)
	[RFC3852] would be used to create a detached DER encoded signature		[RFC3852] would be used to create a detached DER encoded signature
	which is then BASE64 encoded and line wrapped to 72 or fewer		which is then BASE64 encoded and line wrapped to 72 or fewer
	characters.		characters.
	Both the address ranges of the signing certificate and of the		Both the address ranges of the signing certificate and of the
	inetnum: MUST cover all prefixes in the geofeed file; and the address		inetnum: MUST cover all prefixes in the geofeed file; and the address
	range of the signing certificate must cover that of the inetnum:.		range of the signing certificate must cover that of the inetnum:.
	skipping to change at page 8, line 32 ¶		skipping to change at page 8, line 43 ¶
	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]		[geofeed-finder]
	Massimo Candela, "geofeed-finder",		Massimo Candela, "geofeed-finder",
	<https://github.com/massimocandela/geofeed-finder>.		<https://github.com/massimocandela/geofeed-finder>.
			[I-D.michaelson-rpki-rta]
			Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T.,
			and M. Hoffmann, "A profile for Resource Tagged
			Attestations (RTAs)", draft-michaelson-rpki-rta-02 (work
			in progress), November 2020.
	[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",		[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
	STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,		STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
	<https://www.rfc-editor.org/info/rfc959>.		<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",
End of changes. 10 change blocks.
	8 lines changed or deleted		20 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/