From nobody Fri Mar 3 09:37:27 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7681E129967; Fri, 3 Mar 2017 09:37:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Colin Perkins To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148856263248.10117.15594191397352700006.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 09:37:12 -0800 Archived-At: Cc: dns-privacy@ietf.org, ietf@ietf.org, draft-ietf-dprive-dtls-and-tls-profiles.all@ietf.org Subject: [dns-privacy] Review of draft-ietf-dprive-dtls-and-tls-profiles-08 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:37:12 -0000 Reviewer: Colin Perkins Review result: Ready with Nits I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Summary: Ready with nits The draft describe authentication mechanisms for DNS servers accessed via TLS and DTLS, and defines profiles for DNS clients and servers implementing DNS-over-TLS and DTLS. There seems little of transport concern here, since the draft refers to RFC 7858 and draft-ietf-dprive-dnsodtls to specify DNS over TLS and DTLS, and doesn't define such mechanisms itself, Similarly, the (D)TLS profile is a security profile, rather than transport-related changes. I just had a couple of nits: - The short title at the top of each page is “(D)TLS Authentication”. If there’s space, it'd be clearer if this was “(D)TLS Authentication for DNS”, or similar, to avoid confusion about what is being authenticated. - Section 9 mandates implementation of TLS session resumption without server-side state [RFC5077], TLS False Start, and the TLS Cached Information Extension. I can’t comment on the security implications, if any, but these extensions seem appropriate for reducing transport overheads. However, the recommendations in this draft seem inconsistent with those in RFC 7858 (e.g., RFC 7858 says "DNS servers SHOULD enable fast TLS session resumption [RFC5077], and this SHOULD be used when reestablishing connections" but this draft is "MUST implement"). It would help to align these, or mark this draft as updating the RFC. Colin From nobody Mon Mar 20 00:49:57 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@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> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> In-Reply-To: <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> From: Lanlan Pan Date: Mon, 20 Mar 2017 07:49:35 +0000 Message-ID: To: Barry Raveendran Greene Cc: dnsop , "fuyu@cnnic.cn" , dns-privacy@ietf.org Content-Type: multipart/alternative; boundary=001a1147217662d382054b24c582 Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 07:49:57 -0000 --001a1147217662d382054b24c582 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E4=BA=8E2017=E5=B9=B43=E6=9C=88= 19=E6=97=A5=E5=91=A8=E6=97=A5 =E4=B8=8A=E5=8D=882:22=E5=86=99=E9=81=93=EF= =BC=9A 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=EF=BC=8CIf 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) =3D> EIL (CHIN= A, BEIJING, UNICOM)=EF=BC=8Cgive 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 =E2=80=9Cleak client subnet to AUTH=E2=80= =9D is misleading from a =E2=80=9Cprivacy risk.=E2=80=9D Once the connection is made to my CD= N, I know the IP specifics. Privacy risk of ECS: 1. If ECS is clear text in the resolution path =3D> eavesdrop =3D> 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 =EF=BC=8C 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 =E2=80=9Cpay up or I=E2=80=99= ll SWAT your house=E2=80=9D 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 =E4=BA=8E2017=E5=B9=B43=E6=9C=8816=E6=97=A5=E5=91=A8= =E5=9B=9B =E4=B8=8A=E5=8D=8810:37=E5=86=99=E9=81=93=EF=BC=9A > 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.t= xt > >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 > -- > =E8=87=B4=E7=A4=BC Best Regards > > =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan > ______________________________= _________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a1147217662d382054b24c582 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Barry,

Thanks for you= r comments.

Because th=
e draft discussed the DNS privacy problem of ECS, and was first presented i=
n In NDSS 2017 DNS Privacy Workshop, so I cc the email to dprive WG.
<= /div>

Barry Raveendran Green= e <bgreene@senki.org>=E4=BA=8E2017=E5=B9=B43=E6=9C=8819=E6=97=A5= =E5=91=A8=E6=97=A5 =E4=B8=8A=E5=8D=882:22=E5=86=99=E9=81=93=EF=BC=9A
Hello Yu Fu,

I was not at the workshop. Warren already mentioned some issues. I second w= hat he is saying in a stronger terms:

+ What you are proposing has no value for optimizing content delivery on th= e Internet. Physical location and the topology of content delivery do not m= atch. Also, Anycast is used. It is NOT expensive. The reason why so many CD= N operator use DNS based tools for content delivery is granularity of actio= n. An edge compute system (i.e. what many CDNs are) can do all sorts of che= cks via DNS approach vs an Anycast approach.
=C2=A0
Everyone has known tha= t 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 respons= e decision as ECS's client subnet.
Because in da= tabase such as maxmind,=C2=A0 ECS (client subnet) can be map into <AS nu= mber,=C2=A0 country, province, ISP>, which also guide network topology.<= br class=3D"gmail_msg">Therefore, if ECS has ANY value for optimizing conte= nt delivery on the Internet, then EIL has.

For example=EF=BC=8CIf ECS is tell AUTH :=C2=A0 the query is= from 114.240.0.0/24. The AUTH knows that ECS(114.240.0.0/24) is indicate= d (CHINA, BEIJING, UNICOM), which is not only geolocation, but also contain= s network topology information. Then AUTH can return satisfied ip address a= ccording to the topology of content delivery.

For user privacy concern, we can revise=C2=A0 ECS(114.240.0.= 0/24) =3D> EIL (CHINA, BEIJING, UNICOM)=EF=BC=8Cgive a tradeoff betw= een privacy and precise.
<= /code>
=
=C2=A0

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 conne= ction to the client to the CDN is made, the CDN operator has the full detai= ls of the client. The term =E2=80=9Cleak client subnet to AUTH=E2=80=9D is = misleading from a =E2=80=9Cprivacy risk.=E2=80=9D Once the connection is ma= de to my CDN, I know the IP specifics.=C2=A0

Priv= acy risk of ECS:
1. I= f ECS is clear text in the resolution path =3D> eavesdrop =3D> encrypt the dns tra= ffic, in long term.
2. The = passive DNS log analysis risk
=C2=A0=C2=A0 - avoid recursive dns analysis, reserve the optimization EC= S, we can send EIL query by some proxy tunnel.
=C2=A0=C2=A0 - avoid authoritative dns analysis. If CDN= is ALSO the authoritative server, AGREE WITH YOU. But to a third-party aut= horitative service, the more domains publish their zones on the third-party= authoritative server, the more end user privacy information can be gathere= d by the authoritative server according to the ECS queries from recursive.<= br class=3D"gmail_msg">
ECS's security issue is described in DNS Priv= acy Workshop 2017 Background=EF=BC=8C Understanding the Privacy Implications of ECS.
And In RFC7871(ECS)'s abstract section:
Since it ha=
s some known operational and privacy shortcomings, a revision will be worke=
d through the IETF for improvement.
=
<= div class=3D"gmail_msg">
<= div class=3D"gmail_quote gmail_msg">
=C2=A0
+ What you are proposing has great value for Law Enforcement and State Secu= rity. It would cut out the Operator as the middle man and eliminate the nee= d for a court order to release details on suspects.

This also is a tool for criminals. I can easily see bad guys who are droppi= ng ransomware use this as a tool to say =E2=80=9Cpay up or I=E2=80=99ll SWA= T your house=E2=80=9D or move from E-mail exertion threats to phone based t= hreats.

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 alte= rnative privacy improvement for ECS.
>
> The paper and slide are attached.=C2=A0 Test code in github : https://github.com/abbypan/dns_test_eil
>
> Any comments or suggestions will be appreciated.
>
> Regards.
>
> Yu Fu <fuyu@cnnic.cn>=E4=BA=8E2017=E5=B9=B43=E6=9C=8816=E6=97= =A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5=8D=8810:37=E5=86=99=E9=81=93=EF=BC=9A > 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 E= DNS ISP Location (EIL) extension to address the privacy problem of ECS, fin= d the right balance between privacy improvement and user experience optimiz= ation.=C2=A0 EIL is defined to convey ISP location information that is rele= vant to the DNS message.=C2=A0 It will provide sufficient information for t= he 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-loc= ation-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 re= pository.
> >
> >Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-pan-dnsop-edns-isp-l= ocation
> >Revision:=C2=A0 =C2=A0 =C2=A0 00
> >Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ISP Location in DNS Querie= s
> >Document date: 2017-03-13
> >Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
> >Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A014
> >URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/= internet-drafts/draft-pan-dnsop-edns-isp-location-00.txt
> >Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft= -pan-dnsop-edns-isp-location/
> >Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-pan-dnsop-ed= ns-isp-location-00
> >
> >
> >Abstract:
> >=C2=A0 =C2=A0This document describes an Extension Mechanisms for D= NS (EDNS0)
> >=C2=A0 =C2=A0option that is in active use to carry information abo= ut the network
> >=C2=A0 =C2=A0that originated a DNS query and the network for which= the subsequent
> >=C2=A0 =C2=A0response can be cached.
> >
> >=C2=A0 =C2=A0It is inspired by EDNS Client Subnet (ECS) with some = privacy
> >=C2=A0 =C2=A0considerations, goals to reduce the "guess geolo= cation of client's
> >=C2=A0 =C2=A0IP" work on Authoritative Nameservers.
>
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/dnsop
> --
> =E8=87=B4=E7=A4=BC=C2=A0 Best Regards
>
> =E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 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/lis= tinfo/dnsop

