From bb8c89d05c978a31618440b1fbed7505f054b25b Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Mon, 24 Jul 2023 17:02:34 -0700 Subject: [PATCH] -02 published --- draft-ymbk-9092update.xml | 312 ++++++++++++++++++++++++-------------- 1 file changed, 200 insertions(+), 112 deletions(-) diff --git a/draft-ymbk-9092update.xml b/draft-ymbk-9092update.xml index 74d80da..6e4f2bd 100644 --- a/draft-ymbk-9092update.xml +++ b/draft-ymbk-9092update.xml @@ -8,13 +8,13 @@ - + obsoletes="9092" version="2" > - A Minor Update to Finding and Using Geofeed Data + Finding and Using Geofeed Data IIJ & Arrcus @@ -34,15 +34,15 @@ NTT
- Siriusdreef 70-72 - Hoofddorp - 2132 WT + Veemweg 23 + Barneveld + 3771 MT Netherlands massimo@ntt.net
- + Google
@@ -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. 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 , Section 14 in particular. + Also, infrastructure and other services might wish to publish + the locale of their services. 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. This document specifies how to augment the Routing Policy @@ -119,16 +120,13 @@ An optional utterly awesome but slightly complex means for - authenticating geofeed data is also defined. + authenticating geofeed data is also defined in . This document obsoletes . Changes from include the following:
    -
  • - It is no longer assumed that a geofeed file is a CSV, comma - separated value list. -
  • RIPE has implemented the geofeed: attribute.
    • @@ -136,6 +134,9 @@ Allow, but discourage, an inetnum: to have both a geofeed remarks: attribute and a geofeed: attribute. +
  • + Geofeed file only UTF-8 CSV. +
  • Stress that authenticating geofeed data is optional.
    • @@ -174,6 +175,12 @@ locales. + + Per , geofeed files consist of CSVs + (Comma Separated Values) in UTF-8 text format; not HTML, + richtext, or other formats. + + 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 @@ 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 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 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 file. While we leave global agreement of RPSL modification to the relevant parties, we specify that a proper geofeed: attribute in - 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 file. - - Registries MAY, for the interim, provide a mix of - the remarks: attribute form and the geofeed: attribute form. - 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 - MUST be able to consume both the remarks: and + MUST be able to consume both the remarks: and geofeed: forms. + - + 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. - Any particular inetnum: object SHOULD 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 SHOULD be preferred. + attribute SHOULD be preferred. As inetnum: objects form a hierarchy, geofeed references - SHOULD 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 MUST be used. + with a geofeed reference MUST be used. 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. - - Currently, the registry data published by ARIN are not the same - RPSL as that of the other registries (see for a survey of the WHOIS Tower of Babel); - therefore, when fetching from ARIN via FTP , WHOIS , the Registration Data - Access Protocol (RDAP) , etc., the "NetRange" attribute/key - MUST be treated as "inetnum", and the "Comment" - attribute MUST be treated as "remarks". - + +
    + Fetching Geofeed Data + + + This document is to provides a guideline for how interested + parties should fetch and read geofeed files. + + + + 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. + + + + To minimize the load on RIRs' WHOIS + services, the RIR's FTP 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. + + + + When an inetnum: with a geofeed file reference is identified, + the file MUST be downloaded using HTTPS. + + + + 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. + + + + 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: + + 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. + + + + 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. + + + + 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. + + + + There is open-source code to traverse the RPSL data across all + of the RIRs, collect all geofeed references, and process them + . It implements the steps above + and of all the Operational Considerations described in , 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. + +
    +
    Authenticating Geofeed Data (Optional) @@ -350,7 +425,7 @@ there is a fair number of them. - A single optional authenticator MAY be appended + A single optional authenticator MAY be appended to a geofeed 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 character encoding, and the - <CRLF> sequence MUST be used to denote the + <CRLF> sequence MUST be used to denote the end of a line of text. A blank line is represented solely by the <CRLF> sequence. For robustness, any non-printable - characters MUST NOT be changed by - canonicalization. Trailing blank lines MUST NOT + 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 <CRLF> 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 MUST NOT be processed by the digital + markers MUST NOT be processed by the digital signature algorithm. @@ -386,18 +461,18 @@ DER-encoded signature that is then padded BASE64 encoded (as per ) and line wrapped to 72 or fewer characters. - The same digest algorithm MUST 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 . The message digest algorithm identifier - MUST appear in both the SignedData + MUST appear in both the SignedData DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifier . - The address range of the signing certificate MUST + The address range of the signing certificate MUST cover all prefixes in the geofeed file it signs. @@ -432,13 +507,13 @@ Obtaining the signer's certificate from the CMS SignedData CertificateSet . The certificate SubjectKeyIdentifier extension MUST match + target="RFC5280" format="default"/> MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier . If the key identifiers do not match, then validation - MUST fail. + MUST fail. - Validation of the signer's certificate MUST + Validation of the signer's certificate MUST ensure that it is part of the current 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 MUST be valid according to + certification path MUST be valid according to the validation algorithm in and the additional checks specified in associated with the IP Address Delegation certificate extension and the Autonomous System Identifier Delegation certificate extension. If certification path validation is unsuccessful, then validation - MUST fail. + MUST fail.
  • @@ -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 - MUST fail. + MUST fail.
  • Verifying that the IP Address Delegation certificate extension covers all of the address ranges of the geofeed file. If all of the address - ranges are not covered, then validation MUST + ranges are not covered, then validation MUST fail.
    • - All of these steps MUST be successful to consider + All of these steps MUST be successful to consider the geofeed file signature as valid. @@ -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" MUST NOT - 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. Identifying the private key associated with the certificate and @@ -508,7 +584,7 @@ public RPKI, has the needed public key. - The appendix MUST 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 . @@ -527,8 +603,8 @@ The bracketing "# RPKI Signature:" and "# End Signature:" - MUST be present following the model as shown. - Their IP address range MUST 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. @@ -561,24 +637,24 @@ referring to geofeed files. - The geofeed files MUST be published via and fetched using + The geofeed files MUST be published via and fetched using HTTPS . - When using data from a geofeed file, one MUST ignore data + When using data from a geofeed file, one MUST ignore data outside the referring inetnum: object's inetnum: attribute address range. If and only if the geofeed file is not signed per , then multiple inetnum: objects MAY - refer to the same geofeed file, and the consumer MUST + 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. If the geofeed file is signed, and the signer's certificate - changes, the signature in the geofeed file MUST + changes, the signature in the geofeed file MUST be updated. @@ -589,21 +665,14 @@ 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. - - - 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. + 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 @@ -616,26 +685,16 @@ target="GEOFEED-FINDER" format="default"/>. - - 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. - - 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 + 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. @@ -664,6 +723,34 @@ readily available. This is a goal, not an accident.
    + +
    + Implementation Status + + + Currently, the geofeed: attribute in inetnum objects has + been implemented in the RIPE database. + + + + Registrants in databases which do not yet support the geofeed: + attribute are using the remarks:, or equivalent, attribute. + + + + Currently, the registry data published by ARIN are not the same + RPSL as that of the other registries (see for a survey of the WHOIS Tower of Babel); + therefore, when fetching from ARIN via FTP , WHOIS , the Registration Data + Access Protocol (RDAP) , etc., the "NetRange" attribute/key must be + treated as "inetnum", and the "Comment" attribute must be + treated as "remarks". + + +
    Security Considerations @@ -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 MUST be used. + geofeed reference MUST be used. If signatures were mandatory, the above attack would be stymied, but @@ -732,7 +819,6 @@ - @@ -740,10 +826,12 @@ + + @@ -1220,10 +1308,10 @@ following detached CMS signature. Palombini"/>, (INTDIR), , (SECDIR), , , (GENART), , , and . + fullname="Murray Kucherawy"/>, , (GENART), + , , and .