Re: Google IP Geolocation

[Hank Nussbacher]

The issues that others had earlier this month just hit us this morning.

Users in Israel (132.74.0.0/15) trying to access Google.com or 
Youtube.com appear as coming from Iceland (see screenshot).


Change happened overnight.  Someone internally in Google's geo-location 
group typo'ed Israel as Iceland.


We have GGC access and Google ISP Portal access but why should we have 
to change the geolocation which worked well since forever just because 
someone internally messed up?



Regards,

Hank

Re: Google IP Geolocation

[Hank Nussbacher]

On 22/04/2021 11:36, Hank Nussbacher wrote:

The issues that others had earlier this month just hit us this morning.

Users in Israel (132.74.0.0/15) trying to access Google.com or 
Youtube.com appear as coming from Iceland (see screenshot).


Change happened overnight.  Someone internally in Google's geo-location 
group typo'ed Israel as Iceland.


We have GGC access and Google ISP Portal access but why should we have 
to change the geolocation which worked well since forever just because 
someone internally messed up?



Regards,

Hank




Now I am hearing that other universities in Israel have seen this issue 
since as early as April 4.


-Hank

Re: BGP and The zero window edge

[Job Snijders via NANOG]

On Thu, Apr 22, 2021 at 02:29:31PM +0300, Alexandre Snarskii wrote:
> 9002. Hit by Juniper PR1562090, route stuck in DeletePending..
> Workaround applied, sessions with 6939 restarted, route is gone.

Thank you for the details and clearing the issue.

Kind regards,

Job

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Tom Beecher]

>
> If the endpoint (e.g. web server) is physically located in Germany and
> you're helping a client misrepresent that it's located in Estonia in
> order to evade a legal requirement that it be located in Estonia then
> you've made yourself a party to criminal fraud.
>

While I agree with the overall sentiment of your message, I am curious ;
have there been any instances where an internet provider has been found
liable (criminally or civilly) for willfully misrepresenting IP geolocation
information?

On Wed, Apr 21, 2021 at 3:23 PM William Herrin  wrote:

> On Wed, Apr 21, 2021 at 11:58 AM nanoguser100 via NANOG 
> wrote:
> > I wanted to get the communities' opinion on this.
> >
> > Increasingly I have run into 'niche needs' where a client has a few
> users in a country we don't have a POP, say Estonia.  This is 'mainly' for
> localization but also in some cases for compliance (some sites REQUIRE an
> Estonian IP).  With that being said is it common practice to 'fake'
> Geolocations?  In this case the user legitimately lives in Estonia, they
> just happen to be using our cloud service in Germany.
>
> If the endpoint (e.g. web server) is physically located in Germany and
> you're helping a client misrepresent that it's located in Estonia in
> order to evade a legal requirement that it be located in Estonia then
> you've made yourself a party to criminal fraud. Do I really need to
> explain how bad an idea that is?
>
> If the service is a VPN relay for addresses which are actually being
> used in Estonia then what's the problem? You're just a transit for
> those IPs. Report the location where the endpoints are, not the
> transits.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

RE: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Brian Turnbow via NANOG]

Hi,


>>If the endpoint (e.g. web server) is physically located in Germany and
>>you're helping a client misrepresent that it's located in Estonia in
>>order to evade a legal requirement that it be located in Estonia then
>>you've made yourself a party to criminal fraud.

>While I agree with the overall sentiment of your message, I am curious ; have 
>there been any instances where an internet provider has been found liable 
>(criminally or civilly) for willfully misrepresenting IP >geolocation 
>information? 

So to extend this further,  you assign a class of IPs to a customer and 
register it to them  in the RIPE database.
Do you assign it to the customers address, in Estonia , or use the DC Address 
which is in Germany? 
Which could be the basis of geolocalizing the Address.
I would not want to be the lawyer on either side of the battle.

Brian

Re: Geo location Contacts

[nanoguser100 via NANOG]

https://ipdata.co/corrections.html

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, April 21, 2021 5:32 PM, Brian  wrote:

> Good day all. I am trying to find contacts at ipdata.co and ipinfo.io. I 
> recently acquired new ip space and most places have updated. But the above 2 
> have not and still show CA as the location for this ip space. Please feel 
> free to email me off the list.
>
> Thank you
> Brian

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[nanoguser100 via NANOG]

William,

The plan is to carve out a /24 for "Estonia" and have special servers on it.  
This would be the same /24 I'd have to use if I were to put a legitimate POP 
there.  This also means I don't conflict with the real Germany.

I am just worried about violating the 'rules' of these providers and getting 
myself blacklisted from submitting corrections.  Afterall the traceroute will 
still show us hitting a router in Germany before it hits my network.  
Traceroutes aren't the end all be all but it's a tell-tale sign.

I guess this is all ISP-reported info so it's not "illegal" or a violation in 
any way.

-Nanoguser100



Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, April 21, 2021 4:31 PM, William Herrin  wrote:

> On Wed, Apr 21, 2021 at 12:35 PM nanoguser100
> nanoguser...@protonmail.com wrote:
>
> > providing cloud hosted desktop solutions for end users.
>
> I missed this on the first read. Virtual Desktop along the lines of
> Azure Virtual Desktop, Google VDI or Amazon Workspaces.
>
> I would emphasize this; it'll help folks on the group offer better 
> information.
>
> > We are not a VPN per-se, it's more of a cloud hosted remote desktop 
> > service. We do have a VPN service as well which provides security services.
>
> That's a really interesting question. Some uses of geolocation will
> give suboptimal results if you pick Estonia since the packets need to
> go to Germany. Others, like content restriction, won't work right
> unless the IPs reflect the users' location.
>
> Generally, I think the geolocation is represented as the rough region
> where the servers are, with services that care about geolocation for
> content restriction intentionally disallowing them. That's the safe
> answer. For the alternative, I expect the different consumers of
> geolocation services will have different opinions about it.
>
> > With that being said is it proper for transit providers to advertise the IP 
> > of their end users?
>
> Yes.
>
> > Are we considered a true transit provider since we are not an ISP per-se?
>
> No. It's not whether you're an ISP, the IP packets are stopping at
> your network; you're not transiting them onward.
>
> Regards,
> Bill Herrin
>
> 
>
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Geo location Contacts

[Massimo Candela]

Hi Brian,

On 21/04/2021 23:32, Brian wrote:
Good day all. I am trying to find contacts at ipdata.co 
 and ipinfo.io . I recently acquired 
new ip space and most places have updated. But the above 2 have not and 
still show CA as the location for this ip space. 


Both of them support 
https://tools.ietf.org/html/draft-ietf-opsawg-finding-geofeeds-06

You can just update your geofeed.


Ciao,
Massimo

Re: Google IP Geolocation

[Phil Sykes]

Hi Hank,

I reported it against the /15 you supplied, since I agree you shouldn't
have to!

Internal bug reference for Google is bug 186090498.
If others have gone via Google's NOC, mentioning that reference to the NOC
may help get your "me too" on the list, but if it is a systemic .IL -> .IS
hopefully we can clean them all up without needing to be told about each
one.

thanks,

Phil Sykes
(day job: Google Networking SRE)


On Thu, Apr 22, 2021 at 10:06 AM Hank Nussbacher 
wrote:

> On 22/04/2021 11:36, Hank Nussbacher wrote:
> > The issues that others had earlier this month just hit us this morning.
> >
> > Users in Israel (132.74.0.0/15) trying to access Google.com or
> > Youtube.com appear as coming from Iceland (see screenshot).
> >
> > Change happened overnight.  Someone internally in Google's geo-location
> > group typo'ed Israel as Iceland.
> >
> > We have GGC access and Google ISP Portal access but why should we have
> > to change the geolocation which worked well since forever just because
> > someone internally messed up?
> >
> >
> > Regards,
> >
> > Hank
> >
> >
>
> Now I am hearing that other universities in Israel have seen this issue
> since as early as April 4.
>
> -Hank
>

Re: BGP and The zero window edge

[Alexandre Snarskii]

On Thu, Apr 22, 2021 at 01:24:54AM +0200, Job Snijders via NANOG wrote:
[...]
> 
> Another one is 
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2a0b:6b86:d24::/48
> 
> 2a0b:6b86:d24::/48 via:
> BGP.as_path: 201701 9002 6939 42615 212232
> BGP.as_path: 34927 9002 6939 42615 212232
> BGP.as_path: 207960 34927 9002 6939 42615 212232
> BGP.as_path: 44103 50673 9002 6939 42615 212232
> BGP.as_path: 208627 207910 34927 9002 6939 42615 212232
> BGP.as_path: 3280 34927 9002 6939 42615 212232
> BGP.as_path: 206628 34927 9002 6939 42615 212232
> BGP.as_path: 208627 207910 34927 9002 6939 42615 212232
> (first announced March 24th, last withdrawn March 24th, 2021)
[...]
> 
> I checked the AS 6939 Looking glass, but the d24::/48 route is not
> visible in the http://lg.he.net/ web interface. This leads me to believe
> the the route got stuck somewhere along way in either of 201701, 204092,
> 206628, 207910, 207960, 208627, 3280, 34927, 35280, 44103, 50673, 57199,
> and/or 9002.

9002. Hit by Juniper PR1562090, route stuck in DeletePending..
Workaround applied, sessions with 6939 restarted, route is gone.

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Mark Tinka]

On 4/22/21 15:57, Brian Turnbow via NANOG wrote:


So to extend this further,  you assign a class of IPs to a customer and 
register it to them  in the RIPE database.
Do you assign it to the customers address, in Estonia , or use the DC Address 
which is in Germany?
Which could be the basis of geolocalizing the Address.
I would not want to be the lawyer on either side of the battle.


Question - if a country is not assigned to an allocation or 
sub-assignment, what does it default to within the RIPE region?


In the AFRINIC region, for example, it would be MU (Mauritius), as that 
is where AFRINIC are located.


Mark.

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Matthew Petach]

On Thu, Apr 22, 2021 at 7:12 AM nanoguser100 via NANOG 
wrote:

> William,
>
> The plan is to carve out a /24 for "Estonia" and have special servers on
> it.  This would be the same /24 I'd have to use if I were to put a
> legitimate POP there.  This also means I don't conflict with the real
> Germany.
>
> I am just worried about violating the 'rules' of these providers and
> getting myself blacklisted from submitting corrections.  Afterall the
> traceroute will still show us hitting a router in Germany before it hits my
> network.  Traceroutes aren't the end all be all but it's a tell-tale sign.
>
> I guess this is all ISP-reported info so it's not "illegal" or a violation
> in any way.
>
> -Nanoguser100
>

I think it's safe to say that before anyone could be
held accountable for geolocation data, there would
have to *first* be a requirement that the data be able
to be reliably updated to be *correct*.

As we have not yet achieved a way of ensuring that
legitimate holders of IP resources can reliably update
the geolocation data, I think you can rest assured,
nobody will be holding you accountable for whatever
the geolocation data might show for a particular block
of addresses.

Now, if, as an industry, we had a consistent, reliable
way in which geolocation records could be updated
with a means to audit and ensure the updates are
being made only by the legitimate holders of the
number resources...*then* you might have reason
to be concerned.

But as of now, as evidenced by the number of
"how do I get my geolocation data updated"
emails sent to NANOG, which result in a flurry
of "meetoo" followups, no reasonable court
would ever give any legal credence to the
current data in the various geolocation
databases.

You can sleep soundly at night, whichever
road you may choose to take.

Matt

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Izaac]

On Wed, Apr 21, 2021 at 12:21:26PM -0700, William Herrin wrote:
> a legal requirement that it be located in [Atlantis]

A legal requirement of whom?  Undoubtedly the requirement is made of
provider of this theoretical service doing the restricting.  Is that
"legal requirement" satisfied by asking a third party their opinion of
the source of a given IP packet?  Or is there an actual measure of due
diligence necessary on the part of the service provider or the
maintainer of the GeoIP database?

Because it amuses me, let's think this one out:

Let's assume there are sanctions by Utopia against Atlantis, because I
cannot think of any other geolocation-based legal requirement.  Can you?

Widgets Unlimited of Utopia, LLC provides access to technical manuals on
its website.  Someone in their customer service IT support group learns
of the sanctions and wires up their website to IPgeoco's API.  A
"devious" Atlantean sends a SYN to Widgets Unlimited server, who sends a
SYN/ACK back, followed by a GET request from the Atlantean, which
triggers an API call for "geolocation of origin" to IPgeoco, which
returns "El Dorado", and then the LLC sends the Atlantean the manual for
their tractor.

The Utopian government uses its enormous, ubiquitous surveillance
mechanisms (every Utopian government has one) to discover the
transaction and is FURIOUS.  They slap Widgets Unlimited with a huge
fine (also a feature of Utopian governments) and threaten to schedule
them for a holiday at the local re-education camp (Utopian service at
its finest.)  The remaining executives at Widgets Unlimited start to
look into "how this could have happened!"

They discover that no one did any due diligence to qualify these
transactions.  They just asked a third party what their opinion of the
source of the connection might be.  Widgets Unlimited didn't inquire
from the requester if they were a customer, where they might be located,
or anything else.  They based their entire determination on a JSON
field.

One of the younger lawyers decides to seek damages from IPgeoco for
misrepresenting the information in their database.  IPgeoco shrugs and
points at their terms of service.  And they're located in the
Switzerhamas anyway.  "We don't do due diligence on our database.  We
just format and republish information provided to us."

So, the young Widgets Unlimited lawyer, high on ...fees, decides to
bully an ISP in El Dorado who runs a microwave relay across the strait
for some Atlantean customers.  "You misrepresented the geographic
location of those IP addresses!"

"We've never spoken to you and don't know who you are," replies Phantom
Gold ISP's legal team.  "But you provided this information to IPgeoco!"
"And?"  "And you materially misrepresented that information!"  "We did
not.  We're located in El Dorado, we told IPgeoco that the addresses are
assigned to us in El Dorado, and they were issued by FARIN, the RIR for
the Fantastic realms which lists us in El Dorado."

"But it's inaccurate!" "Accurate to what standard?"  "International
borders!"  "Of whom?"  "The actual host sending the packets."  "Why?"
"Because we use this as the basis of our compliance with Utopian
sanctions regulations!"

"So let me get this straight: you blindly trusted a database operated by
a disinterested party ... who collects data from a wide variety of other
disinterested third parties ... who follow widely variant policies for
the meaning of, let alone "accuracy" (to what standard?) of, that data
... and find this to be a sufficiently stable basis for bypassing your
seeking redress from your GeoIP provider and harassing me as a common
carrier in third party nation for some kind of nebulous damages?"

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Eric Kuhnke]

I sincerely doubt that any actual *law* could be enforced against an ISP
which is a legal entity in one location, yet has multiple discrete /23 or
/24 blocks and without any obfuscation choose to announce them from
multiple different geographic locations. Configurations where an AS has
multiple islands of service which are not linked together by an internal
transport network are not that rare these days (see prior discussion about
merits vs risks of filtering out your own netblock at your BGP edge). If
anyone is aware of any case law precedent for such a prosecution it would
be interesting to see citations.

The only scenario in which I could see a legal penalty being imposed on
some ISP, is if it fails to publish an accurate record of its corporate
name, address and contact info for its ARIN, RIPE, AFRINIC, APNIC, etc
entity listing as a corporation. Obviously you can't and shouldn't attempt
to obfuscate where you're headquartered, and you need to be able to prove
your legal entity bona fides to ARIN or RIPE anyways in order to maintain
registration.

As to whether third party content sources might refuse to serve content to
an ISP announcing blocks in weird places, an ISP tunneling a customer's
traffic from one location to another, or misunderstanding their geolocation
(Hulu in the US is a fine example of this, its regional content is broken
on Starlink right now because of a misunderstanding of how the cgnat
traffic meets the real Internet), that's not a law...

