Subject: [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

From: "Yu Fu" <[email-masked]>
Date: Thu, 16 Mar 2017 10:37:54 +0800

Hi all,

We have submitted a new draft as draft-pan-dnsop-edns-isp-location-00.
This document is an improved solution for ECS(RFC7871), describes an EDNS ISP Location (EIL) extension to address the privacy problem of ECS, find the right balance between privacy improvement and user experience optimization.  EIL is defined to convey ISP location information that is relevant to the DNS message.  It will provide sufficient information for the Authoritative Server to decide the response without guessing geolocation of the IP address.

Your comments are appreciated.

Thanks
Lanlan & Yu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Monday, March 13, 2017 6:07 PM
>To: Pan Lanlan; Lanlan Pan; Yu Fu
>Subject: New Version Notification for draft-pan-dnsop-edns-isp-location-00.txt
>
>
>A new version of I-D, draft-pan-dnsop-edns-isp-location-00.txt
>has been successfully submitted by Yu Fu and posted to the IETF repository.
>
>Name:		draft-pan-dnsop-edns-isp-location
>Revision:	00
>Title:		ISP Location in DNS Queries
>Document date:	2017-03-13
>Group:		Individual Submission
>Pages:		14
>URL:            https://www.ietf.org/internet-drafts/draft-pan-dnsop-edns-isp-location-00.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-00
>
>
>Abstract:
>   This document describes an Extension Mechanisms for DNS (EDNS0)
>   option that is in active use to carry information about the network
>   that originated a DNS query and the network for which the subsequent
>   response can be cached.
>
>   It is inspired by EDNS Client Subnet (ECS) with some privacy
>   considerations, goals to reduce the "guess geolocation of client's
>   IP" work on Authoritative Nameservers.

The IETF Secretariat

---

From: Lanlan Pan <[email-masked]>
Date: Sat, 18 Mar 2017 01:57:14 +0000

Hi all,

In NDSS 2017 DNS Privacy Workshop
<https://portal.sinodun.com/wiki/display/TDNS/DNS+Privacy+Workshop+@+NDSS+2017>,
I presented a EIL option as an alternative privacy improvement for ECS.

The paper and slide are attached.  Test code in github :
https://github.com/abbypan/dns_test_eil

Any comments or suggestions will be appreciated.

Regards.

Yu Fu <[email-masked]>于2017年3月16日周四 上午10:37写道：

Hi all,

We have submitted a new draft as draft-pan-dnsop-edns-isp-location-00.
This document is an improved solution for ECS(RFC7871), describes an EDNS
ISP Location (EIL) extension to address the privacy problem of ECS, find
the right balance between privacy improvement and user experience
optimization.  EIL is defined to convey ISP location information that is
relevant to the DNS message.  It will provide sufficient information for
the Authoritative Server to decide the response without guessing
geolocation of the IP address.

Thanks
Lanlan & Yu

>URL:
https://www.ietf.org/internet-drafts/draft-pan-dnsop-edns-isp-location-00.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-00

The IETF Secretariat

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Warren Kumari <[email-masked]>
Date: Sat, 18 Mar 2017 10:07:49 +0100

On Sat, Mar 18, 2017 at 2:57 AM, Lanlan Pan <[email-masked]> wrote:
> Hi all,
>
> In NDSS 2017 DNS Privacy Workshop, I presented a EIL option as an
> alternative privacy improvement for ECS.

Yes, and at NDSS I provided the following feedback (which perhaps you
misunderstood)

Much of the reason that CDNs (and similar) perform things like ECS /
geo-IP  is not because they want to know where the user physically is,
but because they want to provide the fastest, lowest latency
responses; physical topology is not the same as network topology...

RFC7871 makes this quite clear, for example:

Topologically Close:  Refers to two hosts being close in terms of the
      number of hops or the time it takes for a packet to travel from
      one host to the other.  The concept of topological distance is
      only loosely related to the concept of geographical distance: two
      geographically close hosts can still be very distant from a
      topological perspective, and two geographically distant hosts can
      be quite close on the network.

and wherever it talks about "close" it says things like "are
reasonably close in the topological sense" or "topologically close".

A pathological case is Fiji -- there are multiple ISPs, but very
little local peering (at least when I was last there) -- this means
that to get from one ISP to the other requires going down Southern
Cross, making a U-turn in Australia, and then going back up Southern
Cross.  Geolocating a user on one ISP to a cache in another ISP would
add an additional 2 trips across SC, or ~4,000miles, or 6,400KM.

A less pathological case is my home -- I'm right near Ashburn,
Virginia, USA (near Ashburn Equinix and many other datacenters), but
my "closest" (in terms of network topology) caches are in Atlanta, GA,
643miles away....

W

>> ISP Location (EIL) extension to address the privacy problem of ECS, find the
>> right balance between privacy improvement and user experience optimization.
>> EIL is defined to convey ISP location information that is relevant to the
>> DNS message.  It will provide sufficient information for the Authoritative
>> Server to decide the response without guessing geolocation of the IP
>> address.
>>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Barry Raveendran Greene <[email-masked]>
Date: Sat, 18 Mar 2017 11:22:35 -0700

Hello Yu Fu,

I was not at the workshop. Warren already mentioned some issues. I second what he is saying in a stronger terms:

+ What you are proposing has no value for optimizing content delivery on the Internet. Physical location and the topology of content delivery do not match. Also, Anycast is used. It is NOT expensive. The reason why so many CDN operator use DNS based tools for content delivery is granularity of action. An edge compute system (i.e. what many CDNs are) can do all sorts of checks via DNS approach vs an Anycast approach.

Also, the ECS security assessment if off. ECS from the resolver to the aDNS is sending a subnet configured by the operator of the rDNS. Once the connection to the client to the CDN is made, the CDN operator has the full details of the client. The term “leak client subnet to AUTH” is misleading from a “privacy risk.” Once the connection is made to my CDN, I know the IP specifics. 

+ What you are proposing has great value for Law Enforcement and State Security. It would cut out the Operator as the middle man and eliminate the need for a court order to release details on suspects. 

This also is a tool for criminals. I can easily see bad guys who are dropping ransomware use this as a tool to say “pay up or I’ll SWAT your house” or move from E-mail exertion threats to phone based threats. 

Barry

> On Mar 17, 2017, at 6:57 PM, Lanlan Pan <[email-masked]> wrote:
> 
> Hi all,
> 
> In NDSS 2017 DNS Privacy Workshop, I presented a EIL option as an alternative privacy improvement for ECS.
> 
> The paper and slide are attached.  Test code in github : https://github.com/abbypan/dns_test_eil
> 
> <Slide_EIL_Dealing_with_the_Privacy_Problem_of_ECS_PanLanlan.pdf><Paper_EIL_Dealing_with_the_Privacy_Problem_of_ECS.pdf>_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Lanlan Pan <[email-masked]>
Date: Mon, 20 Mar 2017 03:40:46 +0000

Hi Warren，

Obviously we all know that network topology is not equal to physical
topology.

To give "most precisely" for authoritative servers to decide most satisfied
"network topology", ECS use client subnet.

At NDSS there is a question that "why not directly use AS number" ? client
subnet can be maped into AS number, which is used for bgp route at network
topology.

My answer was that  AS4134 cover multiple provinces in china, from south
China to north China, 2000+ kilometers physical distance, also, with long
latency at network topology.

As the maxmind ip geo database showed in the slide, my key point is that,
the "country, province, isp" information can offer the same "network
topology" information like client subnet.

We tell Authorative servers that, "I want to know what is most satisfied ip
address for clients from CHINA, BEIJING, TELECOM at network topology".

But not "I want to know what is the nearest ip address for clients from
CHINA, BEIJING, TELECOM at physical topology".

Thanks Lanlan & Yu.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Mar 2017 06:26:11 +0000

> topology" information like client subnet.

three eyeball-sets in the city of san francisco might be reachable only 
through either los angeles, or else sacramento, or else salt lake city. 
congestion effects on the long haul links will loom larger than speed-of-
photons-in-fibre in the performance differences a CDN might measure if they 
served the same content to the same user from a data center in los angeles vs. 
sacramento vs. salt lake city.

> CHINA, BEIJING, TELECOM at physical topology".

in my example all three eyeball-sets have the same last-mile autnum.

nothing is reliably predictive of last mile performance, except prior 
experience serving similar content to the same client-subnet. estimating the 
client's subnet-size as /24 does some harm to accuracy. estimating it at /28 
does some harm to state-load and state-churn. but anyway you have to serve it 
before you know-- the routing table, the AS path, and the geo-loc are each 
nonpredictive, though each for different reasons.

i am not an ECS fan. far from it! but for what it purports to do, only the 
client's actual subnet will "work" in the live-fire exercise i call "home".

vixie

---

From: Lanlan Pan <[email-masked]>
Date: Mon, 20 Mar 2017 07:49:35 +0000

Hi Barry,

Thanks for your comments.

Because the draft discussed the DNS privacy problem of ECS, and was
first presented in In NDSS 2017 DNS Privacy Workshop, so I cc the
email to dprive WG.

Barry Raveendran Greene <[email-masked]>于2017年3月19日周日 上午2:22写道：

Hello Yu Fu,

I was not at the workshop. Warren already mentioned some issues. I second
what he is saying in a stronger terms:

+ What you are proposing has no value for optimizing content delivery on
the Internet. Physical location and the topology of content delivery do not
match. Also, Anycast is used. It is NOT expensive. The reason why so many
CDN operator use DNS based tools for content delivery is granularity of
action. An edge compute system (i.e. what many CDNs are) can do all sorts
of checks via DNS approach vs an Anycast approach.

Everyone has known that physical location and the topology of content
delivery DO NOT MATCH.
As last mail reply to Warren, my proposal can offer the SAME critical
information for authoritative server to make tailored response decision as
ECS's client subnet.
Because in database such as maxmind,  ECS (client subnet) can be map into
<AS number,  country, province, ISP>, which also guide network topology.
Therefore, if ECS has ANY value for optimizing content delivery on the
Internet, then EIL has.

For example，If ECS is tell AUTH :  the query is from 114.240.0.0/24. The
AUTH knows that ECS(114.240.0.0/24) is indicated (CHINA, BEIJING, UNICOM),
which is not only geolocation, but also contains network topology
information. Then AUTH can return satisfied ip address according to the
topology of content delivery.

For user privacy concern, we can revise  ECS(114.240.0.0/24) => EIL (CHINA,
BEIJING, UNICOM)，give a tradeoff between privacy and precise.

Also, the ECS security assessment if off. ECS from the resolver to the aDNS
is sending a subnet configured by the operator of the rDNS. Once the
connection to the client to the CDN is made, the CDN operator has the full
details of the client. The term “leak client subnet to AUTH” is misleading
from a “privacy risk.” Once the connection is made to my CDN, I know the IP
specifics.

Privacy risk of ECS:
1. If ECS is clear text in the resolution path => eavesdrop => encrypt the
dns traffic, in long term.
2. The passive DNS log analysis risk
   - avoid recursive dns analysis, reserve the optimization ECS, we can
send EIL query by some proxy tunnel.
   - avoid authoritative dns analysis. If CDN is ALSO the authoritative
server, AGREE WITH YOU. But to a third-party authoritative service, the
more domains publish their zones on the third-party authoritative server,
the more end user privacy information can be gathered by the authoritative
server according to the ECS queries from recursive.

ECS's security issue is described in DNS Privacy Workshop 2017 Background
<http://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017/dns-privacy-workshop-2017-call-papers>，
Understanding the Privacy Implications of ECS
<http://www.cc.gatech.edu/~ynadji3/docs/pubs/dimva16_ecs.pdf>.
And In RFC7871(ECS) <https://tools.ietf.org/html/rfc7871>'s abstract
section:

*Since it has some known operational and privacy shortcomings, a
revision will be worked through the IETF for improvement.*

+ What you are proposing has great value for Law Enforcement and State
Security. It would cut out the Operator as the middle man and eliminate the
need for a court order to release details on suspects.

This also is a tool for criminals. I can easily see bad guys who are
dropping ransomware use this as a tool to say “pay up or I’ll SWAT your
house” or move from E-mail exertion threats to phone based threats.

Barry

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Petr Špaček <[email-masked]>
Date: Mon, 20 Mar 2017 15:31:35 +0100

Hello,

On 20.3.2017 08:49, Lanlan Pan wrote:
> Because the draft discussed the DNS privacy problem of ECS, and was first presented in In NDSS 2017 DNS Privacy Workshop, so I cc the email to dprive WG.
> 
> 
> Barry Raveendran Greene <[email-masked] <mailto:[email-masked]>>于
> 2017年3月19日周日 上午2:22写道：
> 
>     Hello Yu Fu,
> 
>     I was not at the workshop. Warren already mentioned some issues. I
>     second what he is saying in a stronger terms:
> 
>     + What you are proposing has no value for optimizing content
>     delivery on the Internet. Physical location and the topology of
>     content delivery do not match. Also, Anycast is used. It is NOT
>     expensive. The reason why so many CDN operator use DNS based tools
>     for content delivery is granularity of action. An edge compute
>     system (i.e. what many CDNs are) can do all sorts of checks via DNS
>     approach vs an Anycast approach.
> 
>  
> information for authoritative server to make tailored response decision
> as ECS's client subnet.
> Because in database such as maxmind,  ECS (client subnet) can be map
> into <AS number,  country, province, ISP>, which also guide network
> topology.
> For example，If ECS is tell AUTH :  the query is from 114.240.0.0/24
> <http://114.240.0.0/24>. The AUTH knows that ECS(114.240.0.0/24
> <http://114.240.0.0/24>) is indicated (CHINA, BEIJING, UNICOM), which is
> not only geolocation, but also contains network topology information.
> Then AUTH can return satisfied ip address according to the topology of
> content delivery.

Thank you for this example, it helps.

> For user privacy concern, we can revise  ECS(114.240.0.0/24
> <http://114.240.0.0/24>) => EIL (CHINA, BEIJING, UNICOM)，give a
> tradeoff between privacy and precise.

Nice, this sounds like appropriate tradeoff to me.

Side-effect of this is that it removes need to maintain copies of
various Geo-IP databases all over the place, which is an improvement to
operational practice.

To sum it up, I support this. Nice work!

Petr Špaček  @  CZ.NIC

> ||||
>  
> 
> 
>     Also, the ECS security assessment if off. ECS from the resolver to
>     the aDNS is sending a subnet configured by the operator of the rDNS.
>     Once the connection to the client to the CDN is made, the CDN
>     operator has the full details of the client. The term “leak client
>     subnet to AUTH” is misleading from a “privacy risk.” Once the
>     connection is made to my CDN, I know the IP specifics. 
> 
> 
> Privacy risk of ECS:
> 1. If ECS is clear text in the resolution path => eavesdrop => encrypt
> the dns traffic, in long term.
> more domains publish their zones on the third-party authoritative
> server, the more end user privacy information can be gathered by the
> authoritative server according to the ECS queries from recursive.
> 
> <http://www.internetsociety.org/events/ndss-symposium/ndss-symposium-
> 2017/dns-privacy-workshop-2017-call-papers>， Understanding the Privacy
> Implications of ECS
> /Since it has some known operational and privacy shortcomings, a revision
> will be worked through the IETF for improvement./
> 
>  
> 
>     + What you are proposing has great value for Law Enforcement and
>     State Security. It would cut out the Operator as the middle man and
>     eliminate the need for a court order to release details on suspects.
> 
>     dropping ransomware use this as a tool to say “pay up or I’ll SWAT
>     your house” or move from E-mail exertion threats to phone based threats.
> 
>     Barry
> 
>     > On Mar 17, 2017, at 6:57 PM, Lanlan Pan <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hi all,
>     >
>     > Yu Fu <[email-masked] <mailto:[email-masked]>>于2017年3月16日周四 上
>     午10:37写道：
>     > Hi all,
>     >
>     > This document is an improved solution for ECS(RFC7871), describes
>     an EDNS ISP Location (EIL) extension to address the privacy problem
>     of ECS, find the right balance between privacy improvement and user
>     experience optimization.  EIL is defined to convey ISP location
>     information that is relevant to the DNS message.  It will provide
>     sufficient information for the Authoritative Server to decide the
>     response without guessing geolocation of the IP address.
>     >
>     > >From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>

---

From: Brian Hartvigsen <[email-masked]>
Date: Mon, 20 Mar 2017 13:34:02 -0600

> various Geo-IP databases all over the place, which is an improvement to

I disagree.  Unless you get the clients to implement EIL, then you’ve simply just pushed the need for geo-ip mapping from CDN to DNS provider.  Of course one would assume that an ISP already has this mapping, but 3rd party DNS would not.  So either they have to build the mappings,  maintain a copy of some Geo-IP database, or hope that all the clients have it implemented.  With 3rd party DNS carrying double digit percentages of traffic (iirc ~15% total from 2015 OARC presentation), that’s not something to just brush away.

— Brian

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 21 Mar 2017 05:28:44 +0000

Hi,

Thanks for Petr and Brian.

> various Geo-IP databases all over the place, which is an improvement to

I disagree.  Unless you get the clients to implement EIL, then you’ve
simply just pushed the need for geo-ip mapping from CDN to DNS provider.
Of course one would assume that an ISP already has this mapping, but 3rd
party DNS would not.  So either they have to build the mappings,  maintain
a copy of some Geo-IP database, or hope that all the clients have it
implemented.  With 3rd party DNS carrying double digit percentages of
traffic (iirc ~15% total from 2015 OARC presentation), that’s not something
to just brush away.

*AUTH*
ECS needs AUTH to do geo-ip mapping to decide most satisfied response.
There is Geo-IP database on the AUTH which is supporting ECS.  (ECS example
figures: Which CDNs support edns-client-subnet? )
<https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>
<https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>
Therefore, if AUTH support ECS, the AUTH can support EIL too.

*RECUR*
<https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>
Return to the origin smart-dns-resolution problem, there are two critical
factors that affect the response accuracy of authoritative server: (details
wrote in my *Paper
<https://drive.google.com/open?id=0B5gNT4RRJ0xPaG9nZ045VXRrZzg>*)
1) Is the resolver's IP address close to the client's IP address?
2) Is the IP geolocation database used by the authoritative server with
high quality?

Public recursive resolvers offer free DNS resolution services for global
users. But these servers are NOT CLOSE TO many users because the public
recursive service providers COULDN'T deploy servers in every country and
every ISP's network.
That is why public recursive service provider starved of ECS, which carried
client subnet to AUTH for geo-ip mapping.
Therefore, public recursive resolvers INCREASE the seperated distance of
client's IP and resolver's IP. Because on traditional ISP recurisve
resolver side, ISP are nearby the client's IP.

That is why I say the most recommend is P-Model, deploy EIL on public
recursive resolver, to partly lighten the burden of AUTH (as Petr pointed),
decrease the user privacy risk at PUB RECUR -> AUTH path.
EIL deploy on I-Model (ISP recursive resolver)  and L-Model (Local
forwarding resolver) is in long-term, the most realistic nowadays is the
P-Model (Public recursive resolver).

By the way，if 3rd party public recursive DNS are carrying double digit
percentages of traffic, there is a high probability that they have strong
technologies and rich resources to do geo-ip mapping for their client
queries.

— Brian

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Tue, 21 Mar 2017 01:11:04 -0700

> On Mar 20, 2017, at 0:49, Lanlan Pan <[email-masked]> wrote:
> 
> Everyone has known that physical location and the topology of content delivery DO NOT MATCH.
> As last mail reply to Warren, my proposal can offer the SAME critical information for authoritative server to make tailored response decision as ECS's client subnet.
> Because in database such as maxmind,  ECS (client subnet) can be map into <AS number,  country, province, ISP>, which also guide network topology.
> Therefore, if ECS has ANY value for optimizing content delivery on the Internet, then EIL has.
> 
> For example，If ECS is tell AUTH :  the query is from 114.240.0.0/24. The AUTH knows that ECS(114.240.0.0/24) is indicated (CHINA, BEIJING, UNICOM), which is not only geolocation, but also contains network topology information. Then AUTH can return satisfied ip address according to the topology of content delivery.

Except for very small networks, the network topology isn’t just the name of the provider. I suspect that if you took away all the geoip type lookups the larger content delivery systems would work fine; but if you did the opposite (what you are proposing with EIL) they would not.

I believe Netflix has public information about how their OpenConnect system uses BGP and network topology information.

Ask (speaking only for myself)

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 22 Mar 2017 04:30:40 +0000

Hi Ask，

Ask Bjørn Hansen <[email-masked]>于2017年3月21日周二 下午4:11写道：

> > For example，If ECS is tell AUTH :  the query is from 114.240.0.0/24.
> The AUTH knows that ECS(114.240.0.0/24) is indicated (CHINA, BEIJING,
> UNICOM), which is not only geolocation, but also contains network topology
> Except for very small networks, the network topology isn’t just the name
> of the provider. I suspect that if you took away all the geoip type lookups
> the larger content delivery systems would work fine; but if you did the
> opposite (what you are proposing with EIL) they would not.
>
> I believe Netflix has public information about how their OpenConnect
> system uses BGP and network topology information.
>

CDN providers configure their BGP with its AS neighbor, the network
topology optimization focus on, make their datacenters connect to more and
more important ISP (such as Level 3, Comcast, etc) , with faster and faster
connect speed.
Consider about DNS based delivery, as last mail I reply to brian, CDN can
work finer if resolver‘s IP nearby client’s IP.

See this example of ECS : Which CDNs support edns-client-subnet?
<https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>,
they *map the ECS client subnet into the geolocation (what EIL give)*, and
then make DNS decision. Because on AUTH side, they do not so care about
each client subnet, but configure on aerial view geolocation level. AUTH no
need configure for each client subnet, geoip-level precision check is offen
took for IP connect speed sample test.

Therefore, EIL <country, province, isp> can give the *SAME* *sufficent*
geolocation information as ECS for AUTH, to decide which is the best IP
addresses to response, because each CDN IP *serves many client subnets in
the same area*.

For example, all of these ECS can be map into*  EIL(CHINA, BEIJING, UNICOM)*

*: ECS(103.3.120.0/24 <http://103.3.120.0/24>), ECS(111.192.0.0/16
<http://111.192.0.0/16>),ECS(114.240.0.0/16 <http://114.240.0.0/16>),
ECS(120.132.0.0/16 <http://120.132.0.0/16>), ECS(123.112.0.0/16
<http://123.112.0.0/16>), ECS(124.64.0.0/16 <http://124.64.0.0/16>),
ECS(125.33.0.0/16 <http://125.33.0.0/16>), ECS(202.106.0.0/16
<http://202.106.0.0/16>), ECS(210.82.0.0/16 <http://210.82.0.0/16>),
ECS(219.158.128.0/24 <http://219.158.128.0/24>), ECS(221.216.0.0/16
<http://221.216.0.0/16>), ECS(222.128.0.0/16 <http://222.128.0.0/16>),
ECS(49.152.0.0/16 <http://49.152.0.0/16>), ECS(61.48.0.0/16
<http://61.48.0.0/16>),......*

致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Tue, 21 Mar 2017 21:40:12 -0700

> On Mar 21, 2017, at 21:30 , Lanlan Pan <[email-masked]> wrote:
> 
> See this example of ECS : Which CDNs support edns-client-subnet?  <https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>, they map the ECS client subnet into the geolocation (what EIL give), and then make DNS decision. Because on AUTH side, they do not so care about each client subnet, but configure on aerial view geolocation level

That’s a fundamental assumption of your proposal. What I’m offering (and I think what Warren said as well) is that it’s not true. The authoritative server will likely care as much or more about the subnet as it does the geo location.

The geo location only is fine for smaller networks or CDNs. Consider for example several pops in one city or region with differing peering connections in each pop.

Ask

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 22 Mar 2017 06:38:02 +0000

Hi Ask,

Ask Bjørn Hansen <[email-masked]>于2017年3月22日周三 下午12:40写道：

> they *map the ECS client subnet into the geolocation (what EIL give)*,
> and then make DNS decision. Because on AUTH side, they do not so care about
> each client subnet, but configure on aerial view geolocation level
>
>
> That’s a fundamental assumption of your proposal. What I’m offering (and I
> think what Warren said as well) is that it’s not true. The authoritative
> server will likely care as much or more about the subnet as it does the geo
> location.
>
> The geo location only is fine for smaller networks or CDNs. Consider for
> example several pops in one city or region with differing peering
> connections in each pop.
>
> First, I TOTALLY AGREE with you that there may be several pops in one city
or region with differing peering connections in each pop.

But, EIL has the *SAME fundamental assumption* of ECS. Because ECS is also
based on the map of  "*client subnet -> geolocation*" information.

So, imagine that,  AUTH gets the precise subnet, and then,  *what is the
accuracy of map the subnet into geolocation* ?

* 2) Is the IP geolocation database used by the authoritative server with
high quality?  ( details in my Paper
<https://drive.google.com/open?id=0B5gNT4RRJ0xPaG9nZ045VXRrZzg> )*

Most of time, AUTH's  geolocation database CAN NOT achieve this accuracy
level, expecially on foreign subnet: several pops in one city or region
with differing peering connections in each pop.
So, the point is ECS send the subnet to AUTH, and AUTH map the subnet into
EIL's aerial view geolocation, and then AUTH makes the DNS decision.

For example, some AUTH may use Maxmind IP geo database.
Maxmind can tell that a subnet is from CHINA, and distinguish Chinese TOP 5
ISP : TELECOM/UNICOM/MOBILE/EDUCATION/TIETONG.
But Maxmind can not distinguish different subnet peering connections in one
city, there are many small ISPs in China,  such as CHANGKUAN, GEHUA,
DIANXINTONG, JUYOU, YOUXIANTONG, etc...
Actually, when I was worked for Tencent, a local company which have
billions of clients at PC and Mobile in China, they DID NOT achieve this
accuracy level too.

However, if you know about the geolocation <COUNTRY, PROVINCE, ISP>,  you
can make a better response, most of time, is the best response too.

Moreover, IPv6 contains huge amount of subnet, the accuracy problem may be
even worse.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Mar 2017 01:00:02 -0700

Lanlan Pan wrote:
> ... Because ECS is
> also based on the map of  "*client subnet -> geolocation*" information.

wait, what?

-- 
P Vixie

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 22 Mar 2017 08:26:39 +0000

Hi Paul,

https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/

致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Mar 2017 03:54:44 -0700

Lanlan Pan wrote:
> ... Because ECS is also based on the map of
> "*client subnet -> geolocation*" information.

Paul Vixie <[email-masked]>于2017年3月22日周

> Hi Paul,

hi.

> https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/

this web page is factually incorrect in that it presupposes that geo-ip
is used. i have added a comment there to this effect.

the original ECS web site
(http://www.afasterinternet.com/howitworks.htm) is somewhat
marketing-oriented, but says only that "With this more intelligent
routing, customers will have a better Internet experience with lower
latency and faster speeds." in other words, it expects that a CDN will
apply its server-selection logic on an address basis, but using the
truncated client subnet rather than to the DNS request source address.
it does not dictate what the CDN's server-selection logic has to be or do.

in RFC 7871 (http://www.afasterinternet.com/ietfrfc.htm) we see this

there is an error on page 22 which is directly on-point:

>    o  Recursive Resolvers implementing ECS should only enable it in
>       deployments where it is expected to bring clear advantages to the
>       end users, such as when expecting clients from a variety of
>       networks or from a wide geographical area.  Due to the high cache
>       pressure introduced by ECS, the feature SHOULD be disabled in all
>       default configurations.

from context, it's clear that they meant "topological area".

actual CDN technology, from as far back as Cisco Distributed Director in
the mid-1990's, has usually ignored geography, for the reasons i gave
up-thread: overlapping and incoherent topology within a geo-ip region
means that geo-location is a very poor predictor of per-path performance.

let me state (again) for the record that i was and remain opposed to ECS
because it's an obviously bad idea and the apparent need for it merely
proves that Stupid DNS Tricks
(http://queue.acm.org/detail.cfm?id=1647302) did not and could not solve
their chosen problem in the first place. it's architectural
cost-shifting, which is a form of both intellectual conversion and
economic compulsion. sad!

however, if you're going to propose a replacement for ECS, you should
correctly describe how it works. <<Because ECS is also based on the map
of "*client subnet -> geolocation*">> is not a correct description. if
EIL is geo-based, then it is completely different from ECS.

-- 
P Vixie

---

From: Lanlan Pan <[email-masked]>
Date: Thu, 23 Mar 2017 07:31:57 +0000

Hi Paul,

Thanks for your comments and detail expatiation, :-)

*Why I think ECS is actually based on the map of " client subnet ->
geolocation (country, province, isp) " ? *

Of course, we all read RFC 7871, they said "Topologically Close" , not
"Geographically close".
Everyone know that geolocation is not precisely equal to realtime network
topology.

But, the duck test – "If it looks like a duck, swims like a duck, and
quacks like a duck, then it probably is a duck".
As last mail I replied to Ask, AUTH will not choose to detect network
topology connection speed with each subnet one by one, but summarized the
subnet into some critical information: AS Number, Country, Province, ISP
name. Most of time, AUTH will select some subnets for sample test, then,
configure by geolocation area.

I don't mean that AUTH decide response based on physical geolocation
distance. I mean that AUTH decide response base on *network topology
distance between the isp geolocation area.*
Imagine that,  www.xxxcdn.com  build two datacenter in (CHINA, SHANGHAI,
UNICOM), (CHINA, LIAONING, UNICOM)

   - physical distance: BEIJING - SHANGHAI  >  BEIJING - LIAONING
   - network topology distance: BEIJING - SHANGHAI <  BEIJING - LIAONING

the AUTH of www.xxxcdn.com  will return (CHINA, SHANGHAI, UNICOM) response
to the user from  (CHINA, BEIJING, UNICOM).

There are some examples:

1) Google Public DNS FAQ :
https://developers.google.com/speed/public-dns/faq#locations

In addition, Google Public DNS engineers have proposed a technical solution
called EDNS Client Subnet
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/>.
This proposal allows resolvers to pass in part of the client's IP address
(the first 24/64 bits or less for IPv4/IPv6 respectively) as the source IP
in the DNS message, so that name servers can return optimized results *based
on the user's location* rather than that of the resolver. To date, we have
deployed an implementation of the proposal for many large CDNs (including
Akamai) and Google properties. The majority of *geo-sensitive* domain names
are already covered.

2) Dyn’s ECS Implementation:
https://help.dyn.com/edns-client-subnet-faq-info/

When a DNS query is received by our nameservers, we analyze the query in
order to determine what response we provide. During this analysis, we will
notice if ECS information is provided and whether a Traffic Director
service will be involved in the response. If both is the case, we will *use
the ECS information for our geolocation lookup* instead of the source IP
address.
Once a geolocation is found and a response is selected, Traffic Director
will provide a DNS response back to the source IP address. As part of this
response we will include information via ECS regarding what subnet the
response should be cached for.

3) Amazon Route 53:
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html

To improve the accuracy of *geolocation routing*, Amazon Route 53 supports
the edns-client-subnet extension of EDNS0. (EDNS0 adds several optional
extensions to the DNS protocol.) Amazon Route 53 can use edns-client-subnet
only when DNS resolvers support it
When a browser or other viewer uses a DNS resolver that does support
edns-client-subnet, the DNS resolver sends Amazon Route 53 a truncated
version of the user's IP address. Amazon Route 53 *determines the location
of the user based on the truncated IP address* rather than the source IP
address of the DNS resolver; this typically provides a more accurate
estimate of the user's location. Amazon Route 53 then responds to
geolocation queries with the DNS record for the user's location.

4)  Gdnsd (an AUTH software) 's Geoip plugin, which support ECS:
https://github.com/gdnsd/gdnsd/wiki/GdnsdPluginGeoip
gdnsd-plugin-geoip uses MaxMind's GeoIP binary databases to map address and
CNAME results based on *geography* and monitored service availability. It
fully supports both IPv6 and the emerging edns-client-subnet standard.

*Is geolocation information good for CDN and DNS? *
In the mid-1990's, network resource is rare and uneven, network path is
inconsistent with geolocation. Therefore, in the mid-1990's, many network
operators usually ignored geography.
There was a popular sentence for Chinese network topology, decribed similar
condition: The distance between China Telecom and China Unicom, is much
longer than the distance between China Telecom and United State.

However, Internet grow up dramatically since 1990s. Nowadays, Internet is
critical information infrastructure, global network path connect every
where. Even into remote mountain village, information spread rapidly.
With internet network path connect every where, the aerial view network
topology distance improve like road path more and more.
CDN do best effort to make end user to visit the closest edge server,
consider about geolocation more and more. They call that geolocation
lookup, geolocation routing, geolocation delivery, and so on.

I AGREE WITH this sentence of your post :
*it has never been wise to assume that a DNS request's IP source address
gives any hint of an end-system Web browser's network location.*
This assumption is not correct in theopy, but the reality is that almost
all smart-auth-dns-resolution working based on this assumption.
So I support ECS's idea : give more precisely information to AUTH.

In the mid-1990's,  DNS is pure. Not work with CDN that contains 50+
datacenters to choose for dns response.
In the mid-1990's,  there is not public recursive resolver. Not increase
the distance between client ip and resolver ip.
Consider about these nowadays problem,  ECS is designed, partly change
traditional dns query, *give addtional subnet information for AUTH to make
a better decision*.
ECS can make DNS query & response more satisfied with nowadays content
delivery ( one domain -> multiple servers distributed in different location
datacenters ), if they don't deploy ip anycast.

Again, as I methioned above, AUTH actually use ECS subnet information
mapped into geolocation information, then make dns decision.

*Why I think EIL can make some revisions to ECS ? *
EIL : We tell Authorative servers that, "*I want to know what is most
satisfied ip address for clients from (CHINA, BEIJING, UNICOM) at network
topology distance*".  The (CHINA, BEIJING, UNICOM) is geolocation,  but
AUTH decide dns response by network topology distance between the
geolocation nodes.

   - *Privacy*:  The biggest privacy concern on ECS is that client subnet
   information is personally identifiable. EIL adjust the sensitive client
   subnet information to aerial view geolocation information for user privacy
   protection.

   - *Operation*:  In P-model (details in my *Paper
   <https://drive.google.com/open?id=0B5gNT4RRJ0xPaG9nZ045VXRrZzg>*), EIL
   move back the "guess geolocation of client’s IP" work from authoritative
   server to public recursive resolver, lighten the burden of authoritative
   server. Anyway, the origin of user latency problem is the public recursive
   service providers couldn't deploy servers in every country and every ISP's
   network.
   - *Cache Size*:  The cache size of ECS grows up with the number of
   client subnets. under future IPv6 environment, huge number of subnet,  the
   cache size of EIL will be smaller than ECS.

致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Barry Raveendran Greene <[email-masked]>
Date: Thu, 23 Mar 2017 11:06:35 -0700

> On Mar 21, 2017, at 11:38 PM, Lanlan Pan <[email-masked]> wrote:
> 
> However, if you know about the geolocation <COUNTRY, PROVINCE, ISP>,  you can make a better response, most of time, is the best response too.

Your statement is not matching the operational realities I live in. I understand how mapping is done in my current environment. I understand how it is done in many of my peer CDNs. I also understand the tools I would need to measure better path calculations. Everything is in IP, RIPs, FIBs, AS Patch, system load, content availability, etc. Knowing that it is in Palo Alto California is not something useful.

What is needed is the allocated IP block to start the mapping determination. Then every CDN does their “secret sauce” to delver the best customer experience. Geographic location is just not one of those factors. ECS delivers this now.

---

From: Lanlan Pan <[email-masked]>
Date: Fri, 24 Mar 2017 02:27:08 +0000

Hi Barry,

There are complex factors to optimize the datacenter connection of CDN.
I know every CDN need "Everything is in IP, RIPs, FIBs, AS Patch, system
load, content availability, etc." to measure better path calculations.
I understand that "Knowing that it is in Palo Alto California" is not
something useful for Data Provider path calculation, load balance
optimization, etc.
Note that, I *DON'T* mean that knowing <country, province, isp> is
sufficient for CDN.

But, as you methioned in last mail:
*        >  Once the connection to the client to the CDN is made, the CDN
operator has the full details of the client. *
CDN can known "Everything is in IP, RIPs, FIBs, AS Patch, system load,
content availability, etc." without ECS.
CDN can do the BGP optimization and datacenter load balance without ECS.

*Sperate the consideration of datacenter path calculation (Data Provider)
and dns response (AUTH).*

   - Data provider can make datacenter path calculation without ECS because
   all clients will connect.
   - ECS is help AUTH to return the satisfied dns response to client.

Therefore, the question is, *what can help AUTH to decide the response* ?
I mean that, most of time, knowing <country, province, isp> is sufficient
for AUTH make dns response.

My statement Is, for example:
the subnets (subnet_1 ... subnet_100) in the same <country, province, isp>
geolocation, always visit the same CDN datacenter sets (DC_1 .. DC_2) .
datacenter sets can be changed when network status is varied, network path
connection latency become larger, load balance adjustment, etc...
EIL is sufficient if AUTH make dns decison on <country, province, isp>
geolocation pricise level.

If your operational realities is:
subnet_1 ... subnet_100 in the same <country, province, isp> geolocation,
you apply subnet_1 ... subnet_50 visit DC_1, subnet_51 .. subnet_100 visit
DC_2
ECS is satisfied with your statement, because your AUTH make dns decision
down to subnet pricise level.

Barry Raveendran Greene <[email-masked]>于2017年3月24日周五 上午2:06写道：

> > However, if you know about the geolocation <COUNTRY, PROVINCE, ISP>,
> you can make a better response, most of time, is the best response too.
>
> Your statement is not matching the operational realities I live in. I
> understand how mapping is done in my current environment. I understand how
> it is done in many of my peer CDNs. I also understand the tools I would
> need to measure better path calculations. Everything is in IP, RIPs, FIBs,
> AS Patch, system load, content availability, etc. Knowing that it is in
> Palo Alto California is not something useful.
>
> What is needed is the allocated IP block to start the mapping
> determination. Then every CDN does their “secret sauce” to delver the best
> customer experience. Geographic location is just not one of those factors.
> ECS delivers this now.
>
>
>
>
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan