[db-wg] New NWI for geofeed?

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
> 
> 
> 
>