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 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"
obsoletes="9092" >
obsoletes="9092" version="2" >
<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">
<organization>IIJ &amp; Arrcus</organization>
@ -34,9 +34,9 @@
<organization>NTT</organization>
<address>
<postal>
<street>Siriusdreef 70-72</street>
<city>Hoofddorp</city>
<code>2132 WT</code>
<street>Veemweg 23</street>
<city>Barneveld</city>
<code>3771 MT</code>
<country>Netherlands</country>
</postal>
<email>massimo@ntt.net</email>
@ -96,12 +96,13 @@
Providers of Internet content and other services may wish to
customize those services based on the geographic location of the
user of the service. This is often done using the source IP
address used to contact the service. Also, infrastructure and
other services might wish to publish the locale of their
services. <xref target="RFC8805" format="default"/> defines
geofeed, a syntax to associate geographic locales with IP
addresses, but it does not specify how to find the relevant
geofeed data given an IP address.
address used to contact the service, which may not point to a
user, see <xref target ="RFC6269"/>, Section 14 in particular.
Also, infrastructure and other services might wish to publish
the locale of their services. <xref target="RFC8805"
format="default"/> defines geofeed, a syntax to associate
geographic locales with IP addresses, but it does not specify
how to find the relevant geofeed data given an IP address.
</t>
<t>
This document specifies how to augment the Routing Policy
@ -119,16 +120,13 @@
</t>
<t>
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>
This document obsoletes <xref target="RFC9092"/>. Changes from
<xref target="RFC9092"/> include the following:
<ul spacing="compact">
<li>
It is no longer assumed that a geofeed file is a CSV, comma
separated value list.
</li>
<li>
RIPE has implemented the geofeed: attribute.
</li>
@ -136,6 +134,9 @@
Allow, but discourage, an inetnum: to have both a geofeed
remarks: attribute and a geofeed: attribute.
</li>
<li>
Geofeed file only UTF-8 CSV.
</li>
<li>
Stress that authenticating geofeed data is optional.
</li>
@ -174,6 +175,12 @@
locales.
</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>
Content providers and other parties who wish to locate an IP
address to a geographic locale need to find the relevant geofeed
@ -225,15 +232,15 @@
<t>
Ideally, RPSL would be augmented to define a new RPSL geofeed:
attribute in the inetnum: class. Currently, this has been
implemented in only the RIPE Database. Until such time, this
document defines the syntax of a Geofeed remarks: attribute,
which contains an HTTPS URL of a geofeed file. The format of
the inetnum: geofeed remarks: attribute <bcp14>MUST</bcp14> be
as in this example, "remarks: Geofeed ", where the token
"Geofeed " <bcp14>MUST</bcp14> be case sensitive, followed by a
URL that will vary, but it <bcp14>MUST</bcp14> refer only to a
single geofeed <xref target="RFC8805" format="default"/> file.
attribute in the inetnum: class. Absent implementation of the
geofeed: attribute in a particular RIR database, this document
defines the syntax of a Geofeed remarks: attribute, which
contains an HTTPS URL of a geofeed file. The format of the
inetnum: geofeed remarks: attribute MUST be as in this example,
"remarks: Geofeed ", where the token "Geofeed " MUST be case
sensitive, followed by a URL that will vary, but it MUST refer
only to a single geofeed <xref target="RFC8805"
format="default"/> file.
</t>
<sourcecode type="rpsl"> <![CDATA[
@ -243,19 +250,15 @@
<t>
While we leave global agreement of RPSL modification to the
relevant parties, we specify that a proper geofeed: attribute in
the inetnum: class <bcp14>MUST</bcp14> be "geofeed:" and
<bcp14>MUST</bcp14> be followed by a single URL that will vary,
but it <bcp14>MUST</bcp14> refer only to a single geofeed <xref
the inetnum: class MUST be "geofeed:" and
MUST be followed by a single URL that will vary,
but it MUST refer only to a single geofeed <xref
target="RFC8805" format="default"/> file.
</t>
<sourcecode type="rpsl"><![CDATA[
inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed
]]></sourcecode>
<t>
Registries <bcp14>MAY</bcp14>, for the interim, provide a mix of
the remarks: attribute form and the geofeed: attribute form.
</t>
<t>
The URL uses HTTPS, so the WebPKI provides authentication,
integrity, and confidentiality for the fetched geofeed file.
@ -270,17 +273,18 @@
Until all producers of inetnum: objects, i.e., the RIRs, state
that they have migrated to supporting a geofeed: attribute,
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.
</t>
<t>
The migration not only implies that the RIRs support the
geofeed: attribute, but that all registrants have migrated any
inetnum: objects from remarks: to geofeed: attributes.
</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
geofeed: attribute when it is implemented. If there is more
than one, the geofeed: attribute SHOULD be used.
@ -306,14 +310,14 @@
When geofeed references are provided by multiple inetnum:
objects that have identical address ranges, then the geofeed
reference on the inetnum: with the most recent last-modified:
attribute <bcp14>SHOULD</bcp14> be preferred.
attribute SHOULD be preferred.
</t>
<t>
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
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>
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
which P has been subdivided into one or more longer prefixes.
</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 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">
<name>Authenticating Geofeed Data (Optional)</name>
<t>
@ -350,7 +425,7 @@
there is a fair number of them.
</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
is a digest of the main body of the file signed by the private
key of the relevant RPKI certificate for a covering address
@ -361,16 +436,16 @@
The canonicalization procedure converts the data from their
internal character representation to the UTF-8 <xref
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
the &lt;CRLF&gt; sequence. For robustness, any non-printable
characters <bcp14>MUST NOT</bcp14> be changed by
canonicalization. Trailing blank lines <bcp14>MUST NOT</bcp14>
characters MUST 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 multiple consecutive &lt;CRLF&gt; sequences. Any
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
markers <bcp14>MUST NOT</bcp14> be processed by the digital
markers MUST NOT be processed by the digital
signature algorithm.
</t>
<t>
@ -386,18 +461,18 @@
DER-encoded signature that is then padded BASE64 encoded (as per
<xref target="RFC4648" sectionFormat="of" section="4"
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
the geofeed file, and for calculating the message digest on the
SignerInfo SignedAttributes <xref target="RFC8933"
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
DigestAlgorithmIdentifier <xref target="RFC5652"
format="default"/>.
</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.
</t>
<t>
@ -432,13 +507,13 @@
Obtaining the signer's certificate from the CMS SignedData
CertificateSet <xref target="RFC5652" format="default"/>. The
certificate SubjectKeyIdentifier extension <xref
target="RFC5280" format="default"/> <bcp14>MUST</bcp14> match
target="RFC5280" format="default"/> MUST match
the SubjectKeyIdentifier in the CMS SignerInfo
SignerIdentifier <xref target="RFC5652" format="default"/>.
If the key identifiers do not match, then validation
<bcp14>MUST</bcp14> fail.</t>
MUST fail.</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"
format="default"/> manifest and that the resources are covered
by the RPKI certificate.
@ -449,14 +524,14 @@
Constructing 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 <bcp14>MUST</bcp14> be valid according to
certification path MUST be valid according to
the validation algorithm in <xref target="RFC5280"
format="default"/> and the additional checks specified in
<xref target="RFC3779" format="default"/> associated with the
IP Address Delegation certificate extension and the Autonomous
System Identifier Delegation certificate extension. If
certification path validation is unsuccessful, then validation
<bcp14>MUST</bcp14> fail.
MUST fail.
</li>
<li>
@ -464,18 +539,18 @@
target="RFC5652" format="default"/> using the public key from
the validated signer's certificate. If the signature
validation is unsuccessful, then validation
<bcp14>MUST</bcp14> fail.
MUST fail.
</li>
<li>
Verifying that the IP Address Delegation certificate extension
<xref target="RFC3779" format="default"/> covers all of the
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.
</li>
</ol>
<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.
</t>
<t>
@ -495,9 +570,10 @@
validation for use with CMS object processing is too hard. And,
the certificates do not get that much bigger by repeating the
information.
Therefore an extension using "inherit" <bcp14>MUST NOT</bcp14>
be used. This is consistent with other RPKI signed objects.
</t>
<t>
Therefore an extension using "inherit" MUST NOT be used. This
is consistent with other RPKI signed objects.
</t>
<t>
Identifying the private key associated with the certificate and
@ -508,7 +584,7 @@
public RPKI, has the needed public key.
</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
incorrect, albeit simple, example. A correct and full example is
in <xref target="example" format="default"/>.
@ -527,8 +603,8 @@
</t>
<t>
The bracketing "# RPKI Signature:" and "# End Signature:"
<bcp14>MUST</bcp14> be present following the model as shown.
Their IP address range <bcp14>MUST</bcp14> match that of the
MUST be present following the model as shown.
Their IP address range MUST match that of the
inetnum: URL followed to the file.
</t>
<t>
@ -561,24 +637,24 @@
referring to geofeed files.
</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"/>.
</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
address range.
</t>
<t>
If and only if the geofeed file is not signed per <xref target="auth"
format="default"/>, then multiple inetnum: objects <bcp14>MAY</bcp14>
refer to the same geofeed file, and the consumer <bcp14>MUST</bcp14>
format="default"/>, then multiple inetnum: objects MAY
refer to the same geofeed file, and the consumer MUST
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.
</t>
<t>
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.
</t>
@ -589,14 +665,7 @@
certificate exclusively for the purpose shown in <xref
target="example" format="default"/>.
</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>
Harvesting and publishing aggregated geofeed data outside of
the RPSL model should be avoided as it can have the effect
@ -616,26 +685,16 @@
target="GEOFEED-FINDER" format="default"/>.
</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>
To prevent undue load on RPSL and geofeed servers,
entity-fetching geofeed data using these mechanisms <bcp14>MUST
NOT</bcp14> do frequent real-time lookups. <xref
entity-fetching geofeed data using these mechanisms MUST
NOT do frequent real-time lookups. <xref
target="RFC8805" sectionFormat="of" section="3.4"
format="default"/> suggests use of the HTTP Expires header <xref
target="RFC7234" format="default"/> to signal when geofeed data
should be refetched. As the data change very infrequently, in
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
UTC, the first of the month, etc., because too many others are
likely to do the same.
@ -665,6 +724,34 @@
</t>
</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">
<name>Security Considerations</name>
<t>
@ -692,7 +779,7 @@
attacker could publish an unsigned equal or narrower (e.g., a
/24) inetnum: in a WHOIS registry that has weak authorization,
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>
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.8805.xml"?>
<?rfc include="reference.RFC.8933.xml"?>
<?rfc include="reference.RFC.9092.xml"?>
</references>
<references title="Informative References">
@ -740,10 +826,12 @@
<?rfc include="reference.RFC.3912.xml"?>
<?rfc include="reference.RFC.4632.xml"?>
<?rfc include="reference.RFC.5485.xml"?>
<?rfc include="reference.RFC.6269.xml"?>
<?rfc include="reference.RFC.7234.xml"?>
<?rfc include="reference.RFC.7485.xml"?>
<?rfc include="reference.RFC.7909.xml"?>
<?rfc include="reference.RFC.9082.xml"?>
<?rfc include="reference.RFC.9092.xml"?>
<?rfc include="reference.RFC.9323.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),
<contact fullname="John Scudder"/>, <contact fullname="Kyle
Rose"/> (SECDIR), <contact fullname="Martin Duke"/>, <contact
fullname="Murray Kucherawy"/>, <contact fullname="Paul
Kyzivat"/> (GENART), <contact fullname="Rob Wilton"/>, <contact
fullname="Roman Danyliw"/>, and <contact fullname="Ties de
Kock"/>.
fullname="Murray Kucherawy"/>, <contact fullname="Mohamed
Boucadair"/>, <contact fullname="Paul Kyzivat"/> (GENART),
<contact fullname="Rob Wilton"/>, <contact fullname="Roman
Danyliw"/>, and <contact fullname="Ties de Kock"/>.
</t>
</section>