That's an arbitrary private choice of some OTT video content provider or
CDN to serve or not serve certain licenses of copyrighted content based on
what it thinks is geolocation data. Another example would be the content
you see on Canadian domestic netflix vs US domestic netflix.



On Wed, Apr 21, 2021 at 12:22 PM William Herrin  wrote:

> On Wed, Apr 21, 2021 at 11:58 AM nanoguser100 via NANOG 
> wrote:
> > I wanted to get the communities' opinion on this.
> >
> > Increasingly I have run into 'niche needs' where a client has a few
> users in a country we don't have a POP, say Estonia.  This is 'mainly' for
> localization but also in some cases for compliance (some sites REQUIRE an
> Estonian IP).  With that being said is it common practice to 'fake'
> Geolocations?  In this case the user legitimately lives in Estonia, they
> just happen to be using our cloud service in Germany.
>
> If the endpoint (e.g. web server) is physically located in Germany and
> you're helping a client misrepresent that it's located in Estonia in
> order to evade a legal requirement that it be located in Estonia then
> you've made yourself a party to criminal fraud. Do I really need to
> explain how bad an idea that is?
>
> If the service is a VPN relay for addresses which are actually being
> used in Estonia then what's the problem? You're just a transit for
> those IPs. Report the location where the endpoints are, not the
> transits.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

RE: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Brian Turnbow via NANOG]

> 
> Question - if a country is not assigned to an allocation or sub-assignment,
> what does it default to within the RIPE region?
> 
> In the AFRINIC region, for example, it would be MU (Mauritius), as that is
> where AFRINIC are located.

AFAIK Ripe does not set a default, it is up to the LIR.
You can assign geoloc to orgs ans assignments
Ripe publishes a list of all allocations made to the provider and lists their 
country of record.
If the address space is unassigned I'm not sure as it is not listed in the file 
 of allocations that contains the country , but I would guess NL as the RIPE 
country of record.

Brian

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Mark Tinka]

On 4/22/21 16:55, Brian Turnbow wrote:


AFAIK Ripe does not set a default, it is up to the LIR.
You can assign geoloc to orgs ans assignments
Ripe publishes a list of all allocations made to the provider and lists their 
country of record.
If the address space is unassigned I'm not sure as it is not listed in the file 
 of allocations that contains the country , but I would guess NL as the RIPE 
country of record.


Thanks for that.

Well, if there is no default and the member has to add a country to the 
assignment or allocation, then the question becomes whether the degree 
of truth implemented by said member when updating the WHOIS database 
with the assignment is sufficient to form a case for or against them.


If there is no strict policy that RIPE publishes and/or enforces that 
defines associating assignments with the country in which they are used, 
I struggle to see how a lawyer could - in a 1+1 way - assert that the 
data is fraudulent. After all, the lack of definitive policy lends 
itself to the notion that (the truthfulness of) this data can be 
not-so-unreasonably discretionary.


Then again, lawyers don't generally go the 1+1 route :-).

Mark.

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Patrick W. Gilmore]

On Apr 22, 2021, at 10:23 AM, Matthew Petach  wrote:
> On Thu, Apr 22, 2021 at 7:12 AM nanoguser100 via NANOG  
> wrote:
>> William,
>> 
>> The plan is to carve out a /24 for "Estonia" and have special servers on it. 
>>  This would be the same /24 I'd have to use if I were to put a legitimate 
>> POP there.  This also means I don't conflict with the real Germany.
>> 
>> I am just worried about violating the 'rules' of these providers and getting 
>> myself blacklisted from submitting corrections.  Afterall the traceroute 
>> will still show us hitting a router in Germany before it hits my network.  
>> Traceroutes aren't the end all be all but it's a tell-tale sign.
>> 
>> I guess this is all ISP-reported info so it's not "illegal" or a violation 
>> in any way.
>> 
>> -Nanoguser100

Love the fact you try to anonymize the question - after giving details like 
“server is in German, we want it to appear in Estonia”.

Anyway



> I think it's safe to say that before anyone could be 
> held accountable for geolocation data, there would 
> have to *first* be a requirement that the data be able 
> to be reliably updated to be *correct*.

