< draft-ietf-opsawg-finding-geofeeds-06.txt   draft-ietf-opsawg-finding-geofeeds-07.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: October 21, 2021 NTT Expires: November 11, 2021 NTT
W. Kumari W. Kumari
Google Google
R. Housley R. Housley
Vigil Security Vigil Security
April 19, 2021 May 10, 2021
Finding and Using Geofeed Data Finding and Using Geofeed Data
draft-ietf-opsawg-finding-geofeeds-06 draft-ietf-opsawg-finding-geofeeds-07
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 October 21, 2021. This Internet-Draft will expire on November 11, 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 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 . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 5 4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 5
5. Operational Considerations . . . . . . . . . . . . . . . . . 6 5. Operational Considerations . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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 [RFC8805] Section 3 this document specifies how to find the relevant [RFC8805]
geofeed 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, dual IPv4/IPv6 spaces are represented, etc. prefixes, dual IPv4/IPv6 spaces are represented, etc.
[RFC8805] geofeed data may reveal the approximate location of an IP Geofeed data do have privacy considerations, see Section 6
address, which might in turn reveal the approximate location of an
individual user. Unfortunately, [RFC8805] provides no privacy
guidance on avoiding or ameliorating possible damage due to this
exposure of the user. In publishing pointers to geofeed files as
described in this document the operator should be aware of this
exposure in geofeed data and be cautious. All the privacy
considerations of [RFC8805] Section 4 apply to this document.
This document also suggests optional signature, which authenticates This document also suggests optional signature, which authenticates
the data when present, for geofeed files to provide stronger the data when present, for geofeed files to provide stronger
authenticity to the data. authenticity to the data.
3. inetnum: Class 3. inetnum: Class
The Routing Policy Specification Language (RPSL), [RFC4012] used by The Routing Policy Specification Language (RPSL), [RFC4012] used by
the Regional Internet Registries (RIRs) specifies the inetnum: the Regional Internet Registries (RIRs) specifies the inetnum:
database class. Each of these objects describes an IP address range database class. Each of these objects describes an IP address range
and its attributes. The inetnum: objects form a hierarchy ordered on and its attributes. The inetnum: objects form a hierarchy ordered on
the address space. 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 of the inetnum: geofeed HTTPS URL of a geofeed file. The format of the inetnum: geofeed
attribute MUST be as in this example, "remarks: Geofeed" followed by attribute MUST be as in this example, "remarks: Geofeed ", where the
a URL which will vary, but MUST refer only to a single [RFC8805] token "Geofeed" is case sensitive, followed by a URL which will vary,
geofeed file. 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 specify 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, but class be simply "geofeed: " followed by a URL which will vary, but
MUST refer only to a [RFC8805] geofeed file. 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
The URL's use of the web PKI can not provide authentication of IP
address space ownership. It is only used to authenticate a pointer
to the geofeed file and transport integrity of the data. In
contrast, the Resource Public Key Infrastructure (RPKI, see
[RFC6481]) can be used to authenticate IP space ownership; see
optional authentication in Section 4.
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 MUST 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 it reference, whether a remarks: or a proper geofeed: attribute when it
is implemented. If there is more than one, all are ignored. is implemented. If there is more than one, all are ignored.
skipping to change at page 5, line 4 skipping to change at page 4, line 52
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. I.e. an INETNUM object for a 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- prefix P could refer to a geofeed file in which P has been sub-
divided into one or more longer prefixes. 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 [RFC8805] geofeed data The question arises of whether a particular [RFC8805] geofeed data
set is valid, i.e. authorized by the 'owner' of the IP address space set 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 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.
An optional authenticator MAY be appended to a [RFC8805] geofeed An optional authenticator MAY be appended to a [RFC8805] geofeed
file. It is a digest of the main body of the file signed by the file. It is a digest of the main body of the file signed by the
private key of the relevant Resource Public Key Infrastructure (RPKI, private key of the relevant RPKI certificate for the covering address
see [RFC6481]) certificate for the covering address range. One needs range. One needs a format that bundles the relevant RPKI certificate
a format that bundles the relevant RPKI certificate with the with the signature and the digest of the geofeed text.
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 nonprintable characters, such as backspace,
are not expected. For robustness, any nonprintable characters MUST are not expected. For robustness, any nonprintable characters MUST
NOT be changed by canonicalization. Trailing blank lines MUST NOT NOT be changed by canonicalization. Trailing blank lines MUST NOT
skipping to change at page 6, line 7 skipping to change at page 6, line 5
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; and therefore must be covered by the
range 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 the CSV lines in the geofeed file do. boundaries, while those of the CSV lines in the geofeed file do.
Validation of the signing certificate needs to ensure that it is part
of the current manifest and that the resources are covered by the
RPKI certificate.
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 with the Hardware Security Module (HSM) to getting the department with the Hardware Security Module (HSM) to
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
skipping to change at page 7, line 35 skipping to change at page 7, line 36
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 SHOULD NOT fetch more
than weekly. It would be polite not to fetch at magic times such as frequently than weekly. It would be polite not to fetch at magic
midnight UTC, the first of the month, etc., because too many others times such as midnight UTC, the first of the month, etc., because too
are likely to do the same. many others are likely to do the same.
6. Security Considerations 6. Privacy Considerations
[RFC8805] geofeed data may reveal the approximate location of an IP
address, which might in turn reveal the approximate location of an
individual user. Unfortunately, [RFC8805] provides no privacy
guidance on avoiding or ameliorating possible damage due to this
exposure of the user. In publishing pointers to geofeed files as
described in this document the operator should be aware of this
exposure in geofeed data and be cautious. All the privacy
considerations of [RFC8805] Section 4 apply to this document.
7. Security Considerations
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 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 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.
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.
7. IANA Considerations 8. 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. Acknowledgments 9. Acknowledgments
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, Rob Wilton, and George Michaelson, the document shepherd. Prado, Rob Wilton, and George Michaelson, the document shepherd.
9. References 10. References
9.1. Normative References 10.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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 9, line 36 skipping to change at page 10, line 5
[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
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 10.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.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.
 End of changes. 18 change blocks. 
37 lines changed or deleted 51 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/