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

attempting to address massimo's concerns

Browse source
This commit is contained in:
Randy Bush 2023-06-23 11:59:46 -07:00
parent 1682a57c2f
commit fd3d04e848
1 changed files with 61 additions and 29 deletions
Download patch file Download diff file Expand all files Collapse all files

90
draft-ymbk-9092update.xml
View file

@ -8,7 +8,7 @@
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ymbk-opsawg-9092-update-00"
<rfc category="std" docName="draft-ymbk-opsawg-9092-update-01"
submissionType="IETF" consensus="true" ipr="trust200902"
obsoletes="9092" >
@ -343,7 +343,7 @@
authorized by the "owner" of the IP address space and is
authoritative in some sense. The inetnum: that points to the
geofeed <xref target="RFC8805" format="default"/> file provides
some assurance. Unfortunately, the RPSL in many repositories is
some assurance. Unfortunately, the RPSL in some repositories is
weakly authenticated at best. An approach where RPSL was signed
per <xref target="RFC7909" format="default"/> would be good,
except it would have to be deployed by all RPSL registries, and
@ -485,9 +485,19 @@
target="RFC5652" format="default"/>.
</t>
<t>
As an IP Address Delegation extension using "inherit" would
complicate processing, it <bcp14>MUST NOT</bcp14> be used. This
is consistent with other RPKI signed objects.
An IP Address Delegation extension using "inherit" would
complicate processing. The implementation would have to build
the certification path from the end-entity to the trust anchor,
then validate the path from the trust anchor to the end-entity,
and then the parameter would have to be remembered when the
validated public key was used to validate a signature on a CMS
object. Having to remember things from certification path
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>
Identifying the private key associated with the certificate and
@ -568,22 +578,32 @@
</t>
<t>
If the geofeed file is signed, and the signer's certificate
changes, the signature in the geofeed file <bcp14>MUST</bcp14> be updated.
changes, the signature in the geofeed file <bcp14>MUST</bcp14>
be updated.
</t>
<t>
It is good key hygiene to use a given key for only one purpose.
To dedicate a signing private key for signing a geofeed file, an
RPKI Certification Authority (CA) may issue a subordinate certificate exclusively for
the purpose shown in <xref target="example" format="default"/>.
RPKI Certification Authority (CA) may issue a subordinate
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.
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
that more specifics from one aggregatee could undesirably
affect the less specifics of a different aggregatee. The
validation model in Section <xref target="auth"/> handles this
issue within the RPSL model.
</t>
<t>
Currently, geolocation providers have bulk WHOIS data access at
@ -592,20 +612,31 @@
authorization. However, for users without such authorization,
the same result can be achieved with extra RDAP effort. There is
open-source code to pass over such data across all RIRs, collect
all geofeed references, and process them <xref target="GEOFEED-FINDER" format="default"/>.
all geofeed references, and process them <xref
target="GEOFEED-FINDER" format="default"/>.
</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 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 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.
Geofeed data are orthogonal to geographic attributes in the
inetnum:. Attributes such as country: tend to be
administrative, and not deployment specific. Consider large,
possibly global, providers with headquarters very far from most
of their deployments.
</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
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
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.
</t>
<t>
@ -620,7 +651,6 @@
<section anchor="privacy" numbered="true" toc="default">
<name>Privacy Considerations</name>
<t>
<xref target="RFC8805" format="default"/> geofeed data may reveal the
approximate location of an IP address, which might in turn reveal the
@ -639,6 +669,7 @@
readily available. This is a goal, not an accident.
</t>
</section>
<section anchor="seccons" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
@ -653,11 +684,12 @@
third-party places ill-advised trust in the third-party.
</t>
<t>
As mentioned in <xref target="auth" format="default"/>, many RPSL
repositories have weak, if any, authentication. This allows spoofing
of inetnum: objects pointing to malicious geofeed files. <xref
target="auth" format="default"/> suggests an unfortunately complex
method for stronger authentication based on the RPKI.
As mentioned in <xref target="auth" format="default"/>, some
RPSL repositories have weak, if any, authentication. This
allows spoofing of inetnum: objects pointing to malicious
geofeed files. <xref target="auth" format="default"/> suggests
an unfortunately complex method for stronger authentication
based on the RPKI.
</t>
<t>
For example, if an inetnum: for a wide address range (e.g., a