Submitting Fake Geolocation for blocks to Data Brokers and RIRs

George Michaelson ggm at
Fri Apr 23 00:21:32 UTC 2021

When an RIR asserts geo in Whois, it's derived from the organisational
data, but usually/often then self asserted. It was asserted by the
delegate, during registration.

When an RIR asserts geo in organisational data, it's self-asserted
through a filter of things like Dunn & Bradstreet and company
registration numbers.  Its less subject to change by the delegate,
because its about them, maintained by the registry. It's as subject to
risks of being wrong, as anything else about an entity.

What gets published by an RIR in things like delegated stats is from
organisational status, not geolocation of the IP addresses in most
cases. So its the "about them, maintained by registry" data

There isn't a strict formalism about how this data is verified. There
isn't some magic geo verification service, which would inherently vest
the data with more than the value of self assertion. It varies by
economy, and compliance issues. For some economies, the data is really
high value. For others, its moot.

I think the RFC geo mechanism, is inherently as good as self-asserted
data in Whois or RDAP. I think its probable it has more specificity
for prefixes used outside the economy of registration of the entity
which is delegated: and that's increasingly common.

I think, its a better mechanism overall.

The disconnect between what is registered, what is  (self) declared,
what is aggregated by geo-IP intelligence companies, what is learned
by BGP speakers, what is actually used, is huge. I think we're doing
ourselves a misservice by allowing this to be ill defined, but I would
be wary of declarations source A is inherently better than source B.

A lot of it, I think is about the curation. If it's well curated, a
good sign is responsiveness to reports it's wrong about some prefix.
Having said that, the interface inside large entities can be very
opaque. I think this is another disconnect: Between engineers who
specify things like geolocation format in IETF, and service delivery
people who may have other goals.



More information about the NANOG mailing list