-- =
=E8=87= =B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pa= n Lanlan
--001a1147217662d382054b24c582-- From nobody Mon Mar 20 07:31:48 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96C91314A1; Mon, 20 Mar 2017 07:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 wlmQTaDR-IY3; Mon, 20 Mar 2017 07:31:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D05313149F; Mon, 20 Mar 2017 07:31:38 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:9811:8ff:feef:6976] (unknown [IPv6:2001:1488:fffe:6:9811:8ff:feef:6976]) by mail.nic.cz (Postfix) with ESMTPSA id 5A37660183; Mon, 20 Mar 2017 15:31:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490020297; bh=9dwL3ErMjBuY7KcIPwoDefnmk66AYmxgkHrT/zQXVdw=; h=To:From:Date; b=PVG2dZYzAreOKQHYYCk0SSe9mWgfBtrVvGShCj9/5lS3HJqSC+yP98ihhk68+fxKn 1F2vttDM1ejmZQELEJTra8ltOzJyI9LEGEUndYbXQuTusHfzmEpclGiB/pDrMb7r29 mci6cFnOI3i7Xm7B5GhssjMvpKMqO7aVPRmQWIbc= To: Lanlan Pan , Barry Raveendran Greene References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> Cc: dns-privacy@ietf.org, dnsop , "fuyu@cnnic.cn" From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Mon, 20 Mar 2017 15:31:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:31:42 -0000 Hello, On 20.3.2017 08:49, Lanlan Pan wrote: > 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. Thank you for this example, it helps. > For user privacy concern, we can revise ECS(114.240.0.0/24 > ) => EIL (CHINA, BEIJING, UNICOM)，give a > tradeoff between privacy and precise. Nice, this sounds like appropriate tradeoff to me. Side-effect of this is that it removes need to maintain copies of various Geo-IP databases all over the place, which is an improvement to operational practice. To sum it up, I support this. Nice work! Petr Špaček @ CZ.NIC > |||| > > > > 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 > 2017/dns-privacy-workshop-2017-call-papers>， 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-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 > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > 致礼 Best Regards > > 潘蓝兰 Pan Lanlan From nobody Mon Mar 20 12:34:16 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0961294C1 for ; Mon, 20 Mar 2017 12:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opendns.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 eXKLyeeIXw0F for ; Mon, 20 Mar 2017 12:34:06 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 6E27F12951B for ; Mon, 20 Mar 2017 12:34:05 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id t143so16290970pgb.2 for ; Mon, 20 Mar 2017 12:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opendns.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o5E1eKJ8cVhenND3c7UuTt7OAmS4li6uO2N+YQ6j8hk=; b=X84FsEuLAQ5VbMk1NQ9a+92JvHpGeppDw6cwpO2xXpF7W+L/GhotsTZ9Gr7wL4XFkn doT92klsBVCfYxXYrVrI1O7Jzm5HbEfdv7i8N+pj9xODnPxGeNga1/RZxyW4GOQ417dd NnfE7f0FSpkiLR+TXbngas4MyNwz+xJPf/pAc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o5E1eKJ8cVhenND3c7UuTt7OAmS4li6uO2N+YQ6j8hk=; b=G07A+nhmPQJ15G0emXAGDKU2NFqy9XhL6iMP7Zpe23gQu2ActrkBn+AFJ3FDPrTQPM zmw8InNvHfwViU1EdRGQoEzXec1cyk7Pp6hlerNqAColEOk3c8EhTao3fNDmkc/49oaG AYaDwcAGizXpqRKtBXyy8F2taLPWvtHHiXGXL10/dQv4j+4IEgHLWpDQxBOoXtajvOOJ Ziqk1HIRLlgmvzYvNFZe3Gp+q9mTP8FgkGE6+H1w2LhMSO2y4UdmKPWuHRgaiIu6/Jmi zxrY+QkVPtcZRz5LPuD7xbKU+dgjVrqh2BeVT13BXNdJ+eibQzBlYIwYQ3yCDXAfT1Zl XYXA== X-Gm-Message-State: AFeK/H0HYz1PGrI6k2HuAY/prP0Tb2/rZzjJVY8orKcXsKD4+IS4cZQuFWCfyEfdmDqUSBHB X-Received: by 10.98.37.69 with SMTP id l66mr25425057pfl.156.1490038444980; Mon, 20 Mar 2017 12:34:04 -0700 (PDT) Received: from brians-air-2.local (24-116-170-61.cpe.cableone.net. [24.116.170.61]) by smtp.gmail.com with ESMTPSA id g27sm34793392pfk.95.2017.03.20.12.34.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 12:34:04 -0700 (PDT) From: Brian Hartvigsen Message-Id: <48FEB26B-8B76-4548-8F72-F907C81C65A6@opendns.com> Content-Type: multipart/signed; boundary="Apple-Mail=_853CB6D8-4E7F-4406-AE84-BE30EAF85171"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 20 Mar 2017 13:34:02 -0600 In-Reply-To: Cc: Lanlan Pan , Barry Raveendran Greene , "fuyu@cnnic.cn" , dns-privacy@ietf.org, dnsop To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:34:08 -0000 --Apple-Mail=_853CB6D8-4E7F-4406-AE84-BE30EAF85171 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> For user privacy concern, we can revise ECS(114.240.0.0/24 >> ) =3D> EIL (CHINA, BEIJING, UNICOM)=EF=BC=8Cgive= a >> tradeoff between privacy and precise. >=20 > Nice, this sounds like appropriate tradeoff to me. >=20 >=20 > Side-effect of this is that it removes need to maintain copies of > various Geo-IP databases all over the place, which is an improvement = to > operational practice. I disagree. Unless you get the clients to implement EIL, then you=E2=80=99= ve simply just pushed the need for geo-ip mapping from CDN to DNS = provider. Of course one would assume that an ISP already has this = mapping, but 3rd party DNS would not. So either they have to build the = mappings, maintain a copy of some Geo-IP database, or hope that all the = clients have it implemented. With 3rd party DNS carrying double digit = percentages of traffic (iirc ~15% total from 2015 OARC presentation), = that=E2=80=99s not something to just brush away. =E2=80=94 Brian --Apple-Mail=_853CB6D8-4E7F-4406-AE84-BE30EAF85171 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY0C6qAAoJEEbuoyCBJVvrkB4QAIbmgYGafeROqzPYUwkWunW4 8idzaiAzh1HH7vVjMiRbLEycFitaG4M6BiUybsZSOKy7IbykVRReuHslj+3A8qjF OpOPDw5UMlrN4InMWCqxuIOrsigRyN++wjU0uxObIz6mjBtBAdAzwPYlx6+n3/5l iKWtQcQvBBhoQoWd5ZGTkRUkKAw2zAfokl1rmE68eBkKqrhjlJ92Z8Vi2dwfIfa1 BNMYtEyYBd13lUZCKMmf3G2D4xpdsZHrRqOmhMpC3cYkgAOhbt2A1PcGDZJIrXLx y6LaNgD/lnto1TuyYh1rnXo45p7sZRxay8cfKmgtGP8aV93m7lgf+lIX4RDlLCvl gQre946DSGmTvngmJKw2oSud3zO+ZKaIOkt5vu1PmZJ+ZRafG8TiGp2aSpejxHih H6w4y169Xw1K4Y8k2OOGDCy1UoZVjEu8c5yQrcJzjAkAynZA/9YBpyKxsr+5PUKc 0UWGn4cziOiS9pzqiwHRpH515kg1/1/mtrLMBeHvZfDvGSS9cgSUWHSn58BMqu+f 7Zv+Kl+dEMeXvGSai6dd+oKdFEkckn1tEolkUAwZACtR+OUW8a4L8PCxSOgNKS42 8VzyvYcim1p5zo9CUtMuAChqnVlj8dCkC4sY8hfm1iobZ2IaTGFkdIazO2GRWOlp fUWQe+OKqfh3nTCemYLv =iBVE -----END PGP SIGNATURE----- --Apple-Mail=_853CB6D8-4E7F-4406-AE84-BE30EAF85171-- From nobody Mon Mar 20 22:29:07 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1C112947C; Mon, 20 Mar 2017 22:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2Qfi0HrTe5Ly; Mon, 20 Mar 2017 22:28:57 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 74B95129471; Mon, 20 Mar 2017 22:28:57 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id u48so104953311wrc.0; Mon, 20 Mar 2017 22:28:57 -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=YF740ceJ3Jkh/VF6a3GkV+RC4ICQQR/Vn3Hrp/y5V8w=; b=GW6/B4YLcJ2loE7GJGmRoNlk2+d/IGo/IEOgR0aRXhTtQkH6KCCEPKGH6fTWlNZlFb V7FUqJiXXND3neCizvYIEo2NUhTU21QIT8/HQeDsmNV2URjGMjbrawsyzgDMwEk7ibVQ kaddkm4idkBc4fC53ltx+63vDwUHeHJlmyREYCqIEpXZYoxAjVfTjHJj5ObGqsN75Bx5 ZYdHrj0/VHYTHgo1GF0TdEHtTHl5/X9fwEFAg8pnAON7dbIdlu1ii9TS/t3dO+qudter 7V1nCwI+wIQczGDhDHgssxeb4bC1N5XYYmBDgdvaKcvdAOxzHCYMIn4V+Hv0t8oTiyV/ eFCw== 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=YF740ceJ3Jkh/VF6a3GkV+RC4ICQQR/Vn3Hrp/y5V8w=; b=PogVcuzIGnwPjMBMeqFUh+MtOHXJe/fHh3HQMydrkrqtSloDlPBXOWubliBxG4yPHP cCTqPGcH1PtptfYbe97+BNH178225jJiR73w1NPqBEfkj/1jbSDbJdkO7O9gBtjeQ9MG yoTRxJb35riP35QZt7ZO3slE8GI6WkbwCPpK+w37/saWRKjg2FffqhvZiLNdHXOJz65V +Jwqt5b7paFgUXW+DoedW4/lJVKFxD2W7T0K+NErU1ubvpYsvZtx7nDaYHSWhHNZuZ9+ kggPxI0gUuTp49kaJYAW3eM43CxVRNRGBb0vtq78FaxHvBt166zBaNF2rwRew+ObD//B jxow== X-Gm-Message-State: AFeK/H2YRFlox0VQ1pddresZEfJ1AbMH6qq25fEjnvLmX1FH3pLPl5/F1xVkzC+jP97vw0LjecPfqIDMg1jahw== X-Received: by 10.223.160.115 with SMTP id l48mr31291536wrl.24.1490074135396; Mon, 20 Mar 2017 22:28:55 -0700 (PDT) MIME-Version: 1.0 References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <48FEB26B-8B76-4548-8F72-F907C81C65A6@opendns.com> In-Reply-To: <48FEB26B-8B76-4548-8F72-F907C81C65A6@opendns.com> From: Lanlan Pan Date: Tue, 21 Mar 2017 05:28:44 +0000 Message-ID: To: Brian Hartvigsen , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: Barry Raveendran Greene , "fuyu@cnnic.cn" , dns-privacy@ietf.org, dnsop Content-Type: multipart/alternative; boundary=94eb2c18513687866e054b36eb33 Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 05:29:00 -0000 --94eb2c18513687866e054b36eb33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for Petr and Brian. Brian Hartvigsen =E4=BA=8E2017=E5=B9=B43=E6=9C=882= 1=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8A=E5=8D=883:34=E5=86=99=E9=81=93=EF=BC= =9A >> For user privacy concern, we can revise ECS(114.240.0.0/24 >> ) =3D> EIL (CHINA, BEIJING, UNICOM)=EF=BC=8Cgive = a >> tradeoff between privacy and precise. > > Nice, this sounds like appropriate tradeoff to me. > > > Side-effect of this is that it removes need to maintain copies of > various Geo-IP databases all over the place, which is an improvement to > operational practice. I disagree. Unless you get the clients to implement EIL, then you=E2=80=99= ve simply just pushed the need for geo-ip mapping from CDN to DNS provider. Of course one would assume that an ISP already has this mapping, but 3rd party DNS would not. So either they have to build the mappings, maintain a copy of some Geo-IP database, or hope that all the clients have it implemented. With 3rd party DNS carrying double digit percentages of traffic (iirc ~15% total from 2015 OARC presentation), that=E2=80=99s not s= omething to just brush away. *AUTH* ECS needs AUTH to do geo-ip mapping to decide most satisfied response. There is Geo-IP database on the AUTH which is supporting ECS. (ECS example figures: Which CDNs support edns-client-subnet? ) Therefore, if AUTH support ECS, the AUTH can support EIL too. *RECUR* Return to the origin smart-dns-resolution problem, there are two critical factors that affect the response accuracy of authoritative server: (details wrote in my *Paper *) 1) Is the resolver's IP address close to the client's IP address? 2) Is the IP geolocation database used by the authoritative server with high quality? Public recursive resolvers offer free DNS resolution services for global users. But these servers are NOT CLOSE TO many users because the public recursive service providers COULDN'T deploy servers in every country and every ISP's network. That is why public recursive service provider starved of ECS, which carried client subnet to AUTH for geo-ip mapping. Therefore, public recursive resolvers INCREASE the seperated distance of client's IP and resolver's IP. Because on traditional ISP recurisve resolver side, ISP are nearby the client's IP. That is why I say the most recommend is P-Model, deploy EIL on public recursive resolver, to partly lighten the burden of AUTH (as Petr pointed), decrease the user privacy risk at PUB RECUR -> AUTH path. EIL deploy on I-Model (ISP recursive resolver) and L-Model (Local forwarding resolver) is in long-term, the most realistic nowadays is the P-Model (Public recursive resolver). By the way=EF=BC=8Cif 3rd party public recursive DNS are carrying double di= git percentages of traffic, there is a high probability that they have strong technologies and rich resources to do geo-ip mapping for their client queries. =E2=80=94 Brian --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c18513687866e054b36eb33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
=
Thanks for Petr and Brian.

Brian Hartvigsen <bhartvigsen@opendns.com>=E4=BA=8E2017= =E5=B9=B43=E6=9C=8821=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8A=E5=8D=883:34=E5= =86=99=E9=81=93=EF=BC=9A

>> For user privacy concern, we can revise=C2=A0 ECS(= 114.240.0.0/24
>> <http://114.240.0.0/24>) =3D> EIL (CH= INA, BEIJING, UNICOM)=EF=BC=8Cgive a
>> tradeoff between privacy and precise.
>
> Nice, this sounds like appropriate tradeoff to me.
>
>
> Side-effect of this is that it removes need to maintain copies of
> various Geo-IP databases all over the place, which is an improvement t= o
> operational practice.

I disagree.=C2=A0 Unless you get the clients to implement EIL, then you=E2= =80=99ve simply just pushed the need for geo-ip mapping from CDN to DNS pro= vider.=C2=A0 Of course one would assume that an ISP already has this mappin= g, but 3rd party DNS would not.=C2=A0 So either they have to build the mapp= ings,=C2=A0 maintain a copy of some Geo-IP database, or hope that all the c= lients have it implemented.=C2=A0 With 3rd party DNS carrying double digit = percentages of traffic (iirc ~15% total from 2015 OARC presentation), that= =E2=80=99s not something to just brush away.
AUTH
ECS needs AUTH to do geo-ip mapping to decide most satisfied response. The= re is Geo-IP database on the AUTH which is supporting ECS.=C2=A0 (ECS examp= le figures: Which CDNs support= edns-client-subnet? )
Therefore, if AUTH support ECS, the AUT= H can support EIL too.

RECUR
Return to the origin= smart-dns-resolution problem, there are two critical factors that affect t= he response accuracy of authoritative server: (details wrote in my Paper)
1) Is the resolver's IP address close to the client's IP add= ress?
2) Is the IP geolocation database used by the = authoritative server with high quality?

Public recursive resolvers offer free DNS resolution services f= or global users. But these servers are NOT CLOSE TO many users because the = public recursive service providers COULDN'T deploy servers in every cou= ntry and every ISP's network.
That is why publi= c recursive service provider starved of ECS, which carried client subnet to= AUTH for geo-ip mapping.
Therefore, public recursiv= e resolvers INCREASE the seperated distance of client's IP and resolver= 's IP. Because on traditional ISP recurisve resolver side, ISP are near= by the client's IP.

That is why I say the most recommend is P-Model,= deploy EIL on public recursive resolver, to partly lighten the burden of A= UTH (as Petr pointed), decrease the user privacy risk at PUB RECUR -> AU= TH path.
EIL deploy o= n I-Model (ISP recursive resolver)=C2=A0 and L-Model (Local forwarding reso= lver) is in long-term, the most realistic nowadays is the P-Model (Public r= ecursive resolver).
<= /div>

By the way=EF=BC=8Cif 3rd party public recursive DNS are carrying= double digit percentages of traffic, there is a high probability that they= have strong technologies and rich resources to do geo-ip mapping for their= client queries.
=C2=A0

=E2=80=94 Brian
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--94eb2c18513687866e054b36eb33-- From nobody Tue Mar 21 01:11:25 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502A9129671 for ; Tue, 21 Mar 2017 01:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 jArbL4UYMcyY for ; Tue, 21 Mar 2017 01:11:18 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by ietfa.amsl.com (Postfix) with ESMTP id B0CEC129672 for ; Tue, 21 Mar 2017 01:11:15 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id 22C90175EFE for ; Tue, 21 Mar 2017 01:11:14 -0700 (PDT) Received: (qmail 31120 invoked from network); 21 Mar 2017 08:11:13 -0000 Received: from c-67-188-112-34.hsd1.ca.comcast.net (HELO ?10.0.200.101?) (ask@mail.dev@67.188.112.34) by smtp.develooper.com with ESMTPA; 21 Mar 2017 08:11:13 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= In-Reply-To: Date: Tue, 21 Mar 2017 01:11:04 -0700 Cc: Barry Raveendran Greene , dns-privacy@ietf.org, dnsop , "fuyu@cnnic.cn" Content-Transfer-Encoding: quoted-printable Message-Id: References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> To: Lanlan Pan X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:11:19 -0000 > On Mar 20, 2017, at 0:49, Lanlan Pan wrote: >=20 > 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. >=20 > For example=EF=BC=8CIf 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. Except for very small networks, the network topology isn=E2=80=99t just = the name of the provider. I suspect that if you took away all the geoip = type lookups the larger content delivery systems would work fine; but if = you did the opposite (what you are proposing with EIL) they would not. I believe Netflix has public information about how their OpenConnect = system uses BGP and network topology information. Ask (speaking only for myself) From nobody Tue Mar 21 21:30:57 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8B1129451; Tue, 21 Mar 2017 21:30:55 -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 O913K2YuEinc; Tue, 21 Mar 2017 21:30:52 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 5B224127698; Tue, 21 Mar 2017 21:30:52 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n11so26284423wma.0; Tue, 21 Mar 2017 21:30:52 -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=sft3eQa2N9RRMfZiH1w/9iOqAlJp2fjv+7PrzEVKs68=; b=eSgXCFkOlqANvU0t7vM8xw42Zo2taRpSgPeJys6kHuekIpP9rSrALiTX4TtLyIjwZK 2/FPSzf1mnt51BPDsQ53LuTEKC8j3iJkE+KI3W0l5rwTCdP+GeAdTCm1+kZNLWKS3MVd y2l+8VwpKtdX5OG/nUmgIeUFw/xWcZnmpumRERC4JaIQYLr+B6Uagh8iYh2sTPq8AXa8 OsNWElIBUOLHo5JmSyRIGicS1YdQZsKwuxSqN/qscO8/SGO/4LvnfC0PaRhExae8S/9V uTrgW7e4Lryg1ZjIQj6+cmGBXczO9975SPlZ50X4FcC6NBKlXL1wd5hgoZCi1YwIsakc wG5Q== 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=sft3eQa2N9RRMfZiH1w/9iOqAlJp2fjv+7PrzEVKs68=; b=UjlLSeVh8dVoDn+6oPPpqCho3hoyQmY4LVovH6urgfcyLqp0lABKYOwSaBZZdjK2F1 IRFVnmjIPuNzgq4MVoJ/LWk3FRPDFZW63mbhTDpqZo3ifaHL3zmCtN9ykTyrs7dDVFho kpH8n7aSaOmtjwWBql0/pIiFl9xRWC2dFSildzwHkFZ3X+Y28oWTPCjOOGH9C96ez7MF MTctygi6KDyrYXAW8/o9AzKvqSCHdcp/lF9y3Q88haHKy2IeTm44RfYB7BCCOlZiaO28 DMlPoP8tr1deXcCQ+PTknW83EmNSNkDT3W3LLpvPqDFPeLJGYern/lKV87hrQT73STUc lTGg== X-Gm-Message-State: AFeK/H0zcsDujp44sxolD9R9WnCpPESnDHsBqN9oIHm3CSvUiZSI7/8WSHitdwEyyZtBvoC6nu6nDdDiCW2/fg== X-Received: by 10.28.128.147 with SMTP id b141mr5466460wmd.45.1490157050893; Tue, 21 Mar 2017 21:30:50 -0700 (PDT) MIME-Version: 1.0 References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> In-Reply-To: From: Lanlan Pan Date: Wed, 22 Mar 2017 04:30:40 +0000 Message-ID: To: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= Cc: Barry Raveendran Greene , dns-privacy@ietf.org, dnsop , "fuyu@cnnic.cn" Content-Type: multipart/alternative; boundary=001a1141e65aad9954054b4a39fa Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 04:30:56 -0000 --001a1141e65aad9954054b4a39fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ask=EF=BC=8C Ask Bj=C3=B8rn Hansen =E4=BA=8E2017=E5=B9=B43=E6=9C=882= 1=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=884:11=E5=86=99=E9=81=93=EF=BC= =9A > > > On Mar 20, 2017, at 0:49, Lanlan Pan wrote: > > > > 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 a= s > 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=EF=BC=8CIf 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 topolog= y > information. Then AUTH can return satisfied ip address according to the > topology of content delivery. > > Except for very small networks, the network topology isn=E2=80=99t just t= he name > of the provider. I suspect that if you took away all the geoip type looku= ps > the larger content delivery systems would work fine; but if you did the > opposite (what you are proposing with EIL) they would not. > > I believe Netflix has public information about how their OpenConnect > system uses BGP and network topology information. > CDN providers configure their BGP with its AS neighbor, the network topology optimization focus on, make their datacenters connect to more and more important ISP (such as Level 3, Comcast, etc) , with faster and faster connect speed. Consider about DNS based delivery, as last mail I reply to brian, CDN can work finer if resolver=E2=80=98s IP nearby client=E2=80=99s IP. See this example of ECS : 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. AUTH no need configure for each client subnet, geoip-level precision check is offen took for IP connect speed sample test. Therefore, EIL can give the *SAME* *sufficent* geolocation information as ECS for AUTH, to decide which is the best IP addresses to response, because each CDN IP *serves many client subnets in the same area*. For example, all of these ECS can be map into* EIL(CHINA, BEIJING, UNICOM)= * *: ECS(103.3.120.0/24 ), ECS(111.192.0.0/16 ),ECS(114.240.0.0/16 ), ECS(120.132.0.0/16 ), ECS(123.112.0.0/16 ), ECS(124.64.0.0/16 ), ECS(125.33.0.0/16 ), ECS(202.106.0.0/16 ), ECS(210.82.0.0/16 ), ECS(219.158.128.0/24 ), ECS(221.216.0.0/16 ), ECS(222.128.0.0/16 ), ECS(49.152.0.0/16 ), ECS(61.48.0.0/16 ),......* > > Ask (speaking only for myself) > > -- =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a1141e65aad9954054b4a39fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ask=EF=BC=8C

Ask Bj=C3=B8rn Hansen <ask@develooper.com>=E4=BA=8E2017=E5=B9=B43=E6=9C=8821=E6=97=A5=E5= =91=A8=E4=BA=8C =E4=B8=8B=E5=8D=884:11=E5=86=99=E9=81=93=EF=BC=9A
=

> On Mar 20, 2017, at 0:49, Lanlan Pan <abbypan@gmail.com> wro= te:
>
> 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,=C2=A0 ECS (client subnet) can be = map into <AS number,=C2=A0 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=EF=BC=8CIf ECS is tell AUTH :=C2=A0 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 g= eolocation, but also contains network topology information. Then AUTH can r= eturn satisfied ip address according to the topology of content delivery.
Except for very small networks, the network topology isn=E2=80=99t just the= name of the provider. I suspect that if you took away all the geoip type l= ookups the larger content delivery systems would work fine; but if you did = the opposite (what you are proposing with EIL) they would not.

I believe Netflix has public information about how their OpenConnect system= uses BGP and network topology information.

CDN providers configure their BGP with its AS neig= hbor, the network topology optimization focus on, make their datacenters co= nnect to more and more important ISP (such as Level 3, Comcast, etc) , with= faster and faster connect speed.=C2=A0
Consider about DNS b= ased delivery, as last mail I reply to brian, CDN can work finer if resolve= r=E2=80=98s IP nearby client=E2=80=99s IP.

See this example of ECS : Which CDNs support edns-client-subnet?<= font color=3D"rgb(0, 0, 0)"> , they map the ECS client subnet= into the geolocation (what EIL give), and then make DNS decision. Beca= use on AUTH side, they do not so care about each client subnet, but configu= re on aerial view geolocation level. AUTH no need configure for each client= subnet, geoip-level precision check is offen took for IP connect speed sam= ple test.

Therefore, EIL <country, province, isp> can gi= ve the SAME sufficent geolocation information as ECS for AUTH= , to decide which is the best IP addresses to response, because each CDN IP= serves many client subnets in the same area.

For examp= le, all of these ECS can be map into=C2=A0 EIL(CHINA, BEIJING, UNICOM):
ECS(103.3.120.0/24), ECS(<= a href=3D"http://111.192.0.0/16">111.192.0.0/16),ECS(114.240.0.0/16), ECS(= 120.132.0.0/16), ECS(123.112.0.0/16), ECS(124.64.0.0/16), ECS(125.33.0.0/16), ECS(202.106.0.0/16), ECS(210.82.0= .0/16), ECS(219.158.128.0/24), = ECS(221.216.0.0/16), ECS(222.128.0.0/16), ECS(49.152.0.0/16), ECS(61.48.0.0/16),
......
=C2=A0

Ask (speaking only for myself)

--001a1141e65aad9954054b4a39fa-- From nobody Tue Mar 21 21:40:38 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D7E120227 for ; Tue, 21 Mar 2017 21:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 nmxz9qEuHesq for ; Tue, 21 Mar 2017 21:40:28 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC81293FB for ; Tue, 21 Mar 2017 21:40:28 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id C6D18175EEB for ; Tue, 21 Mar 2017 21:40:27 -0700 (PDT) Received: (qmail 816 invoked from network); 22 Mar 2017 04:40:25 -0000 Received: from unknown (HELO ?17.149.229.239?) (ask@mail.dev@17.149.229.239) by smtp.develooper.com with ESMTPA; 22 Mar 2017 04:40:25 -0000 From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= Message-Id: <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_983BC0F9-46DD-42A5-9443-A2D5D6D55D47" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 21 Mar 2017 21:40:12 -0700 In-Reply-To: Cc: Barry Raveendran Greene , dns-privacy@ietf.org, dnsop , "fuyu@cnnic.cn" To: Lanlan Pan References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 04:40:31 -0000 --Apple-Mail=_983BC0F9-46DD-42A5-9443-A2D5D6D55D47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 21, 2017, at 21:30 , Lanlan Pan wrote: >=20 > See this example of ECS : Which CDNs support edns-client-subnet?=C2=A0 = , = 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=E2=80=99s a fundamental assumption of your proposal. What I=E2=80=99m= offering (and I think what Warren said as well) is that it=E2=80=99s = 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. Ask= --Apple-Mail=_983BC0F9-46DD-42A5-9443-A2D5D6D55D47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 21, 2017, at 21:30 , Lanlan Pan <abbypan@gmail.com> = wrote:

See this example of ECS : 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=E2=80=99s a = fundamental assumption of your proposal. What I=E2=80=99m offering (and = I think what Warren said as well) is that it=E2=80=99s 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.


Ask
= --Apple-Mail=_983BC0F9-46DD-42A5-9443-A2D5D6D55D47-- From nobody Tue Mar 21 23:38:19 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@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> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> In-Reply-To: <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> From: Lanlan Pan Date: Wed, 22 Mar 2017 06:38:02 +0000 Message-ID: To: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= Cc: Barry Raveendran Greene , dns-privacy@ietf.org, dnsop , "fuyu@cnnic.cn" Content-Type: multipart/alternative; boundary=f403045f1fb0361314054b4c012c Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 06:38:18 -0000 --f403045f1fb0361314054b4c012c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ask, Ask Bj=C3=B8rn Hansen =E4=BA=8E2017=E5=B9=B43=E6=9C=882= 2=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=8812:40=E5=86=99=E9=81=93=EF= =BC=9A > > On Mar 21, 2017, at 21:30 , Lanlan Pan wrote: > > See this example of ECS : 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 abo= ut > each client subnet, but configure on aerial view geolocation level > > > That=E2=80=99s a fundamental assumption of your proposal. What I=E2=80=99= m offering (and I > think what Warren said as well) is that it=E2=80=99s not true. The author= itative > server will likely care as much or more about the subnet as it does the g= eo > 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 cit= y 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 )* 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 , 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 > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045f1fb0361314054b4c012c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ask,

Ask Bj=C3=B8rn Hansen <as= k@develooper.com>=E4=BA=8E2017=E5=B9=B43=E6=9C=8822=E6=97=A5=E5=91= =A8=E4=B8=89 =E4=B8=8B=E5=8D=8812:40=E5=86=99=E9=81=93=EF=BC=9A

On Mar 21, 2017, at = 21:30 , Lanlan Pan <abbypan@gmail.com> wrote:

See this example of ECS :=C2=A0Which CDNs support edns-client-subnet?=C2=A0, they=C2=A0map the ECS client subnet into the geolocation (what EIL give), and then m= ake DNS decision. Because on AUTH side, they do not so care about each clie= nt subnet, but configure on aerial view geolocation level

=
That=E2=80=99s a fundamental assumption of your proposal. What I=E2= =80=99m offering (and I think what Warren said as well) is that it=E2=80=99= 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 on= e city or region with differing peering connections in each pop.

First, I TOTAL= LY 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 SAM= E fundamental assumption of ECS. Because ECS is also based on the map o= f=C2=A0 "client subnet -> geolocation" information.

So, imagine that,=C2=A0 AUTH gets the precise su= bnet, and then,=C2=A0 what is the accuracy of map the subnet into geoloc= ation ?
=C2=A02) Is the IP geolocation database used by the auth= oritative server with high quality?=C2=A0 ( details in my Paper )<= br>

Most of time, AUTH's=C2=A0 g= eolocation database CAN NOT achieve this accuracy level, expecially on fore= ign subnet: several pops in one city or region with differing peering conne= ctions in each pop.
So, the point is ECS send the subnet to AUTH, and AU= TH map the subnet into EIL's aerial view geolocation, and then AUTH mak= es 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 T= OP 5 ISP : TELECOM/UNICOM/MOBILE/EDUCATION/TIETONG.
But Maxmind can not = distinguish different subnet peering connections in one city, there are man= y small ISPs in China,=C2=A0 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>,=C2=A0 you can make a = better response, most of time, is the best response too.

Moreover, IPv6 contains huge amount of subnet, the accura= cy problem may be even worse.


Ask
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85= =B0=C2=A0 Pan Lanlan
--f403045f1fb0361314054b4c012c-- From nobody Wed Mar 22 01:00:17 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9D129582; Wed, 22 Mar 2017 01:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 o9zfg-WGV7Ug; Wed, 22 Mar 2017 01:00:13 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C92E13147E; Wed, 22 Mar 2017 01:00:04 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:c871:8ab0:f80d:ed3c] (unknown [IPv6:2001:559:8000:c9:c871:8ab0:f80d:ed3c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id DC0EC61F9C; Wed, 22 Mar 2017 08:00:03 +0000 (UTC) Message-ID: <58D22F02.60505@redbarn.org> Date: Wed, 22 Mar 2017 01:00:02 -0700 From: Paul Vixie User-Agent: Postbox 5.0.11 (Windows/20170302) MIME-Version: 1.0 To: Lanlan Pan CC: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= , "fuyu@cnnic.cn" , dns-privacy@ietf.org, Barry Raveendran Greene , dnsop References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 08:00:16 -0000 Lanlan Pan wrote: > ... Because ECS is > also based on the map of "*client subnet -> geolocation*" information. wait, what? -- P Vixie From nobody Wed Mar 22 01:30:40 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6066131528; Wed, 22 Mar 2017 01:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 GG7YhtpXT7oF; Wed, 22 Mar 2017 01:30:37 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 7DE9713151E; Wed, 22 Mar 2017 01:26:51 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id t189so30341850wmt.1; Wed, 22 Mar 2017 01:26:51 -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=CP/KWSiJrGYCCGyRPJMJtJOsAWBLJAsa+9AN7jnLaoM=; b=A51ExsA0ajtGBw9SH9gH++4ulAAkc/B2KTNTKJGZzU3IUSdeB5cPXQwAa/7W4Ulp70 L9UCY5CPP3/gLOoeQHf24V/NnXeNqTiXkfuU+e2rT5fjfi8u34GVX31jeEULB/X+dFKs g8rymSjgNaedKC25UylWfD3yCE8wiAbrhNd1s5NlfT1hkm+vL5nWeOuQTWE9FSnxSuRJ 4sRsVugZv8KmUHDG+rDpTeluDCd8oYSsfKdD/3zi9BOsVBvrEqnT9kyA1eCfwb4z9BtJ 43XCbfmcVWjqJ0T3Zod7NlsbdwXJGLn2YeRMKKULBmTCBKD4ECV0uZIuY0gwy3FkucEb axyg== 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=CP/KWSiJrGYCCGyRPJMJtJOsAWBLJAsa+9AN7jnLaoM=; b=U3fjPG8CT73Ns+3oBPU3dIX9+Nx3Db/YbSdXDbtwRmszbixymZ4fqi5HE3+EJLliN1 q6fIYxCG1i58YJs6BOmCdcSkgE3rPHwfpF+qCQvEsGJkLCGo0FvtVGSzEiYjs8O7oBKI /jbjdMcJ+wjwK9uVZFXUkttAd1nxX2CJNnX0asbHjvI0CAZCJHgBrI3/o2B5fIfhYJYM ijtkMNkQsmXYM8vYxiYehBdnRmRoEHIPNtR37bMr9nSV+LL8/4HGrH/TdDf95WXRHNsc RXbNrryMKA0pRqXxqM9BJ1euLRRplk2XCYEnzInIG+YdKQvLbH0v2mj/O9jlzxc+EeyO MgEA== X-Gm-Message-State: AFeK/H1mDvOU0JcL8EEKvw7GqxadmdlqVKrl9ThMEV6kU8KDi3vRkTBUiM/wwUJ89pIozvHWKeTgScNWsewKmA== X-Received: by 10.28.232.13 with SMTP id f13mr6519930wmh.141.1490171210056; Wed, 22 Mar 2017 01:26:50 -0700 (PDT) MIME-Version: 1.0 References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> <58D22F02.60505@redbarn.org> In-Reply-To: <58D22F02.60505@redbarn.org> From: Lanlan Pan Date: Wed, 22 Mar 2017 08:26:39 +0000 Message-ID: To: Paul Vixie Cc: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= , "fuyu@cnnic.cn" , dns-privacy@ietf.org, Barry Raveendran Greene , dnsop Content-Type: multipart/alternative; boundary=001a11477984a1494b054b4d85cb Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 08:30:39 -0000 --001a11477984a1494b054b4d85cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/ Paul Vixie =E4=BA=8E2017=E5=B9=B43=E6=9C=8822=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8B=E5=8D=884:00=E5=86=99=E9=81=93=EF=BC=9A > > > Lanlan Pan wrote: > > ... Because ECS is > > also based on the map of "*client subnet -> geolocation*" information. > > wait, what? > > -- > P Vixie > > -- =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a11477984a1494b054b4d85cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

https://www.cdnplanet.com/blog/whi= ch-cdns-support-edns-client-subnet/

Paul Vixie <pau= l@redbarn.org>=E4=BA=8E2017=E5=B9=B43=E6=9C=8822=E6=97=A5=E5=91=A8= =E4=B8=89 =E4=B8=8B=E5=8D=884:00=E5=86=99=E9=81=93=EF=BC=9A


Lanlan Pan wrote:
> ... Because ECS is
> also based on the map of=C2=A0 "*client subnet -> geolocation*= " information.

wait, what?

--
P Vixie

--
=E8=87=B4=E7=A4=BC=C2=A0 Best Re= gards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--001a11477984a1494b054b4d85cb-- From nobody Wed Mar 22 03:54:54 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737C51316F7; Wed, 22 Mar 2017 03:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 JvykW2cgo0Ss; Wed, 22 Mar 2017 03:54:47 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142F01316FC; Wed, 22 Mar 2017 03:54:46 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:c871:8ab0:f80d:ed3c] (unknown [IPv6:2001:559:8000:c9:c871:8ab0:f80d:ed3c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 94FC361F9C; Wed, 22 Mar 2017 10:54:45 +0000 (UTC) Message-ID: <58D257F4.8090506@redbarn.org> Date: Wed, 22 Mar 2017 03:54:44 -0700 From: Paul Vixie User-Agent: Postbox 5.0.11 (Windows/20170302) MIME-Version: 1.0 To: Lanlan Pan CC: =?UTF-8?B?QXNrIEJqw7hybiBIYW5zZW4=?= , "fuyu@cnnic.cn" , dns-privacy@ietf.org, Barry Raveendran Greene , dnsop References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> <58D22F02.60505@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 10:54:52 -0000 Lanlan Pan wrote: > ... Because ECS is also based on the map of > "*client subnet -> geolocation*" information. Paul Vixie 于2017年3月22日周 > wait, what? Lanlan Pan wrote: > Hi Paul, hi. > https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/ this web page is factually incorrect in that it presupposes that geo-ip is used. i have added a comment there to this effect. the original ECS web site (http://www.afasterinternet.com/howitworks.htm) is somewhat marketing-oriented, but says only that "With this more intelligent routing, customers will have a better Internet experience with lower latency and faster speeds." in other words, it expects that a CDN will apply its server-selection logic on an address basis, but using the truncated client subnet rather than to the DNS request source address. it does not dictate what the CDN's server-selection logic has to be or do. in RFC 7871 (http://www.afasterinternet.com/ietfrfc.htm) we see this definition: > 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. there is an error on page 22 which is directly on-point: > o Recursive Resolvers implementing ECS should only enable it in > deployments where it is expected to bring clear advantages to the > end users, such as when expecting clients from a variety of > networks or from a wide geographical area. Due to the high cache > pressure introduced by ECS, the feature SHOULD be disabled in all > default configurations. from context, it's clear that they meant "topological area". actual CDN technology, from as far back as Cisco Distributed Director in the mid-1990's, has usually ignored geography, for the reasons i gave up-thread: overlapping and incoherent topology within a geo-ip region means that geo-location is a very poor predictor of per-path performance. let me state (again) for the record that i was and remain opposed to ECS because it's an obviously bad idea and the apparent need for it merely proves that Stupid DNS Tricks (http://queue.acm.org/detail.cfm?id=1647302) did not and could not solve their chosen problem in the first place. it's architectural cost-shifting, which is a form of both intellectual conversion and economic compulsion. sad! however, if you're going to propose a replacement for ECS, you should correctly describe how it works. < geolocation*">> is not a correct description. if EIL is geo-based, then it is completely different from ECS. -- P Vixie From nobody Thu Mar 23 00:32:24 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CC912D574; Thu, 23 Mar 2017 00:32:15 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 4bXT5xDULQD6; Thu, 23 Mar 2017 00:32:11 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 1106312E6D7; Thu, 23 Mar 2017 00:32:10 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u132so53629393wmg.0; Thu, 23 Mar 2017 00:32:09 -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=EGqu4Q1ErFRt96OWJjN0bxcoUvpWqK/6nt2MfuTT5Pk=; b=eRqZq2E5l2N+lM52ae/K2rGPNzWkRGFkuFjq81UsG+LNYpoKOSQozd/5HHiOgOM6i8 0EiWIzQyyFlzdODDBoSBYCW0GRQkFh5QPh1iHNgfSk6p8YnCo5cuDYgNB6z1OnBEd+IP BqLXzjszCDDLcAMphQ7KPmOkxEiLlUUh4GzO7v7OBJebk9tdRXOLOb9EGXCukiPm4Iyg O0yyoqgdInZlVNEbm6K6AWfMdnt5H4Qgmh4svayMpICcXmMCIBeAj4YRIS8xizU/mH98 vsmwhjyMxMsRsu3yn0Qbp6Y6TGN7M+7FN9q846rrgJMrojCuTSGWcPcKceNDoDdycpZx H6Hg== 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=EGqu4Q1ErFRt96OWJjN0bxcoUvpWqK/6nt2MfuTT5Pk=; b=uONR3zXpmogut+zni6I+qBDRDv2SSqthKK9ITJG2WuYikoIr/2LvjwtZDO1+pLlHXB 7GotfOms/qYhdDdP75o69pHOdFfodQ0ve8Ensg9smumj/v5f3ApKXtNzuQey4UpU617J pCzAUiym3h7GhHYWeDgH3b27bmc7dypn9T1KwpM/K9vmY4cvQh9QzKJO7df3wlvJdUAI nOwjVIBFQgyZmrleK/DhroAN88Zm5WN0kSPyN7iADjjGZu7Lr8l1zeJ5yHt+/Ek9plAz DA2yhggTp5k8dRLUcJ/6piB3RpzVC5mMTQU076qjJ/bWPuZyM6Yx0P8Wsf+3qWRN4drk U/vw== X-Gm-Message-State: AFeK/H2eU1444Q9+Y5zixC83zAvEgiyOHzQoI2chKsrZ5/t1wE44dNR9nr7VQn4N22O3PQLR7zy2SqGdTeCyNA== X-Received: by 10.28.152.11 with SMTP id a11mr11648384wme.64.1490254328125; Thu, 23 Mar 2017 00:32:08 -0700 (PDT) MIME-Version: 1.0 References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> <58D22F02.60505@redbarn.org> <58D257F4.8090506@redbarn.org> In-Reply-To: <58D257F4.8090506@redbarn.org> From: Lanlan Pan Date: Thu, 23 Mar 2017 07:31:57 +0000 Message-ID: To: Paul Vixie Cc: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= , "fuyu@cnnic.cn" , dns-privacy@ietf.org, Barry Raveendran Greene , dnsop , petr.spacek@nic.cz Content-Type: multipart/alternative; boundary=001a114b9412da5ce3054b60df5d Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 07:32:16 -0000 --001a114b9412da5ce3054b60df5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, Thanks for your comments and detail expatiation, :-) *Why I think ECS is actually based on the map of " client subnet -> geolocation (country, province, isp) " ? * Of course, we all read RFC 7871, they said "Topologically Close" , not "Geographically close". Everyone know that geolocation is not precisely equal to realtime network topology. But, the duck test =E2=80=93 "If it looks like a duck, swims like a duck, a= nd quacks like a duck, then it probably is a duck". As last mail I replied to Ask, AUTH will not choose to detect network topology connection speed with each subnet one by one, but summarized the subnet into some critical information: AS Number, Country, Province, ISP name. Most of time, AUTH will select some subnets for sample test, then, configure by geolocation area. I don't mean that AUTH decide response based on physical geolocation distance. I mean that AUTH decide response base on *network topology distance between the isp geolocation area.* Imagine that, www.xxxcdn.com build two datacenter in (CHINA, SHANGHAI, UNICOM), (CHINA, LIAONING, UNICOM) - physical distance: BEIJING - SHANGHAI > BEIJING - LIAONING - network topology distance: BEIJING - SHANGHAI < BEIJING - LIAONING the AUTH of www.xxxcdn.com will return (CHINA, SHANGHAI, UNICOM) response to the user from (CHINA, BEIJING, UNICOM). There are some examples: 1) Google Public DNS FAQ : https://developers.google.com/speed/public-dns/faq#locations In addition, Google Public DNS engineers have proposed a technical solution called EDNS Client Subnet . This proposal allows resolvers to pass in part of the client's IP address (the first 24/64 bits or less for IPv4/IPv6 respectively) as the source IP in the DNS message, so that name servers can return optimized results *base= d on the user's location* rather than that of the resolver. To date, we have deployed an implementation of the proposal for many large CDNs (including Akamai) and Google properties. The majority of *geo-sensitive* domain names are already covered. 2) Dyn=E2=80=99s ECS Implementation: https://help.dyn.com/edns-client-subnet-faq-info/ When a DNS query is received by our nameservers, we analyze the query in order to determine what response we provide. During this analysis, we will notice if ECS information is provided and whether a Traffic Director service will be involved in the response. If both is the case, we will *use the ECS information for our geolocation lookup* instead of the source IP address. Once a geolocation is found and a response is selected, Traffic Director will provide a DNS response back to the source IP address. As part of this response we will include information via ECS regarding what subnet the response should be cached for. 3) Amazon Route 53: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.htm= l To improve the accuracy of *geolocation routing*, Amazon Route 53 supports the edns-client-subnet extension of EDNS0. (EDNS0 adds several optional extensions to the DNS protocol.) Amazon Route 53 can use edns-client-subnet only when DNS resolvers support it When a browser or other viewer uses a DNS resolver that does support edns-client-subnet, the DNS resolver sends Amazon Route 53 a truncated version of the user's IP address. Amazon Route 53 *determines the location of the user based on the truncated IP address* rather than the source IP address of the DNS resolver; this typically provides a more accurate estimate of the user's location. Amazon Route 53 then responds to geolocation queries with the DNS record for the user's location. 4) Gdnsd (an AUTH software) 's Geoip plugin, which support ECS: https://github.com/gdnsd/gdnsd/wiki/GdnsdPluginGeoip gdnsd-plugin-geoip uses MaxMind's GeoIP binary databases to map address and CNAME results based on *geography* and monitored service availability. It fully supports both IPv6 and the emerging edns-client-subnet standard. *Is geolocation information good for CDN and DNS? * In the mid-1990's, network resource is rare and uneven, network path is inconsistent with geolocation. Therefore, in the mid-1990's, many network operators usually ignored geography. There was a popular sentence for Chinese network topology, decribed similar condition: The distance between China Telecom and China Unicom, is much longer than the distance between China Telecom and United State. However, Internet grow up dramatically since 1990s. Nowadays, Internet is critical information infrastructure, global network path connect every where. Even into remote mountain village, information spread rapidly. With internet network path connect every where, the aerial view network topology distance improve like road path more and more. CDN do best effort to make end user to visit the closest edge server, consider about geolocation more and more. They call that geolocation lookup, geolocation routing, geolocation delivery, and so on. I AGREE WITH this sentence of your post : *it has never been wise to assume that a DNS request's IP source address gives any hint of an end-system Web browser's network location.* This assumption is not correct in theopy, but the reality is that almost all smart-auth-dns-resolution working based on this assumption. So I support ECS's idea : give more precisely information to AUTH. In the mid-1990's, DNS is pure. Not work with CDN that contains 50+ datacenters to choose for dns response. In the mid-1990's, there is not public recursive resolver. Not increase the distance between client ip and resolver ip. Consider about these nowadays problem, ECS is designed, partly change traditional dns query, *give addtional subnet information for AUTH to make a better decision*. ECS can make DNS query & response more satisfied with nowadays content delivery ( one domain -> multiple servers distributed in different location datacenters ), if they don't deploy ip anycast. Again, as I methioned above, AUTH actually use ECS subnet information mapped into geolocation information, then make dns decision. *Why I think EIL can make some revisions to ECS ? * EIL : We tell Authorative servers that, "*I want to know what is most satisfied ip address for clients from (CHINA, BEIJING, UNICOM) at network topology distance*". The (CHINA, BEIJING, UNICOM) is geolocation, but AUTH decide dns response by network topology distance between the geolocation nodes. - *Privacy*: The biggest privacy concern on ECS is that client subnet information is personally identifiable. EIL adjust the sensitive client subnet information to aerial view geolocation information for user priva= cy protection. - *Operation*: In P-model (details in my *Paper *), EIL move back the "guess geolocation of client=E2=80=99s IP" work from autho= ritative server to public recursive resolver, lighten the burden of authoritative server. Anyway, the origin of user latency problem is the public recursi= ve service providers couldn't deploy servers in every country and every ISP= 's network. - *Cache Size*: The cache size of ECS grows up with the number of client subnets. under future IPv6 environment, huge number of subnet, t= he cache size of EIL will be smaller than ECS. Paul Vixie =E4=BA=8E2017=E5=B9=B43=E6=9C=8822=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8B=E5=8D=886:54=E5=86=99=E9=81=93=EF=BC=9A > Lanlan Pan wrote: > > ... Because ECS is also based on the map of > > "*client subnet -> geolocation*" information. > > Paul Vixie =E4=BA=8E2017=E5=B9=B43=E6=9C=8822=E6=97=A5= =E5=91=A8 > > wait, what? > > Lanlan Pan wrote: > > Hi Paul, > > hi. > > > https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/ > > this web page is factually incorrect in that it presupposes that geo-ip > is used. i have added a comment there to this effect. > > the original ECS web site > (http://www.afasterinternet.com/howitworks.htm) is somewhat > marketing-oriented, but says only that "With this more intelligent > routing, customers will have a better Internet experience with lower > latency and faster speeds." in other words, it expects that a CDN will > apply its server-selection logic on an address basis, but using the > truncated client subnet rather than to the DNS request source address. > it does not dictate what the CDN's server-selection logic has to be or do= . > > in RFC 7871 (http://www.afasterinternet.com/ietfrfc.htm) we see this > definition: > > > 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. > > there is an error on page 22 which is directly on-point: > > > o Recursive Resolvers implementing ECS should only enable it in > > deployments where it is expected to bring clear advantages to the > > end users, such as when expecting clients from a variety of > > networks or from a wide geographical area. Due to the high cache > > pressure introduced by ECS, the feature SHOULD be disabled in all > > default configurations. > > from context, it's clear that they meant "topological area". > > actual CDN technology, from as far back as Cisco Distributed Director in > the mid-1990's, has usually ignored geography, for the reasons i gave > up-thread: overlapping and incoherent topology within a geo-ip region > means that geo-location is a very poor predictor of per-path performance. > > let me state (again) for the record that i was and remain opposed to ECS > because it's an obviously bad idea and the apparent need for it merely > proves that Stupid DNS Tricks > (http://queue.acm.org/detail.cfm?id=3D1647302) did not and could not solv= e > their chosen problem in the first place. it's architectural > cost-shifting, which is a form of both intellectual conversion and > economic compulsion. sad! > > however, if you're going to propose a replacement for ECS, you should > correctly describe how it works. < of "*client subnet -> geolocation*">> is not a correct description. if > EIL is geo-based, then it is completely different from ECS. > > -- > P Vixie > > -- =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a114b9412da5ce3054b60df5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for your comm= ents and detail expatiation, :-)

Why I think ECS is actually based on the map of " client subnet -> geolocation (country, province, isp) " ?=

Of course, we all read RFC= 7871, they said "Topologically Close" , not "Geographically= close".
Everyone know that geolocation is not precis= ely equal to realtime network topology.

But, the duck test =E2=80=93 "If it looks like a duck, swims like a = duck, and quacks like a duck, then it probably is a duck".
As last mail I replied to Ask, AUTH will not choose to detect network to= pology connection speed with each subnet one by one, but summarized the sub= net into some critical information: AS Number, Country, Province, ISP name.= Most of time, AUTH will select some subnets for sample test, then, configu= re by geolocation area.

I don't mean that AUTH decide= response based on physical geolocation distance. I mean that AUTH decide r= esponse base on network topology distance between the isp geolocation ar= ea.
Imagine that,=C2=A0 www.xxxcdn= .com=C2=A0 build two datacenter in (CHINA, SHANGHAI, UNICOM), (CHINA, L= IAONING, UNICOM)
  • physical distance: BEIJING - SHANGHAI=C2= =A0 >=C2=A0 BEIJING - LIAONING
  • network topology distance: BEIJIN= G - SHANGHAI <=C2=A0 BEIJING - LIAONING
the AUT= H of www.xxxcdn.com=C2=A0 will return= (CHINA, SHANGHAI, UNICOM) response to the user from=C2=A0 (CHINA, BEIJING,= UNICOM).

There are some examples:
<= div>
1) Google Public DNS FAQ : https://developers.google.com/speed/public= -dns/faq#locations

In addition, Google Public DNS engineers have= proposed a technical solution called EDNS Client Subnet. This proposal allows resolvers to pass in part of the client's IP addre= ss (the first 24/64 bits or less for IPv4/IPv6 respectively) as the source IP = in the DNS message, so that name servers can return optimized results based= on the user's location rather than that of the resolver. To date, we have deployed an implementation of the proposal for many large = CDNs (including Akamai) and Google properties. The majority of geo-sensitive domain names are already covered.
<= br>
2) Dyn=E2=80=99s ECS Implementation: https://help.dyn.com/edns-client-subn= et-faq-info/

When a DNS query is received by our nameservers, we= analyze the query in order to determine what response we provide. During t= his analysis, we will notice if ECS information is provided and whether a T= raffic Director service will be involved in the response. If both is the ca= se, we will use the ECS information for our geolocation lookup inste= ad of the source IP address.
Once a geolocation is found and a response = is selected, Traffic Director will provide a DNS response back to the sourc= e IP address. As part of this response we will include information via ECS = regarding what subnet the response should be cached for.

3) Amazon R= oute=C2=A053: http://docs.aws.amazon.com/Route53/latest/Devel= operGuide/routing-policy.html

To improve the accuracy of geol= ocation routing, Amazon Route=C2=A053 supports the edns-client-subnet extension of EDNS0. (EDNS0 adds=20 several optional extensions to the DNS=20 protocol.) Amazon Route=C2=A053 can use edns-client-subnet only when DNS=20 resolvers support it
When a browser or other viewer uses a DNS res= olver that does support=20 edns-client-subnet,=20 the DNS resolver sends Amazon=20 Route=C2=A053 a truncated version of the user's IP address. Amazon Rout= e=C2=A053=20 determines the =20 location of the user based on the truncated IP address rather than the source IP address of the DNS=20 resolver;=20 this typically provides a more=20 accurate estimate of the user's location. Amazon Route=C2=A053 then res= ponds=20 to=20 geolocation queries with the DNS=20 record for the user's location.

4)=C2=A0 Gdnsd (an AUTH so= ftware) 's Geoip plugin, which support ECS: https://github.com/gdnsd/gdnsd/wiki/G= dnsdPluginGeoip
gdnsd-plugin-geoip uses MaxMind's GeoIP binary d= atabases to map=20 address and CNAME results based on geography and monitored service= =20 availability. It fully supports both IPv6 and the emerging=20 edns-client-subnet standard.


Is geolocation information good for CDN and DNS?
In the mid-1990's, network resource is rare and un= even, network path is inconsistent with geolocation. Therefore, in the mid-= 1990's, many network operators usually ignored geography.
There was a popular sentence for Chinese network topology, decribed simil= ar condition: The distance between China Telecom and China Unicom, is much = longer than the distance between China Telecom and United State.

However, Internet grow up dramatically since 1990s. Nowadays, Inter= net is critical information infrastructure, global network path connect eve= ry where. Even into remote mountain village, information spread rapidly.
With internet network path connect every where, the aerial view netwo= rk topology distance improve like road path more and more.
CDN do = best effort to make end user to visit the closest edge server, consider abo= ut geolocation more and more. They call that geolocation lookup, geolocatio= n routing, geolocation delivery, and so on.

I AGREE WITH = this sentence of your post : it has never been wise to assume that a DNS= request's IP source address=20 gives any hint of an end-system Web browser's network location.
=
This assumption is not correct in theopy, but = the reality is that almost all smart-auth-dns-resolution working based on t= his assumption.
So I support ECS's idea : give mor= e precisely information to AUTH.

In the mid-1990's,=C2=A0 DNS is pure. Not work with CDN that contains = 50+ datacenters to choose for dns response.
In the mid-1990&#= 39;s,=C2=A0 there is not public recursive resolver. Not increase the distan= ce between client ip and resolver ip.
Consider about these nowadays prob= lem,=C2=A0 ECS is designed, partly change traditional dns query, give ad= dtional subnet information for AUTH to make a better decision.
ECS can make DNS query & response more satisfied with nowadays co= ntent delivery ( one domain -> multiple servers distributed in different= location datacenters ), if they don't deploy ip anycast.

Again, as I methioned above, AUTH actually use ECS subnet inform= ation mapped into geolocation information, then make dns decision.
=

Why I think EIL can make some revisions to ECS ?

=
EIL : We tell Authorative servers that, "I want to k= now what is most satisfied ip address for clients from (CHINA, BEIJING, UNICOM) at network=20 topology distance".=C2=A0 The (CHINA, BEIJING, UNICOM) is geolocat= ion,=C2=A0 but AUTH decide dns response by network topology distance betwee= n the geolocation nodes.
  • Privacy:=C2=A0 T= he biggest privacy concern on ECS is that client subnet information is pers= onally identifiable. EIL adjust the sensitive client subnet information to = aerial view geolocation information for user privacy protection.
<= /div>
  • Operation:=C2=A0 In P-model (details in my Paper),= EIL move back the "guess geolocation of client=E2=80=99s IP" wor= k from authoritative server to public recursive resolver, lighten the burde= n of authoritative server. Anyway, the origin of user latency problem is th= e public recursive service providers couldn't deploy servers in every c= ountry and every ISP's network.
  • Cache Size:=C2=A0 The ca= che size of ECS grows up with the number of client subnets. under future IP= v6 environment, huge number of subnet,=C2=A0 the cache size of EIL will be = smaller than ECS.

Paul Vixie <pau= l@redbarn.org>=E4=BA=8E2017=E5=B9=B43=E6=9C=8822=E6=97=A5=E5=91=A8= =E4=B8=89 =E4=B8=8B=E5=8D=886:54=E5=86=99=E9=81=93=EF=BC=9A
Lanlan Pan wrote:
> ... Because ECS is also based on the map of
> "*client subnet -> geolocation*" information.

Paul Vixie <paul@redbarn.org>=E4=BA=8E2017=E5=B9=B43=E6=9C=8822=E6= =97=A5=E5=91=A8
> wait, what?

Lanlan Pan wrote:
> Hi Paul,

hi.

> https:= //www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/

this web page is factually incorrect in that it presupposes that geo-ip
is used. i have added a comment there to this effect.

the original ECS web site
(http://www.afasterinternet.com/how= itworks.htm) is somewhat
marketing-oriented, but says only that "With this more intelligent
routing, customers will have a better Internet experience with lower
latency and faster speeds." in other words, it expects that a CDN will=
apply its server-selection logic on an address basis, but using the
truncated client subnet rather than to the DNS request source address.
it does not dictate what the CDN's server-selection logic has to be or = do.

in RFC 7871 (http://www.afasterinterne= t.com/ietfrfc.htm) we see this
definition:

> Topologically Close:=C2=A0 Refers to two hosts being close in terms of= the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0number of hops or the time it takes for a pa= cket to travel from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0one host to the other.=C2=A0 The concept of = topological distance is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0only loosely related to the concept of geogr= aphical distance: two
>=C2=A0 =C2=A0 =C2=A0 =C2=A0geographically close hosts can still be very= distant from a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0topological perspective, and two geographica= lly distant hosts can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be quite close on the network.

there is an error on page 22 which is directly on-point:

>=C2=A0 =C2=A0 o=C2=A0 Recursive Resolvers implementing ECS should only = enable it in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0deployments where it is expected to bring cl= ear advantages to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0end users, such as when expecting clients fr= om a variety of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0networks or from a wide geographical area.= =C2=A0 Due to the high cache
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pressure introduced by ECS, the feature SHOU= LD be disabled in all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default configurations.

from context, it's clear that they meant "topological area".<= br class=3D"gmail_msg">
actual CDN technology, from as far back as Cisco Distributed Director in the mid-1990's, has usually ignored geography, for the reasons i gave up-thread: overlapping and incoherent topology within a geo-ip region
means that geo-location is a very poor predictor of per-path performance.
let me state (again) for the record that i was and remain opposed to ECS because it's an obviously bad idea and the apparent need for it merely<= br class=3D"gmail_msg"> proves that Stupid DNS Tricks
(http://queue.acm.org/detail.cfm?id= =3D1647302) did not and could not solve
their chosen problem in the first place. it's architectural
cost-shifting, which is a form of both intellectual conversion and
economic compulsion. sad!

however, if you're going to propose a replacement for ECS, you should correctly describe how it works. <<Because ECS is also based on the m= ap
of "*client subnet -> geolocation*">> is not a correct d= escription. if
EIL is geo-based, then it is completely different from ECS.

--
P Vixie

-- =
=E8=87= =B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pa= n Lanlan
--001a114b9412da5ce3054b60df5d-- From nobody Thu Mar 23 11:06:43 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3857D1296BE for ; Thu, 23 Mar 2017 11:06:41 -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 A3n5uzCtj77l for ; Thu, 23 Mar 2017 11:06:39 -0700 (PDT) Received: from smtp80.ord1c.emailsrvr.com (smtp80.ord1c.emailsrvr.com [108.166.43.80]) (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 CC316129B49 for ; Thu, 23 Mar 2017 11:06:39 -0700 (PDT) Received: from smtp3.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B5E17A0457; Thu, 23 Mar 2017 14:06:36 -0400 (EDT) X-Auth-ID: bgreene@senki.org Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 47D98A0443; Thu, 23 Mar 2017 14:06:36 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [172.16.1.5] (c-73-92-124-43.hsd1.ca.comcast.net [73.92.124.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 23 Mar 2017 14:06:36 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Barry Raveendran Greene In-Reply-To: Date: Thu, 23 Mar 2017 11:06:35 -0700 Cc: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= , "fuyu@cnnic.cn" , dns-privacy@ietf.org, dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <3CD9E11E-F2C5-4871-8D6F-019317C8D983@senki.org> References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> To: Lanlan Pan X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:06:41 -0000 > On Mar 21, 2017, at 11:38 PM, Lanlan Pan wrote: >=20 > However, if you know about the geolocation , = you can make a better response, most of time, is the best response too. Your statement is not matching the operational realities I live in. I = understand how mapping is done in my current environment. I understand = how it is done in many of my peer CDNs. I also understand the tools I = would need to measure better path calculations. Everything is in IP, = RIPs, FIBs, AS Patch, system load, content availability, etc. Knowing = that it is in Palo Alto California is not something useful. What is needed is the allocated IP block to start the mapping = determination. Then every CDN does their =E2=80=9Csecret sauce=E2=80=9D = to delver the best customer experience. Geographic location is just not = one of those factors. ECS delivers this now.=20 From nobody Thu Mar 23 19:27:30 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBC71292F4; Thu, 23 Mar 2017 19:27:23 -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 FJaQzkcAiz4C; Thu, 23 Mar 2017 19:27:21 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 CAE2112940C; Thu, 23 Mar 2017 19:27:20 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id u108so885693wrb.3; Thu, 23 Mar 2017 19:27:20 -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=QsbRnc7jaaIG9sq9QUmYjovXz8XX45y5qmON+yy6Hns=; b=m93WeGiwU3SOrvjfOdKh5YIE4SuRFlShPecrUN1ObSnvnixW7nTEeobk7ZQmlilBDL MbbC0hkdvdQSLtHgbT7v6aWclQ0V+80l6tJWN27DIzZxYcYxwp9JFGcEaL5BQv4Fm4zP HqcyIPGJjz19B++bVJG+kvM3asXnLNoYOI7AK1dQph+c1QAbsFADD99KPEJFzevYjbng d6eABEk8JXtI2CrgVDfJ0IC2J0SvNLdxHd960CH3k+63UQ8fkHXCNVBMtD+cxzvxi+B4 KRS3bWyLYiON6SxYoLUQKOPj8Ucg40E4RZzeKafdm2MmYNyOvL9/vA/VE0o/1gcliCOg gsOA== 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=QsbRnc7jaaIG9sq9QUmYjovXz8XX45y5qmON+yy6Hns=; b=Ij7pcWYGwY477Ymsdn7Eok2xE7+5YWK0tZeq4jmtm7SN7/hhv67RlMH2nXEm8I1IrS eS4a5Jf2mg4bb5Tbn/aONvmuMVvLXl6JTYoOG7/swe849tTKCG8HwsWIr5+rmLjwEpL1 5bfSwMCRkwZALPeh693b/gPUghWQPPMpAG+fRf6NRm2ee7y0QL+YAciBAQBqhEa/TIGX vNFKtXK1L4Iy8cPbfQL3Kg7XvX93TXc5xvHyYJm+lPGJdOxjAMb9MB/SO4Ehke08QC0a 52Ooqz3JhIjBkv11kw5Y1GKO8iv+CPpI1i4/q69o8rKpQTSC8MOg+bg16xEwlsDuLmIO 44Ow== X-Gm-Message-State: AFeK/H2L6Xle4sLpbxweksYg379hkdpx5nlhc3GokFaEP/vQ/dLHcGMc1Jbegd53HS42KOHbPbySXGwIgTi8EQ== X-Received: by 10.223.130.214 with SMTP id 80mr5408272wrc.43.1490322439316; Thu, 23 Mar 2017 19:27:19 -0700 (PDT) MIME-Version: 1.0 References: <000f01d29dfe$50b6b190$f22414b0$@cn> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <3C0E763C-4C7F-4A63-A178-58F2AD77D3AC@develooper.com> <3CD9E11E-F2C5-4871-8D6F-019317C8D983@senki.org> In-Reply-To: <3CD9E11E-F2C5-4871-8D6F-019317C8D983@senki.org> From: Lanlan Pan Date: Fri, 24 Mar 2017 02:27:08 +0000 Message-ID: To: Barry Raveendran Greene Cc: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= , "fuyu@cnnic.cn" , dns-privacy@ietf.org, dnsop Content-Type: multipart/alternative; boundary=001a114c1dd698ac25054b70bb60 Archived-At: Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 02:27:23 -0000 --001a114c1dd698ac25054b70bb60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Barry, There are complex factors to optimize the datacenter connection of CDN. I know every CDN need "Everything is in IP, RIPs, FIBs, AS Patch, system load, content availability, etc." to measure better path calculations. I understand that "Knowing that it is in Palo Alto California" is not something useful for Data Provider path calculation, load balance optimization, etc. Note that, I *DON'T* mean that knowing is sufficient for CDN. But, as you methioned in last mail: * > Once the connection to the client to the CDN is made, the CDN operator has the full details of the client. * CDN can known "Everything is in IP, RIPs, FIBs, AS Patch, system load, content availability, etc." without ECS. CDN can do the BGP optimization and datacenter load balance without ECS. *Sperate the consideration of datacenter path calculation (Data Provider) and dns response (AUTH).* - Data provider can make datacenter path calculation without ECS because all clients will connect. - ECS is help AUTH to return the satisfied dns response to client. Therefore, the question is, *what can help AUTH to decide the response* ? I mean that, most of time, knowing is sufficient for AUTH make dns response. My statement Is, for example: the subnets (subnet_1 ... subnet_100) in the same geolocation, always visit the same CDN datacenter sets (DC_1 .. DC_2) . datacenter sets can be changed when network status is varied, network path connection latency become larger, load balance adjustment, etc... EIL is sufficient if AUTH make dns decison on geolocation pricise level. If your operational realities is: subnet_1 ... subnet_100 in the same geolocation, you apply subnet_1 ... subnet_50 visit DC_1, subnet_51 .. subnet_100 visit DC_2 ECS is satisfied with your statement, because your AUTH make dns decision down to subnet pricise level. Barry Raveendran Greene =E4=BA=8E2017=E5=B9=B43=E6=9C=88= 24=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8A=E5=8D=882:06=E5=86=99=E9=81=93=EF= =BC=9A > > > On Mar 21, 2017, at 11:38 PM, Lanlan Pan wrote: > > > > However, if you know about the geolocation , > you can make a better response, most of time, is the best response too. > > Your statement is not matching the operational realities I live in. I > understand how mapping is done in my current environment. I understand ho= w > it is done in many of my peer CDNs. I also understand the tools I would > need to measure better path calculations. Everything is in IP, RIPs, FIBs= , > AS Patch, system load, content availability, etc. Knowing that it is in > Palo Alto California is not something useful. > > What is needed is the allocated IP block to start the mapping > determination. Then every CDN does their =E2=80=9Csecret sauce=E2=80=9D t= o delver the best > customer experience. Geographic location is just not one of those factors= . > ECS delivers this now. > > > > > > -- =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --001a114c1dd698ac25054b70bb60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Barry,

There are complex fa= ctors to optimize the datacenter connection of CDN.
I know every CDN need "Everything is in IP, RIPs, FIBs, AS Patch, = system load, content availability, etc." to measure better path calcul= ations.
I understand that "Knowing that it is in Palo A= lto California" is not something useful for Data Provider path calculation, load balance optimization, etc.
<= div>Note that, I DON'T mean that knowing <country, province, = isp> is sufficient for CDN.

But, as you methioned in last = mail:=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0 Once the connection to the client to the CDN is made, the CDN operator = has the full details of the client.
CDN can known "Everything= is in IP, RIPs, FIBs, AS Patch, system load, content availability, etc.&qu= ot; without ECS.
CDN can do the BGP optimization and datacent= er load balance without ECS.

Spe= rate the consideration of datacenter path calculation (Data Provider) and d= ns response (AUTH).
  • Data provider can make datacenter = path calculation without ECS because all clients will connect.
  • ECS = is help AUTH to return the satisfied dns response to client.
= Therefore, the question is, what can help AUTH to decide the response ?
I mean that, most of time, knowing <country= , province, isp> is sufficient for AUTH make dns response.

My statement Is, for example:
the subnets (subnet_1 ... = subnet_100) in the same <country, province, isp> geolocation, always = visit the same CDN datacenter sets (DC_1 .. DC_2) .
datacente= r sets can be changed when network status is varied, network path connectio= n latency become larger, load balance adjustment, etc...
EIL = is sufficient if AUTH make dns decison on <country, province, isp> ge= olocation pricise level.

If your operational r= ealities is:=C2=A0
subnet_1 ... subnet_100 in the same <country, pro= vince, isp> geolocation,=C2=A0 you apply subnet_1 ... subnet_50 visit DC= _1, subnet_51 .. subnet_100 visit DC_2
ECS is satisfied with = your statement, because your AUTH make dns decision down to subnet pricise = level.

Barry Raveendran Greene <bgreene@senki.org>=E4=BA=8E2017=E5=B9=B43=E6=9C= =8824=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8A=E5=8D=882:06=E5=86=99=E9=81=93= =EF=BC=9A

> On Mar 21, 2017, at 11:38 PM, Lanlan Pan <abbypan@gmail.com>= wrote:
>
> However, if you know about the geolocation <COUNTRY, PROVINCE, ISP&= gt;,=C2=A0 you can make a better response, most of time, is the best respon= se too.

Your statement is not matching the operational realities I live in. I under= stand how mapping is done in my current environment. I understand how it is= done in many of my peer CDNs. I also understand the tools I would need to = measure better path calculations. Everything is in IP, RIPs, FIBs, AS Patch= , system load, content availability, etc. Knowing that it is in Palo Alto C= alifornia is not something useful.

What is needed is the allocated IP block to start the mapping determination= . Then every CDN does their =E2=80=9Csecret sauce=E2=80=9D to delver the be= st customer experience. Geographic location is just not one of those factor= s. ECS delivers this now.





--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85= =B0=C2=A0 Pan Lanlan
--001a114c1dd698ac25054b70bb60-- From nobody Fri Mar 31 13:34:59 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DE712714F; Fri, 31 Mar 2017 13:34:57 -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, 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 9wJ57yD7ZisM; Fri, 31 Mar 2017 13:34:55 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 4C66A129436; Fri, 31 Mar 2017 13:34:52 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id x124so7719513wmf.0; Fri, 31 Mar 2017 13:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=jEiQuC6TXs7o5XUbK3bxz3cheVr0ECSwKWTgBUX2YY0=; b=Sac9/PzzrjkvvcJc9Yr2MjNoALMLfRXDiSkCcJxMEst84Qgfj/BXVDRF8FJz5yH8IO fkx9hYt0kiHZMxmNQSnh6zVpaEe7tSBuq2c0bqAvvAkIqohUAyN+xNsgPXiYzTc6fvP8 quXA+wx93p5PNBKFZ4pJ5qd9QiKNHjbul9frqipfPpHzkfckTqrFgUPb/FeZhDNcabJO +LRf2mkYajIU6AbjsUvLzstDWPNZrv7b8CMP2rYXyrr/sXkzAZoCcULCBcrrvr48Y5Vc DlYziltENFfK8A3BbG6PASXCgTW/kOt/zaNu8amPnPBFt6D5wCqOXhvIZvu4M1Ya5jI3 NR3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=jEiQuC6TXs7o5XUbK3bxz3cheVr0ECSwKWTgBUX2YY0=; b=k4xoPNsXim3LKSYMGwWgU8dzN2FcxJAc/TsCn0fKNPfKk/IDq03DuasrVFFZJ6Mn25 weXI4+IwTWAU7wc48ubi+q69/xZbzwMUsL/8dTpI5RRAIJxcPH3hdnX6ThO2QqKyacZv EmC7YySkDN1EFSW1F4c1lbW3S/P/5WMmcZluWNBCBnp91L2+65GI9YDePWW7wM+n5Fpj lYanWgCfS0oOjQJpXjn08+QUSR7KQnhRj0uiLT4ZLBplpdf2Ag85v7oGnHRa7NT7zKbK /cB+fA4se11ao0amCAfdf3O7IpNndyCsxF3kvi4p9lE9rUXpwbNNR3t6fAr/B/2nA7hy Cg6A== X-Gm-Message-State: AFeK/H2ZDS7QeQFMnfuIuQguTj0vmNSWIh87XmVvOKT4j1LF+BU+Mlh7xuTg4Gq91A+weJ7BSfOJrMCzlvI5gA== X-Received: by 10.28.48.16 with SMTP id w16mr4642579wmw.10.1490992490591; Fri, 31 Mar 2017 13:34:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.165.70 with HTTP; Fri, 31 Mar 2017 13:34:50 -0700 (PDT) From: tjw ietf Date: Fri, 31 Mar 2017 15:34:50 -0500 Message-ID: To: "dns-privacy@ietf.org" Cc: "dprive-chairs@ietf.org" Content-Type: multipart/alternative; boundary=001a11422afcc3ba77054c0cbd18 Archived-At: Subject: [dns-privacy] Looking for a second DPRIVE chair X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 20:34:57 -0000 --001a11422afcc3ba77054c0cbd18 Content-Type: text/plain; charset=UTF-8 Hi With Warren become Area Director, he is stepping down as DPRIVE chair and we are in the market for a second chair as we take on the next stages. If you are interested or think someone may be a good candidate please drop warren and myself a note. thanks tim --001a11422afcc3ba77054c0cbd18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi

With Warren become Ar= ea Director, he is stepping down as DPRIVE chair and we are in the market f= or a second chair as we take on the next stages.=C2=A0

=
If you are interested or think someone may be a good candidate please = drop warren and myself a note.

thanks
ti= m
--001a11422afcc3ba77054c0cbd18--