[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

Linda Dunbar <ldunbar@futurewei.com> Thu, 27 May 2021 22:51 UTC

Return-Path: <ldunbar@futurewei.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787E13A16EC; Thu, 27 May 2021 15:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 yJAKdMmpDo3m; Thu, 27 May 2021 15:51:31 -0700 (PDT)
Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam07on2131.outbound.protection.outlook.com [40.107.95.131]) (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 10AA63A16EA; Thu, 27 May 2021 15:51:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YpuoCcb0O/eChdIYRNR6sk9B/zBX3w9ncFwFOh/h7nKlc2D5EXZr6RWCx4zkevXKD7JAMJCe4hgq88IOlgkvo/l7vjKH8SDATq8wk2m6xrcF2RzORGTL3TkygbV0VLQvDjOaT7+oT/R+ZjYPx5HuG+VTzLTTTEdYrlJBM0JNmbujdCzOcSC0lrcOLagK0/3xeEWyUBWlE89YXlcmvjJeOnVt4BxMRbtx3IF1/ZJuDF00OlXYE8MsxuhJyrR2M4dmi+05SZKa65mvpUZLd3ntyrQcNrqeDQ/oQVAseFrobG0adfZbypCtgQU0Dp/mJD4RSfD7rjbFpIrl+ZxBU6Ufeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9XICWxuMcCpHx5v7GCUbWIPKB+6PDErPCofONN3OfFA=; b=HsMXrjMI7oivSJHOBf8ovZRnEtz9ui0X0Kahg3vECqjQAQP2Kqqcw3d+V+VBTpzEizOETfabTT/7rlH248rR7hLAs9lb4M6GKJ0p/OqZiBbFuKhgT6OefVzchcGyx0w6KaGibECN30krOeIma/yq4wCy/vAt8pd1A8waxZ1BV+pA6g10L9M9HBM4xsXPGivn7+15tkhFEKjRsnBe9BI9V+7g8gALy0a93yU7aBe++CX7/iQBBz8nZYUoe7DuwXeAbWNuIA1WOofdmYsMmPRWe5WRW9jAltnsUfg7Te0bmUV09zEq1PiTNDFaJfIkDJCyNIbHZ/bpdk6X3OOfzCYmOA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9XICWxuMcCpHx5v7GCUbWIPKB+6PDErPCofONN3OfFA=; b=s/WUtuVlPJLa6aXjNLIoXrdftwb6xcbdwDdu2vZ6wlz94j5rs3b9dREU9HTEj1gIdQF7Q4iLcR7DQAcBT/hfZs4zI7s+BK0dUJgiv5XTC3v+6hBWjOGcPOYcQs/BbSryZPp8tiWiMzZQ7S1J16w7dhOzm9GUzPxuDDdKtmKvI+Y=
Received: from PH0PR13MB4922.namprd13.prod.outlook.com (2603:10b6:510:92::5) by PH0PR13MB4937.namprd13.prod.outlook.com (2603:10b6:510:79::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.12; Thu, 27 May 2021 22:51:26 +0000
Received: from PH0PR13MB4922.namprd13.prod.outlook.com ([fe80::e0bd:a1eb:fcce:c744]) by PH0PR13MB4922.namprd13.prod.outlook.com ([fe80::e0bd:a1eb:fcce:c744%7]) with mapi id 15.20.4173.023; Thu, 27 May 2021 22:51:26 +0000
From: Linda Dunbar <ldunbar@futurewei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "rtgwg@ietf.org" <rtgwg@ietf.org>
CC: "apn@ietf.org" <apn@ietf.org>
Thread-Topic: 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
Thread-Index: AddTStILnyj6Dkg0TeKd5kZUmkwsjA==
Date: Thu, 27 May 2021 22:51:25 +0000
Message-ID: <PH0PR13MB4922A88EFE55FA2398651301A9239@PH0PR13MB4922.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [2603:8081:1700:ab:f19d:c6c7:59c1:7092]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f6c59e89-a953-4d85-762a-08d92161f558
x-ms-traffictypediagnostic: PH0PR13MB4937:
x-microsoft-antispam-prvs: <PH0PR13MB49374A24C6FD96505668DC94A9239@PH0PR13MB4937.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OhgVK5JmM36pcIH2Po3+PH7CQCC29YVy0lFpNf0vobzeVVO5kNy7HSHk45HGW0KbxpcIF5g/CVDWawJVRkD/M8AX2frnpJREo23QlwAbdsQdGv5OAGRp6PNYGuM4XCLO3Npd/BIKb14QMgkdPxt2yJLO2jFuCtDtpRbQKZytFNxioHnqohVeEquqsRgllYWDfmDG9IFbvK81vJq8BBFLi69XO4Kxk+NvAnBMKPUTBCOPKE8Krl9y+yS5jD6v7kj1gMc2u9JEeFnk+1335H5FR1e/s0Xoj53KlgiMq/psVJK0IA7SZsoiZqRTMcr+1bp4v/VZKZmFKZztKtZU5obmilgMfmNPYl9byGQUSMYhziZCwEYIu6TvuzCN3mrxoAiq3b6sjyRBF/TBRugUYNE6MkDm472pD/McSZg0s9aGiaqrVH9f4ptQfttVTckt+9xAaYkkuj2Y8STPjjK5rMb/nSmLmIMr+bNbAHN27LU4BTfPx2v/hDqtaf5PeNddZgGUnOiZ5oZGVUt2MZWZpVSz4TnyZlmx6sKn9250uC+yNGaxqWVsJaltNdp68BCYVKwZszZVvO05CNb6YEfyQyQIpzoo+DvoHvZMN9r+uFk2hFYKUyvFNbnlSSSYNr5VXYoRvbxLmAw6cf0br7SWeOhAoeO6loBfSPmg4xlx061jsQ0QPfrbD/WsqeHBDzRXafonABi7oiqjOizO+ruFpDybDUw2/va48CKr2HDRLN6CqKquXAV+XixDf++BHbWi1iR8IOSW+lPBNouSAtdeHzv7UQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR13MB4922.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39830400003)(396003)(366004)(136003)(376002)(2906002)(316002)(33656002)(186003)(45080400002)(8936002)(4326008)(76116006)(5660300002)(83380400001)(52536014)(66556008)(966005)(38100700002)(64756008)(66446008)(66946007)(66476007)(122000001)(478600001)(66574015)(110136005)(53546011)(86362001)(15650500001)(9686003)(55016002)(7696005)(6506007)(71200400001)(8676002)(141324003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?uTV6WW0blHpUYBqQi01clJKf0iY+qjXp1WVld6NgfpgzOgAusb6A0jv7m5Un?= =?us-ascii?Q?p9WX/TQQRw8P4Ld7sIZUZoC6pyLO9EtFanGCnriCWmKlGrBQayb6kVjbYIhe?= =?us-ascii?Q?/WakjSdHTTX2INpPMVw7/wn/MxxjJq1n1fqwWYaB2SlDDnRb/f0e5fPVz67W?= =?us-ascii?Q?PH8Idj4R+45rFZVb0cyqENG89krxDF/nVcqdWObHV37svKq4SkgCLDTQ2/y+?= =?us-ascii?Q?y2iJw6oN7MTbp4eUFRxLFxRfddeceg+308A3aRbSVjEBC5f5S3NxoovIawIT?= =?us-ascii?Q?IbpwbIjKH7VWjPN5mCbFOq4B6ADABtCYI9kcLbvMBsz0gedwwxmcP+HPMJir?= =?us-ascii?Q?JVaPwXLolmqm+yzWhspEMyJku4oUbJ6xQymNXHbHAWMFJ6ky0vYGM8PFiS4I?= =?us-ascii?Q?XwsOH5mgmu8Xqk7BNUy/B+un+XbAKqcYIJQapkSG41/x1fnJ/YcYngDi01JK?= =?us-ascii?Q?E5+qnQHV/1/biveHthX2/CUStTuHa7NwOz3i5ImmMv3bk3ftArGB60LVIb+k?= =?us-ascii?Q?VSqchjmbniNx4v5x9jM2xJUIajZhlqjVqecmEMyYA6UuU4tMsmxoxoMdYDF+?= =?us-ascii?Q?4Al3pEKVg1QzRKeVfH6/WfZAssaNM53hsVsjud1NNycu9689mNSOy492xSrV?= =?us-ascii?Q?4f7EoNFMHdpxZLNJ2Sb287UWGySfhZB36qS8jPl3v+kZ2qCA8+bMfzORu39x?= =?us-ascii?Q?AIMvzDpNbWHRbblVwZ/YaFvDgc8Yj45b55FmB45jIeoxYxCmw4Lgt8p5ALCt?= =?us-ascii?Q?g8mUPBXcovQDs3h1D0w0u+Orpw1tC/5indYMCbG0zVYEUPed7ixpLNM3FDKo?= =?us-ascii?Q?9GvmuqqS0+ZjCY89WkE0go9h0KhCqCWnk0KvQZ4aytuRO7M9VkB5+KjB0zUv?= =?us-ascii?Q?bO84oWX/omTjO7lhUHTI4gWT7xSSPWuN6REr+7fbMxwIuUIv1zeooJgS2yHD?= =?us-ascii?Q?7rS7HbPxvqeRo1IoXD+XOPZ+voDpDKJTRpZntUvA1lOFzvNOatc6qDRB2v9B?= =?us-ascii?Q?FYqsfBXaf4RGd85QaAwSZloO32d+u4NSk4U3m6qT6IeR2eE2J6FnYIMV7Bp9?= =?us-ascii?Q?2dP81/6FoBTZQ7gNSAZ6JgrcnlTDMTY13HmvDR38ngywUgM6+228OnETT3qz?= =?us-ascii?Q?kew2k/Sen5rP/jEXTO5jaWmguK4+udaPR1sbu5QM/J19ytZQb0gowLTVn+sz?= =?us-ascii?Q?ocakWWnAEf8CyfLV+P2QHSla9FIZZ+m+SSSaASbjN2kxc3NdDjPtvn4xMgt8?= =?us-ascii?Q?4E5enyjkL1i7orjEBoAKaVji5Px0gEd2mLgUYRMhEzT1TPZj1voOTl9I+DIl?= =?us-ascii?Q?UAtISndmoAqVA+XFQu6kPf2gkGN4rElYzkx6QFCqDSqjWtTsP58XGMU4xIOr?= =?us-ascii?Q?icmpx/K2lUoVP4JJLHH7wU4NQkTT?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR13MB4922.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f6c59e89-a953-4d85-762a-08d92161f558
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2021 22:51:25.8856 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: E1JOmH4hG15UwGCweLn9mCykH0UVzcKBabM90KgXZme8C+T1GA72pivKYvpA7JRLgTqWo5iL1nGoGgePLLeMjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR13MB4937
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/IiMxFhl_sY0nSErdbv6FTPrbWow>
Subject: [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-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2021 22:51:36 -0000

Michael, 

Since you have "mostly ignored 5G", here are some real money making business enabled by 5G. 

https://www.youtube.com/watch?v=herCDIhWUnM
https://youtu.be/Gtu11EuCSXw 
https://www.youtube.com/watch?v=ZNQ4c4xeKEg

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. 


My two cents. 

Linda Dunbar

-----Original Message-----
From: rtgwg <rtgwg-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Thursday, May 27, 2021 11:34 AM
To: rtgwg@ietf.org
Subject: Re: Application-Aware Networking (APN) focused interim

On 2021-05-06 6:37 p.m., Jeff Tantsura wrote:
> Dear RTGWG,
> 
> We have scheduled Application-Aware Networking (APN) focused interim 
> (agenda to be published), June 3rd, 2021, 7:00AM PST

Hi, I'm glad that we are having this meeting.
I saw the APN presentations (in recording) at the SECDISPATCH and SAAG, I think it was.

I've been through the documents, and I think that they get lost in the weeds.  What is confusing people, particularly security people, is that we simply don't have a model as to how any of this is supposed to work.
As someone who has mostly ignored "5G", but who survived the "revolution" that was ATM, then diffserv/diffedge, then the MPLS revolution, I feel justified in ignoring the huge oversell that is 5G.

Let me explain why all these things failed to increase operator incomes.
(Did they reduce complexity for some entities? Sure. Did it offer new ways of provisioning networks that weren't available before? Sometimes)

Lack of financial model.  Inherit with this is a TRUST MODEL that includes senders, receivers, requestors and responders.
(Senders transmit data. Requestors ask for data to be sent) In my relationship with, for instance, Netflix, I'm:
   a) the receiver of the data
   b) the requestor of the data
Netflix is:
   c) the sender of the data
   d) the responder to my request