Matt: I find it amusing you think rationality and logic have anything to do 
with government activity. You are not usually this naïve.


> As we have not yet achieved a way of ensuring that 
> legitimate holders of IP resources can reliably update 
> the geolocation data, I think you can rest assured, 
> nobody will be holding you accountable for whatever 
> the geolocation data might show for a particular block 
> of addresses.

I am not at all certain of this. At the very least, the maintainer of the 
information may hold it against you if they find out you have intentionally 
falsified the data. Remember, the people offering IP address <> Geo-location 
databases for money are not beholden to you. They are beholden to the people 
paying them money. If $CONTENT_OWNER wants to ensure only devices in Estonia 
get certain content, and you go out of your way to allow devices in German get 
the content, this could present a problem.

Will they sue you? I cannot see that happening. Will they ignore any future 
updates you give them? Would not surprise me.

BTW: I know VPN providers advertise this precise ability. However, at least the 
VPN end point is where they say it is.


> Now, if, as an industry, we had a consistent, reliable 
> way in which geolocation records could be updated 
> with a means to audit and ensure the updates are 
> being made only by the legitimate holders of the 
> number resources...*then* you might have reason 
> to be concerned.

Wait, I thought we did. At least I see it in every movie….


> But as of now, as evidenced by the number of 
> "how do I get my geolocation data updated" 
> emails sent to NANOG, which result in a flurry 
> of "meetoo" followups, no reasonable court 
> would ever give any legal credence to the 
> current data in the various geolocation 
> databases.

I find a difference between “we tried to keep the data straight, but there are 
mistakes” and “this data was intentionally misrepresented”. My guess is the law 
might as well.

As stated above, I seriously doubt anyone will someone sue you over it. Will 
you go to jail? Yeah, again, I cannot see that happening. Doesn’t mean you 
should do it.


> You can sleep soundly at night, whichever 
> road you may choose to take.

What is this “sleep” you mention?

-- 
TTFN,
patrick

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Jaap Akkerhuis]

 Brian Turnbow via NANOG writes:

 > If the address space is unassigned I'm not sure as it is not listed in the 
 > file  of allocations that contains the country , but I would guess NL as the 
 > RIPE country of record.

I seem to remember they use ZZ for unknown geographical area.

jaap

Cloudflare OCTO RPKI Validator - LACNIC CAs issues

[Douglas Fischer]

Does anybody else have problems with Cloudflare's RPKI Validator with
prefixes from LACNIC?

Customers were sending us some reports of issues with LACNIC's IPBlocks
using Cloudflare RPKI as source of validation.

A friend and I did some checks. And looks like that some issue is happening
on the Lacnic Trust Anchor, specifically on OctoRPKI.
We took the Registro.Br Prefix to do the tests -> 200.160.0.0/20 -> AS22548

 -> On Cloudflare
https://rpki.cloudflare.com/?view=validator&validateRoute=22548_200.160.0.0%2F20
AS22548_200.160.0.0/20 is Unknown at 19:30 20201-04-22
https://pasteboard.co/JYy8fjI.png

-> On Ripe
https://rpki-validator.ripe.net/bgp-preview
AS22548_200.160.0.0/20 is Valid at 19:30 20201-04-22
https://pasteboard.co/JYycsd4.png

An interesting thing is that on the graph of ROAs over Timer of the Lacnic
Trust Anchor shows a big drop on 20201/04/19.
https://rpki.cloudflare.com/?ohlcTa=LACNIC
"Volume Removed: 14.761"
"ROAs Removed: 13.392"
https://pasteboard.co/JYyeSaw.png

Any idea of possible causes?
Any suggestions on how to solve it?

--
Douglas Fernando Fischer
Engº de Controle e Automação

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[nanoguser100 via NANOG]

I see a lot of replies about the legality. As mentioned I have legitimate 
reasons for doing this. I plan on serving customers in country.

My questions really are:

* Is most geo data simply derived from self reporting?
* Do these vendors have verification mechanisms?
* Going to the Estonia\Germany example would a traceroute "terminating" in 
Germany before being handed off to my network 1ms away be a tell-tale sign the 
servers are in Germany.
* Is the concept of creating "pseudoPOPs" where it's not cost effective to 
start a POP in the region a 'common practice'?
* Do I run the risk of being blacklisted for this practice?

