randy/draft-9092update
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

-02 published

Browse source
This commit is contained in:
Randy Bush 2023-07-24 17:02:34 -07:00
parent bc9f0d26bf
commit bb8c89d05c
1 changed files with 200 additions and 112 deletions
Download patch file Download diff file Expand all files Collapse all files

298
draft-ymbk-9092update.xml
View file

@ -8,13 +8,13 @@
<?rfc compact="yes"?> <?rfc compact="yes"?>
<?rfc subcompact="no"?> <?rfc subcompact="no"?>
<rfc category="std" docName="draft-ymbk-opsawg-9092-update-01" <rfc category="std" docName="draft-ymbk-opsawg-9092-update-02"
submissionType="IETF" consensus="true" ipr="trust200902" submissionType="IETF" consensus="true" ipr="trust200902"
obsoletes="9092" > obsoletes="9092" version="2" >
<front> <front>
<title abbrev="Finding Geofeeds, an Update">A Minor Update to Finding and Using Geofeed Data</title> <title abbrev="Finding and Using Geofeed Data">Finding and Using Geofeed Data</title>
<author fullname="Randy Bush" initials="R." surname="Bush"> <author fullname="Randy Bush" initials="R." surname="Bush">
<organization>IIJ &amp; Arrcus</organization> <organization>IIJ &amp; Arrcus</organization>
@ -34,9 +34,9 @@
<organization>NTT</organization> <organization>NTT</organization>
<address> <address>
<postal> <postal>
<street>Siriusdreef 70-72</street> <street>Veemweg 23</street>
<city>Hoofddorp</city> <city>Barneveld</city>
<code>2132 WT</code> <code>3771 MT</code>
<country>Netherlands</country> <country>Netherlands</country>
</postal> </postal>
<email>massimo@ntt.net</email> <email>massimo@ntt.net</email>
@ -96,12 +96,13 @@
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 customize those services based on the geographic location of the
user of the service. This is often done using the source IP user of the service. This is often done using the source IP
address used to contact the service. Also, infrastructure and address used to contact the service, which may not point to a
other services might wish to publish the locale of their user, see <xref target ="RFC6269"/>, Section 14 in particular.
services. <xref target="RFC8805" format="default"/> defines Also, infrastructure and other services might wish to publish
geofeed, a syntax to associate geographic locales with IP the locale of their services. <xref target="RFC8805"
addresses, but it does not specify how to find the relevant format="default"/> defines geofeed, a syntax to associate
geofeed data given an IP address. geographic locales with IP addresses, but it does not specify
how to find the relevant geofeed data given an IP address.
</t> </t>
<t> <t>
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
@ -119,16 +120,13 @@
</t> </t>
<t> <t>
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 in <xref
target="auth"/>.
</t> </t>
<t> <t>
This document obsoletes <xref target="RFC9092"/>. Changes from This document obsoletes <xref target="RFC9092"/>. Changes from
<xref target="RFC9092"/> include the following: <xref target="RFC9092"/> include the following:
<ul spacing="compact"> <ul spacing="compact">
<li>
It is no longer assumed that a geofeed file is a CSV, comma
separated value list.
</li>
<li> <li>
RIPE has implemented the geofeed: attribute. RIPE has implemented the geofeed: attribute.
</li> </li>
@ -136,6 +134,9 @@
Allow, but discourage, an inetnum: to have both a geofeed Allow, but discourage, an inetnum: to have both a geofeed
remarks: attribute and a geofeed: attribute. remarks: attribute and a geofeed: attribute.
</li> </li>
<li>
Geofeed file only UTF-8 CSV.
</li>
<li> <li>
Stress that authenticating geofeed data is optional. Stress that authenticating geofeed data is optional.
</li> </li>
@ -174,6 +175,12 @@
locales. locales.
</t> </t>
<t>
Per <xref target="RFC8805"/>, geofeed files consist of CSVs
(Comma Separated Values) in UTF-8 text format; not HTML,
richtext, or other formats.
</t>
<t> <t>
Content providers and other parties who wish to locate an IP Content providers and other parties who wish to locate an IP
address to a geographic locale need to find the relevant geofeed address to a geographic locale need to find the relevant geofeed
@ -225,15 +232,15 @@
<t> <t>
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. Currently, this has been attribute in the inetnum: class. Absent implementation of the
implemented in only the RIPE Database. Until such time, this geofeed: attribute in a particular RIR database, this document
document defines the syntax of a Geofeed remarks: attribute, defines the syntax of a Geofeed remarks: attribute, which
which contains an HTTPS URL of a geofeed file. The format of contains an HTTPS URL of a geofeed file. The format of the
the inetnum: geofeed remarks: attribute <bcp14>MUST</bcp14> be inetnum: geofeed remarks: attribute MUST be as in this example,
as in this example, "remarks: Geofeed ", where the token "remarks: Geofeed ", where the token "Geofeed " MUST be case
"Geofeed " <bcp14>MUST</bcp14> be case sensitive, followed by a sensitive, followed by a URL that will vary, but it MUST refer
URL that will vary, but it <bcp14>MUST</bcp14> refer only to a only to a single geofeed <xref target="RFC8805"
single geofeed <xref target="RFC8805" format="default"/> file. format="default"/> file.
</t> </t>
<sourcecode type="rpsl"> <![CDATA[ <sourcecode type="rpsl"> <![CDATA[
@ -243,19 +250,15 @@
<t> <t>
While we leave global agreement of RPSL modification to the While we leave global agreement of RPSL modification to the
relevant parties, we specify that a proper geofeed: attribute in relevant parties, we specify that a proper geofeed: attribute in
the inetnum: class <bcp14>MUST</bcp14> be "geofeed:" and the inetnum: class MUST be "geofeed:" and
<bcp14>MUST</bcp14> be followed by a single URL that will vary, MUST be followed by a single URL that will vary,
but it <bcp14>MUST</bcp14> refer only to a single geofeed <xref but it MUST refer only to a single geofeed <xref
target="RFC8805" format="default"/> file. target="RFC8805" format="default"/> file.
</t> </t>
<sourcecode type="rpsl"><![CDATA[ <sourcecode type="rpsl"><![CDATA[
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed geofeed: https://example.com/geofeed
]]></sourcecode> ]]></sourcecode>
<t>
Registries <bcp14>MAY</bcp14>, for the interim, provide a mix of
the remarks: attribute form and the geofeed: attribute form.
</t>
<t> <t>
The URL uses HTTPS, so the WebPKI provides authentication, The URL uses HTTPS, so the WebPKI provides authentication,
integrity, and confidentiality for the fetched geofeed file. integrity, and confidentiality for the fetched geofeed file.
@ -270,17 +273,18 @@
Until all producers of inetnum: objects, i.e., the RIRs, state Until all producers of inetnum: objects, i.e., the RIRs, state
that they have migrated to supporting a geofeed: attribute, that they have migrated to supporting a geofeed: attribute,
consumers looking at inetnum: objects to find geofeed URLs consumers looking at inetnum: objects to find geofeed URLs
<bcp14>MUST</bcp14> be able to consume both the remarks: and MUST be able to consume both the remarks: and
geofeed: forms. geofeed: forms.
</t>
<t>
The migration not only implies that the RIRs support the The migration not only implies that the RIRs support the
geofeed: attribute, but that all registrants have migrated any geofeed: attribute, but that all registrants have migrated any
inetnum: objects from remarks: to geofeed: attributes. inetnum: objects from remarks: to geofeed: attributes.
</t> </t>
<t> <t>
Any particular inetnum: object <bcp14>SHOULD</bcp14> have, at Any particular inetnum: object SHOULD have, at
most, one geofeed reference, whether a remarks: or a proper most, one geofeed reference, whether a remarks: or a proper
geofeed: attribute when it is implemented. If there is more geofeed: attribute when it is implemented. If there is more
than one, the geofeed: attribute SHOULD be used. than one, the geofeed: attribute SHOULD be used.
@ -306,14 +310,14 @@
When geofeed references are provided by multiple inetnum: When geofeed references are provided by multiple inetnum:
objects that have identical address ranges, then the geofeed objects that have identical address ranges, then the geofeed
reference on the inetnum: with the most recent last-modified: reference on the inetnum: with the most recent last-modified:
attribute <bcp14>SHOULD</bcp14> be preferred. attribute SHOULD be preferred.
</t> </t>
<t> <t>
As inetnum: objects form a hierarchy, geofeed references As inetnum: objects form a hierarchy, geofeed references
<bcp14>SHOULD</bcp14> be at the lowest applicable inetnum: SHOULD be at the lowest applicable inetnum:
object covering the relevant address ranges in the referenced object covering the relevant address ranges in the referenced
geofeed file. When fetching, the most specific inetnum: object geofeed file. When fetching, the most specific inetnum: object
with a geofeed reference <bcp14>MUST</bcp14> be used. with a geofeed reference MUST be used.
</t> </t>
<t> <t>
It is significant that geofeed data may have finer granularity It is significant that geofeed data may have finer granularity
@ -321,20 +325,91 @@
object for an address range P could refer to a geofeed file in object for an address range P could refer to a geofeed file in
which P has been subdivided into one or more longer prefixes. which P has been subdivided into one or more longer prefixes.
</t> </t>
<t>
Currently, the registry data published by ARIN are not the same
RPSL as that of the other registries (see <xref target="RFC7485"
format="default"/> for a survey of the WHOIS Tower of Babel);
therefore, when fetching from ARIN via FTP <xref
target="RFC0959" format="default"/>, WHOIS <xref
target="RFC3912" format="default"/>, the Registration Data
Access Protocol (RDAP) <xref target="RFC9082"
format="default"/>, etc., the "NetRange" attribute/key
<bcp14>MUST</bcp14> be treated as "inetnum", and the "Comment"
attribute <bcp14>MUST</bcp14> be treated as "remarks".
</t>
</section> </section>
<section anchor="fetch" numbered="true" toc="default">
<name>Fetching Geofeed Data</name>
<t>
This document is to provides a guideline for how interested
parties should fetch and read geofeed files.
</t>
<t>
Historically, before geofeed files, this was done in varied
ways, at the discretion of the implementer, often without
consistent authentication, where data were mostly imported from
email without formal authorisation or validation.
</t>
<t>
To minimize the load on RIRs' WHOIS <xref target="RFC3912"/>
services, the RIR's FTP <xref target="RFC0959"/> services SHOULD
be used for large-scale access to gather geofeed URLs. This
uses efficient bulk access instead of fetching via brute-force
search through the IP space.
</t>
<t>
When an inetnum: with a geofeed file reference is identified,
the file MUST be downloaded using HTTPS.
</t>
<t>
When reading data from the geofeed file, one MUST ignore data
outside the referring inetnum: object's address range. This is
to avoid importing data about ranges not under the control of
the operator. If geofeed files are fetched, other location
information from the inetnum: MUST be ignored.
</t>
<t>
Given an address range of interest, the most specific inetnum:
object with a geofeed reference MUST be used to fetch the
geofeed file. For example, if the fetching party finds
the following inetnum: objects:
<sourcecode type="rpsl"> <![CDATA[
inetnum: 192.0.2.0/12 # example
remarks: Geofeed https://example.com/geofeed_1
inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed_2
]]></sourcecode>
and the file geofeed_1 contains geolocation data about
192.0.2.0/29, this MUST be discarded because 192.0.2.0/24 is
within the more specific inetnum: covering the address range and
that inetnum: has a geofeed reference.
</t>
<t>
If an inetnum: object has both remarks: with geofeed data and
also has a geofeed: attribute, the geofeed: attribute SHOULD be
used and the remarks: ignored.
</t>
<t>
Hints in inetnum:s such as country:, geoloc:, etc. tend to be
administrative, and not deployment specific. Consider large,
possibly global, providers with headquarters very far from most
of their deployments. Therefore, if geofeed data are specified,
either as a geofeed: attribute or in a geofeed remarks:
attribute, other geographic hints such as country:, geoloc:, DNS
geoloc RRsets, etc., for that address range MUST be ignored.
</t>
<t>
There is open-source code to traverse the RPSL data across all
of the RIRs, collect all geofeed references, and process them
<xref target="GEOFEED-FINDER"/>. It implements the steps above
and of all the Operational Considerations described in <xref
target="ops"/>, including caching. It produces a single geofeed
file, merging all the geofeed files found. This open-source
code can be run daily by a cronjob, and the output file can be
directly used.
</t>
</section>
<section anchor="auth" numbered="true" toc="default"> <section anchor="auth" numbered="true" toc="default">
<name>Authenticating Geofeed Data (Optional)</name> <name>Authenticating Geofeed Data (Optional)</name>
<t> <t>
@ -350,7 +425,7 @@
there is a fair number of them. there is a fair number of them.
</t> </t>
<t> <t>
A single optional authenticator <bcp14>MAY</bcp14> be appended A single optional authenticator MAY be appended
to a geofeed <xref target="RFC8805" format="default"/> file. It to a geofeed <xref target="RFC8805" format="default"/> file. It
is a digest of the main body of the file signed by the private is a digest of the main body of the file signed by the private
key of the relevant RPKI certificate for a covering address key of the relevant RPKI certificate for a covering address
@ -361,16 +436,16 @@
The canonicalization procedure converts the data from their The canonicalization procedure converts the data from their
internal character representation to the UTF-8 <xref internal character representation to the UTF-8 <xref
target="RFC3629" format="default"/> character encoding, and the target="RFC3629" format="default"/> character encoding, and the
&lt;CRLF&gt; sequence <bcp14>MUST</bcp14> be used to denote the &lt;CRLF&gt; sequence MUST be used to denote the
end of a line of text. A blank line is represented solely by end of a line of text. A blank line is represented solely by
the &lt;CRLF&gt; sequence. For robustness, any non-printable the &lt;CRLF&gt; sequence. For robustness, any non-printable
characters <bcp14>MUST NOT</bcp14> be changed by characters MUST NOT be changed by
canonicalization. Trailing blank lines <bcp14>MUST NOT</bcp14> canonicalization. Trailing blank lines MUST NOT
appear at the end of the file. That is, the file must not end appear at the end of the file. That is, the file must not end
with multiple consecutive &lt;CRLF&gt; sequences. Any with multiple consecutive &lt;CRLF&gt; sequences. Any
end-of-file marker used by an operating system is not considered end-of-file marker used by an operating system is not considered
to be part of the file content. When present, such end-of-file to be part of the file content. When present, such end-of-file
markers <bcp14>MUST NOT</bcp14> be processed by the digital markers MUST NOT be processed by the digital
signature algorithm. signature algorithm.
</t> </t>
<t> <t>
@ -386,18 +461,18 @@
DER-encoded signature that is then padded BASE64 encoded (as per DER-encoded signature that is then padded BASE64 encoded (as per
<xref target="RFC4648" sectionFormat="of" section="4" <xref target="RFC4648" sectionFormat="of" section="4"
format="default"/>) and line wrapped to 72 or fewer characters. format="default"/>) and line wrapped to 72 or fewer characters.
The same digest algorithm <bcp14>MUST</bcp14> be used for The same digest algorithm MUST be used for
calculating the message digest on content being signed, which is calculating the message digest on content being signed, which is
the geofeed file, and for calculating the message digest on the the geofeed file, and for calculating the message digest on the
SignerInfo SignedAttributes <xref target="RFC8933" SignerInfo SignedAttributes <xref target="RFC8933"
format="default"/>. The message digest algorithm identifier format="default"/>. The message digest algorithm identifier
<bcp14>MUST</bcp14> appear in both the SignedData MUST appear in both the SignedData
DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifiers and the SignerInfo
DigestAlgorithmIdentifier <xref target="RFC5652" DigestAlgorithmIdentifier <xref target="RFC5652"
format="default"/>. format="default"/>.
</t> </t>
<t> <t>
The address range of the signing certificate <bcp14>MUST</bcp14> The address range of the signing certificate MUST
cover all prefixes in the geofeed file it signs. cover all prefixes in the geofeed file it signs.
</t> </t>
<t> <t>
@ -432,13 +507,13 @@
Obtaining the signer's certificate from the CMS SignedData Obtaining the signer's certificate from the CMS SignedData
CertificateSet <xref target="RFC5652" format="default"/>. The CertificateSet <xref target="RFC5652" format="default"/>. The
certificate SubjectKeyIdentifier extension <xref certificate SubjectKeyIdentifier extension <xref
target="RFC5280" format="default"/> <bcp14>MUST</bcp14> match target="RFC5280" format="default"/> MUST match
the SubjectKeyIdentifier in the CMS SignerInfo the SubjectKeyIdentifier in the CMS SignerInfo
SignerIdentifier <xref target="RFC5652" format="default"/>. SignerIdentifier <xref target="RFC5652" format="default"/>.
If the key identifiers do not match, then validation If the key identifiers do not match, then validation
<bcp14>MUST</bcp14> fail.</t> MUST fail.</t>
<t> <t>
Validation of the signer's certificate <bcp14>MUST</bcp14> Validation of the signer's certificate MUST
ensure that it is part of the current <xref target="RFC6486" ensure that it is part of the current <xref target="RFC6486"
format="default"/> manifest and that the resources are covered format="default"/> manifest and that the resources are covered
by the RPKI certificate. by the RPKI certificate.
@ -449,14 +524,14 @@
Constructing the certification path for the signer's Constructing the certification path for the signer's
certificate. All of the needed certificates are expected to certificate. All of the needed certificates are expected to
be readily available in the RPKI repository. The be readily available in the RPKI repository. The
certification path <bcp14>MUST</bcp14> be valid according to certification path MUST be valid according to
the validation algorithm in <xref target="RFC5280" the validation algorithm in <xref target="RFC5280"
format="default"/> and the additional checks specified in format="default"/> and the additional checks specified in
<xref target="RFC3779" format="default"/> associated with the <xref target="RFC3779" format="default"/> associated with the
IP Address Delegation certificate extension and the Autonomous IP Address Delegation certificate extension and the Autonomous
System Identifier Delegation certificate extension. If System Identifier Delegation certificate extension. If
certification path validation is unsuccessful, then validation certification path validation is unsuccessful, then validation
<bcp14>MUST</bcp14> fail. MUST fail.
</li> </li>
<li> <li>
@ -464,18 +539,18 @@
target="RFC5652" format="default"/> using the public key from target="RFC5652" format="default"/> using the public key from
the validated signer's certificate. If the signature the validated signer's certificate. If the signature
validation is unsuccessful, then validation validation is unsuccessful, then validation
<bcp14>MUST</bcp14> fail. MUST fail.
</li> </li>
<li> <li>
Verifying that the IP Address Delegation certificate extension Verifying that the IP Address Delegation certificate extension
<xref target="RFC3779" format="default"/> covers all of the <xref target="RFC3779" format="default"/> covers all of the
address ranges of the geofeed file. If all of the address address ranges of the geofeed file. If all of the address
ranges are not covered, then validation <bcp14>MUST</bcp14> ranges are not covered, then validation MUST
fail. fail.
</li> </li>
</ol> </ol>
<t> <t>
All of these steps <bcp14>MUST</bcp14> be successful to consider All of these steps MUST be successful to consider
the geofeed file signature as valid. the geofeed file signature as valid.
</t> </t>
<t> <t>
@ -495,9 +570,10 @@
validation for use with CMS object processing is too hard. And, validation for use with CMS object processing is too hard. And,
the certificates do not get that much bigger by repeating the the certificates do not get that much bigger by repeating the
information. information.
</t>
Therefore an extension using "inherit" <bcp14>MUST NOT</bcp14> <t>
be used. This is consistent with other RPKI signed objects. Therefore an extension using "inherit" MUST NOT be used. This
is consistent with other RPKI signed objects.
</t> </t>
<t> <t>
Identifying the private key associated with the certificate and Identifying the private key associated with the certificate and
@ -508,7 +584,7 @@
public RPKI, has the needed public key. public RPKI, has the needed public key.
</t> </t>
<t> <t>
The appendix <bcp14>MUST</bcp14> be hidden as a series of "#" comments at the The appendix MUST be hidden as a series of "#" comments at the
end of the geofeed file. The following is a cryptographically end of the geofeed file. The following is a cryptographically
incorrect, albeit simple, example. A correct and full example is incorrect, albeit simple, example. A correct and full example is
in <xref target="example" format="default"/>. in <xref target="example" format="default"/>.
@ -527,8 +603,8 @@
</t> </t>
<t> <t>
The bracketing "# RPKI Signature:" and "# End Signature:" The bracketing "# RPKI Signature:" and "# End Signature:"
<bcp14>MUST</bcp14> be present following the model as shown. MUST be present following the model as shown.
Their IP address range <bcp14>MUST</bcp14> match that of the Their IP address range MUST match that of the
inetnum: URL followed to the file. inetnum: URL followed to the file.
</t> </t>
<t> <t>
@ -561,24 +637,24 @@
referring to geofeed files. referring to geofeed files.
</t> </t>
<t> <t>
The geofeed files <bcp14>MUST</bcp14> be published via and fetched using The geofeed files MUST be published via and fetched using
HTTPS <xref target="RFC2818" format="default"/>. HTTPS <xref target="RFC2818" format="default"/>.
</t> </t>
<t> <t>
When using data from a geofeed file, one <bcp14>MUST</bcp14> ignore data When using data from a geofeed file, one MUST ignore data
outside the referring inetnum: object's inetnum: attribute outside the referring inetnum: object's inetnum: attribute
address range. address range.
</t> </t>
<t> <t>
If and only if the geofeed file is not signed per <xref target="auth" If and only if the geofeed file is not signed per <xref target="auth"
format="default"/>, then multiple inetnum: objects <bcp14>MAY</bcp14> format="default"/>, then multiple inetnum: objects MAY
refer to the same geofeed file, and the consumer <bcp14>MUST</bcp14> refer to the same geofeed file, and the consumer MUST
use only lines in the geofeed file where the prefix is covered by the use only lines in the geofeed file where the prefix is covered by the
address range of the inetnum: object's URL it has followed. address range of the inetnum: object's URL it has followed.
</t> </t>
<t> <t>
If the geofeed file is signed, and the signer's certificate If the geofeed file is signed, and the signer's certificate
changes, the signature in the geofeed file <bcp14>MUST</bcp14> changes, the signature in the geofeed file MUST
be updated. be updated.
</t> </t>
@ -589,14 +665,7 @@
certificate exclusively for the purpose shown in <xref certificate exclusively for the purpose shown in <xref
target="example" format="default"/>. target="example" format="default"/>.
</t> </t>
<t>
To minimize the load on RIR WHOIS <xref target="RFC3912"
format="default"/> services, use of the RIR's FTP <xref
target="RFC0959" format="default"/> services
<bcp14>SHOULD</bcp14> be used for large-scale access to gather
geofeed URLs. This also provides bulk access instead of
fetching by brute-force search through the IP space.
</t>
<t> <t>
Harvesting and publishing aggregated geofeed data outside of Harvesting and publishing aggregated geofeed data outside of
the RPSL model should be avoided as it can have the effect the RPSL model should be avoided as it can have the effect
@ -616,26 +685,16 @@
target="GEOFEED-FINDER" format="default"/>. target="GEOFEED-FINDER" format="default"/>.
</t> </t>
<t>
Hints in inetnum:s such as country:, geoloc:, etc. tend to be
administrative, and not deployment specific. Consider large,
possibly global, providers with headquarters very far from most
of their deployments. Therefore, if geofeed data are specified,
either as a geofeed: attribute or in a geofeed remarks:
attribute, other geographic hints such as country:, geoloc:, DNS
geoloc RRsets, etc., for that address range MUST be ignored.
</t>
<t> <t>
To prevent undue load on RPSL and geofeed servers, To prevent undue load on RPSL and geofeed servers,
entity-fetching geofeed data using these mechanisms <bcp14>MUST entity-fetching geofeed data using these mechanisms MUST
NOT</bcp14> do frequent real-time lookups. <xref NOT do frequent real-time lookups. <xref
target="RFC8805" sectionFormat="of" section="3.4" target="RFC8805" sectionFormat="of" section="3.4"
format="default"/> suggests use of the HTTP Expires header <xref format="default"/> suggests use of the HTTP Expires header <xref
target="RFC7234" format="default"/> to signal when geofeed data target="RFC7234" format="default"/> to signal when geofeed data
should be refetched. As the data change very infrequently, in should be refetched. As the data change very infrequently, in
the absence of such an HTTP Header signal, collectors the absence of such an HTTP Header signal, collectors
<bcp14>SHOULD NOT</bcp14> fetch more frequently than weekly. It SHOULD NOT fetch more frequently than weekly. It
would be polite not to fetch at magic times such as midnight would be polite not to fetch at magic times such as midnight
UTC, the first of the month, etc., because too many others are UTC, the first of the month, etc., because too many others are
likely to do the same. likely to do the same.
@ -665,6 +724,34 @@
</t> </t>
</section> </section>
<section anchor="impl" numbered="true" toc="default">
<name>Implementation Status</name>
<t>
Currently, the geofeed: attribute in inetnum objects has
been implemented in the RIPE database.
</t>
<t>
Registrants in databases which do not yet support the geofeed:
attribute are using the remarks:, or equivalent, attribute.
</t>
<t>
Currently, the registry data published by ARIN are not the same
RPSL as that of the other registries (see <xref target="RFC7485"
format="default"/> for a survey of the WHOIS Tower of Babel);
therefore, when fetching from ARIN via FTP <xref
target="RFC0959" format="default"/>, WHOIS <xref
target="RFC3912" format="default"/>, the Registration Data
Access Protocol (RDAP) <xref target="RFC9082"
format="default"/>, etc., the "NetRange" attribute/key must be
treated as "inetnum", and the "Comment" attribute must be
treated as "remarks".
</t>
</section>
<section anchor="seccons" numbered="true" toc="default"> <section anchor="seccons" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
@ -692,7 +779,7 @@
attacker could publish an unsigned equal or narrower (e.g., a attacker could publish an unsigned equal or narrower (e.g., a
/24) inetnum: in a WHOIS registry that has weak authorization, /24) inetnum: in a WHOIS registry that has weak authorization,
abusing the rule that the most-specific inetnum: object with a abusing the rule that the most-specific inetnum: object with a
geofeed reference <bcp14>MUST</bcp14> be used. geofeed reference MUST be used.
</t> </t>
<t> <t>
If signatures were mandatory, the above attack would be stymied, but If signatures were mandatory, the above attack would be stymied, but
@ -732,7 +819,6 @@
<?rfc include="reference.RFC.6486.xml"?> <?rfc include="reference.RFC.6486.xml"?>
<?rfc include="reference.RFC.8805.xml"?> <?rfc include="reference.RFC.8805.xml"?>
<?rfc include="reference.RFC.8933.xml"?> <?rfc include="reference.RFC.8933.xml"?>
<?rfc include="reference.RFC.9092.xml"?>
</references> </references>
<references title="Informative References"> <references title="Informative References">
@ -740,10 +826,12 @@
<?rfc include="reference.RFC.3912.xml"?> <?rfc include="reference.RFC.3912.xml"?>
<?rfc include="reference.RFC.4632.xml"?> <?rfc include="reference.RFC.4632.xml"?>
<?rfc include="reference.RFC.5485.xml"?> <?rfc include="reference.RFC.5485.xml"?>
<?rfc include="reference.RFC.6269.xml"?>
<?rfc include="reference.RFC.7234.xml"?> <?rfc include="reference.RFC.7234.xml"?>
<?rfc include="reference.RFC.7485.xml"?> <?rfc include="reference.RFC.7485.xml"?>
<?rfc include="reference.RFC.7909.xml"?> <?rfc include="reference.RFC.7909.xml"?>
<?rfc include="reference.RFC.9082.xml"?> <?rfc include="reference.RFC.9082.xml"?>
<?rfc include="reference.RFC.9092.xml"?>
<?rfc include="reference.RFC.9323.xml"?> <?rfc include="reference.RFC.9323.xml"?>
<?rfc include="reference.I-D.ietf-sidrops-rpki-rta.xml"?> <?rfc include="reference.I-D.ietf-sidrops-rpki-rta.xml"?>
@ -1220,10 +1308,10 @@ following detached CMS signature.</t>
Palombini"/>, <contact fullname="Jean-Michel Combes"/> (INTDIR), Palombini"/>, <contact fullname="Jean-Michel Combes"/> (INTDIR),
<contact fullname="John Scudder"/>, <contact fullname="Kyle <contact fullname="John Scudder"/>, <contact fullname="Kyle
Rose"/> (SECDIR), <contact fullname="Martin Duke"/>, <contact Rose"/> (SECDIR), <contact fullname="Martin Duke"/>, <contact
fullname="Murray Kucherawy"/>, <contact fullname="Paul fullname="Murray Kucherawy"/>, <contact fullname="Mohamed
Kyzivat"/> (GENART), <contact fullname="Rob Wilton"/>, <contact Boucadair"/>, <contact fullname="Paul Kyzivat"/> (GENART),
fullname="Roman Danyliw"/>, and <contact fullname="Ties de <contact fullname="Rob Wilton"/>, <contact fullname="Roman
Kock"/>. Danyliw"/>, and <contact fullname="Ties de Kock"/>.
</t> </t>
</section> </section>