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

Barry Raveendran Greene <bgreene@senki.org> Sat, 18 March 2017 18:22 UTC

Return-Path: <bgreene@senki.org>
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 A522A1293E3 for <dnsop@ietfa.amsl.com>; Sat, 18 Mar 2017 11:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.696
X-Spam-Level:
X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no
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 9bpPDY7APnNx for <dnsop@ietfa.amsl.com>; Sat, 18 Mar 2017 11:22:44 -0700 (PDT)
Received: from smtp117.iad3a.emailsrvr.com (smtp117.iad3a.emailsrvr.com [173.203.187.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F6B1293EE for <dnsop@ietf.org>; Sat, 18 Mar 2017 11:22:42 -0700 (PDT)
Received: from smtp7.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 09D8F4E99; Sat, 18 Mar 2017 14:22:37 -0400 (EDT)
X-Auth-ID: bgreene@senki.org
Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 99C6E4E7D; Sat, 18 Mar 2017 14:22:36 -0400 (EDT)
X-Sender-Id: bgreene@senki.org
Received: from [172.30.81.120] ([UNAVAILABLE]. [23.79.235.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 18 Mar 2017 14:22:37 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Barry Raveendran Greene <bgreene@senki.org>
In-Reply-To: <CANLjSvXGO3rSpqb7hzwmV=vfm=UTHnQYqfBmt=uD9Mi8cL59Jg@mail.gmail.com>
Date: Sat, 18 Mar 2017 11:22:35 -0700
Cc: dnsop@ietf.org, "fuyu@cnnic.cn" <fuyu@cnnic.cn>
Content-Transfer-Encoding: quoted-printable
Message-Id: <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org>
References: <000f01d29dfe$50b6b190$f22414b0$@cn> <CANLjSvXGO3rSpqb7hzwmV=vfm=UTHnQYqfBmt=uD9Mi8cL59Jg@mail.gmail.com>
To: Lanlan Pan <abbypan@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Qlts4qGq2UITXUIxcjE3Fm1h5Lw>
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: Sat, 18 Mar 2017 18:22:47 -0000

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