Finding and Using Geofeed Data
obsoleted by
- rfc-9632 — Finding and Using Geofeed Data
Extracted elements (32)
A remarks: attribute with the 'Geofeed' token is used as an interim solution rather than a new RPSL geofeed: attribute because change control for RPSL effectively lies in the operator community, requiring broader coordination before a formal attribute can be standardized.
Authentication of geofeed data is made optional rather than mandatory because mandatory signatures would require deployment across all RPSL registries and all registrants, which is not achievable in the near term.
RPKI-based CMS signing is used for optional authentication because RPSL authentication is widely weak; WebPKI HTTPS provides integrity and confidentiality for fetching but cannot authenticate IP address space assignment, which only RPKI can do.
ARIN's registry data uses non-standard RPSL attribute names: 'NetRange' instead of 'inetnum' and 'Comment' instead of 'remarks'; consumers must map these when accessing ARIN data via FTP, WHOIS, RDAP, or other means.
Geofeed files that describe multiple disjoint IP address ranges will have geofeed references from multiple inetnum: objects, and such files are not compatible with the Section 4 RPKI signing procedure.
Wherever inetnum: is used in this specification, inet6num: should also be assumed, ensuring the geofeed referencing mechanism applies to both IPv4 and IPv6 address space.
A proper geofeed: attribute in the inetnum: class MUST be 'geofeed:' followed by a single URL that MUST refer only to a single geofeed file.
All four RPKI signature validation steps (SubjectKeyIdentifier match, certification path validity per RFC 5280 and RFC 3779, CMS SignedData signature validation, and IP Address Delegation coverage) MUST be successful to consider the geofeed file signature valid.
Any particular inetnum: object MUST have at most one geofeed reference (whether remarks: or geofeed:); if there is more than one, all are ignored.
Canonicalization of geofeed content for signing MUST use UTF-8 encoding with CRLF line endings; non-printable characters MUST NOT be changed; trailing blank lines MUST NOT appear at end of file; end-of-file markers MUST NOT be processed by the digital signature algorithm.
Entities fetching geofeed data MUST NOT do frequent real-time lookups; in the absence of an HTTP Expires header, collectors SHOULD NOT fetch more frequently than weekly.
Geofeed files MUST be published via and fetched using HTTPS (RFC 2818).
If the geofeed file is signed and the signer's certificate changes, the signature in the geofeed file MUST be updated.
The address range of the RPKI signing certificate MUST cover all prefixes in the geofeed file it signs; if all address ranges are not covered, validation MUST fail.
The format of the inetnum: geofeed remarks: attribute MUST be 'remarks: Geofeed ' with the token 'Geofeed ' case sensitive, followed by a URL that MUST refer only to a single geofeed file.
The RPKI signature appendix MUST be hidden as a series of '#' comments at the end of the geofeed file; the bracketing '# RPKI Signature:' and '# End Signature:' MUST be present; their IP address range MUST match that of the inetnum: URL followed to the file.
The same digest algorithm MUST be used for both the geofeed file content digest and the SignerInfo SignedAttributes digest; the algorithm identifier MUST appear in both the SignedData DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifier.
Until all RIRs 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 geofeed: attribute forms.
When fetching from ARIN, the 'NetRange' attribute/key MUST be treated as 'inetnum' and the 'Comment' attribute MUST be treated as 'remarks' due to ARIN's non-standard RPSL format.
When fetching geofeed data, the most specific inetnum: object with a geofeed reference MUST be used; geofeed references SHOULD be placed at the lowest applicable inetnum: object covering the relevant address ranges.
When geofeed references are provided by multiple inetnum: objects with identical address ranges, the geofeed reference on the inetnum: with the most recent last-modified: attribute SHOULD be preferred.
When using data from a geofeed file, one MUST ignore data outside the referring inetnum: object's address range.
Geofeed data may reveal the approximate geographic location of an IP address, which could in turn reveal the approximate location of an individual user; this document makes bulk access to that data readily available, which is an intentional design goal.
An optional RPKI-based CMS detached signature may be appended to a geofeed file as '#' comments; it is a digest of the file body signed by the private key of the relevant RPKI certificate covering the geofeed's address range, bundled with the signing certificate.
The geofeed: attribute is the proper long-term RPSL extension to the inetnum: class, containing a single HTTPS URL pointing to a geofeed CSV file as defined in RFC 8805.
The inetnum: geofeed remarks: attribute is an interim mechanism to associate a geofeed file URL with an IP address range object in RPSL, using the case-sensitive token 'Geofeed ' as a prefix within the remarks: field.
IANA registered OID decimal 47 with description 'id-ct-geofeedCSVwithCRLF' in the 'SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)' registry, as defined by RFC 9092.
An attacker can publish an unsigned, narrower (e.g., /24) inetnum: with a malicious geofeed URL in a weakly-authorized WHOIS registry to override a legitimately RPKI-signed broader (e.g., /16) inetnum:, exploiting the most-specific rule.
Many RPSL repositories have weak or no authentication, which allows spoofing of inetnum: objects that point to malicious geofeed files; the RPKI-based signing in Section 4 provides stronger but optional authentication.
RPSL providers have needed to throttle overly frequent queries; geofeed file servers will likely need similar defenses such as rate limiting by querying IP address or block.
The CMS detached signature is a DER-encoded CMS SignedData structure (borrowing from RFC 5485), padded BASE64-encoded per RFC 4648 Section 4, line-wrapped to 72 or fewer characters, and appended to the geofeed file as lines prefixed with '# '.
The RPKI signature block in a geofeed file begins with '# RPKI Signature: <IP range>' and ends with '# End Signature: <IP range>', with each line of the BASE64 CMS blob prefixed by '# '; the signature does not cover the signature comment lines themselves.