CDN versus edge compute use case distinction (was: Requesting reviews of draft-vanrein-httpauth-sasl)

Michiel Leenaars <michiel.ml@nlnet.nl> Fri, 15 May 2020 08:17 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E893A00AD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 May 2020 01:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.747
X-Spam-Level:
X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnet.nl
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 9ZuMYnnS-9F9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 May 2020 01:17:12 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 D00523A0064 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 May 2020 01:17:12 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jZVTf-0002F4-GB for ietf-http-wg-dist@listhub.w3.org; Fri, 15 May 2020 08:13:55 +0000
Resent-Date: Fri, 15 May 2020 08:13:55 +0000
Resent-Message-Id: <E1jZVTf-0002F4-GB@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <michiel.ml@nlnet.nl>) id 1jZVTe-0002EJ-4o for ietf-http-wg@listhub.w3.org; Fri, 15 May 2020 08:13:54 +0000
Received: from open.nlnet.nl ([185.49.140.12]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <michiel.ml@nlnet.nl>) id 1jZVTc-0005sv-3n for ietf-http-wg@w3.org; Fri, 15 May 2020 08:13:53 +0000
Received: from nlnet.nl (localhost [127.1.0.1]) by open.nlnet.nl (Postfix) with ESMTP id 8B56382FF4 for <ietf-http-wg@w3.org>; Fri, 15 May 2020 10:13:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnet.nl; h= content-transfer-encoding:content-type:content-type:user-agent :references:in-reply-to:message-id:mime-version:date:date :subject:subject:from:from:received:received; s=gerrit; t= 1589530419; x=1591344820; bh=aZb9sTP/9AZbMg/mPpfzxLc/FELcBCT19Rg V7fumiGQ=; b=lc1YKzsH5TcFmg3sd2eR0tvq+P6FZHcEFCOro2PMnn6fMZRKvIy n3nm/WNhq8r2PezXMCTzOdSRaByZZ9bJQH8gMtXgmT5uNhKeAjsVZc45ByKIwXXC UWiQaUYA3C3Q9HGntMktodZqkdWnHqfFcSJBx+/1op/GOgrtBctlp/o4=
X-Virus-Scanned: amavisd-new at nlnet.nl
Received: from open.nlnet.nl ([127.1.0.1]) by nlnet.nl (open.nlnet.nl [127.1.0.1]) (amavisd-new, port 10026) with ESMTP id 1pAPaHUKoKpu for <ietf-http-wg@w3.org>; Fri, 15 May 2020 10:13:39 +0200 (CEST)
Received: from localhost (unknown [IPv6:2001:984:2ab3:1:15d6:8754:8216:7431]) by open.nlnet.nl (Postfix) with ESMTPSA id 0A37082FEC for <ietf-http-wg@w3.org>; Fri, 15 May 2020 10:13:39 +0200 (CEST)
From: Michiel Leenaars <michiel.ml@nlnet.nl>
To: ietf-http-wg@w3.org
Date: Fri, 15 May 2020 10:13:38 +0200
MIME-Version: 1.0
Message-ID: <3b1b613f-fcd8-4b2a-84ab-10f7e0cd22d7@nlnet.nl>
In-Reply-To: <3041889.qWDYiAHMai@linux-9daj>
References: <B9974B38-6CC7-4979-B08C-ADA6EB22A66A@apple.com> <CABcZeBMD8++_dRtSD704Ymchi2hBxw74Xs+fLSXWj_6WS5d97g@mail.gmail.com> <217a4fc6-4805-4ee2-bd04-6fbe1d99c35c@nlnet.nl> <3041889.qWDYiAHMai@linux-9daj>
User-Agent: Trojita
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=185.49.140.12; envelope-from=michiel.ml@nlnet.nl; helo=open.nlnet.nl
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jZVTc-0005sv-3n 387050b30f932d7bf11cc5da14a72269
X-Original-To: ietf-http-wg@w3.org
Subject: CDN versus edge compute use case distinction (was: Requesting reviews of draft-vanrein-httpauth-sasl)
Archived-At: <https://www.w3.org/mid/3b1b613f-fcd8-4b2a-84ab-10f7e0cd22d7@nlnet.nl>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37626
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Paul,

(@all: I moved this into a separate thread, as a newcomer to this 
particular list I do not know is appropriate, but I do not think it is 
useful to continue diluting the responses to the original thread which had 
an actual action to them. And I apologise for diverting your attention from 
more important discussions, and for the length of my response to follow. 
Feel free to ignore, or to contact me directly should you wish to discuss 
further) 

> i don't think your attempt to define CDN is relevant. the companies selling 
> things under that umbrella are either leading or following the 
> market, rather 
> than consulting a dictionary to find our what business they are 
> in.

I certainly agree that market actors will gladly use and abuse any 
technical term as marketing terminology, no matter if it makes absolutely 
no sense or is even an outright lie. I have seen cable companies in our 
part of the planet deliver so called 'ADSL' services to consumers with a 
straight face, because 'their marketing department said that people 
associated that with fast internet'. The inability to make certificate 
providers see that a logo 'protected by SSL' is inadequate 'because people 
do not understand what TLS means' goes in the same direction.

I agree of course also that all relevant use cases, such as 
container-orchestration systems, need to be taken into account. This 
belongs back in the original thread.

That does not preclude us from having a working definition of different 
roles we see in the landscape. The word 'delivery' in CDN is rather key 
here, anything more than delivering is a fundamental change of role. I 
certainly do not claim the authoritity to write the ultimate definition of 
what a CDN actually is or is not, but having a temporary working definition 
helps to subsequently distinguish passive roles (i.e. a bit bucket for high 
volume assets one can fully replace even client side, as browser plugins 
like DecentralEyes prove) from actual active nodes at the edge which 'own' 
or 'originate' unique elements and processes present nowhere else (for 
which this is fundamentally not possible). 

The passive component is instantly exchangeable and thus tolerated inside a 
trusted computing base as long as that complies with the required level of 
security and privacy, but for sure it can also be easily removed or 
instantly swapped for use cases that are different - e.g. by a local or 
external proxy that caches the content before it reaches the CDN a second 
time. It is not fundamentally necessary to deploy CDNs either, and I 
personally avoid doing so. The active end point cannot be placed outside of 
the trusted computing base in any way, it does not have the mere role of 
delivery but is a data source or service component which is unique for the 
given situation. By virtue of that, use of such a service does leak 
information about the user base of a service to a another party. 

That is a meaningful and fundamental distinction, for which I am obviously 
happy to mentally link or retrofit into to any official definition you can 
point me to rather than me trying to crudely define it myself. Correct 
terminology matters a great deal, because it provides the linguistic 
surgery tools of our thinking. The abstract distinction between the two 
different roles is what matters to me.

To illustrate, this is perhaps in part analogous to how traditional postal 
companies deliver mail which may or may not have a sealed envelope around 
it (*), versus fulfillment companies which actually do personalised mass 
mail merges and print and compile those sealed envelopes based on full 
access to their content as well. All postal companies offer fulfillment 
services, and all fulfillment services get your mail to some delivery 
company - which may be a traditional postal service or an alternative 
network of smaller delivery companies (or even a postal delivery robot as 
we saw recently). 

(*) envelopes are not always closed and postal service deliver unprotected 
postcards and print too, of course, and with enough equipment letters can 
be looked into without opening them.

If you use such a combined service, the end result is the same whichever 
operator you use. Economically, on the outside when looking at all of them 
as 'one stop' service providers it is indeed a group of actors delivering a 
similar set of services. 

But of course, a significant part of regular mail is not done through 
fulfillment. If I (or the tax office) want to send you a confidential 
letter with say access credentials, we write or print a letter ourselves 
and carefully seal a scan-proof envelope, and just use the delivery 
channel. I have no need to use a third party fulfillment service, and it 
would be unwise in terms of operational security as it vastly increases the 
attack surface. Delivering traditional mail with a sealed envelope is the 
core service which is only available from the postal company and its 
competitors in the delivery realm. This does not require a full transfer of 
trust, the delivery company does not per se have the sender nor the 
contents of the mail delivered - as long as there are enough stamps and the 
envelope is adequately sealed. I can easily replace the delivery company 
with say a courier, or deliver it myself if I hire people. 

Fulfillment (like edge computing) is a different role from delivery, as the 
content or service delived by the edge node (like the postal piece) would 
just not exist. It is outsourcing core functionality. My reason to reply to 
the original thread was that the traditional CDN role can take place fully 
without authentication (even by pushing it to another subdomain), and 
therefore is not that relevant to consider. The edge compute case is 
indistinguishable from the cloud provider case, which is fully in scope - 
but I believe that has been taken into account and should not be an issue. 

As mentioned above, apologies for the lenghty reply. I am happy to continue 
this argument offline, since it sparked off a remark made by me. But we all 
have better and more urgent things to do. I wanted to clarify since asked, 
and hope there is nothing controversial in my reply that makes it necessary 
to continues this thread.

Have a great day,
Michiel