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

Lanlan Pan <abbypan@gmail.com> Wed, 22 March 2017 06:38 UTC

Return-Path: <abbypan@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6F112778E; Tue, 21 Mar 2017 23:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReT9JTbBRMYa; Tue, 21 Mar 2017 23:38:15 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722C2129450; Tue, 21 Mar 2017 23:38:15 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id g10so124224301wrg.2; Tue, 21 Mar 2017 23:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T3TQS/XfTuQuWCeu+O4SDIJ2IWEIBpr3ljOX443vVQo=; b=E+DE91nV5slhRJKx8XLkd2bAjrmSMMGvNpQyZ+BlXR2oFlVKgbwOJksgH8E0HH9x44 D1iK2yi6nQcEkAxfLhp+5vyVknslUqOdscp5LGsOk/klpyercUlk08Xi6QLlVgcvIyxo g/f/gsEERfjQQWmoM961pK0ZuE3z2TI+GVMhHNmdparBoyUhd2KOrU0Ew4ulE24ha00Y xxS2dkVDiwMHSGAaQjqpqu92tHofGgO8PFa4kXcQVrGup1ijWYjxIInCT88NKiWcNuBK 6Wf9cElFxqYdI8fhouryK85aIh1ajMu2Pg9TYbxsQVVPT0gbLrKkkjRORpHK/qj/7y/b Za9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T3TQS/XfTuQuWCeu+O4SDIJ2IWEIBpr3ljOX443vVQo=; b=P/0HjyA0kBzSM8jI5vCJdkH54E7V7XbM4rVQgAxE56hKmDWnbxpbJ1YHgEYFZ0ry25 ogf3vCVtFP2IIv1TQWaARQ4MzsWiEEsVIn7EDpGN0QElgSu3M8WA0tXuVF6ZwTtDzi+4 zqxbPMtKeaNH1tYjb1OGwHCWrH5akSrl5Ujff9igbTMTUbslSv9gB8RP7I9LUcjJp+q6 ozgzHf2VnKZ3ZxTmF9RcahR4Mf/dMDcWlvZV/RNsk2Av3pKCFdSNCSjvluzMc15Sa0QH 0k1QvqBC+tfZtKjAQmnUfZkULm6hK7ZQQiPzT8p7EgrAepLZz1/+h0iU1SOnHNhKx8tZ 2szQ==
X-Gm-Message-State: AFeK/H38TQY9ZiU15PJ+tjOsZlZZlqFoOicfPUuIiZgQOedQ6pUxkulSXdYGRB40xk+UtSHIbUWaegQR4qmTkg==
X-Received: by 10.223.165.17 with SMTP id i17mr36020103wrb.70.1490164693470; Tue, 21 Mar 2017 23:38:13 -0700 (PDT)
MIME-Version: 1.0
References: <000f01d29dfe$50b6b190$f22414b0$@cn> <CANLjSvXGO3rSpqb7hzwmV=vfm=UTHnQYqfBmt=uD9Mi8cL59Jg@mail.gmail.com> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <CANLjSvUJfU1cafGXHyg=DuCnhm09mBm5z4ve2_g6j2ONgt2tRQ@mail.gmail.com> <BBCEC002-D8D9-498E-8567-507181F9215E@develooper.com> <CANLjSvXA03qGN9TZ2oON7bJfygU7Uzor6H3ku83E_NhA3FBa7A@mail.gmail.com> <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com>
In-Reply-To: <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Wed, 22 Mar 2017 06:38:02 +0000
Message-ID: <CANLjSvWMYt1khfETApcW4Wt3aourPmhY-7Kz3Jrxjv4x89=3HA@mail.gmail.com>
To: Ask Bjørn Hansen <ask@develooper.com>
Cc: Barry Raveendran Greene <bgreene@senki.org>, dns-privacy@ietf.org, dnsop <dnsop@ietf.org>, "fuyu@cnnic.cn" <fuyu@cnnic.cn>
Content-Type: multipart/alternative; boundary="f403045f1fb0361314054b4c012c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7koKHTXxnXvcYYVRKyK99g0HFq0>
Subject: Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2017 06:38:18 -0000

Hi Ask,

Ask Bjørn Hansen <ask@develooper.com>于2017年3月22日周三 下午12:40写道:

>
> On Mar 21, 2017, at 21:30 , Lanlan Pan <abbypan@gmail.com> 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.
>
> 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.


> Ask
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan