Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

Christian Huitema <huitema@huitema.net> Thu, 09 January 2020 08:28 UTC

Return-Path: <huitema@huitema.net>
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 3DF5A12087B for <dns-privacy@ietfa.amsl.com>; Thu, 9 Jan 2020 00:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 MBkGteZJbnAo for <dns-privacy@ietfa.amsl.com>; Thu, 9 Jan 2020 00:28:36 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 5F5BC120873 for <dns-privacy@ietf.org>; Thu, 9 Jan 2020 00:28:36 -0800 (PST)
Received: from xse179.mail2web.com ([66.113.196.179] helo=xse.mail2web.com) by mx62.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ipTBA-000Bit-Ol for dns-privacy@ietf.org; Thu, 09 Jan 2020 09:28:34 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 47tfQQ0VpxzLs4 for <dns-privacy@ietf.org>; Thu, 9 Jan 2020 00:28:30 -0800 (PST)
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1ipTB7-0001gT-US for dns-privacy@ietf.org; Thu, 09 Jan 2020 00:28:29 -0800
Received: (qmail 22317 invoked from network); 9 Jan 2020 08:28:29 -0000
Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dns-privacy@ietf.org>; 9 Jan 2020 08:28:29 -0000
To: mohamed.boucadair@orange.com, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, Sara Dickinson <sara@sinodun.com>
Cc: "last-call@ietf.org" <last-call@ietf.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
References: <4639bd67-6fca-47d1-aaeb-85fcd0394f46@www.fastmail.com> <7E5F804D-535F-4CB3-8F7F-ABD0ED4B833A@sinodun.com> <CABcZeBON0ung2htbaiKWGKJSUsHrPhrcEfJgVDoO3+UYCQZxsg@mail.gmail.com> <7729E44B-38EB-4EAF-8EFF-ED286696373E@sinodun.com> <CABcZeBNKsQ1pEVwxwYMgGTUhFntQ4h+L1Qyo=Q_nfN7p13y-UQ@mail.gmail.com> <85cb9bdb-690f-dd01-b824-3f33dbe111b7@huitema.net> <313877282.18779.1578483742473@appsuite-gw2.open-xchange.com> <787AE7BB302AE849A7480A190F8B9330313F779C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <dca04f57-386b-54cc-e00d-6e142845957d@huitema.net>
Date: Wed, 08 Jan 2020 22:28:28 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313F779C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------07C915A282B3375377BC8FD9"
Content-Language: en-US
X-Originating-IP: 66.113.196.179
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.179/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.179/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0c2Pj46HODYmpAMVAv0J1pOpSDasLI4SayDByyq9LIhVtgI4TOMJb0JE W2FX7zW5lUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwPzgJ2Ucltmld9WkfaJBY9Xt FNSzkMWnDricnMrpFJr+gtL5ZZgBYOBfMF4HHzvIQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEWDZrN5vok1pgM+wBB3y9fg7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsewmjBB9FK8WR3PmFasrrKyloBpdWj8QLYr5sN4Ugz0te4YvvNM4yXv5TPlA51d8fss0 4mFhMRgL0WaLCJWgZwPCkbvssIV5m5z4HvhSzwII9ZXked+P+aSZU/EB7YnRWs2LBDMrD7q/cJog wbqzsuokMfru+URL4EPaEDg3t6E1RU7JPy9twDyaj6un7qWOkNcNzO0DzSPiLy3VkJczIgVph2Pc cyEydHbxrY/KYFwgYePXdRjeeYOc4D1auWIFhSHwJ+3NXiPvej4YAhcPelPQw6nIoDr0sXUZ7YZo Z/GZ+hXPnkLS9Oo2rnoDkPMmYws/jALIEk7e/m7I/2vCMQjvMFTIwLG5tR7EnM5HsSwoavLd14/y 82ebPziYNS9mrGfphl+Vcq8rhM3tJ8iXgDJaTYQ7ppmvpzmHp5jJAeLmE9zghLEjHJbHVHmv5sbq r/Q=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/AaI1iuGS5AdVAICaAtol7RI6_14>
Subject: Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 08:28:38 -0000

On 1/8/2020 6:09 AM, mohamed.boucadair@orange.com wrote:
> FWIW, slide 6 of
> https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01
> shows that very few DNS providers are handling +53% of the traffic. It
> is fair to mention the risk to see such centralization further
> exacerbated. Of course, the one mentioned by Christian is to be called
> as well

I am not sure that I understand the methodology behind the slides that
you cite, but it appears that they are measuring traffic by volume based
on passive DNS data collection.

I have been working with the APNIC data, as published at
https://ithi.research.icann.org/graph-m5.html. The data attempts to
answer the question, how many "resolvers" handle what fraction of the
user population. The first problem is "how do you identify resolvers".
The classic simplification is to just count autonomous system numbers
(AS), but this lumps together the resolvers managed by ISP and those
managed by small businesses connecting through those ISP. The immediate
problem is, "how do you count", because users and their devices
sometimes send multiple copies of the same query to different resolvers,
and also sometimes send a second batch of queries to a different set of
resolvers if they did not get a response the first time. One way to
count would be, all the resolvers needed to handle all the repetitions
of the queries of a users. Let's call that the inclusive count. Another
way would be, the smallest numbers of resolvers that would handle X% of
the users, if all the other resolvers were out of service. Let's call
that the exclusive count, which is by definition smaller than the
inclusive count.

As of January 2020, the data shows that:
     * The traffic of 50% of the users is seen by resolvers in 57 AS
(inclusive count). Handling that traffic would require at least 22 AS
(exclusive count).
     * The traffic of 90% of the users is seen by resolvers in 570 AS
(inclusive count). Handling that traffic would require at least 385 AS
(exclusive count).

If we count by network prefix (/24 for IPv4, /48 for IPv6), we get:
     * The traffic of 50% of the users is seen by resolvers in 478
networks (inclusive count). Handling that traffic would require at least
143 networks (exclusive count).
     * The traffic of 90% of the users is seen by resolvers in 3403
networks (inclusive count). Handling that traffic would require at least
2150 networks (exclusive count).

Is that a form of concentration? Yes of course, but even the lowest
number, 22 AS, is larger than the 8 networks mentioned as handling 53%
of traffic in Pawel and Oliver's study.

And yes, it is important to monitor these trends.

-- Christian Huitema