< draft-ietf-opsawg-finding-geofeeds-08.txt   draft-ietf-opsawg-finding-geofeeds-09.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 12, 2021 NTT Expires: November 16, 2021 NTT
W. Kumari W. Kumari
Google Google
R. Housley R. Housley
Vigil Security Vigil Security
May 11, 2021 May 15, 2021
Finding and Using Geofeed Data Finding and Using Geofeed Data
draft-ietf-opsawg-finding-geofeeds-08 draft-ietf-opsawg-finding-geofeeds-09
Abstract Abstract
This document describes how to find and authenticate geofeed data. This document specifies how to augment the Routing Policy
Specification Language inetnum: class to refer specifically to
geofeed data CSV files, and describes an optional scheme to use the
Routing Public Key Intrastructure to authenticate the geofeed data
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 12, 2021. This Internet-Draft will expire on November 16, 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 14 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 . . . . . . . . . . . . . . . . . 6 5. Operational Considerations . . . . . . . . . . . . . . . . . 7
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Providers of Internet content and other services may wish to Providers of Internet content and other services may wish to
customize those services based on the geographic location of the user customize those services based on the geographic location of the user
of the service. This is often done using the source IP address used of the service. This is often done using the source IP address used
to contact the service. Also, infrastructure and other services to contact the service. Also, infrastructure and other services
might wish to publish the locale of their services. [RFC8805] might wish to publish the locale of their services. [RFC8805]
defines geofeed, a syntax to associate geographic locales with IP defines geofeed, a syntax to associate geographic locales with IP
addresses. But it does not specify how to find the relevant geofeed addresses. But it does not specify how to find the relevant geofeed
data given an IP address. data given an IP address.
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language (RPSL) [RFC4012] inetnum: class to refer Specification Language (RPSL) [RFC2622] inetnum: class to refer
specifically to geofeed data CSV files, and how to prudently use specifically to geofeed data CSV files, and how to prudently use
them. In all places inetnum: is used, inet6num: should also be them. In all places inetnum: is used, inet6num: should also be
assumed [RFC4012]. assumed [RFC4012].
The reader may find [INETNUM] and [INET6NUM] informative, and The reader may find [INETNUM] and [INET6NUM] informative, and
certainly more verbose, descriptions of the inetnum: database certainly more verbose, descriptions of the inetnum: database
classes. classes.
An optional, utterly awesome but slightly complex, means for An optional, utterly awesome but slightly complex means for
authenticating geofeed data is also defined. authenticating geofeed data is also defined.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Geofeed Files 2. Geofeed Files
Geofeed files are described in [RFC8805]. They provide a facility Geofeed files are described in [RFC8805]. They provide a facility
for an IP address resource 'owner' to associate those IP addresses to for an IP address resource 'owner' to associate those IP addresses to
geographic locale(s). geographic locales.
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.
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), and [RFC2622] and
the Regional Internet Registries (RIRs) specifies the inetnum: [RFC4012] used by the Regional Internet Registries (RIRs) specifies
database class. Each of these objects describes an IP address range the inetnum: database class. Each of these objects describes an IP
and its attributes. The inetnum: objects form a hierarchy ordered on address range and its attributes. The inetnum: objects form a
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
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 ", where the remarks: attribute MUST be as in this example, "remarks: Geofeed ",
token "Geofeed" is case sensitive, followed by a URL which will vary, where the token "Geofeed" MUST be case-sensitive, followed by a URL
but MUST refer only to a single [RFC8805] geofeed file. which will vary, but MUST refer only to a single [RFC8805] geofeed
file.
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed.csv remarks: Geofeed https://example.com/geofeed.csv
While we leave global agreement of RPSL modification to the relevant While we leave global agreement of RPSL modification to the relevant
parties, we 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 MUST be "geofeed: ", and MUST be followed by a single URL which
MUST refer only to a [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:
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 and transport integrity of the data. In
contrast, the Resource Public Key Infrastructure (RPKI, see contrast, the Resource Public Key Infrastructure (RPKI, see
[RFC6481]) can be used to authenticate IP space ownership; 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
skipping to change at page 4, line 46 skipping to change at page 4, line 52
the lowest applicable inetnum: object covering the relevant prefixes the lowest applicable inetnum: object covering the relevant prefixes
in the referenced geofeed file. When fetching, the most specific in the referenced geofeed file. When fetching, the most specific
inetnum: object with a geofeed reference MUST be used. inetnum: object with a geofeed reference MUST be used.
When geofeed references are provided by multiple inetnum: objects When geofeed references are provided by multiple inetnum: objects
which have identical address ranges, then the geofeed reference on which have identical address ranges, then the geofeed reference on
the inetnum: with the most recent last-modified: attribute SHOULD be the inetnum: with the most recent last-modified: attribute SHOULD be
preferred. preferred.
It is significant that geofeed data may have finer granularity than It is significant that geofeed data may have finer granularity than
the inetnum: which refers to them. I.e. an INETNUM object for a the inetnum: which refers to them. For example an INETNUM object for
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 the other registries; therefore, when fetching from ARIN via FTP as that of the other registries (see [RFC7485] for a survery of the
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 of whether a particular [RFC8805] geofeed data The question arises whether a particular [RFC8805] geofeed data set
set is valid, i.e. 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 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 RPKI certificate for the covering address private key of the relevant RPKI certificate for the covering address
range. One needs a format that bundles the relevant RPKI certificate range. One needs a format that bundles the relevant RPKI certificate
with the signature and the digest of the geofeed text. with the signature and the digest of the geofeed text.
skipping to change at page 5, line 37 skipping to change at page 5, line 44
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
appear at the end of the file. That is, the file must not end with appear at the end of the file. That is, the file must not end with
multiple consecutive <CRLF> sequences. Any end-of-file marker used multiple consecutive <CRLF> sequences. Any end-of-file marker used
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. Borrowing detached processed by the digital signature algorithm.
signatures from [RFC5485], after file canonicalization, the
Cryptographic Message Syntax (CMS) [RFC5652] would be used to create Should the authenticator be syntactically incorrect per the above,
a detached DER encoded signature which is then BASE64 encoded and the authenticator is invalid.
line wrapped to 72 or fewer characters.
Borrowing detached signatures from [RFC5485], after file
canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
would be used to create a detached DER encoded signature which is
then BASE64 encoded and line wrapped to 72 or fewer characters.
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.
skipping to change at page 7, line 8 skipping to change at page 7, line 21
5. Operational Considerations 5. Operational Considerations
To create the needed inetnum: objects, an operator wishing to To create the needed inetnum: objects, an operator wishing to
register the location of their geofeed file needs to coordinate with register the location of their geofeed file needs to coordinate with
their RIR/NIR and/or any provider LIR which has assigned prefixes to their RIR/NIR and/or any provider LIR which has assigned prefixes to
them. RIRs/NIRs provide means for assignees to create and maintain them. RIRs/NIRs provide means for assignees to create and maintain
inetnum: objects. They also provide means of [sub-]assigning IP inetnum: objects. They also provide means of [sub-]assigning IP
address resources and allowing the assignee to create whois data, address resources and allowing the assignee to create whois data,
including inetnum: objects, and thereby referring to geofeed files. including inetnum: objects, and thereby referring to geofeed files.
The geofeed files SHOULD be published over and fetched using https The geofeed files MUST be published via and fetched using https
[RFC8446]. [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 the
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.
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 with tweezers.
Currently, geolocation providers have bulk whois data access at all Currently, geolocation providers have bulk whois data access at all
the RIRs. An anonymized version of such data is openly available for the RIRs. An anonymized version of such data is openly available for
all RIRs except ARIN, which requires an authorization. However, for all RIRs except ARIN, which requires an authorization. However, for
users without such authorization the same result can be achieved with users without such authorization, the same result can be achieved
extra RDAP effort. There is open source code to pass over such data with extra RDAP effort. There is open source code to pass over such
across all RIRs, collect all geofeed references, and process them data across all RIRs, collect all geofeed references, and process
[geofeed-finder]. 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 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.
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 of 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.
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
skipping to change at page 8, line 43 skipping to change at page 9, line 5
----------------------------------------------------------------- -----------------------------------------------------------------
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]
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, helpful reviews we thank Adrian Farrel, Antonio Prado, Rob Wilton,
George Michaelson, the document shepherd, Kyle Rose for a probing George Michaelson, the document shepherd, Kyle Rose for a probing
SECDIR review, and Paul Kyzivat for a helpful GENART directorate SECDIR review, Paul Kyzivat for a helpful GENART directorate review,
review and Jean-Michel Combes for an INTDIR review.
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>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999,
<https://www.rfc-editor.org/info/rfc2622>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<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>.
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
"Routing Policy Specification Language next generation "Routing Policy Specification Language next generation
(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005, (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,
<https://www.rfc-editor.org/info/rfc4012>. <https://www.rfc-editor.org/info/rfc4012>.
[RFC5485] Housley, R., "Digital Signatures on Internet-Draft [RFC5485] Housley, R., "Digital Signatures on Internet-Draft
skipping to change at page 9, line 40 skipping to change at page 10, line 14
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<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>.
10.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. G., Huston, G., Harrison, T., Bruijnzeels,
and M. Hoffmann, "A profile for Resource Tagged T., and M. Hoffmann, "A profile for Resource Tagged
Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work
in progress), January 2021. in progress), January 2021.
[I-D.spaghetti-sidrops-rpki-rsc] [I-D.spaghetti-sidrops-rpki-rsc]
Snijders, J., "RPKI Signed Checklists", draft-spaghetti- Snijders, J., "RPKI Signed Checklists", draft-spaghetti-
sidrops-rpki-rsc-03 (work in progress), February 2021. sidrops-rpki-rsc-03 (work in progress), February 2021.
[INET6NUM] [INET6NUM]
RIPE, "Description of the INET6NUM Object", RIPE, "Description of the INET6NUM Object",
<https://www.ripe.net/manage-ips-and- <https://www.ripe.net/manage-ips-and-
skipping to change at page 11, line 5 skipping to change at page 11, line 19
[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>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015,
<https://www.rfc-editor.org/info/rfc7485>.
[RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy [RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy
Specification Language (RPSL) Objects with Resource Public Specification Language (RPSL) Objects with Resource Public
Key Infrastructure (RPKI) Signatures", RFC 7909, Key Infrastructure (RPKI) Signatures", RFC 7909,
DOI 10.17487/RFC7909, June 2016, DOI 10.17487/RFC7909, June 2016,
<https://www.rfc-editor.org/info/rfc7909>. <https://www.rfc-editor.org/info/rfc7909>.
Appendix A. Example Appendix A. Example
This appendix provides an example, including a trust anchor, a CA This appendix provides an example, including a trust anchor, a CA
certificate subordinate to the trust anchor, an end-entity certificate subordinate to the trust anchor, an end-entity
 End of changes. 32 change blocks. 
53 lines changed or deleted 77 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/