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

[Lanlan Pan]

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 于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
, 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
，
Understanding the Privacy Implications of ECS
.
And In RFC7871(ECS) '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

> On Mar 17, 2017, at 6:57 PM, Lanlan Pan  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
>
> Any comments or suggestions will be appreciated.
>
> Regards.
>
> Yu Fu 于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.
>
> Your comments are appreciated.
>
> Thanks
> Lanlan & Yu
>
> >-Original Message-
> >From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> >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 po

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

[Paul Vixie]

On Monday, March 20, 2017 3:40:46 AM GMT Lanlan Pan wrote:
> 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.

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.

> 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".

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Lanlan Pan]

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.

Warren Kumari 于2017年3月18日周六 下午5:08写道：

> On Sat, Mar 18, 2017 at 2:57 AM, Lanlan Pan  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
>
>
>
>
> >
> > 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 于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.
> >>
> >> Your comments are appreciated.
> >>
> >> Thanks
> >> Lanlan & Yu
> >>
> >> >-Original Message-
> >> >From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> >> >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 orig

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

[Barry Raveendran Greene]

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  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
> 
> Any comments or suggestions will be appreciated.
> 
> Regards.
> 
> Yu Fu 于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.
> 
> Your comments are appreciated.
> 
> Thanks
> Lanlan & Yu
> 
> >-Original Message-
> >From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> >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
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> -- 
> 致礼  Best Regards
> 
> 潘蓝兰  Pan Lanlan
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Sat, Mar 18, 2017 at 2:57 AM, Lanlan Pan  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




>
> 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 于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.
>>
>> Your comments are appreciated.
>>
>> Thanks
>> Lanlan & Yu
>>
>> >-Original Message-
>> >From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>> >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
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> 致礼  Best Regards
>
> 潘蓝兰  Pan Lanlan
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop