<figure><img src="image_1.png" /></figure>

HAL
open science

# GeoFINDR: Practical Approach to Verify Cloud Instances Geolocation in Multicloud

Said Ider, Maryline Laurent

<figure><img src="image_2.png" /></figure>

► To cite this version:

Said Ider, Maryline Laurent. GeoFINDR: Practical Approach to Verify Cloud Instances Geolocation in Multicloud. 2025. hal-05253993

HAL Id: hal-05253993

https://hal.science/hal-05253993v1

Preprint submitted on 15 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_3.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# GeoFINDR: Practical Approach to Verify Cloud Instances
## Geolocation in Multicloud

*

Saïd Ider

Samovar, Télécom SudParis,
Institut Polytechnique de Paris

Palaiseau, France

said.ider@telecom-sudparis.eu

Maryline Laurent

Samovar, Télécom SudParis,
Institut Polytechnique de Paris

Palaiseau, France

0000-0002-7256-3721

April 2025

## Abstract

In multicloud environments, where legal obligations, technical constraints and economic interests are at stake, it is of interest to stakeholders to be able to locate cloud data or the cloud instance where data are decrypted for processing, making it particularly vulnerable. This paper proposes an original and practical delay-based approach, called GeoFINDR, to locate a cloud instance, e.g. a Virtual Machine (VM), over the Internet, based on RIPE Atlas landmarks. First, the assumed threat model and assumptions are more realistic than in existing solutions, e.g. VM-scale localization in multicloud environments, a Cloud Service Provider (CSP) lying about the VM's location. Second, the originality of the approach lies in four original ideas: (1) geolocalization is performed from the VM, (2) a Greedy algorithm selects a first set $LM_A$ of distributed audit landmarks in the vicinity of the declared area, (3) a sectorization algorithm identifies a set $LM_S$ of other landmarks with distance delay behavior similar to that of the VM to estimate the sector of the VM, and (4) the estimated location of the VM is calculated as the barycenter position of the $LM_S$ landmarks. An open source tool is published on GitHub and experiments show that localization accuracy can be as high as 22.1km, under unfavorable conditions where the CSP lies about the location of the VM.

**Keywords:** Delay-based geolocation, multicloud, VM-scale localization, GeoFINDR, RIPE Atlas, dishonest cloud service providers

## 1 Introduction

Even if customers specify in their SLAs that they want their data and data processing to be located in data centers in certain regions or cities, it is difficult for them to be sure that their SLA is being met, because most cloud services operate like a complex black box. Verifying the actual location of data and workloads from the declared cloud region is virtually impossible and never 100% reliable anyway, even when expensive means are deployed.

Geolocalization of data and physical resources on the Internet is very useful [1] [2] for customers and also for cloud service providers (CSP) themselves, in meeting their obligations to customers in multicloud environments and avoiding penalties. (1) For legal and sovereignty reasons, there is a need to have guarantees where the externalized data is stored to benefit from GDPR protection [5], to avoid the CLOUD Act, which allows the US to collect data from US companies or data stored in US cloud servers. (2) For availability and resiliency reasons, customers have an interest in ensuring that their virtual resources are replicated in different geographic locations to avoid, for example, losing all their data in the event of a fire, as happened in 2021, resulting in OVH paying customers at least 400,000€ in compensation<fnref n="1" />. (3) To combat mistrust of CSP, it is important to provide guarantees on the location of virtual resources.

This paper proposes a new approach called GeoFINDR, to verify the physical location of cloud instances, e.g. a VM, over the Internet. GeoFINDR is practical in many aspects. It supports VM-scale localization, which has a higher granularity than the cloud server loocalization, which is provided by most of the geolocation solutions of the literature. Localizing at VM scale is interesting as it matches the requirements of multicloud

<footnote>*This work was supported by the France 2030 ANR Project ANR-23-PECL-0009 TRUSTINCloudS.</footnote>

<footnote n="1">¹https://www.transatlantic-lawyer.com/ovh-must-pay-more-than-400000-e-after-a-fire-destroyed-its-data-centers-why-this-decision-is-important-for-hosting-providers-hosting-eu-personal-data/</footnote>
environments and the VM is known as a vulnerable instance, since it is there that data is decrypted before being processed. An open source tool is available on GitHub $^2$, and experiments show upto 22.1km accuracy with an average of 22.6km, which are very good results compared to other solutions. Note that these measures were obtained under unfavorable conditions where the CSP lies about the location of the VM.

The paper is organized as follows. After positioning our GeoFINDR solution against related works on delay-
based solutions in Section 2, Section 3 presents our GeoFINDR approach, from the threat model and assumptions
to the improvements brought to the area of delay-based solutions. Section 4 describes the implementation details,
including the resulting pseudocode. Section 5 presents the experiments performed with the methodology and
fully explains the achieved results, before concluding in Section 6.

## 2 Related Works on Delay-based Solutions

Delay-based solutions rely on multilateration to locate an entity, without CSP intervention, and derive the
position of an entity from a set of landmarks with known positions and a method for calculating the distance
between the entity and the landmarks. Table 1 summarizes the main features of the existing solutions.

CBDG (Constraint-Based Data Geolocation) [9] is the first software implementation for locating data over
the Internet. CBDG uses PlanetLab servers as landmarks and calculates the **Distance-Delay Relation
(DDR)** by linear regression of the ping RTT (Round Trip Time) between all landmarks. All landmarks then
ping the server to measure RTT and derive a distance that is used to define areas where the server might be
located. We emphasize that attempting to locate data is pointless, since data is duplicated anyway due to the
high-availability architecture of the cloud and can circulate by physical means. Therefore, we consider the issue
of data location outside the scope of our study and instead focus our efforts on verifying the location of a cloud
instance, which is relevant because it is where encrypted data is processed.

In IGOD [10], the authors improve CBDG DDR computation, overall performance, and accuracy by imple-
menting several refinements, such as using file transfers instead of pings, and computing a minimum regression
instead of an average regression. In addition, IGOD introduces a while loop that selects three dispersed land-
marks in an area where the server is located, which gets smaller until it reaches a small enough satisfactory size.
They showed that dispersed and closer landmarks gave more accurate results than more distant and randomly
chosen landmarks. In doing so, they significantly reduced the number of landmarks needed to estimate the
server's position compared to CBDG with greater accuracy.

In SPLITTER [12], the authors use a "double ring triangulation" to reduce the area in which the server
could be located, and they manage to reduce the uncertainty of an estimate, but they do not address common
issues like the risk of zero intersections.

In VLOC [13], the approach to server localization is reversed from previous solutions. Instead of performing
the audit from outside the server, they propose a method for each VM to perform the audit internally using
available landmarks. VLOC use web pages as landmarks with approximate positions due to low reliability of
IP databases [14]. DDR is defined by average delays of measurements with landmarks combined with a trust
coefficient to be specified.

The advantage of internal audit, as proposed by VLOC and our GeoFINDR approach, is the ability to localize
at the cloud instance level, while the external audit limits location to a single server instance or cloud PROXY.
Therefore, internal audit allows for better scalability and adaptation to cloud and multicloud requirements by
being able to verify the location of each VM instance in the cloud's backend and include in-cloud delays.

Note that the threat model differs from one approach to another, as shown in Table 1. CBDG, IGOD and
SPLITTER consider the economically rational CSP, i.e. a CSP that has an interest in moving data to cheaper
regions to operate and has no interest in having multiple copies of the same data for cost reasons. This model
is not realistic because a CSP can classically run multiple cloud instances, or make copies of them, and the
CSP can move them arbitrarily, which is referred to as the "dishonest CSP" model in the table. The difference
between VLOC and GeoFINDR threat model is that GeoFINDR considers a realistic dishonest CSP which can
use dark fibers, i.e. a faster private network between sites.

Note also that neither paper explains how to handle cases where the distance estimates have no intersections.
We believe that for unstable measurements such as network delays and inaccurate DDR, the probability of not
finding an intersection by multilateration is high and needs to be addressed to have an automated deployable
solution. GeoFINDR provides a solution to this problem thanks to the barycenter calculation (cf. Section 3.4).

## 3 Our GeoFINDR Approach

GeoFINDR is based on a realistic threat model and assumptions, which are presented in Section 3.1. GeoFINDR
proposes to improve the 3 key stages of delay-based geolocation solutions, namely: (1) the Greedy landmarks

<footnote n="2">²https://github.com/diasredi/GeoFINDR</footnote>
selection algorithm (cf. Section 3.2), which selects audit landmarks $LM_A$ in the vicinity of the declared area, (2) the sectorization (cf. Section 3.3) based on a new definition of the Distance-Delay Relation (DDR) and the selection of landmarks $LM_S$ with similar distance delay behavior as the VM, and (3) the estimation of the position with barycenter calculation (cf. Section 3.4).

<table><caption>Table 1: Comparative Delay-based Solutions including our GeoFINDR Approach</caption><thead><tr><th>Method</th><th>Audit type</th><th>Delay<sup>a</sup></th><th>Landmarks</th><th>Threat model</th><th>Contributions</th><th>Results</th></tr></thead><tbody><tr><td>CBDG [9]</td><td>external</td><td>internet</td><td>PlanetLab</td><td>economically<br>rational CSP</td><td>reference<br>method</td><td>median 166km<br>90% &lt;626km</td></tr><tr><td>IGOD [10]</td><td>external</td><td>total</td><td>PlanetLab</td><td>economically<br>rational CSP</td><td>reduce needed<br>LM amount</td><td>avg 88.5km</td></tr><tr><td>SPLITTER [12]</td><td>external</td><td>total</td><td>PlanetLab</td><td>economically<br>rational CSP</td><td>double ring<br>triangulation</td><td>best 30km<br>avg 139km</td></tr><tr><td>VLOC [13]</td><td>internal</td><td>total</td><td>Web sites</td><td>dishonest CSP</td><td>VM geolocation</td><td>best 150km</td></tr><tr><td><strong>GeoFINDR</strong></td><td><strong>internal</strong></td><td><strong>total</strong></td><td><strong>RIPE Atlas</strong></td><td><strong>realistic<br>dishonest CSP</strong></td><td><strong>VM geolocation</strong></td><td><strong>best 22.1km<br>avg 22.6km<sup>a</sup></strong></td></tr></tbody></table>

## 3.1 Realistic Threat Model and Assumptions

The considered threat model corresponds to the realistic dishonest CSP model presented in Section 2. That is, the CSP is inclined to lie about the declared location of the VM and has the following capabilities:

1. Total control and unlimited access to data and hardware in the cloud,

2. High performance architecture (dark fiber, cutting edge hardware, etc.),

3. Multicloud architecture (large scale cloud, subcontractor, etc.),

GeoFINDR also relies on the following assumptions to verify the location of the VM/cloud instance:

1. There is another machine with similar performance (DDR) to the VM that is connected to the Internet,

2. Delay measured from two Internet machines has a low variance in time,

3. Two machines on the same network with similar configuration and hardware will get the same RTT when pinging a third machine,

4. The cloud instance is a IaaS or PaaS that is connected to the Internet and able to run GeoFINDR,

5. The cloud instance is able to send and receive packets to/from the landmarks.

## 3.2 Greedy Audit Landmark Selection Algorithm

As reported in previous studies [10], dispersed and closer landmarks have better overall accuracy than more distant and undispersed landmarks. Therefore, there is a need for the maximum amount of available landmarks, with multiple positions around the world to maximize their density and dispersion. For technical purposes, landmarks need verified positions, continuous calculation of delays between them, transparent measurement data to derive DDR, a limited set of hardware configurations to minimize the variance of response delays between different landmarks (so position is more important), and a public IP address without PROXY to guarantee that we communicate only with the desired landmark. For all of these reasons, the landmarks of RIPE Atlas were chosen (see Section 4.1).

Once the size of $LM_A$ is specified as the $NB_LM$ parameter (cf. Table 2), which is the amount of audit landmarks required, we need to select distributed landmarks in an area of size $zone_size$ around the estimated location of the VM, as shown in Figure 3a. $NB_LM$ and $zone_size$ are input parameters to GeoFINDR. We start with a low value of $zone_size$ to reduce communication time and get better accuracy. If there are not enough landmarks in the area, we increase $zone_size$ until there are enough.

Landmark latitude and longitude coordinates can be described as points placed on a space, the Earth. The most dispersed points in a scatterplot are those that maximize the sum of their distances from each other.

<footnote><sup>a</sup>Total delay means Internet and in-cloud delay</footnote>

<footnote><sup>b</sup>Results of the tolerance experiment (Section 5) with parameters tolerance = 100, zone_size = 1000, NB_LM = 15, interval_percent = 15%</footnote>
To efficiently select dispersed landmarks, we implemented an original Greedy algorithm (see Algorithm 1) that selects dispersed points 1 called Dispoints with a $\theta(n \times m)$ complexity that is new to our knowledge. In addition to the great circle distance [15], used to compute the physical distance between two landmarks, we obtain an efficient way to obtain a deterministic set of dispersed landmarks, as shown in Figure 3b.

**Algorithm 1:** Greedy Algorithm to Select *n* Dispersed Points - Dispoints Code Available at https://github.com/diasredi/dispoints

**Data:** list of *n* points with coordinates, function *distance* to calculate a distance between 2 points, positive integer *m*

**Result:** list of *m* dispersed points *result*
*selected* ← list of *m* points;

for each point *p* in points do

nearest_point ← point from *selected* that minimizes its distance with *p*;

delete nearest_point from *selected*;

if sum of distances between *p* and all selected points > sum of distances between nearest_point and all selected points then

Append *p* to *selected*;

else

Append *nearest_point* to *selected*;

end

end

*result* ← *selected*;

## 3.3 DDR-based Sectorization Principle

The distance-delay relation (DDR) is the key component to get accurate estimations of the positions. If the DDR is inaccurate, the error will propagate to the position estimation and produce very large deviations.

Previous works generalize the DDR either with theoretical formulas or empirically by measuring delays between each landmark. However, for some landmarks, the generalized DDR is incorrect and leads to large deviations. Looking at the anchor measurements from RIPE Atlas, even with similar hardware and configurations, we find that distances can vary too much for a given measured RTT. For example, in Figure 1, for an RTT of about 20ms, the distances vary from 250 to 1100 km. This makes it unreasonable to construct the DDR by regression with acceptable error rates. Defining a unique DDR for each landmark or machine tested, results in too many errors and inaccuracies, demonstrating the need for a dynamic approach to define DDR based on each landmark.

<figure><img src="image_4.png" /><figcaption>Figure 1: Example of the Distance-delay Relations Distribution between a Landmark and all available Landmarks under 50ms</figcaption></figure>
GeoFINDR's intuition regarding DDR is the following one: since distances can vary so much for a given delay, and the "true" distance value for a delay is likely to be close to one of the measurements (to one or more landmarks), the question becomes "Which landmark has the closest DDR to my VM?". To find the most "similar" landmark, we have to make several measurements with other landmarks to infer it. A landmark with the exact same configuration and placement as our VM will have very close delays and distances with other landmarks.

GeoFINDR consists of finding a set $LM_S$ of similar landmarks that have close distance-delay behavior to our VM to infer a sector where the VM might be located, as shown in Figure 3c. Similar landmarks are found by measuring delays with the defined set $LM_A$ of audit landmarks, then landmarks with delays equal to our VM +/- *interval_percent* are selected, as shown in Figure 2. The similar landmarks, i.e. landmarks with close DDR, are the landmarks with the most occurrences between all measurements.

<figure><img src="image_5.png" /><figcaption>Figure 2: Example of GeoFINDR Operation to Determine a Set of $LM_S$ using the Distance-Delay Relations between a $LM_A$ and other Landmarks, based on the Measured Delay of 30ms with the VM</figcaption></figure>

## 3.4 Estimation of the Position

Ideally, similar landmarks of set $LM_S$ (cf. Section 3.3) should be close to the true position of our VM if there are enough landmarks nearby. However, similar landmarks may be too far away to define a satisfactory position. Therefore, we estimate the position of the VM by calculating the barycenter of all landmarks within $LM_S$ weighted by the delays measured between them and our VM. To solve the zero intersection problem identified in 2, we first consider multilateration as an optimization problem instead of an intersection [16]. The goal is to find the position that minimizes its squared distances with the circles drawn by the estimated distances around the landmarks. By dividing the square root of the squared distances, we obtain an indicator over the estimation's quality, the squared mean root error (SMRE), zero being a perfect intersection. To obtain the barycenter, we normalize the measured delays between each $LM_S$ and multiply them by the lowest distance that minimizes the given SMRE in previous step. The lowest distance obtained then allows us to deduce the optimal position, the barycenter, as shown in Figure 3d.

# 4 GeoFINDR Implementation

This section includes details on the choice of the RIPE Atlas landmark network, the resulting pseudocode, and the specifics of the Python implementation. The reader is invited to refer to the notations in Table 2 to better understand the pseudocode and related explanations.

## 4.1 RIPE Atlas Landmarks

Most implementations have used PlanetLab servers as landmarks. The problem is the relatively low density of available server locations on it's network, the high amount of different hardware configurations and the difficulty
<figure><img src="image_6.png" /><figcaption>Figure 3: Illustration of GeoFINDR Operations</figcaption></figure>

to implement permanent measurements.

For deployment in real use cases, we recommend to deploy a custom set of landmarks to have more control over each audit step. For this study, we used the RIPE Atlas network to demonstrate the validity of our approach.

We chose RIPE Atlas anchors as landmarks because of their limited hardware configurations, public IP addresses, worldwide presence with about 850 available anchors, open source permanent real-time measurements between anchors, and verified geographic location [18].

## 4.2 Pseudocode

The pseudocode of our GeoFINDR approach is provided in Algorithm 2, which refers to the three key steps described in Section 3, namely, the Greedy algorithm for selecting dispersed audit landmarks ($LM_A$), the DDR-based sectorization estimate to measure delays with audit landmarks and infer similar landmarks ($LM_S$), and the VM location estimate with the barycenter calculation. These steps are contained in a do-while loop that ends when the distance between the last sector coordinates and the previous one is less than *tolerance*. If both are close enough to end the loop, we consider the result to be "converged". It is necessary to define a threshold to end the loop because the estimates depend on measured delays, a very volatile value that can produce non-significant differences between two results that we consider satisfactory. If the solution doesn't converge, the main do-while loop allows us to redo the estimates by moving the initial search point to correct the estimate and thus obtain more accurate results.

## 4.3 Python Implementation

We use Python 3 to implement our model due to its large presence in scientific fields, high-level programming, wide compatibility across systems, and high number of libraries, including the RIPE Atlas library [19].

Measurements for the audit uses the ICMP ping protocol in IPv4, using the same amount of pings and payload as the RIPE Atlas measurements (3 pings and 64 bytes of payload by default). RTT includes in-cloud and Internet delay. The in-cloud delay is obtained by measuring the ping delay to the server's public IP address or PROXY and can be used to detect potential fraud, as we expect a low in-cloud delay for an honestly declared
**Data:** *declared_position*, *zone_size*, *tolerance*, *interval_percent*, *NB_LM* ≥ 1

**Result:** *estimated_position*

import landmarks;

sector coordinates ← declared_position;

do

initial_position ← sector coordinates;

near landmarks ← landmarks where distance(initial_position, landmark) < zone_size;

LM_A ← Dispoints(near landmarks, Distance(), NB_LM);

similars ← ∅;

for lm in LM_A do

measured_delay ← Ping(lm.ip);

add in *similars* landmarks with measured RTT from *lm* in

[measured_delay - interval_percent, measured_delay + interval_percent];

end

LM_S ← landmarks with maximum occurrences in *similars*;

measured_delays ← ∅;

for lm in LM_S do

add in *measured_delays* Ping(lm.ip).RTT;

end

distance_scale ← Normalize(measured_delays);

sector coordinates ← Barycenter(similar landmarks, distance scale);

while Distance(initial_position, sector coordinates) ≥ tolerance;

estimated_position ← sector coordinates;

position.

To estimate the location of the VM, we used the great circle distance function provided in [15] to calculate
the distance between two coordinates in kilometers using their real latitude and longitude.

5 Experimentations

The full methodology used in the experiments is described in Section 5.1, followed by several experiments presented in Sections 5.2 and 5.3.

5.1 Methodology

To test our method, we use a 64bit 8-core CPU @ 1.60GHz, 32Gb RAM, Linux kernel version 6.12.11-
200.fc41.x86_64 (64-bit) computer connected via a 1Gb/s link at the Telecom SudParis campus in Evry (25km
south of Paris). This machine plays the role of the VM in a datacenter that needs to be located in our experi-
ment. The advantage is that we have the environment completely under control, and we know its position and
the landmarks around. The aim is to have a fixed VM and fictitiously modify the surrounding environment (for
example, the number of landmarks available in the area).

Let's not lose sight of the fact that we want to show whether our GeoFINDR solution can reliably 1) detect a lie in the SLA's declared position and 2) find the true region of the datacenter from different declared positions in Europe and the world.

Our GeoFINDR algorithm (Algorithm 2) uses four setup parameters that users must configure: *tolerance*, *zone_size*, *NB_LM* and *interval_percent* (cf. Table 2). Each parameter changes the behavior of our solution and more or less affects the accuracy and the time to complete the audit.

To measure the impact of each parameter, we are able to calculate two accuracy metrics - the accuracy of estimation with distance_real_declared, and the ability to detect a lie with distance_estimation_declared - and two performance metrics: nb iterations and audit_time. Finally, our solution measures loopbackRTT and proxyRTT throughout the audit to give the user an estimation of the cloud instance's process time and in-cloud delay, respectively, by pinging the cloud's public IP address. All these features are defined in Table 2 with their associated implications.

The following experiments are conducted to better understand the behavior of GeoFINDR according to:

1. the **Setup Parameters** (cf. Section 5.2): after selecting an arbitrarily set of parameter values that give us satisfactory results for each declared position, i.e. tolerance = 100, zone_size = 200, NB_LM = 15 and
*interval_percent* = 15, we modify each one of them individually to observe its effect on the accuracy of the estimates (i.e. low average *distance_estimation_real*) and the performance (i.e. average time *audit_time* to complete the audit) of GeoFINDR, from a set of real and false declared positions.

2. **the Landmark Meshing** (cf. Section 5.3): after defining an optimal set of parameters from the previous experiment, i.e. *tolerance* = 100, *zone_size* = 1000, *NB_LM* = 16 and *interval_percent* = 35, we consider two mesh configurations simulating two landmark configurations: an area dense in landmarks (Paris area), and a less populated area by removing available landmarks in the Paris area to simulate a dead zone (rural or depopulated in landmarks area) to observe the influence of the landmark distribution on the estimates.

To measure the ability of GeoFINDR to detect a false declaration and find the true position of the cloud instance, we change for both experiments, the declared position from the true position to known capital cities around the world, i.e. 24 positions: Evry (true position), Amsterdam, Tirana, Andorra la Vella, Helsinki, Paris, Berlin, Budapest, Reykjavik, Rome, Warsaw, Lisbon, Moscow, Madrid, Stockholm, Bern, London, Torshavn, Tokyo, Melbourne, Dubai, Buenos Aires, Los Angeles, and Kinshasa.

We consider an estimation satisfactory if the distance between the estimated position and the true position is less than 50km. This is the size of the Paris area. In the case of a true declaration, we expect the estimated position of the VM to be close to the declared position. In the case of a low accuracy, the solution will still be able to detect a lie in the declared position if the distance between the estimated and declared positions is greater than the *tolerance*, the opposite would indicate that the method cannot detect a misleading declaration and is therefore vulnerable.

Note that in real use, the *true* position of the VM can't be inferred, hence the need to measure GeoFINDR's ability to recover accurate estimates in a controlled environment.

<table><caption>Table 2: GeoFINDR Setup Parameters, Notations and Metrics</caption><thead><tr><th>Type</th><th>Notation</th><th>Function</th><th>Implication</th></tr></thead><tbody><tr><td rowspan="4">setup parameters</td><td>tolerance</td><td>distance threshold between the last two estimated positions, used to terminate the audit</td><td>too low and the audit is longer; too high and the audit is inaccurate</td></tr><tr><td>zone_size</td><td>size of area to select LM<sub>A</sub>, augmented if not enough landmarks available</td><td>higher values allow measurements with additional landmarks, low impact on accuracy</td></tr><tr><td>NB_LM</td><td>size of the set LM<sub>A</sub></td><td>lower size increases the size of LM<sub>S</sub></td></tr><tr><td>interval_percent</td><td>tolerated deviation between measured delays to make up the set LM<sub>S</sub></td><td>higher values increases the size of LM<sub>S</sub></td></tr><tr><td>accuracy metrics</td><td>distance_A_B</td><td>distance in kilometers between positions A and B (declared, real or estimated)</td><td>distance_realDeclared measures the extent of the lie, distance_realEstimated is the accuracy, distance_estimatedDeclared is the lie estimation</td></tr><tr><td rowspan="2">performance metrics</td><td>nb iterations</td><td>number of iterations of the main loop until convergence performed by the algorithm</td><td>higher values means more measurements and estimations</td></tr><tr><td>audit_time</td><td>audit duration</td><td>higher values mean more time to estimate the position of the VM</td></tr><tr><td rowspan="2">in-cloud measurements</td><td>loopbackRTT</td><td>loopback address ping RTT</td><td>estimate VM's internal ping processing time, lower means lower VM capacity</td></tr><tr><td>proxyRTT</td><td>proxy's address ping RTT</td><td>estimate in-cloud delay, high value reflects complexity of flow routing within the CSP (e.g. dark fiber)</td></tr></tbody></table>

## 5.2 Impact of Setup Parameters

**zone_size.** We set the initial *zone_size*, the size of the area in which LM<sub>A</sub> are selected around the initial position, to 1, 50, 100, 250, 500, 750, 1000, 1500, 2000, 3000, 5000, 7500, 10000 and 15000 kilometers, respectively. Overall, we found that changing the initial *zone_size* has a small effect on accuracy, with only 3 out of 336 estimates giving more than 50km from the true position. For lower values of *zone_size*, *zone_size* is gradually increased until there are enough LM<sub>A</sub> inside, and higher values don't affect the accuracy, thus showing the
ability of GeoFINDR to estimate a sector even with more $LM_A$. However, the effect on the average audit time is up to 78.2s for very large values of *zone_size* due to higher RTT delays from distant $LM_A$, and the longer time to select the dispersed $LM_A$ due to the higher number of landmarks in the selection area. We recommend setting the initial *zone_size* to the size of the desired audit area to combine both a lower audit time and accurate estimates.

