Subject: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt

From: Lanlan Pan <[email-masked]>
Date: Mon, 17 Jul 2017 02:35:46 +0000

Hi all,

Following discussion on previous version draft,  we have some updates.

1) Focus on *GeoIP-enabled* Authoritative Nameserver:  Section-1
<https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-02#section-1>,
Appendix Geo-IP Example
<https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-02#section-10>
.

2) Clarify the difference between *path calculation* (Data Provider)
and *tailored
DNS response* (Authoritative Nameserver), which are offen obfuscated at CDN
scenario: Section-1.1
<https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-02#section-1.1>
.

Your comments are appreciated.

Regards,

Lanlan & Yu

---------- Forwarded message ---------
From: <[email-masked]>
Date: 2017年7月17日周一 上午9:55
Subject: New Version Notification for
draft-pan-dnsop-edns-isp-location-02.txt
To: Pan Lanlan <[email-masked]>, Yu Fu <[email-masked]>

A new version of I-D, draft-pan-dnsop-edns-isp-location-02.txt
has been successfully submitted by Lanlan Pan and posted to the
IETF repository.

Name:           draft-pan-dnsop-edns-isp-location
Revision:       02
Title:          ISP Location in DNS Queries
Document date:  2017-07-17
Group:          Individual Submission
Pages:          19
URL:
https://www.ietf.org/internet-drafts/draft-pan-dnsop-edns-isp-location-02.txt
Status:
https://datatracker.ietf.org/doc/draft-pan-dnsop-edns-isp-location/
Htmlized:
https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-pan-dnsop-edns-isp-location-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-pan-dnsop-edns-isp-location-02

Abstract:
   Nowadays, many Authoritative Nameservers support GeoIP feature, they
   guess the user's geolocation by the client subnet of EDNS Client
   Subnet (ECS) or by the source IP address of DNS query, return tailor
   DNS response based on the user's geolocation.  However, ECS raises
   some privacy concerns because it leaks client subnet information on
   the resolution path to the Authoritative Nameserver.

   This document is inspired by EDNS Client Subnet (ECS), describes an
   improved solution for GeoIP-enabled Authoritative Nameservers,
   defines an EDNS ISP Location (EIL) extension to address the privacy
   problem of ECS, tries to find the right balance between privacy
   improvement and user experience optimization.

   EIL is defined to convey isp location < COUNTRY, AREA, ISP >
   information that is relevant to the DNS message.  It will directly
   provide the same sufficient information for the GeoIP-enabled
   Authoritative Nameserver as ECS, to decide the response without
   guessing geolocation of the IP address.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 17 Jul 2017 05:01:52 -0400

Have you had any feedback from authority server implementers who are
interested in using this? 

I'm having a hard time picturing many CDNs wanting to switch, in no
small part because geo is not the only goal of mapping.  The
< COUNTRY, AREA, ISP > tuple that is defined is insufficient.

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 18 Jul 2017 06:41:51 +0000

Hi Dave,

Thanks for your feedback, :-)

> interested in using this?
We plan to contact authoritative server implementers and public recursive
implementers, for further realistic using, welcome cooperation.

> < COUNTRY, AREA, ISP > tuple that is defined is insufficient.
Not "switch to", but we can try to add *an alternative solution* for
GeoIP-enabled Authoritative Nameserver  *with user privacy concern*.
CDN can do all analysis based on client ip *without ECS and EIL*, because
it is data provider, every client will visit.

The < COUNTRY, AREA, ISP > tuple *can be sufficient for GeoIP-enabled
Authoritative Nameserver*, because the Authoritative Nameserver map client
ip into geolocation, and then return the tailored response based on
geolocation, such as  Appendix A. GeoIP-enabled Nameservers Example
<https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-02#section-10>
.

More details in  Section 1.1 Path Calculation and Tailored DNS Response
<https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-02#section-1.1>
.
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 28 Jul 2017 13:17:23 -0400

Hi,

> interested in using this? 

As an authority server implementer at a CDN -- we have no interest in
using anything like this.

> < COUNTRY, AREA, ISP > tuple that is defined is insufficient.

Yes, as has been made clear in previous discussion on this document.

Even if it were sufficient, using only a <COUNTRY, AREA, ISP> tuple to
direct traffic makes it incumbent on the resolver operator to accurately
geolocate the client IP and faithfully transmit the result to the
authoritative operator. If the resolver operator is an ISP, this
proposal would give the ISP an enormous amount of counter- traffic
engineering power by spoofing the COUNTRY/AREA fields.

-- 
Robert Edmonds

---

From: Lanlan Pan <[email-masked]>
Date: Mon, 31 Jul 2017 03:05:51 +0000

Hi Robert,

Thanks for your comments.

> using anything like this.
Fastly support  Creating location-based tagging
<https://docs.fastly.com/guides/vcl/creating-location-based-tagging> ,
offer HTTP header like Fastly-GeoIP-CountryCode for geographically
sensitive content, and Geolocation-related VCL features
<https://docs.fastly.com/guides/vcl/geolocation-related-vcl-features>.
Fastly has something like this, give tailor HTTP response based on client
ip's Geo Feature.

Hope you have interest to support something like this on DNS level in the
future, welcome cooperation, :-)

> Yes, as has been made clear in previous discussion on this document.
The "sufficient" vs "not sufficent" has repeat many times.
Seperate path calculation and tailor DNS response
<https://github.com/abbypan/dns_test_eil#path-calculation-and-tailored-dns-response>:
CDN can do all analysis based on client ip *without ECS and EIL*, because
it is data provider, every client will visit.
Geoip enabled ECS vs EIL
<https://github.com/abbypan/dns_test_eil#eil-is-sufficient-for-geoip-enabled-authoritative-nameserver>
: The < COUNTRY, AREA, ISP > tuple *can be sufficient for GeoIP-enabled
Authoritative Nameserver*.
See also 3 pictures in attach.

> authoritative operator.

For user privacy concern and realistic geoip-enabled authoritative server,
EIL can be an alternative feature, not many cost on geoip-enabled
authoritative server to add this feature.

Generally speaking, the global public dns, which make resolver's IP not
close to client's IP, is the origin of "response accurate problem". Their
GeoIP database's accuracy should be no less than authoritative service
providers.
With ECS, authoritative server incumbent to accurately geolocate the client
IP. Big company with huge number of users has advantage. EIL can be more
fairly for small company and third patry startup authoritative sevice if
they have less accuracy GeoIP database.

Common security concern, if resolver not "faithfully transmit the <COUNTRY,
AREA, ISP> tuple to the authoritative operator", would it "faithfully
transmit the client-subnet tuple to the authoritative operator" ?

If the resolver operator is an ISP, this
> engineering power by spoofing the COUNTRY/AREA fields.
ISP resolver (or all type resolvers) can redirect traffic because its key
position, between user and authoritative server.

Use the same logic, we can imagine that,  ECS can give the ISP an enormous
amount of counter- traffic
engineering power by spoofing the CLIENT-SUBNET fields.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan