< draft-ietf-opsawg-finding-geofeeds-10.txt   draft-ietf-opsawg-finding-geofeeds-11.txt >
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ & Arrcus Internet-Draft IIJ & Arrcus
Intended status: Standards Track M. Candela Intended status: Standards Track M. Candela
Expires: November 18, 2021 NTT Expires: November 20, 2021 NTT
W. Kumari W. Kumari
Google Google
R. Housley R. Housley
Vigil Security Vigil Security
May 17, 2021 May 19, 2021
Finding and Using Geofeed Data Finding and Using Geofeed Data
draft-ietf-opsawg-finding-geofeeds-10 draft-ietf-opsawg-finding-geofeeds-11
Abstract Abstract
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language inetnum: class to refer specifically to Specification Language inetnum: class to refer specifically to
geofeed data CSV files, and describes an optional scheme to use the geofeed data CSV files, and describes an optional scheme to use the
Routing Public Key Intrastructure to authenticate the geofeed data Routing Public Key Infrastructure to authenticate the geofeed data
CSV files. CSV files.
Status of This Memo Status of This Memo
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 November 18, 2021. This Internet-Draft will expire on November 20, 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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 8
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 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.
Geofeed data do have privacy considerations, see Section 6. Geofeed data do have privacy considerations, see Section 6; and this
process makes bulk access to those data easier.
This document also suggests optional signature, which authenticates This document also suggests an optional signature to strongly
the data when present, for geofeed files to provide stronger authenticate the data in the geofeed files.
authenticity to the data.
3. inetnum: Class 3. inetnum: Class
The original RPSL specifications starting with [RIPE81], [RIPE181], The original RPSL specifications starting with [RIPE81], [RIPE181],
and a trail of subsequent documents were done by the RIPE community. and a trail of subsequent documents were done by the RIPE community.
The IETF standardardized RPSL in [RFC2622] and [RFC4012]. Since The IETF standardardized RPSL in [RFC2622] and [RFC4012]. Since
then, it has been modified and extensively enhanced in the RIR then, it has been modified and extensively enhanced in the Regional
community, mostly by RIPE, [RIPE-DB]. Currently, change contol Interney Registry (RIR) community, mostly by RIPE, [RIPE-DB].
effectively lies in the operator community. Currently, change control effectively lies in the operator community.
The Routing Policy Specification Language (RPSL), and [RFC2622] and The Routing Policy Specification Language (RPSL), and [RFC2622] and
[RFC4012] used by the Regional Internet Registries (RIRs) specifies [RFC4012] used by the Regional Internet Registries (RIRs) specifies
the inetnum: database class. Each of these objects describes an IP the inetnum: database class. Each of these objects describes an IP
address range and its attributes. The inetnum: objects form a address range and its attributes. The inetnum: objects form a
hierarchy ordered on the address space. 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
skipping to change at page 4, line 26 skipping to change at page 4, line 26
will vary, but MUST refer only to a single [RFC8805] geofeed file. 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
geofeed: https://example.com/geofeed.csv geofeed: https://example.com/geofeed.csv
Registries MAY, for the interim, provide a mix of the remarks: Registries MAY, for the interim, provide a mix of the remarks:
attribute form and the geofeed: attribute form. attribute form and the geofeed: attribute form.
The URL's use of the web PKI can not provide authentication of IP 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 address space ownership. It is only used to authenticate a pointer
to the geofeed file and transport integrity of the data. In to the geofeed file, authenticate the domain name in the URL, and
contrast, the Resource Public Key Infrastructure (RPKI, see provide confidentiality and integrity for the geofeed file in
[RFC6481]) can be used to authenticate IP space ownership; see transit. In contrast, the Resource Public Key Infrastructure (RPKI,
see [RFC6481]) can be used to authenticate IP space ownership; see
optional authentication in Section 4. 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. The migration not only implies that the
support the geofeed: attribute, but that all registrants have RIRs 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.
If a geofeed CSV file describes multiple disjoint ranges of IP If a geofeed CSV file describes multiple disjoint ranges of IP
address space, there are likely to be geofeed references from address space, there are likely to be geofeed references from
multiple inetnum: objects. multiple inetnum: objects.
skipping to change at page 5, line 16 skipping to change at page 5, line 16
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. For example an INETNUM object for the inetnum: which refers to them. For example an INETNUM object for
a prefix P could refer to a geofeed file in which P has been sub- a 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 that of the other registries (see [RFC7485] for a survery of the as that of the other registries (see [RFC7485] for a survey of the
whois Tower of Babel); therefore, when fetching from ARIN via FTP whois Tower of Babel); therefore, when fetching from ARIN via FTP
[RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the [RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the
"NetRange" attribute/key MUST be treated as "inetnum" and the "NetRange" attribute/key MUST be treated as "inetnum" and the
"Comment" attribute MUST be treated as "remarks". "Comment" attribute MUST be treated as "remarks".
4. Authenticating Geofeed Data 4. Authenticating Geofeed Data
The question arises whether a particular [RFC8805] geofeed data set The question arises whether a particular [RFC8805] geofeed data set
is valid, i.e. is authorized by the 'owner' of the IP address space is valid, i.e. is authorized by the 'owner' of the IP address space
and is authoritative in some sense. The inetnum: which points to the and is authoritative in some sense. The inetnum: which points to the
[RFC8805] geofeed file provides some assurance. Unfortunately, the [RFC8805] geofeed file provides some assurance. Unfortunately, the
RPSL in many repositories is weakly authenticated at best. An RPSL in many repositories is weakly authenticated at best. An
approach where RPSL was signed a la [RFC7909] would be good, except approach where RPSL was signed a la [RFC7909] would be good, except
it would have to be deployed by all RPSL registries, and there is a it would have to be deployed by all RPSL registries, and there is a
fair number of them. fair number of them.
An optional authenticator MAY be appended to a [RFC8805] geofeed A single optional authenticator MAY be appended to a [RFC8805]
file. It is a digest of the main body of the file signed by the geofeed file. It is a digest of the main body of the file signed by
private key of the relevant RPKI certificate for the covering address the private key of the relevant RPKI certificate for the covering
range. One needs a format that bundles the relevant RPKI certificate address range. One needs a format that bundles the relevant RPKI
with the signature and the digest of the geofeed text. certificate with the 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 11 skipping to change at page 6, line 11
by an operating system is not considered to be part of the file by an operating system is not considered to be part of the file
content. When present, such end-of-file markers MUST NOT be content. When present, such end-of-file markers MUST NOT be
processed by the digital signature algorithm. processed by the digital signature algorithm.
Should the authenticator be syntactically incorrect per the above, Should the authenticator be syntactically incorrect per the above,
the authenticator is invalid. the authenticator is invalid.
Borrowing detached signatures from [RFC5485], after file Borrowing detached signatures from [RFC5485], after file
canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
would be used to create a detached DER encoded signature which is would be used to create a detached DER encoded signature which is
then BASE64 encoded and line wrapped to 72 or fewer characters. then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
or fewer characters.
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 As the signer specifies the covered RPKI resources relevant to the
of the current manifest and that the resources are covered by the signature, the RPKI certificate covering the inetnum: object's
RPKI certificate. address range is included in the [RFC5652] CMS SignedData
certificates field.
Identifying the private key associated with the certificate, and
getting the department with the Hardware Security Module (HSM) to
sign the CMS blob is left as an exercise for the implementor. On the
other hand, verifying the signature requires no complexity; the
certificate, which can be validated in the public RPKI, has the
needed public key. The trust anchors for the RIRs are expected to
already be available to the party performing signature validation.
Validation of the CMS signature on the geofeed file involves:
1. Obtain the signer's certificate from an RPKI Repository. The
certificate SubjectKeyIdentifier extension [RFC5280] MUST match
the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
xref target="RFC5286"/>. If the key identifiers do not match,
then validation MUST fail.
2. Construct the certification path for the signer's certificate.
All of the needed certificates are expected to be readily
available in the RPKI Repository. The certification path MUST be
valid according to the validation algorithm in [RFC5280] and the
additional checks specified in [RFC3779] associated with the IP
Address Delegation certificate extension and the Autonomous
System Identifier Delegation certificate extension. If
certification path validation is unsuccessful, then validation
MUST fail.
3. Validate the CMS SignedData as specified in [RFC5652] using the
public key from the validated signer's certificate. If the
signature validation is unsuccessful, then validation MUST fail.
4. Verify that the IP Address Delegation certificate extension
[RFC3779] covers the address range of the geofeed file. If the
address range is not covered, then validation MUST fail.
5. Validation of the signing certificate MUST ensure that it is part
of the current manifest and that the resources are covered by the
RPKI certificate.
All of these steps MUST be successful to consider the geofeed file
signature as valid.
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
skipping to change at page 7, line 5 skipping to change at page 7, line 46
# 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. The signature does not cover the signature lines.
The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
present exactly as shown.
[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 7, line 38 skipping to change at page 8, line 34
[RFC2818]. [RFC2818].
When using data from a geofeed file, one MUST ignore data outside the When using data from a geofeed file, one MUST ignore data outside the
referring inetnum: object's inetnum: attribute address range. referring inetnum: object's inetnum: attribute address range.
If and only if the geofeed file is not signed per Section 4, then If and only if the geofeed file is not signed per Section 4, then
multiple inetnum: objects MAY refer to the same geofeed file, and the multiple inetnum: objects MAY refer to the same geofeed file, and the
consumer MUST use only geofeed lines where the prefix is covered by consumer MUST use only geofeed lines where the prefix is covered by
the address range of the inetnum: object they have followed. the address range of the inetnum: object they have followed.
If the geofeed file is signed, and the signer's certificate changes,
the signature in the geofeed file MUST be updated.
It is good key hygene to use a given key for only one purpose. To
dedicate a signing private key for signing a geofeed file, an RPKI CA
may issue a subordinate certificate exclusively for the purpose as
shown in Appendix A.
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 tweezers. also provides bulk access instead of fetching by brute force search
through the IP space.
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 users without such authorization, the same result can be achieved
with extra RDAP effort. There is open source code to pass over such with extra RDAP effort. There is open source code to pass over such
data across all RIRs, collect all geofeed references, and process data across all RIRs, collect all geofeed references, and process
them [geofeed-finder]. them [geofeed-finder].
An entity fetching geofeed data using these mechanisms MUST NOT do To prevent undue load on RPSL and geofeed servers, an entity fetching
frequent real-time look-ups to prevent load on RPSL and geofeed geofeed data using these mechanisms MUST NOT do frequent real-time
servers. [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP look-ups. [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 SHOULD NOT fetch more such an HTTP Header signal, collectors SHOULD NOT fetch more
frequently than weekly. It would be polite not to fetch at magic frequently than weekly. It would be polite not to fetch at magic
times such as midnight UTC, the first of the month, etc., because too times such as midnight UTC, the first of the month, etc., because too
many others are likely to do the same. many others are likely to do the same.
6. Privacy Considerations 6. Privacy Considerations
[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.
Where [RFC8805] provided the ability to publish location data, this
document makes bulk access to those data readily available.
7. Security Considerations 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 the Security other sources to cross-validate the data. All the Security
Considerations of [RFC8805] apply here as well. Considerations of [RFC8805] apply here as well.
As mentioned in Section 4, many RPSL repositories have weak if any As mentioned in Section 4, many RPSL repositories have weak if any
authentication. This allows spoofing of inetnum: objects pointing to authentication. This allows spoofing of inetnum: objects pointing to
malicious geofeed files. Section 4 suggests an unfortunately complex malicious geofeed files. Section 4 suggests an unfortunately complex
method for stronger authentication based on the RPKI. method for stronger authentication based on the RPKI.
skipping to change at page 9, line 15 skipping to change at page 10, line 25
9. 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 substantial external review, Erik Kline Michaelson for the first and substantial external review, Erik Kline
who was too shy to agree to co-authorship. Additionally, we express who was too shy to agree to co-authorship. Additionally, we express
our gratitude to early implementors, including Menno Schepers, Flavio our gratitude to early implementors, including Menno Schepers, Flavio
Luciani, Eric Dugas, Job Snijders who provided running code, and Luciani, Eric Dugas, Job Snijders who provided running code, and
Kevin Pack. Also, to geolocation providers that are consuming Kevin Pack. Also, to geolocation providers that are consuming
geofeeds with this described solution, Jonathan Kosgei (ipdata.co), geofeeds with this described solution, Jonathan Kosgei (ipdata.co),
Ben Dowling (ipinfo.io), and Pol Nisenblat (bigdatacloud.com). For Ben Dowling (ipinfo.io), and Pol Nisenblat (bigdatacloud.com). For
helpful reviews we thank Adrian Farrel, Antonio Prado, Rob Wilton, an amazing number of helpful reviews we thank Adrian Farrel, Antonio
George Michaelson, the document shepherd, Kyle Rose for a probing Prado, Francesca Palombini, Jean-Michel Combes (INTDIR), John
SECDIR review, Paul Kyzivat for a helpful GENART directorate review, Scudder, Kyle Rose (SECDIR), Martin Duke, Paul Kyzivat (GENART), Rob
and Jean-Michel Combes for an INTDIR review. Wilton, and Roman Danyliw. The authors also thank George Michaelson,
the awesome document shepherd.
10. References 10. References
10.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>.
skipping to change at page 9, line 43 skipping to change at page 11, line 5
<https://www.rfc-editor.org/info/rfc2622>. <https://www.rfc-editor.org/info/rfc2622>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[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>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>.
[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 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc5485>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[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 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012, DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>. <https://www.rfc-editor.org/info/rfc6481>.
skipping to change at page 11, line 13 skipping to change at page 12, line 36
objects/4-2-4-description-of-the-inetnum-object>. objects/4-2-4-description-of-the-inetnum-object>.
[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>.
[RFC5485] Housley, R., "Digital Signatures on Internet-Draft
Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009,
<https://www.rfc-editor.org/info/rfc5485>.
[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
Protocol (RDAP) Query Format", RFC 7482, Protocol (RDAP) Query Format", RFC 7482,
DOI 10.17487/RFC7482, March 2015, DOI 10.17487/RFC7482, March 2015,
<https://www.rfc-editor.org/info/rfc7482>. <https://www.rfc-editor.org/info/rfc7482>.
 End of changes. 24 change blocks. 
48 lines changed or deleted 122 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/