Finding and Using Geofeed Data
obsoletes
- rfc-9092 — Finding and Using Geofeed Data
Extracted elements (30)
A signed geofeed file MUST only contain prefixes within the signing inetnum:'s range, making it incompatible with being referenced from multiple inetnum: objects; unsigned files may be shared across objects. This design ensures the signing certificate's address coverage constraint is always satisfiable.
RPKI-based authentication of geofeed files is explicitly optional. RPSL in many repositories is weakly authenticated, providing at best limited assurance; the RPKI approach is described as 'unfortunately complex,' and making signatures mandatory was not considered feasible for near-term deployment.
The 'inherit' capability in IP Address Delegation extensions is prohibited for geofeed signing certificates because it would require the implementation to build the certification path, validate it, and then carry remembered state from path validation forward into CMS object processing — a complexity and error-prone coupling judged not worth the minor certificate size savings.
ARIN registry data is not in the same RPSL format as other RIRs; when fetching from ARIN, the 'NetRange' attribute must be treated as 'inetnum' and the 'Comment' attribute must be treated as 'remarks'.
RDAP is converging on support for geofeed data, but RDAP SHOULD NOT be used for bulk retrieval; bulk access should use RIR FTP services instead.
A Certification Authority MUST generate a new end entity (EE) certificate for each signing of a geofeed file; the CA SHOULD also generate a new key pair for each new version of the file.
A proper geofeed: attribute in the inetnum: class MUST be 'geofeed:' followed by a single URL referring only to a single geofeed file. This is preferred over the remarks: form when the RIR supports it.
During canonicalization for signing, the <CRLF> sequence MUST be used to denote the end of each line; non-printable characters MUST NOT be changed; trailing blank lines MUST NOT appear at the end of the file.
During CMS signature validation, the certificate SubjectKeyIdentifier extension MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier; if they do not match, validation MUST fail.
Entities fetching geofeed data MUST NOT perform frequent real-time lookups; in the absence of HTTP Expires header signals, collectors SHOULD NOT fetch more frequently than weekly.
For inetnum: objects covering the same address range, a signed geofeed file MUST be preferred over an unsigned file; if none or multiple are signed, the one with the most recent last-modified: attribute MUST be preferred.
Geofeed files MUST be published via and fetched using HTTPS, which provides authentication, integrity, and confidentiality for the transport.
If an inetnum: object contains both a geofeed remarks: attribute and a geofeed: attribute, the geofeed: attribute MUST be used.
If geofeed files are fetched, other location information from the inetnum: object (e.g., country:, geoloc:, DNS geoloc RRsets) MUST be ignored for that address range.
The address range of the RPKI signing certificate MUST cover all prefixes in the signed geofeed file; if not, the authenticator is invalid.
The eContentType OID in the CMS signature MUST be id-ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47), and it MUST appear in both the eContentType in encapContentInfo and the ContentType signed attribute in signerInfo.
The inetnum: remarks: attribute carrying a geofeed reference MUST use the format 'remarks: Geofeed <URL>', where the token 'Geofeed ' is case-sensitive and the URL MUST refer only to a single geofeed file.
The RPKI authenticator MUST be embedded as a series of '#' comment lines at the end of the geofeed file, bracketed by '# RPKI Signature: <range>' and '# End Signature: <range>' lines; the IP address range MUST match that of the geofeed URL in the inetnum:.
The same digest algorithm MUST be used for both calculating the message digest of the geofeed file content and for calculating the message digest on the SignerInfo SignedAttributes; the algorithm identifier MUST appear in both CMS SignedData DigestAlgorithmIdentifiers and SignerInfo DigestAlgorithmIdentifier.
The signing certificate MUST NOT include the Autonomous System Identifier Delegation certificate extension; the IP Address Delegation certificate extension MUST NOT use the 'inherit' capability — either condition renders the authenticator invalid.
To minimize load on RIR WHOIS services, RIR FTP services SHOULD be used for large-scale bulk access to collect inetnum: objects with geofeed references rather than brute-force WHOIS queries.
Until all RIRs have migrated to the geofeed: attribute, consumers MUST be able to consume both the remarks: and geofeed: forms of geofeed references in inetnum: objects.
When fetching geofeed data, the most specific inetnum: object with a geofeed reference MUST be used; data from less-specific inetnum: objects MUST be ignored when a more-specific one covering the address of interest has a geofeed reference.
When reading data from an unsigned geofeed file, one MUST ignore data outside the referring inetnum: object's address range to avoid importing data about ranges not under the operator's control.
Geofeed data may reveal the approximate geographic location of IP addresses and thereby of individual users. This document makes bulk access to such data readily available by design; operators publishing geofeed pointers should be aware of this exposure. All privacy considerations of RFC 8805 Section 4 apply.
A six-step RPKI signature validation procedure covers: (1) extracting the signer certificate and verifying SubjectKeyIdentifier match, (2) confirming the certificate is on the current RPKI manifest with all resources covered, (3) building and validating the certification path per RFC 5280 and RFC 3779, (4) validating the CMS SignedData, (5) confirming the eContentType OID, and (6) verifying the IP Address Delegation extension covers all prefixes in the file. All six steps MUST succeed.
IANA SMI Security for S/MIME CMS Content Type registry (1.2.840.113549.1.9.16.1): decimal 47 is assigned to id-ct-geofeedCSVwithCRLF; the reference is updated from RFC 9092 to RFC 9632.
Because some RPSL repositories have weak authentication, an attacker or customer can publish an unsigned, narrower inetnum: in a weakly-authorized WHOIS registry that points to a malicious geofeed file; since the most-specific inetnum: MUST be used, this overrides a broader RPKI-signed entry. Mandatory signatures would prevent this but are not required.
Consumers of geofeed data SHOULD fetch and process the data themselves rather than importing third-party processed datasets, since doing so places significant trust in the third party. Cross-validation against other sources is generally prudent.
The optional RPKI authenticator appended to a geofeed file is a CMS detached DER-encoded signature over the canonicalized (UTF-8, CRLF) geofeed body, then Base64-encoded with padding and line-wrapped to 72 or fewer characters, embedded as '#'-prefixed comment lines.