diff --git a/draft-ymbk-9092update.xml b/draft-ymbk-9092update.xml index 5b7d356..1ce7c9e 100644 --- a/draft-ymbk-9092update.xml +++ b/draft-ymbk-9092update.xml @@ -8,7 +8,7 @@ - @@ -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 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 would be good, except it would have to be deployed by all RPSL registries, and @@ -485,9 +485,19 @@ target="RFC5652" format="default"/>. - As an IP Address Delegation extension using "inherit" would - complicate processing, it MUST NOT 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" MUST NOT + be used. This is consistent with other RPKI signed objects. Identifying the private key associated with the certificate and @@ -568,22 +578,32 @@ If the geofeed file is signed, and the signer's certificate - changes, the signature in the geofeed file MUST be updated. + changes, the signature in the geofeed file MUST + be updated. 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 . + RPKI Certification Authority (CA) may issue a subordinate + certificate exclusively for the purpose shown in . To minimize the load on RIR WHOIS services, use of the RIR's FTP services SHOULD 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 + SHOULD 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. + + + 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 handles this + issue within the RPSL model. 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 . + all geofeed references, and process them . - To prevent undue load on RPSL and geofeed servers, entity-fetching - geofeed data using these mechanisms MUST NOT do - frequent real-time lookups. suggests use of the HTTP Expires - header to signal when - geofeed data should be refetched. As the data change very - infrequently, in the absence of such an HTTP Header signal, collectors - 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. + 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. + + + + To prevent undue load on RPSL and geofeed servers, + entity-fetching geofeed data using these mechanisms MUST + NOT do frequent real-time lookups. suggests use of the HTTP Expires header to signal when geofeed data + should be refetched. As the data change very infrequently, in + the absence of such an HTTP Header signal, collectors + 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. @@ -620,7 +651,6 @@
Privacy Considerations - 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.
+
Security Considerations @@ -653,11 +684,12 @@ third-party places ill-advised trust in the third-party. - As mentioned in , many RPSL - repositories have weak, if any, authentication. This allows spoofing - of inetnum: objects pointing to malicious geofeed files. suggests an unfortunately complex - method for stronger authentication based on the RPKI. + As mentioned in , some + RPSL repositories have weak, if any, authentication. This + allows spoofing of inetnum: objects pointing to malicious + geofeed files. suggests + an unfortunately complex method for stronger authentication + based on the RPKI. For example, if an inetnum: for a wide address range (e.g., a