On 06/05/2021 21:27, Massimo Candela via db-wg wrote:
Hi Hank,
On 06/05/2021 07:18, Hank Nussbacher via db-wg wrote:
What if you have a /16 as recorded by inetnum: as well as an RPKI certificate for that /16 but within the /16 there is a /24 that has been assigned to some other ASN? Can you publish a geofeed file for the /16?
What if there is no inetnum: listed for that /24 yet in the global BGP tables there is an announcement of that /24 from a different ASN - would you still accept the geofeed announcement for the /16 based on inetnum: and RPKI cert?
ASNs and BGP announcements do not come into play.
That is what I too would have thought. But Google, which wrote RFC8805 sees it differently. I have submitted to Google via their ISP Portal the follow geo-feed file: http://noc.ilan.net.il/GGC/iucc-geo-feed-for-google.csv Google accepted 15 of 16 prefixes from AS378 but *rejected* 128.139.0.0/16 since there is a BGP announcement from AS8551 for 128.139.194.0/24. Google's solution of "split the ranges in the feed to not include the subranges announced by other ASNs" seems to interpret RFC8805 differently than previous RFCs. From RFC8805 section 3.2: A consumer should only trust geolocation information for IP addresses or prefixes for which the publisher has been verified as administratively authoritative. All other geolocation feed entries should be ignored and logged for further administrative review. AS8551 cannot be administrative authoritative for 128.139.194.0/24 simply because they find such a prefix in the global BGP table. Common whois checks (whois.ripe.net) determines who is authoritative for 128.139.0.0/16 as well as for 128.139.194.0/24. It would appear based on Google's interpretation and implementation of RFC8805 that they nullify the RIR registry mechanism and base administrative authority based solely on what appears in the BGP table. I believe this is incorrect and I have emailed the Google authors of RFC8805 and await a response from them. I am wondering whether others who will implement RFC8805 will also use BGP routing tables as authoritative for geo-location checks. Regards, Hank
If a /16 inetnum has a geofeed link, the pointed file can specify entries covering the /16. If a /24 inetnum with geofeed link exists, this takes priority for that /24 portion. RPKI signature (optional) can be used -after- the inetnum hierarchy is resolved to verify ownership of the prefix.
Ciao, Massimo