**interval_percent.** We set *interval_percent* to go from 5% to 105%, with a step of 10%. Increasing *interval_percent* increases the number of similar landmarks $LM_S$ for each measurement.

As shown in Figure 4, lower values give less accurate estimates because the *interval_percent* is too restrictive and many $LM_A$ do not lead to finding similar landmarks, which doesn't allow the most similar landmarks to be selected. Results are satisfactory from *interval_percent* = 15% to *interval_percent* = 95%, which shows that the selected $LM_S$ are in the desired region. However, increasing the amount of $LM_S$ has limitations. First, the probability of selecting a $LM_S$ outside the true region increases, which can lead to more errors: At *interval_percent* = 105%, two very distant $LM_S$ are chosen, which ruins the estimation with a 4250.6km error on average. Second, more $LM_S$ means more measurements to perform to determine the barycenter, which significantly increases the time required to complete the audit (from an average of 56s for *interval_percent* = 35% to an average of 102.6s for *interval_percent* = 105%).

In our experiment, the best result and the fastest audit time are obtained with *interval_percent* = 35% with an average *dist_estimation_real* = 25.8km and an average audit time of 56s.

<figure><img src="image_7.png" /><figcaption>Figure 4: Average Estimation Accuracy and Average Audit Time as a Function of *Interval Percent* (*tolerance* = 100, *zone_size* = 200, *NB_LM* = 15)</figcaption></figure>

**tolerance.** We set *tolerance* to 1, 10, 25, 50, 75, 100, 150, 200, 250, 300, 350, 400, 500, 750, 1000, 1500, 2000, 3000, 5000 and 10000 kilometers.

As can be seen in Figure 5, lower values of *tolerance* give satisfactory results up to *tolerance* = 250km. After that, the results become very inaccurate because higher values of *tolerance* prevent a proper correction of the estimates by leaving the main do-while loop (cf. Algorithm 2) too early, showing the necessity of such a correction mechanism. Likewise, audit time is reduced for higher *tolerance* values because fewer do-while loop iterations are realized. However, very low values of *tolerance* make the audit too long by executing superfluous do-while loop iterations that don't give more accurate results.

In our experiment, the best result is obtained for *tolerance* = 100km with an average *dist_estimation_real* = 22.6km and an average audit time of 49.8s, the lowest audit time among the satisfactory results (i.e. *tolerance* < 300).

<figure><img src="image_8.png" /><figcaption>Figure 5: Average Estimation Accuracy and Average Audit Time as a Function of *Tolerance* (*zone_size* = 200, *NB_LM* = 15 and *interval_percent* = 15)</figcaption></figure>
**NB_LM.** We set *NB_LM* to go from 1 to 25. From previous tests, we know that running the audit with every available landmark gives a satisfactory estimate, but is suboptimal in terms of performance.

As shown in Figure 6, higher values of *NB_LM* give more accurate estimates than lower values, but significantly increase the total audit time, because more *LM*<sub>A</sub> generally means less *LM*<sub>S</sub>. For smaller amounts of *LM*<sub>A</sub>, the amount of *LM*<sub>S</sub> is too high and can't be filtered due to the small sample size of measurements, leading to less accurate estimates. On the other hand, larger amounts of *LM*<sub>A</sub> require more measurements to be taken and processed for the audit, resulting in performance degradation.

In our experiment, the best result is obtained for *NB_LM* = 16 with an average *dist_estimation_real* = 22.1km and an average audit time of 67.7s. Although lower *NB_LM* are significantly faster to run and able to detect a lie in the region declaration, the estimates are too imprecise for our purposes.

<figure><img src="image_9.png" /><figcaption>Figure 6: Average Estimation Accuracy and Average Audit Time as a Function of NB_LM (*tolerance* = 100, *zone_size* = 200 and *interval_percent* = 15)</figcaption></figure>

## 5.3 Impact of Landmark Meshing Configurations

Since the available landmarks (e.g. RIPE Atlas) are unevenly distributed around the world and mostly concentrated in large urban areas, thus creating dead zones (e.g. areas without landmarks), the aim of these new experiments is to observe the influence of the landmark distribution on the accuracy and audit time of GeoFINDR. This will allow us to understand the sensitivity of the location estimation to the choice of *LM*<sub>S</sub>, and the sensitivity of the associated DDR to the proximity of *LM*<sub>S</sub> to the cloud instance.

In previous Section 5.2, experiments are conducted with nearby, densely populated landmarks in the Paris area, with the landmark distribution shown in Figure 7a, and, with the right set of parameters, GeoFINDR is shown to be able to estimate the true position of our machine, even in the case of incorrectly declared VM locations. In this section, we compare the results of GeoFINDR's ability to detect a lie, based on the set of declared false positions listed in Section 5.1, and to estimate the true location of an instance by considering two mesh configurations. The first mesh configuration considers the RIPE Atlas landmarks, including the landmarks of the Paris region (cf. Figure 7a) and the second one simulates the Paris area as a dead zone, by removing the landmarks in the Paris area from the list of available RIPE Atlas landmarks, as shown in Figure 7b. By removing all landmarks in the Paris area, our closest landmarks to the true Evry VM location are in the cities of Reims and Tours, which are respectively 135km and 185km away from our VM's position.

**With landmarks in the Paris area,** we obtain satisfactory estimations with an accuracy of 22.1km for 34.3s with a true declaration and an average of 22.4km for an average of 87.4s from the set of false declared positions, as shown in Table 3. In presence of multiple nearby landmarks, GeoFINDR is able to estimate the true position of the VM and thus reliably detect a false declared position.

