Re: [Apn] why it is necessary to differentiate the security concern for 5G Vertical Networks from the grand Internet ( was RE: Application-Aware Networking (APN) focused interim

Michael Richardson <> Fri, 04 June 2021 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62F793A1863; Fri, 4 Jun 2021 09:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fF0D8Z4ic3wf; Fri, 4 Jun 2021 09:32:11 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4ACA33A1862; Fri, 4 Jun 2021 09:32:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 078D338CE2; Fri, 4 Jun 2021 12:32:38 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id WIiO14tsch6k; Fri, 4 Jun 2021 12:32:34 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id F2A5538C91; Fri, 4 Jun 2021 12:32:33 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 67080C3B; Fri, 4 Jun 2021 12:32:04 -0400 (EDT)
References: <>
From: Michael Richardson <>
Message-ID: <>
Date: Fri, 4 Jun 2021 12:32:04 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Apn] why it is necessary to differentiate the security concern for 5G Vertical Networks from the grand Internet ( was RE: Application-Aware Networking (APN) focused interim
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jun 2021 16:32:13 -0000

On 2021-05-27 6:51 p.m., Linda Dunbar wrote:
> Michael,
> Since you have "mostly ignored 5G", here are some real money making business enabled by 5G.

_New 5G technology 'transforms virtual sport and entertainment viewing'
Was pretty much content-free.  I learnt that I might be able to order 
hotdogs while at the game


5G for Sport	- a bunch of not yet here user interface technologies from 
BT... Google Glasses redux... "Every seat will be the best seat in the 
house"... just pure fantasy for the UI side of things in my opinion. 
But, I'll accept this technological McGuffin for the moment.


Verizon 5G Edge and AWS Wavelength: Changing the experience of 
basketball | Verizon

All about shot-tracker.  They compared 5G to "4G", but not, to for 
instance, wifi6.

> The business model is no longer the traditional monthly subscribers, but more of the Services oriented business model, enabled by dedicated closed-looped or Non-Public Networks (called by 3GPP).
> Those Closed-Looped networks or Non-Public Networks, where APN is more likely to be valuable, have different security concern than the public Internet. It is not Netflix sending traffic across the public Internet and requiring subscribers to pay a premium, which has net neutrality and privacy issues.
> In the Closed Looped Service Network, there is always a Service controller dictating various policies. There are many things that the Network needs to interact with the Service Controller, which is out of the scope of IETF APN. From IETF APN perspective, it needs to achieve optimized forwarding based on the Application characteristics managed by the Application/Service Controller.

Videos 1 and 2 were all about subscribers getting access to content, 
exactly as with netflix, but now all multi-feed, live and in 3D plus 
replays.   I saw nothing about a services oriented business model.
I see that the applications need to very clearly articulate which 
streams they care about, and this needs to go into the network.
(I don't really care if "Netflix" is across the Internet or via private 
peering.  It crosses an AS, and in the virtual interim this fact was 

The shot-tracker situation sounds like some kind of local 5G deployment 
at the basketball team training facility replacing, I guess, wifi. I'm 
unclear why there is any data going offsite ("edge computing" is 
mentioned a lot).... but maybe there is some AWS connection.  But, given 
that the whole facility is wired, I don't see why fiber can't provide.

So all my points remain: if end-user devices are involved (up to the 
application in order to know which QUIC streams are which), then we need 
a trust model between the devices and the Service Controller.  The lack 
of this trust model is why all the previous efforts have failed. 
Rejigging the L2 encoding won't change this.

Getting that trust model in place would be truly revolutionary.
Not only could I pay for better bandwidth when I need it, but I could 
also "unpay" for nuissance traffic and have it blocked upstream.
DOTS has gotten a lot way towards this, but it depends somewhat upon the 
home routers being provisioned by the ISP, and does not include end 
devices as yet.