Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
> > * 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 b...@herrin.us https://bill.herrin.us/
Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
> 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”. Under normal circumstances where user has a proper laptop with a DIA connection in Estonia they would get the Estonian content. Because the user's organization decided to consolidate their PCs and security services into a cloud hosted remote desktop product should have no bearing on how the end user's experience is. The end users at the org don't know they are "going through us". They just open their "computer" and work. > 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. Thank you. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, April 23, 2021 11:11 AM, Patrick W. Gilmore wrote: > 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.
Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
On Apr 22, 2021, at 7:58 PM, nanoguser100 via NANOG 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 > 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. >> >
Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
The RIPE Database offers the “geoloc:” attribute on ORGANISATION and INET(6)NUM objects that may or may not be used as an additional source of information by these providers. https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-database https://labs.ripe.net/author/denis/geolocation-prototype-for-ripe-database/ https://labs.ripe.net/author/denis/example-usage-of-ripe-database-geolocation-prototype/ -- regards, Rafał Fitt
Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
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?
Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
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: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
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
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
Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
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
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
> > 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
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
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
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
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
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: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
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: Submitting Fake Geolocation for blocks to Data Brokers and RIRs
> > 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
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/
Submitting Fake Geolocation for blocks to Data Brokers and RIRs
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.
