Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services

Toerless Eckert <> Thu, 16 April 2020 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57EB63A09D9 for <>; Thu, 16 Apr 2020 10:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UKp8N3Tn-w9c for <>; Thu, 16 Apr 2020 10:48:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF6173A09D6 for <>; Thu, 16 Apr 2020 10:48:46 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id B36D7548045; Thu, 16 Apr 2020 19:48:40 +0200 (CEST)
Received: by (Postfix, from userid 10463) id ACFE5440055; Thu, 16 Apr 2020 19:48:40 +0200 (CEST)
Date: Thu, 16 Apr 2020 19:48:40 +0200
From: Toerless Eckert <>
To: John C Klensin <>
Cc: Christian Huitema <>, Brian E Carpenter <>,
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <E029AEC023B1A60E3E956641@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E029AEC023B1A60E3E956641@PSB>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Apr 2020 17:48:50 -0000

On Mon, Apr 13, 2020 at 02:56:30PM -0400, John C Klensin wrote:
> It may also be worth noting that a, perhaps the, major add-on
> change in IPv6 --much touted in its early days-- was supposed to
> be ubiquitous lP-level encryption.

Indeed. It is almost puzzling to think that end-to-end
encryption at IP(sec) level was presumed to be a good
architectural choice. Besides the obvious beneeit of being
agnostic to transport protocol choices but then failing on
ever getting a host stack model that would allow applications
to leverage it easily. Of couse, luckily we have it (IPsec)
as there are a lot of other good use cases for it.
Maybe a bit too much of the "one size fits all" syndrom that
new technologies by sheer self interest always come to presume ?

>  That post-2013 encryption
> deployment, at least AFAICT, relies on methods much closer to
> the applications layer, sometimes ones that are at least
> partially specific to particular applications and applications
> protocols.  If there is a message in those things, I think it is
> either that we are not good at predicting which of our
> innovations will be successful and which will not or that, when
> the IETF says "go forth and do X", thee are no guarantees that
> the world will listen.

Well, i think IPsec was an example of things working well in IETF.
They may have overexpected on the range of where it best
fits (and can be completed by host stack/APIs, which always is
the worst dependency of any IETF work), but they (IPsec) folks
AFAIK never tried to stop TLS with arguments like "we must only
have one protocol" or the like, one of the negative syndroms we
have IMHO seen for othre protocols in the IETF. But nothing
the IETF can really do. Just comes when its participants develop
a particular protocol religion or know how their jobs may depend
on a specific protocol.

> And I expect it will be some years more before we actually know
> whether our more recent push toward encryption has helped the
> Internet and its users by increasing privacy or whether pushback
> and reactions from the political and law enforcement sectors
> ultimately result in fragmentation, large-scale interconnection
> problems, and the either development of a lot of ad hoc
> solutions or movement of work to other SDOs because the IETF was
> too stuck on the importance of encryption no matter what.   I
> don't predict that outcome and definitely don't wish for it, but
> I think our architectural work would be improved by more
> recognition of the possibility.

If i limit your "encryption to "(TLS) end-to-end encryption", then
i think there are already a lot of people that have opinions about
the results even visible today.

IMHO, TLS has two main neglected consequences: It has become the
key component of a strategy for revenue supremacy from one part of
the industry, and it has moved the bad behavior (perpass and its
revenue tail) into a layer of the solution (application) where it
is out of the control of the IETF. Or at least out of the scope
of interest of the companies shaping the IETF standards in that
space because they are the beneficiaries of this evolution.

So, the next round of privacy discussion as we already see will
mostly be happening outside the IETF. For better or worse.

This is of course non-withstanding the basic necessities to use
TLS and its benefits.


> best,
>      john
> _______________________________________________
> Architecture-discuss mailing list