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 compact="yes"?>
<?rfc subcompact="no"?> <?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" submissionType="IETF" consensus="true" ipr="trust200902"
obsoletes="9092" > obsoletes="9092" >
@ -343,7 +343,7 @@
authorized by the "owner" of the IP address space and is authorized by the "owner" of the IP address space and is
authoritative in some sense. The inetnum: that points to the authoritative in some sense. The inetnum: that points to the
geofeed <xref target="RFC8805" format="default"/> file provides 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 weakly authenticated at best. An approach where RPSL was signed
per <xref target="RFC7909" format="default"/> would be good, per <xref target="RFC7909" format="default"/> would be good,
except it would have to be deployed by all RPSL registries, and except it would have to be deployed by all RPSL registries, and
@ -485,9 +485,19 @@
target="RFC5652" format="default"/>. target="RFC5652" format="default"/>.
</t> </t>
<t> <t>
As an IP Address Delegation extension using "inherit" would An IP Address Delegation extension using "inherit" would
complicate processing, it <bcp14>MUST NOT</bcp14> be used. This complicate processing. The implementation would have to build
is consistent with other RPKI signed objects. 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>
<t> <t>
Identifying the private key associated with the certificate and Identifying the private key associated with the certificate and
@ -568,22 +578,32 @@
</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> be updated. changes, the signature in the geofeed file <bcp14>MUST</bcp14>
be updated.
</t> </t>
<t> <t>
It is good key hygiene to use a given key for only one purpose. 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 To dedicate a signing private key for signing a geofeed file, an
RPKI Certification Authority (CA) may issue a subordinate certificate exclusively for RPKI Certification Authority (CA) may issue a subordinate
the purpose shown in <xref target="example" format="default"/>. certificate exclusively for the purpose shown in <xref
target="example" format="default"/>.
</t> </t>
<t> <t>
To minimize the load on RIR WHOIS <xref target="RFC3912" To minimize the load on RIR WHOIS <xref target="RFC3912"
format="default"/> services, use of the RIR's FTP <xref format="default"/> services, use of the RIR's FTP <xref
target="RFC0959" format="default"/> services <bcp14>SHOULD</bcp14> be target="RFC0959" format="default"/> services
used for large-scale access to gather geofeed URLs. This also <bcp14>SHOULD</bcp14> be used for large-scale access to gather
provides bulk access instead of fetching by brute-force search geofeed URLs. This also provides bulk access instead of
through the IP space. 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>
<t> <t>
Currently, geolocation providers have bulk WHOIS data access at Currently, geolocation providers have bulk WHOIS data access at
@ -592,20 +612,31 @@
authorization. However, for users without such authorization, authorization. However, for users without such authorization,
the same result can be achieved with extra RDAP effort. There is the same result can be achieved with extra RDAP effort. There is
open-source code to pass over such data across all RIRs, collect 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>
<t> <t>
To prevent undue load on RPSL and geofeed servers, entity-fetching Geofeed data are orthogonal to geographic attributes in the
geofeed data using these mechanisms <bcp14>MUST NOT</bcp14> do inetnum:. Attributes such as country: tend to be
frequent real-time lookups. <xref target="RFC8805" sectionFormat="of" administrative, and not deployment specific. Consider large,
section="3.4" format="default"/> suggests use of the HTTP Expires possibly global, providers with headquarters very far from most
header <xref target="RFC7234" format="default"/> to signal when of their deployments.
geofeed data should be refetched. As the data change very </t>
infrequently, in the absence of such an HTTP Header signal, collectors
<bcp14>SHOULD NOT</bcp14> fetch more frequently than weekly. It would <t>
be polite not to fetch at magic times such as midnight UTC, the first To prevent undue load on RPSL and geofeed servers,
of the month, etc., because too many others are likely to do the same. 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>
<t> <t>
@ -620,7 +651,6 @@
<section anchor="privacy" numbered="true" toc="default"> <section anchor="privacy" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t> <t>
<xref target="RFC8805" format="default"/> geofeed data may reveal the <xref target="RFC8805" format="default"/> geofeed data may reveal the
approximate location of an IP address, which might in turn 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. readily available. This is a goal, not an accident.
</t> </t>
</section> </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>
@ -653,11 +684,12 @@
third-party places ill-advised trust in the third-party. third-party places ill-advised trust in the third-party.
</t> </t>
<t> <t>
As mentioned in <xref target="auth" format="default"/>, many RPSL As mentioned in <xref target="auth" format="default"/>, some
repositories have weak, if any, authentication. This allows spoofing RPSL repositories have weak, if any, authentication. This
of inetnum: objects pointing to malicious geofeed files. <xref allows spoofing of inetnum: objects pointing to malicious
target="auth" format="default"/> suggests an unfortunately complex geofeed files. <xref target="auth" format="default"/> suggests
method for stronger authentication based on the RPKI. an unfortunately complex method for stronger authentication
based on the RPKI.
</t> </t>
<t> <t>
For example, if an inetnum: for a wide address range (e.g., a For example, if an inetnum: for a wide address range (e.g., a