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

Lanlan Pan <abbypan@gmail.com> Mon, 20 March 2017 07:49 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 9AFC11200C1; Mon, 20 Mar 2017 00:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2bjDgh-PidEQ; Mon, 20 Mar 2017 00:49:48 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 8610C1296C3; Mon, 20 Mar 2017 00:49:47 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id n11so56339429wma.1; Mon, 20 Mar 2017 00:49:47 -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=fZ2V1k2v+WYW8xexhX9xugNHzHHC1etoL//frHigciI=; b=EPkkA6+RPOPJ2soajoN7Riya0y3TVKWqyyM1RlWKEPAxZ0g5T2YhdlVVQG53Z/aJxK 4/gyEeonUAnhzUCR0LRfDgKcTd0hbGDsYBJORK4kdP67aWTd1Ui3NsXsMGzjtHCyWA/1 UmQVInWoMzLa1Nl6DtmrJROh3Eub6ShM6OfoKPy9lZty606jOyUWR01jGV3Q3y8TSY5Z 5Pg+ajmM9TNgNvnT+ZTzsaapT2exybtmoKZ1ip+svgBYK2MnTtwo7VrSElPI9t6iQPKx 6G3q97KLOM+5dVXUZXsim+k89T/LEdITjXZR78wPlNzU/QNjKMQRN4M8zLeqLCM31tfJ MYlQ==
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=fZ2V1k2v+WYW8xexhX9xugNHzHHC1etoL//frHigciI=; b=IFeUIdKWFsz87T+ZtMOO5gUxqfA9KfLlRcboF2kqpsHybHsrlamR6qYtqXFAIiKdCv s6H3IofHFlTlp8kTsHdSURQEyP4RAkw2uFJoJbdxb5+TqlfP3eTxO2RAQaQ3cYG3gJOR /Jx+BRDImzWwD77+0rgI6XzorbA9u4B2oTzxXcylf8fSS0GUzZaijWZuiwRppLY6N8jB cjdO0YJyyVfk1uRXNOvGNdAGLfoAFBsTZsIKavq2vU4v4cg+3VarOo2DqFuBAmTpMUyF HaRMY0ARfgR0sv8pDdrbqvdyx0PbpSJGhqBoQzS6B/XfVqPR/cXuwgvTJ2COmmuju+wE ENdg==
X-Gm-Message-State: AFeK/H25QTOpHKOQUmTClBQTzgk7M42hQAeGuwIdjZ4wAg7ZPNMiCf6Q4nCN60Ui9BvB4aAiJ9u9U9iRPS1Vfw==
X-Received: by 10.28.210.133 with SMTP id j127mr8787584wmg.64.1489996186045; Mon, 20 Mar 2017 00:49:46 -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>
In-Reply-To: <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org>
From: Lanlan Pan <abbypan@gmail.com>
Date: Mon, 20 Mar 2017 07:49:35 +0000
Message-ID: <CANLjSvUJfU1cafGXHyg=DuCnhm09mBm5z4ve2_g6j2ONgt2tRQ@mail.gmail.com>
To: Barry Raveendran Greene <bgreene@senki.org>
Cc: dnsop <dnsop@ietf.org>, "fuyu@cnnic.cn" <fuyu@cnnic.cn>, dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="001a1147217662d382054b24c582"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Yy7y82W0y0O6PEzRlWPiAdDV594>
Subject: Re: [DNSOP] 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: Mon, 20 Mar 2017 07:49:57 -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 <bgreene@senki.org>于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

> On Mar 17, 2017, at 6:57 PM, Lanlan Pan <abbypan@gmail.com> 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 <fuyu@cnnic.cn>于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-drafts@ietf.org [mailto:internet-drafts@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
>
<Slide_EIL_Dealing_with_the_Privacy_Problem_of_ECS_PanLanlan.pdf><Paper_EIL_Dealing_with_the_Privacy_Problem_of_ECS.pdf>_______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan