Report from the IAB Workshop on IP Address Geolocation

1.1. About this workshop report content

This document is a report on the proceedings of the workshop. The views and positions documented in this report are expressed during the workshop by participants and do not necessarily reflect IAB's views and positions.¶

Furthermore, the content of the report comes from presentations given by workshop participants and notes taken during the discussions, without interpretation or validation. Thus, the content of this report follows the flow and dialogue of the workshop but does not attempt to capture a consensus.¶

3.1. Why is IP geolocation used?

Some of the identified use cases were focused on optimizations to user experience or network behavior, such as:¶

• Automatically choosing appropriate language or regional settings for content¶

• Providing relevant nearby content (for searches or serving advertisements)¶

• Optimizing network routes and server selection, generally used to optimize Content Delivery Network (CDNs)¶

For these use cases, errors in IP geolocation cause annoyance or performance issues, but are generally recoverable (the user can change the location or update their search).¶

Other use cases treat the accuracy of the IP geolocation as a more critical piece of information:¶

• Enforcing legal or compliance-related requirements¶

• Enforcing contractual requirements between corporations¶

• Providing information for disaster relief or law enforcement when other location signals are unavailable¶

IP geolocation is often not the only signal used to satisfy these use cases, but it is often used as an important piece of them.¶

All of these use cases are relying on IP geolocation being a passive and implicit signal, without explicit intent being communicated on network connections.¶

Details of some of these use cases are included below.¶

3.2. What are the current IP geolocation mechanisms?

Geofeeds are defined by [GEOFEED] as CSV-formatted mappings from IP address subnets to locations, by country/region and city. [RFC9632] additionally defines how to discover this data and to authenticate it using the Resource Public Key Infrastructure (RPKI).¶

Often, servers that are checking IP geolocation information are not directly consuming geofeed information, but instead use the services of one or more IP geolocation providers. These services provide not only a mapping from IP address to location, but add in other information, such as notions of IP address "reputation" (indicating if they think this IP address represents traffic from a human user, an automated bot, or a malicious attacker) or a categorization (indicating if an address is associated with proxied or VPN traffic).¶

IP geolocation providers use various signals to improve the accuracy of their mapping from IP address to location, and have notions of confidence in the validity of the mapping. The workshop noted that various providers won't necessarily agree on mappings; and, even when they do agree, that does not guarantee that the mapping is accurate. Additionally, the certainty around a location mapping is not something expressed in a standard format for geofeeds, so ambiguity is hidden.¶

The workshop discussion noted that current mechanisms generally assume that there is a single (generally stable) location associated with an IP address. This is flawed for various reasons: an associated location may change (as in cellular networks or satellite networks), and often there may be many users at different locations behind a single address.¶

3.3. What does IP geolocation mean?

One of the key points that was raised in discussion was that different use cases and different parties involved in using IP geolocation can have vastly different assumptions about what a particular IP-address-to-location mapping means. For any use case or deployment, a question needs to be asked: what is the claim being made about the IP geolocation mapping?¶

There are various possible interpretations of a mapping. The location could mean:¶

• The physical location of a user¶

• The location of a network egress¶

• The location of network infrastructure¶

• The regulatory jurisdiction associated with a network¶

Geofeeds provide mappings of IP addresses to locations, but they do not define any ontology to describe what these mappings are claiming.¶

4.1. Architectural issues

At an achitectural level, IP addresses are not designed to be indications of physical location. This point was brought up in many contexts. This underlying issue causes various problems:¶

• Geolocation effectiveness is reduced; accuracy issues often stem from the IP address being a poor indicator of location due to not having stable location or a one-to-one relationship with users.¶

• Privacy and lack of consent; the passive nature of looking at IP addresses and mapping them to locations means that users can have their location targeted without their knowledge, consent, or ability to opt out.¶

• Lack of support in standardization; IP geolocation is a very impactful part of deployment realities and heavily influences the experience users have, but changes to network protocols don't necessarily account for the impact on IP geolocation. This is seen in cases where deployments as varied as IPv6 address support on servers and privacy proxy systems all needed significant work and engagement with IP geolocation providers to ensure that user experiences still functioned.¶

• Assumptions about the usefulness of geolocation; physical location does not necessarily correspond to network topologies, so systems assuming that closer physical locations will be faster can be detrimental to network performance.¶

• Inconsistent effectiveness for security; IP geolocation is often used as an element of security or compliance checks, but often has errors and is hard to validate. It cannot be relied on for security properties, but ends up being used as such in some scenarios.¶

4.2. Geofeed gaps and inaccuracies

Many of the issues raised were concerned with specifics of geofeeds. These take various forms, such as details that cannot currently be expressed in geofeeds, or inaccurate content in feeds.¶

The issues raised include:¶

• Entries cannot express an address being mapped to multiple locations, or express varying levels of confidence in a location mapping¶

• Names of regions and cities may not be consistent across geofeeds (due to typos, different languages, etc.)¶

• Identities of regions and cities may vary or have problematic geopolitical nuances¶

• False specificity occurs when feeds map an address to a city, but the location associated with the address is much bigger than the city¶

• Geofeed entries may be blatantly incorrect due to staleness or intentional inaccuracies¶

• Geofeeds may be out of date or stale, without a time-to-live or refresh mechanism¶

Some of the biggest challenges for providing an accurate geofeed are in dealing with satellite networks or mobile networks using Carrier-Grade NATs (CGNAT). A client device may have a particular true location, but its traffic may exit to the internet via a gateway in a different region. Geo-locating the IP identifies the gateway, not the user, rendering the data coarse or misleading for hyper-local applications.¶

While country-level accuracy in geofeedds is generally high (estimated >95%), city-level or coordinate-level accuracy degrades significantly. Participants noted instances where IP geolocation defaults to the geographical center of a country or state when specific data is missing, creating "digital sinkholes" (e.g., a farm in Kansas mapped to millions of IP addresses).¶

4.3. Ecosystem issues

Some issues relate to the deployment and commercial realities of the IP geolocation ecosystem.¶

IP geolocation providers currently use differing proprietary formats and techniques. Methodologies for determining location are proprietary, and there is no standardized feedback loop for Internet Service Providers (ISPs) to correct erroneous data in third-party databases.¶

Additionally, updating the version of a IP geolocation database used by a server is asynchronous, and can be a manual process. When there is a major change, such as when an IP address block is transferred from an ISP in Asia to one in Europe, the addresses may remain "located" in Asia in some databases for weeks or months.¶

With IPv4 exhaustion, the secondary market for address space is active and exacerbates these problems. IP address blocks are frequently sold and moved globally. The "legacy" location data often sticks to these blocks in WHOIS registries or static datasets, leading to persistent misidentification of the new owners' locations.¶

4.4. Location-based issues

Assigning geolocation to addresses is fraught with issues around location borders. The discussion covered anecdotes of incorrect behavior that came from mobile devices being used near jurisdictional borders between two countries, where the device's IP geolocation could frequently "jump" between countries. Similarly, on borders between timezones, the correct behavior is often ambiguous if derived from IP addresses alone.¶

4.5. Privacy issues

As discussed in [RFC6973], IP addresses can be used as identifiers to correlate user activity and reveal user identity. IP addresses are often considered Personally Identifiable Information (PII), and the correlation to geolocation makes this very sensitive information that can be correlated to other metadata that identifies users.¶

The source IP addresses of a connection established by a client device working on behalf of a user does not come along with any specific consent for how the IP address will be used, and does not imply intent.¶

Virtual Private Networks (VPNs) or proxies (such as privacy proxies discussed in [RFC9614]) allow users to anonymize their specific IP addresses to avoid correlation. However, this can also come with a degredation in behavior by servers that rely on IP geolocation services to determine how to serve content. Sometimes VPNs or proxies intentionally obfuscate or change how the user is represented to IP geolocation providers; but other deployments of privacy services do use geofeeds to preserve the general user location to avoid user experience or compliance issues.¶

5.1. Why should IP geolocation change?

Various motivations for changing the status quo of the IP geolocation ecosystem were raised:¶

• Existing geofeeds have technical gaps that need addressing in order to scale well and continue to be used effectively¶

• New network deployments, such as satellite networks and privacy proxies, are stretching and challenging the status quo mechanisms¶

• Pressure from new policies or regulations add requirements for accurate assessment of client location, which IP addresses cannot always provide¶

• The bar for security and privacy is increasing, challenging the use of passive identifiers like IP addresses being used to tag location¶

These various motivations and pressures are often in conflict, and create requirements in different directions. Economic and regulatory incentives have shaped the status quo mechanisms, and will continue to shape the evolution of this space.¶

The technical community, and the various stakeholders in the ecosystem, play an important role in deciding how to handle these pressures and drive the change in the space of IP geolocation.¶

5.2. In what ways could IP geolocation change?

Two high-level categories of changes were discussed.¶

First, there are a number of ways in which geofeeds themselves can be improved:¶

• Add the ability to express infrastructure vs. user locations¶

• Get beyond the assumption that an IP address always maps to a single location¶

• Better handle the dynamic nature of geolocation (time-to-live indications, timestamps, live updates to feeds)¶

• More accurately represent the granularity and specificity of geolocation mappings; be able to express certainty levels¶

• Improve tooling for publishing, validating, and consuming geofeeds¶

• Improve measurements for determining accurate geolocation¶

• Rely more on the RPKI to more reliably verify location claims¶

Second, and more ambitiously, the community can consider alternative solutions to the use cases behind IP geolocation that do not rely on IP address mapping. [SZAMONEK], [LAOUAR], and [PAULY] propose various ways forward here. These explore ways to let users provide location hints with consent, and involve trying to provide explicit signals that involve trust and verifiability.¶

Across both of these categories, communicating information with more intentionality and clarity is a key change.¶

5.3. Considerations for future work

When looking toward future work, the workshop discussion raised some key points to consider:¶

• The community should work to explain clearly what geofeeds and IP geolocation are able to solve, and what problems they are ill-suited for.¶

• As new technologies are introduced (either updated geofeeds or new alternative mechanisms), there need to be clear plans for transitions and incremental adoption.¶

• New solutions need to avoid "ossification" and build in ways to continue to evolve and update.¶

• New solutions should be careful designed to avoid creating worse privacy problems. For example, a pressure to have explicit signals for location could lead to increased sharing of more specific user location coordinates (such as from GPS data).¶

• It is unlikely that any one new technical solution can address the various use cases that currently passively use IP geolocation. Different technical solutions will be fit for purpose for different use cases, and will not be one-size-fits-all.¶

5.4. Further work and consideration is needed

A final conclusion of the workshop was that collaboration and discussion amongst the various stakeholders in this space will be a necessary part of making technical improvements. Not all of the stakeholders in this space are currently actively participating in standards discussions within the IETF, but standards work would benefit from working on improvements in this space.¶

Some of the stakeholders include, but are not limited to:¶

• IP geolocation providers¶

• Client device platforms¶

• Content publishers¶

• Network operators¶

• Data brokers¶

• Enterprises¶

• Firewall operators and vendors¶

• VPN / proxy operators and vendors¶

• IP address leasers¶

• Policymakers¶

• End users¶

The exact shape of a forum for this community is not yet determined, but this report encourages further work and discussion in this space.¶