Question for network hackers (please boost).
What's the safest way to prove that the ethernet responding to a certain public IP (v4) is located in a certain nation (or at least continent)?
I mean, I can use a geolocation db but I guess it could be outdated. Trace routing the IP and geolocating each hop through the db? Maybe better but... is there an even better way?
@Shamar "Safest" in the sense of fewest false positives? Ping from a host you know is in the vicinity of where he claims to be. It's hard to fake fast ping from a geographically distant host.
There's a tradeoff between low false positives and high false negatives, though. If a nearby host has high latency he could be either far away or on e.g. satellite internet.
@Shamar Not that I know of; technically, the duplicate *is* the ethernet responding to a certain public IP at that point. If there's a specific impersonator (or a list of impersonators), you could test for it with a traceroute like you said watch for a hop through an address on your blacklist.
What about comparing the #traceroute from different continents?
Or maybe there is a way to dump and compare the #BGP routes of an IP range and spot the duplication?
To be honest, these are deep waters for my #networking skills, so be patient with my dumb questions... but I really need an answer.
@Shamar Can you be a bit more specific about what you're trying to achieve? With this talk about BGP trickery, we're out of the scope of your original question, which was about the computer reachable at a certain IP address - now you're asking for statements about the computer that *should* be reachable at that address if not for malfeasance by the network.
My understanding is that you have a scenario where Alice wants to prove to Bob that she (or rather, the computer under her control) is physically close to Bob, where the network may be maliciously misrouting packets and/or forging responses.
Ping can carry a payload - and according to spec, the reply contains the same payload as the request. But you could invent a derivative where that rule isn't observed. So it would go something like this:
1. Bob sends a ping with an unpredictable payload.
2. Alice computes a hash of the original payload, signs the hash, and sends a ping response with the signature as the new payload.
3. Bob checks that the response time is inconsistent with a distant interlocutor, computes the same hash as Alice did, and verifies the signature against her public key.
Bob's initial payload must be unpredictable so that Alice cannot precompute the response and send it before receiving Bob's message. The payload may have a specific format, though - which would allow Alice to respond correctly to normal pings (i.e. echo the unmodified payload) on the same interface.
Of course if Alice is uncooperative, she could do things to make herself appear further from Bob, but it is hard to appear closer. Similarly, she may be unable to prove location if she's on e.g. a satellite connection - her communication takes exactly the same path from anywhere in roughly a quarter of the globe, so Bob can't tell if she's next door or 10000km away.
Ok sorry let's be more specific.
Suppose that Eve controls several public IPs, a datacenter in the US, one in Europe and one in China. Eve is not necessarily evil, but she is uncooperative and cannot be trusted on this specific matter.
Alice is in Europe and want to ensure Bob (who is in the US) that when they connect to a certain Eve's IP, their packets will reach an ethernet in the US. What happen to the packets after they reach the target IP is out of scope for this question.
Bob trust Alice.
What experiment could they do to verify that such specific IP is routed to the same physical ethernet from both sources (their point of observation) and that such ethernet is actually in the US?
They want to exclude that (something like) BGP trickery can cause that specific public IP to be assigned to different ethernet in different continents.
While this might look as a theoretical problem, it's not.
That's why I wrote this is something for #networking #hackers and asked to boost in the hope it reach somebody deep enough in these low level waters that could actually help.
@Shamar ah that helps.
> Alice is in Europe and wants to ensure Bob (who is in the US) that when they connect to a certain Eve's IP, their packets will reach an ethernet in the US.
> Bob trust Alice.
Bob can host a VPN, secure proxy, SSH tunnel, etc., through which Alice connects to Eve. Then as long as Bob's ping to Eve stays below what he could expect for a transoceanic RTT, he knows that both he and Alice are connected to the US one.
If a BGP attack redirects Bob's traffic intended for Eve-US to Eve-CN, his ping will jump. If a BGP attack redirects Alice's traffic intended for Bob to an imposter, she will see a mismatch between Bob's certificate and the imposter's.
Well, that would probably solve the security issue of Bob and Alice but would not solve my issue that is to prove that a certain IP is ONLY going to a certain continent.
I mean, I know they could both move to an alternative architecture, but for reasons, their issue is to actually prove that such specific IP is in the states.
🇳🇱
So i presume the reason kihrd's solution wasnt good for you is because you need a location more specific than just the continent.
Do you need the position you get from the client to be proven, as in, secure and reliable in such a way that the client can not reasonably pretend to be somwhere they are not?
How fine grained do you need the location to be?
Continent level precision is actually enough but a nation level would be better.
The issue in @khird's solution (vpn tunneling) is that it doesn't say anything about the IP location, just ensures that both Bob and Alice connect to the same location.
Instead I need to ensure that such IP, when connected directly from Alice, goes to the same etherney when connected from Bob.
In other terms Alice and Bob need a test that proves that the ethernet responding to such specific IP is globally unique and physically located in the US (or at least in America).
I guess the key is to exploit transoceanic TTL but... I do not know exactly how.
Maybe an altermative would be to actually dump and compare the respective BGP routes... but I do not know how.
sorry but im still a bit lost on your question (thought i understood it until you explained it just now, lol)...
> the ethernet responding to such specific IP
referring to the ethernet as a singular entity I think is what is confusing me. an ethernet is really just the set of protocols and technologies that allow us to construct lans, wans, and the internet as a whole. "Ethernet" isnt a word but if i were to guess what you mean I think it sounds like your talking about a LAN maybe, or atleast some set, probably privately owned, group of computers.
> In other terms Alice and Bob need a test that proves that the ethernet
Again this confuses me as the ethernet is not a thing that responds, it is a set of technologies, which may be used to facilitate a response, buyt something else is doing the responding...
Is it safe, for simplicty sake to just say you want some server that is serving up some port, when connected to by a TCP address (or perhaps more specifically HTTP), that it needs a way to determine the location of the connecting computer down to its nation?
Moreover, and this is the important part i need to know to provide an answer... do you need a solution that is near to impossible for a client to spoof or deceive in some way. As in hard to circumvent.
@freemo
Sorry for my bad explaination.
Let me try again.
By "ethernet" I meant the public internet-facing interface that first handles the packets that target a specific public IP.
In our example, this is likely a router's interface in the Eve's datacenters. I do not care about what happen inside the Eve's datacenter that receives the packet, but I need to prove that when Alice sends an level 3 packet (it could be a HTTPS over TCP or even a HTTP/3 over Quic, but I think it's not relevant to routing... is it?) to such IP address, the Eve's datacenter that receive the packet from the public Internet is the one in the US.
Now, I know that in mainsteream networking theory, an IP should only match one physical destination on earth.
So I know my question look weird (and possibly is dumb).
BUT I remember of a iranian attack, some time ago, that used fake BGP routes to obtain victim traffic to known US IP addresses. So I thought: what if such techniques (or similar ones I'm not aware of) were used as a sort of level 3 load balancing to reduce latency?
In this case, I'm looking for ways to ensure this is not happening.
In other terms, I'm looking for a way to exclude such IP address duplication in different zones of the planet.
Is my question more clear?
(I'm doing my best from my limited networking knowledge, maybe you can ask good questions...)
So there are many problems with what your trying to do. The fist is the fact that the computer that is trying to determine the location does nt and can not know anything about the content of the TCP stream or be a party to that communication. As you point out you need to handle encrypted streams like HTTPS which means you are excluded from being aware of anything in the content of that stream.
the reason this is a problem is because even if you were the HTTPS server itself hosting the service it would be very difficult for you to reliably and securely detect the geolocation of an IP. you can of course do a reverse GEO lookup on the IP, but that is easily circuvented by just routing through an IP address in the USA very a VPN. You could also use the browser API that almost all browsers have to request the clients location. In thsi case the browser will give a fairly accurate location as it uses GPS, cell tower location, pretty much anything it has access to in order to get the location of the client. However again this requires the cooperation of the client. A client could trivially just not use a browser and write their own program that connects to the server directly, or even just use curl, and can spoof any location data it wishes, with or without combining this with VPN.
In fact there are a great many very large and well funded companies that put a significant amount of effort into trying to solve a similar problem. Take netflix as a example. They have a significant financial incentive to know the correct geolocation of its users so it can know what shows it can provide the user, which changes based on their location (as a result of the agreement with the owners of the copyright of the shows). so they employ significant efforts to try to do this.
Even with netflixes resources it is still trivial to just use a VPN and get around it. The way they do it is they use reverse geoip like everyone else but then have a very extensive blacklist of IP addresses that are known or suspected to be a VPN and simply reject anyone behind a VPN and refuse to try to even try to figure out their real geo location at that point.
There are technologies that are in the proposal stage that may solve this like Client Presence Verification and Secure Location Verification, but they arent really ready for prime-time yet.
That said if your end points are HTTPs then any attack such as you describe would be pointless presuming valid certificate chains are maintained. Even if someone could route the traffic off to their location they couldnt do anything with it as it is all encrypted and HTTPS prevents a man in the middle attack as well.
The problem is that I do not care about the client location, but the server's one.
In our working evample, Eve has several public IP addresses available and 3 datacenters: one in the US, one in Europe and one in China.
We know that packets for a certain IP are routed to the US datacenter but we want to to check that this statement is true even for Alice (that is in Europe) as it is for Bob (that is in the US).
As said, whatever happen inside the datacenter (say, the transfer a copy of all the data to the Chinese datacenter) is not relevant for this specific problem.
We just want to be sure that Alice's packets for say 6.6.6.6 is not routed to the datacenter in the EU or the one in China, but just the one in the US (like the Bob's ones are). They could be ICMP packets... doesn't matter for our purpose.
