Send geolocation feed tags instead of geohash?

[tfpauly]

One option we could consider for the client "region/location" hint is to share a geolocation feed tag instead of a geohash. This would be the format as described for IP geolocation feeds:

https://www.rfc-editor.org/rfc/rfc8805.html#name-geolocation-feed-individual

Examples from that doc include: SG,SG-01,Singapore US,US-AL,Alabaster

We could define the header to share this as Sec-CH-IP-Geo, which would be an sf-item of type String.

Which could expand as:

Sec-CH-IP-Geo = "US,US-AL,Alabaster"

The intent of this would be for the client to tell the server that it believes it knows the accurate mapping for its client IP, such that an origin server with an out-of-date or inaccurate geolocation feed doesn't do the wrong thing. This of course would not be a matter that could be used for access control or security, but it provides a hint that can be useful for localizing content and results without needing to share GPS coordinates.

This has an advantage over geohash in that it is more clearly tied to or derived from the client's public IP, and would be less likely to accidentally include information derived from GPS coordinates. It also presumably would not be exposing any new information that the server couldn't already infer from a properly updated geo IP database feed.

We could also include parameters associated with the value to point to which geo IP feed is authoritative for this mapping, such that an origin could go further and try to validate the mapping if it wants to make a trust decision based on the value. It could then compare the client's IP address, the header value, and the mapping in the geo IP feed, and if it trusts this feed provider, it would allow the action.

For example:

Sec-CH-IP-Geo = "SG,SG-01,Singapore"; feed="https://noc.ietf.org/geo/google.csv"

[tfpauly]

This is related to #156. @enygren what do you think?

[tfpauly]

We could also include a hash of the geofeed to handle changes.

[DavidSchinazi]

What's the purpose of including the feed here? We can't create a proof of relationship with a feed without some cryptographic binding.

[tfpauly]

@DavidSchinazi the feed, which would be optional, would be a way for a client to point to the feed that is authoritative for their IP-to-geo mapping.

For example, Private Relay publishes a geo IP feed. A client could say "hey website, I'm in US,US-AL,Alabaster, and if you want to check the IP address you see me coming from against a published feed, it's available here".

For these cases of proxying, it wouldn't say anything about the client's original IP address and real geolocation, but it would just make it very explicit that the client thinks that its public IP address is already indicating this location, and lets origins discover feeds.

In a way, it allows origins to not need relationships with third-party companies that maintain geo-IP feed aggregators — instead, you could get the "correct" list from the people who own IP address.

[DavidSchinazi]

From the client's perspective, I understand this: the client will be configured with a way to get the geo tag, and that configuration can also contain the feed URI.

From the server, I don't understand this. What does a server do with this information?

• if the server already knows about this feed (let's say it's in the server's list of known feeds) and the tags match, the server does nothing
• if the server already knows about this feed and the tags don't match, does the server ignore the tags?
• if the server doesn't know about this feed, what does it do? It shouldn't use it for other clients since the feed could be malicious or just wrong.

[tfpauly]

To note, we could certainly remove the feed bit, but I don't think it's harmful.

For the server behavior, I was imagining this:

• If the servers knows/accepts this feed, but has multiple conflicting entries for the IP address or subnet the client is on, it could use the feed in the hint from the client to recognize which feed is more authoritative. For example, a server could generally use some third-party geofeed service, but also trust the lists for things like private relay that directly publish. So the feed hint helps a server know which service to check against to verify.
• If the feed tag doesn't match, it may be an indication to a server that it's copy is out of date. It obviously can't go refetch a new copy of the feed every time a client sends a new hash, because that could be malicious, but it could trigger some refresh logic that is dampened.
• If the feed is unknown but starts becoming common, it could be flagged and the server administrators could discover that they should add the feed to the list (i.e., a new feed/service comes online).

[DavidSchinazi]

Thanks, that makes sense. I'm not sure we'd really need this feature, but it can see how it might be useful.

[tfpauly]

We should discuss the relationship with RFC 9092, also.

[tfpauly]

This change is now made: https://www.ietf.org/archive/id/draft-pauly-httpbis-geoip-hint-00.html