Re: [arch-d] consolidation draft ( was New Version Notification for draft-nottingham-avoiding-internet-centralization-01.txt)

Watson Ladd <watsonbladd@gmail.com> Tue, 11 January 2022 07:48 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA513A1CB5 for <architecture-discuss@ietfa.amsl.com>; Mon, 10 Jan 2022 23:48:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iLyv1aZmf14S for <architecture-discuss@ietfa.amsl.com>; Mon, 10 Jan 2022 23:47:57 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 5C96D3A1CB0 for <architecture-discuss@ietf.org>; Mon, 10 Jan 2022 23:47:57 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id 30so62008822edv.3 for <architecture-discuss@ietf.org>; Mon, 10 Jan 2022 23:47:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OBU4bSnAhswQy+2up5aztEqNJUkKRtF1JkAt2lBfHL8=; b=DVW1A0vIwVZwE1xA3S0Z66h8HM9felQI13CsSkENjIgE/jss5CYMoiP1sewllKcVlq /B7zPDDups4IZBHQJiubCQB2unfPB4pYcv/PXZQJFhIhdjTVUiQBYMjUiSp6uA82mZJ9 OY69TTx883DLlC26z5Cr9RJXh0dfhR2Y3a+SSWDr+OUiO3mSkQvk56o4LzmK8Zvh892J Bgikuwm6hngOlgIp9FxY0k0kxzvAmtp7wJKoWc7R7immt3nlEjnAjGtWIvdxHP2GCEIb x0ZMnIDLFy+9ofySARwZtPvcPv8WGbYX/LBLDsiSD6UqY3kqlk/twMKWqJ8iDhxaWwh6 8rnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OBU4bSnAhswQy+2up5aztEqNJUkKRtF1JkAt2lBfHL8=; b=x8uvZTiZ291Ejo+CtlhyP3xCkRiLI9wOm/P7t54aSGDW83Mdx3Q2Rj5rUd3AdzQLmk XxfkbP0Zdqgj2Ixvd0jgEnbeVsNgwcPtwmn91JHKVsLp6lkUb40ti8Voup1FM1UzOGaH vzF+wVwSryhEny2dmgOZEcHfxqkO+KM1Ut5L4HZJ9+ytRjF5n3rToVtkPuT8ted8ebkB WanTQrbxxz8lglSxq5i1/jAAk8dI6WRE2yR+n8+25JOvhFvlfm/ROGwPVWG5Ksj6q1wd om6FynvCH2NZ8tB/BoBqXjCC1/nit1pjLnaZRbTiIEFbunBoc4G7jHFtQi1oQhesbV44 Zcfw==
X-Gm-Message-State: AOAM530Hc5ruRCicGP4H/TZ+cmgZleRlGVQ56WxPxzVmYzj2ti5fArmL jk7AqkqL/f+yyBmev3MLUgaKgDbC9wV2GYkU+J4=
X-Google-Smtp-Source: ABdhPJxdyaUUVtJa/F13x/CsDmxGEha2UszjedoXpCci/ZwJ8McQTBh8IWL0lVtIIk1a1y10R5zJXDpZpFdLm60C74E=
X-Received: by 2002:a17:907:334e:: with SMTP id yr14mr2619837ejb.222.1641887274421; Mon, 10 Jan 2022 23:47:54 -0800 (PST)
MIME-Version: 1.0
References: <164171968336.24353.16126612424502758413@ietfa.amsl.com> <2D72A384-6402-49E8-8960-CBACB5A84DCE@mnot.net> <230757985.6992.1641813463365@appsuite-gw1.open-xchange.com> <5FF81E2D-1164-4563-A04E-2F747906AFB7@lastpresslabel.com> <CACsn0cm4pHZ_r7J=8420rDNXYyJrFaAi1YaukPaQr+XqkteGzA@mail.gmail.com> <02017972-97fd-85c2-d0c3-ea6c52ec7392@lear.ch>
In-Reply-To: <02017972-97fd-85c2-d0c3-ea6c52ec7392@lear.ch>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 10 Jan 2022 23:47:41 -0800
Message-ID: <CACsn0ckuzUenYG11KQAjpsGueYLOVh6BvBV7Y_bXZzp4HTFEhg@mail.gmail.com>
To: Eliot Lear <lear@lear.ch>
Cc: Dominique Lazanski <dml@lastpresslabel.com>, architecture-discuss@ietf.org, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/4t7pKCF_rPk1Bhw3XF6IZ4rnXow>
Subject: Re: [arch-d] consolidation draft ( was New Version Notification for draft-nottingham-avoiding-internet-centralization-01.txt)
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jan 2022 07:48:02 -0000

On Mon, Jan 10, 2022 at 10:33 PM Eliot Lear <lear@lear.ch> wrote:
>
> Watson,
>
> Full disclosure- my name is on the draft, but it is a draft, and it
> needs work.  In this regard, I think you have jumped the gun in your
> review.  Please see below.
>
> On 11.01.22 05:43, Watson Ladd wrote:
> > On Mon, Jan 10, 2022 at 8:27 AM Dominique Lazanski
> > <dml@lastpresslabel.com> wrote:
> >> Also, Mark and I have a slightly updated take on our draft here:
> >>
> >> https://datatracker.ietf.org/doc/draft-lazanski-consolidation/
> > This draft makes a number of misleading and poorly substantiated
> > statements about DoH that easily could have been corrected by checking
> > against the published RFC. Given that several of the authors were
> > vocal participants in the rather ugly and extended debate about DoH, I
> > expect better. A sampling
> >
> > - "This change in the look up process is forcing the technology to
> > develop in a way which has narrowed the ability for companies and
> > small industries to do DNS look ups without updating out of date
> > hardware and software, therefore disenfranchising developing countries
> > and smaller companies without  big budgets."
> >
> > The  addition of a protocol does not narrow the ability to use the
> > older protocol. You would have to show revolvers turning off 53 in
> > favor of DoH. That hasn't happened.
>
> I don't think you have to show that resolvers are turning off port 53,
> but rather simply that the query traffic has shifted from port 53.
> Certainly that has, to some extent or another, happened.

That's not what the sentence says: it says that ability to do DNS
lookups (not serve queries) via port 53 has been reduced. A shift in
traffic doesn't mean anything to the traffic that remains.

<snip>
> I think the fundamental risk here is concentration of resolver
> providers.  What would happen to load if a Big Cloud Provider Who Offers
> DoH Today had a systemic failure (we have certainly seen such things)?
> This can of course be remediated by having a large and diverse selection
> of providers to spread load, so that no one provider can cause an
> excessive load shift.

Why does DoH make this worse than DNS? 8.8.8.8 works just fine over
53, and you have the same concentration issue. I think this a more
general thing than with DNS and should be a risk of concentration:
failures might remove substantial capacity.
Yes, AWS-East-1, I'm looking at you.

>
> By the way, your own statement is baseless.  That is, if you are going
> to correct someone, please be so kind as to at least cite some sources,
> since you claim they are readily available.  Not that the draft
> shouldn't support its own claims, of course.

I retract that, there aren't very clear contradictions. I'll link some
sources that complicate the picture
https://w3techs.com/technologies/overview/proxy shows that the most
common reverse proxy is none. Only 20% of sites use Cloudflare.
Unfortuately it doesn't seem to have historical data, but Netcraft
does, but alas only for server, and they had 10% for Cloudflare
recently https://news.netcraft.com/archives/2021/11/23/november-2021-web-server-survey.html.
These are substantial percentages!

The problem is that these measurements only look at sites, not
traffic. And traffic is highly skewed, with many large sites running
their own CDN, and many CDNs only competing for high traffic sites or
in particular niches. I don't really know what the market looks like:
a handful of competitors as it says in the draft is too few.  Probably
the best way is to try to pull it out from IX records, but off-nets
complicate it. It's not an easy number to get.

My recommendation would be to focus on sites, as it's more observable
and substantiated. And there's a more interesting dynamic: DDoS
attacks make it difficult to run small networks, filtering services
and CDN make it easier to run websites, but at the cost of having a
substantial impact for the rest of the world if it goes down and a lot
of sites impacted.

The other technical point is about CDN geolocation being disrupted by
DoH. This doesn't actually happen: the CDNs that do rely on geographic
IP assigment see some degradation even without /24 propagated, but
it's not big as the destination of the DoH resolver is close
networkwise to the query. No different from what happens with Do53,
and the same solutions like explicit client indication work. Useless
is way overstating it.

>
> > Unless there is a workable discovery protocol, and the people calling
> > for it should be the ones to propose it, I don't think we should hold
> > off on real privacy improvements for real users as a result. I think
> > there are real problems to think about in this space, but making this
> > a referendum on the biggest privacy improvement for real users since
> > Firesheep is not going to help have that conversation.
>
> Where is anyone being held back?

Nobody is, because the IETF process hasn't stopped ODOH and DOH
because people want discovery. That doesn't stop people from arguing
otherwise. Your draft argues that we need more review of protocols
then the already ponderously slow IETF consensus process, focused on
the claimed operational problems, that protocol design has economic
implications we need to review, etc. These seem like extremely
difficult things to actually get to solid conclusions on.

>
> >
> >> It seems that there is common ground among all three and also some big differences. However, its clear to me that there are technical, economic and policy related issues that are intertwined and need to be discussed further. The unintended consequences of legislation in, say, Russia (for example) is based in consolidation taking place on US platforms. These can’t be ignored.
> > I'm not aware of any large consequences of laws in Russia caused by US
> > consolidation. That definitely doesn't mean there haven't been any,
> > but it might be useful to point to examples.
>
> Indeed examples are good.  By the way, The Verge had an article about
> the Swiss Army doing its own version of IM because of risks associated
> with WhatsApp being a US company.  Yes, there are a number of
> entertaining aspects to that bit of information; and I'm confident the
> Verge doesn't have the story quite right.  But at least enjoy the
> entertainment as it comes.
>
> Eliot



-- 
Astra mortemque praestare gradatim