**Without landmarks in the Paris area,** as expected, results are less accurate and audit times are longer, as shown in Table 3. We get an accuracy of 303.8km for 396.9s with a true declaration and an average accuracy of 164.3km for an average audit time of 244.1s with false declarations. Out of the 24 conducted audits, only 4 are satisfactory (accuracy below 50km) and identify the Paris area as the true location of our instance, and the worst result achieved an accuracy of 421.8km.

Even without landmarks in the Paris area, GeoFINDR is able to detect a lie in position declarations. In fact, we can compare the average lie extent, i.e. the difference between the falsely declared position and the true one, with the lie estimation, i.e. the distance between the declared position and the position estimate. The average lie extent in our experiment is of 3406.9km and we have an average lie estimation of 3445.3km, which is only a small difference of 1.1%. These results show that without nearby landmarks, GeoFINDR is still able to locate our instance in Western Europe, which corresponds to a continental scale estimate.

The drop in performance is thus explained by the inappropriate setup parameters used for continental level estimation. The setup parameters used aim to estimate the location of our instance at a city level, but the
<figure><img src="image_10.png" /><figcaption>(a) Mesh Configuration 1 - "Paris as a Landmark-Dense Zone", with all RIPE Atlas Western Europe Landmarks</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>(b) Mesh Configuration 2 - "Paris as a Dead Zone", where Paris Area Landmarks are Excluded from the RIPE Atlas Western Europe Landmarks List</figcaption></figure>

<caption>Figure 7: Mesh configurations with RIPE Atlas Western Europe Landmarks</caption>

lack of nearby landmarks changes the scale of GeoFINDR estimation accuracy. This causes the estimation to make a lot of measurements and do-while loop iterations because the solution cannot properly converge to a satisfactory solution.

This experiment demonstrates the impact of landmark distribution and the need to have nearby landmarks to get an accurate estimation. Thus, there is a need to correctly define the scale to which GeoFINDR can reliably estimate an instance's geolocation. Therefore, we recommend to set the *tolerance* parameter value to correspond to the size of the available nearby landmarks scale to avoid long audit times.

<caption>Table 3: Landmark Meshing Experiment Results</caption>

Setup parameters: tolerance = 100, zone_size = 1000, NB_LM = 16 and interval_percent = 35

<table><thead><tr><th rowspan="2">Declared positions</th><th colspan="4">With landmarks in Paris area</th><th colspan="3">Without landmarks in Paris area</th></tr><tr><th>Lie extent<sup>b</sup></th><th>Lie estimation<sup>c</sup></th><th>Accuracy</th><th>Audit time</th><th>Lie estimation<sup>c</sup></th><th>Accuracy</th><th>Audit time</th></tr></thead><tbody><tr><td>TRUE</td><td>0km</td><td>22.1km</td><td>22.1km</td><td>34.3s</td><td>303.8km</td><td>303.8km</td><td>396.9s</td></tr><tr><td>FALSE<sup>a</sup></td><td>3406.9km<br>σ = 4319.7km</td><td>3404.4km<br>σ = 4320.3km</td><td>22.4km<br>σ = 1.9km</td><td>87.4s<br>σ = 34.4km</td><td>3445.3km<br>σ = 4300.8km</td><td>164.3km<br>σ = 10km</td><td>244.1s<br>σ = 43.9km</td></tr></tbody></table>

# 6 Conclusion

Our proposed GeoFINDR approach is a practical software approach to geolocate multiple cloud instances by developing a program that runs from each cloud instance to determine its true location individually. To do this, we redefined and corrected several weaknesses in the key steps of similar work. We redefined the threat model to be more realistic with respect to the actual capabilities of a cloud service provider. We defined a two-step selection of landmark sets $LM_A$ and $LM_S$. The selection of $LM_A$ is performed by an original Greedy algorithm of dispersed points selection called Dispoints. RIPE Atlas anchors are used as landmarks for their real-time open source measurements and worldwide distribution. From $LM_A$, we find a set of $LM_S$ to derive the distance-delay relation and estimate the position of the instance using a method that calculates the barycenter of $LM_S$ to always determine a position.

By using the latest measurements from RIPE Atlas, the barycenter computation to derive the estimated position, and a do-while correction loop, GeoFINDR is able to reliably detect a lie in the CSP's declaration and obtain an average accuracy of 22.6km from multiple declared positions around the world. GeoFINDR's accuracy and audit time depends on a set of parameter values and the distribution of landmarks in the area of the instance's physical location. With good settings, GeoFINDR estimates the position of an instance in less than two minutes, which meets the need to verify the location of instances, to meet legal or security requirements. In the event of

<footnote><sup>a</sup>Values are averages calculated on the 23 false declarations only, σ is for the standard deviation; <sup>b</sup>distance_realDeclared; <sup>c</sup>distance_estimatedDeclared;</footnote>
a fraud in the instance's declared position, GeoFINDR provides all the data the customer needs to investigate, using in-cloud delays, quality metrics and estimated distances between declared and estimated positions.

GeoFINDR is a solution suitable for any distributed infrastructure that requires its cloud instances to be geolocated at a city or country scale, and where the required responsiveness meets current audit times. The source code and experiment results and outputs are available in the public GeoFINDR GitHub repository to ensure its continuity. However, further work is needed to evaluate the GeoFINDR capabilities with other fraud methods (e.g. use of dark fibers, VPN tunnel or tempering), to experiment from different real-world locations and infrastructures, and to reduce the audit time by multithreading the measurements to make our solution more robust and adapted to highly dynamic deployments.

