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