-Nanoguser100

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, April 21, 2021 9:00 AM, nanoguser100 via NANOG  
wrote:

> I wanted to get the communities' opinion on this.
>
> I am an admin for a quasi-ISP providing cloud hosted desktop solutions for 
> end users. We have POPs all around the world, own our own ASN, and advertise 
> /24s or /23s at each of our POPs fro our large aggregate. As an ISP we submit 
> our blocks to popular geolocation vendors such as Google, Maxmind, IP2, etc 
> and put the proper geolocations in our RIR records (RADB, ARIN, etc).
>
> Increasingly I have run into 'niche needs' where a client has a few users in 
> a country we don't have a POP, say Estonia. This is 'mainly' for localization 
> but also in some cases for compliance (some sites REQUIRE an Estonian IP). 
> With that being said is it common practice to 'fake' Geolocations? In this 
> case the user legitimately lives in Estonia, they just happen to be using our 
> cloud service in Germany. I do want to operate in compliance with all the ToS 
> as I don't want to risk our ranges getting blacklisted or the geo vendors 
> stop accepting our data. I would think it's pretty easy to tell given a 
> traceroute would end in Germany even though you're claiming the IP is in 
> Estonia. How common of a practice is it to 'fake' the geos? Is it an 
> acceptable practice?
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[George Michaelson]

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.

cheers

-G

Re: Cloudflare OCTO RPKI Validator - LACNIC CAs issues

[Aftab Siddiqui]

Hi Douglas,
Not sure about dip in their rpki monitoring page for lacnic, but I could
see the VRP here
https://rpki.cloudflare.com/rpki.json

The daily snapshot taken at 23:47 22-04-2021 using rpki.cloudflare.com
shows the prefix.

cloudflare# grep 200.160.0.0 2021-04-22-2347-UTC
+ 200.160.0.0 20 -  2422548

rtrclient tcp -k -p rtr.rpki.cloudflare.com 8282

Regards,

Aftab A. Siddiqui


On Fri, 23 Apr 2021 at 05:50, Douglas Fischer 
wrote:

> Does anybody else have problems with Cloudflare's RPKI Validator with
> prefixes from LACNIC?
>
> Customers were sending us some reports of issues with LACNIC's IPBlocks
> using Cloudflare RPKI as source of validation.
>
> A friend and I did some checks. And looks like that some issue is
> happening on the Lacnic Trust Anchor, specifically on OctoRPKI.
> We took the Registro.Br Prefix to do the tests -> 200.160.0.0/20 ->
> AS22548
>
>  -> On Cloudflare
>
> https://rpki.cloudflare.com/?view=validator&validateRoute=22548_200.160.0.0%2F20
> AS22548_200.160.0.0/20 is Unknown at 19:30 20201-04-22
> https://pasteboard.co/JYy8fjI.png
>
> -> On Ripe
> https://rpki-validator.ripe.net/bgp-preview
> AS22548_200.160.0.0/20 is Valid at 19:30 20201-04-22
> https://pasteboard.co/JYycsd4.png
>
> An interesting thing is that on the graph of ROAs over Timer of the Lacnic
> Trust Anchor shows a big drop on 20201/04/19.
> https://rpki.cloudflare.com/?ohlcTa=LACNIC
> "Volume Removed: 14.761"
> "ROAs Removed: 13.392"
> https://pasteboard.co/JYyeSaw.png
>
> Any idea of possible causes?
> Any suggestions on how to solve it?
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Robert Blayzor via NANOG]

On 4/22/2021 9:30 AM, Tom Beecher wrote:
While I agree with the overall sentiment of your message, I am curious ; 
have there been any instances where an internet provider has been found 
liable (criminally or civilly) for willfully misrepresenting IP 
geolocation information?


How could there be? Isn't geolocation data just a "best guess" where the 
endpoint may be? Technically you could route an IP (at least a /24) 
almost anywhere. What about anycast prefixes?