For the operator to get more revenue from me, I have to have a way to give them more money, or a way for me to indicate to the sender of the data that I requested, a way to give the operator money for new services.  (Netflix never pays for the traffic in the end, because I pay them.  This is far more obvious if this is e2e game traffic, or webrtc pandemic conference traffic)

Most of the security questions about whether the *application* or the
*kernel* (of the smartphone), or the Home/LTE/5G router or the 5G tower, etc. is doing some signaling into some 5G thingy... (I'll call it a "VC" 
in ATM speak, because really, it shows why this is a 25+ year failure)

It has all failed due to layer-9 issues.

I still can't ask, (during pandemic) for my carrier or ISP to prioritize traffic that *I* care about for an extra fee.  Anything that involves the ISP or carrier "guessing" is a fail thanks to
   1) invasion or privacy
   2) Net Neutrality
   3) QUIC <-- largely a response to failures of (1) and (2)

Diffserv's "diffedge" (never published as an RFC, alas) got closest to being real.  Windows2000 had an API apparently.  Specifically, it had a way for an application to ask the kernel for additional services.  That failed in the market, because really it had no place to connect to an "operator" ...

Fundamentally, this goes back to the fact that we continue to design networks which are either anonymous or stateful.  The end-to-end principal says keep the state out of the core, and this keeps winning each time we add a zero to core network speed (now with Gbps at the end).  Meanwhile, the telco/mobile space keeps adding more and more state that has to be connected to some identity. (IMEI/SIM/etc.)

We need a situation in the middle where the network actually says who it is to the end-systems, and indicates, via authenticated communication between "middle box"en and end system that the middle box exists, and what services it can offer... "for you my friend? special deal!"

Said middle boxes are in quote, because they aren't NATs, and they don't throttle or firewall traffic, but they can be taught to remark in various directions.

diffedge did this with RSVP, but back in 1998, the secure communication on top of that that is required to establish trust sufficient to enable exchange of currency was just too much for people.

I'm writing this now, a week ahead of the virtual interim in the hope that the proponents will go back to their slides and refocus their effort into explaining to the security and routing people what your goals are.

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg&amp;data=04%7C01%7Cldunbar%40futurewei.com%7C80f90ca33f094b190fcd08d921423eab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637577390709048952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ubk4NU1tIe%2BxtfGh43V3RJ3iYOfKuRmYtoWCuOoHc78%3D&amp;reserved=0