The ability of customers to locate their resources in the cloud with reliability and transparency from CSPs still faces many challenges. However, we believe that GeoFINDR is a step towards building a cloud of trust.

## References

[1] Z. Hu, "How Data Localization Impacts Cybersecurity and Cloud Protection," Hillstone Networks. Accessed: Mar. 06, 2025. [Online]. Available: https://www.hillstonenet.com/blog/how-data-localization-impacts-cybersecurity-and-cloud-protection/

[2] J. Waldsmith, "Importance of Data Center Locations," LightWave Networks. Accessed: Mar. 06, 2025. [Online]. Available: https://www.lightwavenetworks.com/blog/importance-of-data-center-locations/

[3] D. A. S. GEORGE and A. S. H. GEORGE, "Potential Risk: Hosting Cloud Services Outside the Country," International Journal of Advanced Research in Computer and Communication Engineering, vol. 11, no. 4, pp. 5-11, Apr. 2022, doi: 10.5281/zenodo.6548114.

[4] H. Ursic, R. Nurullaev, M. O. Cuevas, and P. Szulewski, "Data localisation measures and their impacts on data science," in Research Handbook in Data Science and Law, Edward Elgar Publishing, 2018, pp. 322-353. Accessed: Mar. 06, 2025. [Online]. Available: https://www.elgaronline.com/edcollchap/edcoll/9781788111294/9781788111294.00021.xml

[5] "Regulation - 2016/679 - EN - gdpr - EUR-Lex." Accessed: Mar. 06, 2025. [Online]. Available: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng

[6] V. N. Padamanabban and L. Subramanian, "Determining the geographic location of Internet hosts," SIGMETRICS Perform. Eval. Rev., vol. 29, no. 1, pp. 324-325, Jun. 2001, doi: 10.1145/384268.378814.

[7] B. Gueye, A. Ziviani, M. Crovella, and S. Fdida, "Constraint-based geolocation of internet hosts," in Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, in IMC '04. New York, NY, USA: Association for Computing Machinery, Oct. 2004, pp. 288-293. doi: 10.1145/1028788.1028828.

[8] K. Benson, R. Dowsley, and H. Shacham, "Do you know where your cloud files are?," in Proceedings of the 3rd ACM workshop on Cloud computing security workshop, in CCSW '11. New York, NY, USA: Association for Computing Machinery, Oct. 2011, pp. 73-82. doi: 10.1145/2046660.2046677.

[9] M. Gondree and Z. N. J. Peterson, "Geolocation of data in the cloud," in Proceedings of the third ACM conference on Data and application security and privacy, in CODASPY '13. New York, NY, USA: Association for Computing Machinery, Feb. 2013, pp. 25-36. doi: 10.1145/2435349.2435353.

[10] C. Jaiswal and V. Kumar, "IGOD: identification of geolocation of cloud datacenters," Journal of Information Security and Applications, vol. 27-28, pp. 85-102, Apr. 2016, doi: 10.1016/j.jisa.2016.01.001.

[11] Y. Zhao, H. Yuan, T. Jiang, and X. Chen, "Secure distributed data geolocation scheme against location forgery attack," Journal of Information Security and Applications, vol. 47, pp. 50-58, Aug. 2019, doi: 10.1016/j.jisa.2019.04.003.

[12] Y. Zhang, D. Jia, S. Jia, L. Liu, and J. Lin, "Splitter: An Efficient Scheme to Determine the Geolocation of Cloud Data Publicly," in 2020 29th International Conference on Computer Communications and Networks (ICCCN), Aug. 2020, pp. 1-11. doi: 10.1109/ICCCN49398.2020.9209651.

[13] M. Eskandari, A. S. De Oliveira, and B. Crispo, "VLOC: An Approach to Verify the Physical Location of a Virtual Machine In Cloud," in 2014 IEEE 6th International Conference on Cloud Computing Technology and Science, Dec. 2014, pp. 86-94. doi: 10.1109/CloudCom.2014.47.
[14] M. Schopman, "Validating the accuracy of the MaxMind GeoLite2 City database", [Online]. Available: https://www.cs.ru.nl/bachelors-theses/2021/Mike_Schopman__1007619__Validating_the_accuracy_of_the_MaxMind_GeoLite2_City_database.pdf

[15] A. Zucconi, "Understanding Geographical Coordinates," Alan Zucconi. Accessed: Mar. 06, 2025. [Online]. Available: https://www.alanzucconi.com/2017/03/13/understanding-geographical-coordinates/

[16] A. Zucconi, "Positioning and Trilateration," Alan Zucconi. Accessed: Mar. 06, 2025. [Online]. Available: https://www.alanzucconi.com/2017/03/13/positioning-and-trilateration/

[17] "RIPE Atlas — RIPE Network Coordination Centre." Accessed: Mar. 06, 2025. [Online]. Available: https://www.ripe.net/analyse/internet-measurements/ripe-atlas/

[18] "Host an Anchor," RIPE Network Coordination Center. Accessed: Mar. 06, 2025. [Online]. Available: https://www.ripe.net/analyse/internet-measurements/ripe-atlas/host-an-anchor/

[19] "RIPE Atlas Cousteau — RIPE Atlas Cousteau 1.1 documentation." Accessed: Mar. 06, 2025. [Online]. Available: https://ripe-atlas-cousteau.readthedocs.io/en/latest/