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 <bill@herrin.us> wrote:

On Wed, Apr 21, 2021 at 11:58 AM nanoguser100 via NANOG <nanog@nanog.org> 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 bill@herrin.us https://bill.herrin.us/

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.

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.

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?

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 <bill@herrin.us> wrote:

On Wed, Apr 21, 2021 at 11:58 AM nanoguser100 via NANOG <nanog@nanog.org> 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 bill@herrin.us https://bill.herrin.us/

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

On Apr 22, 2021, at 7:58 PM, nanoguser100 via NANOG <nanog@nanog.org> wrote:

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.

Your “legitimate” reason is to avoid someone else’s restrictions on the content they own. You are intentionally falsifying data to keep the owner of something from controlling that thing the way they want to control it. You and I have different definitions of “legitimate”.

My questions really are:

* Is most geo data simply derived from self reporting?

No comment.

* Do these vendors have verification mechanisms?

Yes.

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

Yes. BTW: Adding artificial latency to mimic a trip back to Estonia is a bad idea, IMHO.

* Is the concept of creating "pseudoPOPs" where it's not cost effective to start a POP in the region a 'common practice'?

No, but it is not unheard-of.

* Do I run the risk of being blacklisted for this practice?

Risk? Blacklisted where? The risk of another ISP filtering your traffic for this is very low, almost certainly to the right of the decimal, but not mathematically zero to infinite decimal places. As I mentioned before, the risk of geo-loc providers ignoring any of your manual updates in the future is higher, but still low. Most of those things are automated. -- TTFN, patrick

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, April 21, 2021 9:00 AM, nanoguser100 via NANOG <nanog@nanog.org> 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 Secure Email.

...

* Do I run the risk of being blacklisted for this practice?

Risk? Blacklisted where?

The risk of another ISP filtering your traffic for this is very low, almost certainly to the right of the decimal, but not mathematically zero to infinite decimal places. As I mentioned before, the risk of geo-loc providers ignoring any of your manual updates in the future is higher, but still low. Most of those things are automated.

I doubt the geo-loc provider will blacklist you unless you give them detail locations (e.g. an exact building) which have no relationship to you or the users at all. They get embarrassed when police rely on them and then knock on the wrong door. There is some risk of content owners blacklisting your entire address space on the grounds that you have been caught circumventing their restrictions. I have no idea how significant or insignificant this risk is. If it happens, good luck getting it undone. There is some risk of legal action should a government entity rely on your information to mean that data in its unencrypted form has stayed within a particular locality when it has not. For example, China expects that its citizens browse the web from behind the great firewall where they can control and interdict information they don't like. I have no idea how significant or insignificant this risk is. Understand that while you may not actually be in the other country, many countries have treaties which allow cases to be brought in the resident's country when the behavior is unlawful in both countries and at least part of the actual activity happened in the other country. Fraud abetting some other unlawful behavior is broadly unlawful itself. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/