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

[Lanlan Pan <[e-mail]>]

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 <[e-mail]>于2017年3月18日周六 下午5:08写道：

> On Sat, Mar 18, 2017 at 2:57 AM, Lanlan Pan <[e-mail]> 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 <[e-mail]>于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: [e-mail] [mailto:[e-mail]]
> >> >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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dnsop
> >
> > --
> > 致礼  Best Regards
> >
> > 潘蓝兰  Pan Lanlan
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > 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
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan