Re: [arch-d] centralization

Eliot Lear <lear@cisco.com> Sun, 14 March 2021 10:46 UTC

Return-Path: <lear@cisco.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 81FE13A0D48 for <architecture-discuss@ietfa.amsl.com>; Sun, 14 Mar 2021 03:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 fS81RfKEhvYD for <architecture-discuss@ietfa.amsl.com>; Sun, 14 Mar 2021 03:45:59 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233C33A0D47 for <architecture-discuss@ietf.org>; Sun, 14 Mar 2021 03:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8249; q=dns/txt; s=iport; t=1615718759; x=1616928359; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=JzejeDYALIpEIEzIit9RV5sLZSs5a9iQC0NPGmCNaa0=; b=mKBrjgq21StaGYJip9rDyw/oPXkLW6jxifViZm26N04Hz443wYPpiT5M fy6JbHAQbxTuI5AlVtdVR5VeJ041N500vf2pnqWEvSercO87rOTDPNqHZ ejgaiZfinYCbLSbWO3t9mw/euhEdfr3rS51f+oV4r49iVwo4dGrk3W+4f 0=;
X-Files: signature.asc : 488
X-IPAS-Result: A0DkBgBe6E1gjBbLJq1aHQEBAQEJARIBBQUBgg+BdoErVgEnEjGEQYkEiEEDlDaIHwQHAQEBCgMBAR0BCgwEAQGBWIJ1AoF1JjgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAYY6DYZEAQEBAQIBAQEhVgULCxgqAgInMAYTgnABgmYhD6tXd4EyhViEfgoGgTmBU4UcDgGGRUKCDIERJxyCWD6CYAEDFoERDYM/NYIrBIFPFoFmJhAUOwwYUQx1L5A8CoxMnGiDDIMzgT+XTAMfk3GQJLJTGmIBg3gCBAYFAhaBayGBWTMaCBsVOyoBgj4+EhkNjjiDVoUUhUZAAy84AgYBCQEBAwmMJIJFAQE
IronPort-HdrOrdr: A9a23:Zndho6i6YrgYv+W7ZNhGSviPL3BQXlgji2hD6mlwRA09T+Wzna mV7Zcm/DXzjyscX2xlpMCYNMC7LU/02JZp7eAqXIuKcxLhvAKTRr1KzYyn+DH4Hj27y+g178 ddWoxzEsf5A1Q/rcuS2mSFOvIhxNXCz6yyn+fZyB5WIj1CUK1r4wdnBgvzKCQfLzVuPpY3GI GR4cBKvVObCBEqR/6mDXoIVfWrnbP2va/hCCR2ZSIP2U2rhTOs5KWSKWn94j4uFxVS3Lwl7W /J1yv+66nLiYDc9jbsk0nO8p9RhNztjuFmOfXJoM0UJjLw4zzYA7hcZw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,245,1610409600"; d="asc'?scan'208,217";a="34172859"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2021 10:45:54 +0000
Received: from [10.61.144.24] ([10.61.144.24]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 12EAjrEQ002943 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Mar 2021 10:45:54 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <8F545663-2F15-450A-8D70-4B09758570C4@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_9226E8AF-5073-430A-9217-561EBCE487FB"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Sun, 14 Mar 2021 11:45:53 +0100
In-Reply-To: <11840e55-3942-780f-00c6-038bd0a56d8c@cs.tcd.ie>
Cc: "Hutchison, David" <d.hutchison@lancaster.ac.uk>, Toerless Eckert <tte@cs.fau.de>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <0155CC72-571D-4540-8BD2-5A3B7FE4F7FB@lancaster.ac.uk> <11840e55-3942-780f-00c6-038bd0a56d8c@cs.tcd.ie>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Outbound-SMTP-Client: 10.61.144.24, [10.61.144.24]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/Tfym3-Wpd7IKaveXvL0pL7o4-NE>
Subject: Re: [arch-d] centralization
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: Sun, 14 Mar 2021 10:46:02 -0000

Hi Stephen,

I think that’s the wrong conclusion to draw, especially given events of the last year.  In fact, I myself missed some pretty important work that came out on this topic, which I believe ISOC actually advertised/sponsored[1].  IMHO there are limited aspects of concentration that the IETF can take on, but the IAB would be quite remiss to not engage  in this sort of activity, given the risks to the Internet.

What can the IAB do?  The problem here is that there is movable feast.  We can look through the prism and see cybersecurity risks, or we can see resiliency risks, and of course the two are related.

The board can bring relevant people together like, Geer, Jardine, Leverett, Radu and Hausding, along with software service providers to discuss how to mitigate the risks they described.
Beginning with a workshop
With a potential program or IRTF effort
The board can articulate design recommendations for the IETF in terms of what can lead to more or less centralization.  As I mentioned, I think some of Martin’s work on middle boxes is interesting in this regard, but it’s not the only activity.  How does service orchestration and network management play into all of this?
In coordination with ISOC, the board could discuss concerns with regulators where they see the need to do so.  This is intertwined, IMHO, with the evolving nature of lawful intercept, and probably needs to be handled with some circumspection.
The board can engaged different internet user communities to discuss the risk and what sorts of mitigations should be undertaken.  Do you know that there are large classes of TCP/IP use that do not allow for DNS because of resiliency concerns?  Is that a physical law or a design failure?

There is no shortage of work to be done here.

Eliot

[1] https://www.tandfonline.com/toc/rcyb20/5/1?nav=tocList

> On 12 Mar 2021, at 13:33, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> Hiya,
> 
> On 12/03/2021 11:44, Hutchison, David wrote:
>> Of course, I agree resilience is an important topic to pursue -- and
>> like Toerless I was disappointed to see the previous "lukewarm"
>> response ...
> Yeah, me too. It was funny that we had a good discussion
> on this list around the end of 2019 but then once we
> started a new list [1] it totally died. My conclusion
> was that indicated that people were interested in chatting
> but not in doing actual work on this topic.
> 
> S.
> 
> [1] https://www.iab.org/mailman/listinfo/chirp
> <OpenPGP_0x5AB2FAF17B172BEA.asc>